kemon icon indicating copy to clipboard operation
kemon copied to clipboard

UDP filter is always not filtered in sflt_data_in and sflt_data_out

Open LittleLydia opened this issue 5 years ago • 4 comments

it seems that entry->ump_ipv4_attached is always false in the two call-back functions: sflt_data_in and sflt_data_out

LittleLydia avatar Feb 25 '20 10:02 LittleLydia

Always false? Let me check it. btw, what version of macOS are you using? If you are using macOS 10.15, you can find here that the sflt_* APIs are deprecated, including: sflt_register, sflt_unregister, sflt_attach and sflt_detach. https://developer.apple.com/support/kernel-extensions/

keenjoy95 avatar Feb 25 '20 14:02 keenjoy95

"udp_ipv4_attached" is always false means sflt_attach_udp_ipv4 / sflt_register initialization failed: https://github.com/didi/kemon/blob/master/kemon/network.c#L230

Can you see the error message from this UDP branch? https://github.com/didi/kemon/blob/master/kemon/network.c#L2060

keenjoy95 avatar Feb 25 '20 14:02 keenjoy95

"udp_ipv4_attached" is always false means sflt_attach_udp_ipv4 / sflt_register initialization failed: https://github.com/didi/kemon/blob/master/kemon/network.c#L230

Can you see the error message from this UDP branch? https://github.com/didi/kemon/blob/master/kemon/network.c#L2060

Always false? Let me check it. btw, what version of macOS are you using? If you are using macOS 10.15, you can find here that the sflt_* APIs are deprecated, including: sflt_register, sflt_unregister, sflt_attach and sflt_detach. https://developer.apple.com/support/kernel-extensions/

The MacOS version I am using is 10.13.6.

It was always true in sflt_attach_udp_ipv4 call back, but whenever it comes to callback sflt_data_in and sflt_data_out, the value becomes false. Well, the tcp call back is right.

LittleLydia avatar Feb 26 '20 00:02 LittleLydia

I think you have added some redundant checks in your code when dealing with the udp handling. I found out that in network.c, some native udp request or requests with source port being 0 or dst port being zero. And entry->info.first_in_packet isn't null after the first callback. so this check if (!entry->info.first_in_packet) is superfluous.

LittleLydia avatar Mar 06 '20 08:03 LittleLydia