Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UDP filter is always not filtered in sflt_data_in and sflt_data_out #4

Open
LittleLydia opened this issue Feb 25, 2020 · 4 comments
Open

Comments

@LittleLydia
Copy link

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

@keenjoy95
Copy link
Collaborator

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
Copy link
Collaborator

"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

@LittleLydia
Copy link
Author

LittleLydia commented Feb 26, 2020

"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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants