Harald Welte writes: > the counter argument is that the queue is part of the lower-layer drivers > and not part of the IPv4 stack. netfilter hooks are always restricted > to one protocol stack - there's separate hooks for ipv4, ipv6, ipx, ...
This seems more a psychological than technical argument. Is there some reason the lower level can't be interleaved in execution order with the upper level? Or is it more related to the files? You want NF_HOOK to be called by ip_output but not by dev.c ? The single protocol stack I guess means that my original question really only applies to ipv4, so the code I propose to add to dev.c should test for ipv4 first. If the complaint is then that it's ugly for dev.c to depend on ipv4 stuff, the fix would be to generalize this to a new "after-dequeue" hook, and have ipv4 register its postrouting function there. > > I understand why dnat has to be done pre-routing. I don't see why > > snat couldn't also be done there. > > theoretically, yes. but then you wouldn't be able to match on the original > source of the packet anymore (imagine the standard masquerading case, > you wouldn't be able to distinguish your individual clients, because all > the source adresses have already been overwriten). This raises another general point. There are lots of cases where a certain thing has to be done in a certain place cause that's where the data is available. At the moment, there are things that just can't be done cause they require two pieces of data that are not both available at the same time, e.g., input device and output device. When you want to do something like that you end up adding kernel code to save the old data so you can use it later. I think in general it would be worth while to save more of this data for use in later hooks. So I think that nat should save the original data just for use in later hooks.
