Nflog support MVP #48
Conversation
|
Linking here #37, the macros... |
|
CI can't compile libc :-(. |
|
Note to self. I've just discovered methods like |
|
Restarting CI here too. |
|
CI is fixed. |
src/socket.rs
Outdated
| @@ -336,9 +336,9 @@ impl NlSocket { | |||
| Some(ref mut b) => Nlmsghdr::deserialize(b)?, | |||
| None => unreachable!(), | |||
| }; | |||
| if self.pid.is_none() { | |||
| if self.pid.is_none() && msg.nl_pid != 0 { | |||
There was a problem hiding this comment.
Please move the socket changes into a separate PR. I'm happy to merge those before this one. I agree that PID tracking is very broken and I'm looking to fix that in v0.5.0 but am happy to turn this off for now in another PR.
There was a problem hiding this comment.
OK, I've submitted the commit as #57. It's the same one, so it should disappear from the diff here once that one is merged into master.
There was a problem hiding this comment.
Excellent thank you! I want to think through that one a little more before merging, hence the separate PR. Once we figure that out, I'll ask you to rebase onto master so that you pull in whatever we decide on and then I'll merge this one.
|
Hi @vorner, thanks for your other contribution. I've merged that PR so can you rebase onto master and force push here? I'll do one final review before merging. |
Support receiving packets from the kernel over nflog. Some parts are not yet implemented ‒ conntrack integration, hardware headers... Closes jbaublitz#38.
Nfnetfilter log This adds the constants from linux/netfilter/nfnetlink.h and nfnetlink_log.h. These are the files I need for jbaublitz/neli#48. After this gets in, I'd like to follow-up with the other nfnetlink_*.h files too, as I'd like to extend neli with further protocols in the future, but I want to do a smaller PR first to see if there are some things to tweak. I've noticed similar netfilter constants are also in the android subfolder, therefore I'm adding them there too (I don't like the copy-pasting, but it seems the other ones are already copy-pasted). I assume the test will catch it if anything is different on that platform.
Nfnetfilter log This adds the constants from linux/netfilter/nfnetlink.h and nfnetlink_log.h. These are the files I need for jbaublitz/neli#48. After this gets in, I'd like to follow-up with the other nfnetlink_*.h files too, as I'd like to extend neli with further protocols in the future, but I want to do a smaller PR first to see if there are some things to tweak. I've noticed similar netfilter constants are also in the android subfolder, therefore I'm adding them there too (I don't like the copy-pasting, but it seems the other ones are already copy-pasted). I assume the test will catch it if anything is different on that platform.
Hello
This adds the support for basic use of the nflog protocol. There are still some parts missing, but I'd prefer to have a feedback about it sooner than later and I tried to make sure all the missing pieces can be added without breaking API.
I've also tried to structure it in a way that makes it possible/natural to add all the other netfilter protocols over time (NFQUEUE, CONNTRACK).
There are, however, few things I'm not entirely happy about or don't know how to handle properly. I'll probably open separate issues to discuss them one by one, if there's some nice solution for them. But I'll still list my worries here first.
NetfilterMsgenum, but that would still not help much, because it would still try to deserialize the rest asLogPacket. This doesn't currently fail, but is kind of wrong. It would be great if I could somehow specify a nl-type => parse type relation. UnlikeNlAttr<_, Vec<u8>>, the Nlmsghdr<_, Vec>` doesn't have methods to parse as one or another type.serializefor theLogPacket. For now, I've putunimplementedin them, but it kind of doesn't feel right. Would it make sense to split the Nl trait into reading and writing halves?Vectype quite generously. For example, when parsing a message, it allocates a Vec as the receive buffer, then it allocates a Vec for all the attributes and, as they have diffferent types, each one is a smaller Vec... As the Vec contains a heap allocation, it might turn somewhat expensive. This probably doesn't matter for things like manipulating the routing table, but with the NFLOG, the number of packets received per second can be quite huge. It would be great if there was a way to use the library with smaller number of allocations (some of my ideas could get down to 0 per packet).impl_*macros don't want to let me put documentation onto the individual variants. I've tried to poke at them a little bit, but I've managed to only break existing code, so I've given up for now.Anyway, if I'm missing anything important here, or if there's any way to improve the code or interface, I'm happy to hear it. I'd then add some fixup commits and rebuild the branch before merging.