Messages in this thread | | | Date | Tue, 24 Nov 1998 21:29:24 -0300 | From | Juanjo Ciarlante <> | Subject | Re: Oops in 2.1.129 |
| |
Hi Paul! On Tue, Nov 24, 1998 at 12:33:52PM +1130, you wrote: > In message <19981119212856.A447@osiris.ml.org> you write: > > 2.1.129 get a Null Pointer Dereference followed by an oops, followed by a > > panic when I enable ip_forwarding under 2.1.129 with masquarading ipchains > > rules present. > > This is due to a bug in ip_masq.c:proto_doff() handling of th->doff. Its fixed in pre-2.1.130-2.
Anyway, although now it correctly checks th->doff bounds, it DOESN'T change bogus ip_masq behavior when handling fragments (only iff CONFIG_IP_ALWAYS_DEFRAG=n).
> > This trace is currupted: cleanup() is a leafnode. It's almost > certainly the masq code barfing on a fragment. While that *shouldn't* > happen, it doesn't surprise me since few people do this. > > Juanjo, how about this patch for 2.2: > --- linux/net/ipv4/Config.in.~1~ Mon Oct 5 02:51:45 1998 > +++ linux/net/ipv4/Config.in Tue Nov 24 12:27:34 1998 > @@ -32,11 +32,13 @@ > fi > fi > bool 'IP: transparent proxy support' CONFIG_IP_TRANSPARENT_PROXY > - bool 'IP: always defragment' CONFIG_IP_ALWAYS_DEFRAG > + bool 'IP: always defragment (required for masquerading)' CONFIG_IP_ALWAYS_DEFRAG > fi > fi > if [ "$CONFIG_IP_FIREWALL" = "y" ]; then > - bool 'IP: masquerading' CONFIG_IP_MASQUERADE > + if [ "$CONFIG_IP_ALWAYS_DEFRAG" != n ]; then > + bool 'IP: masquerading' CONFIG_IP_MASQUERADE > + fi > if [ "$CONFIG_IP_MASQUERADE" != "n" ]; then > comment 'Protocol-specific masquerading support will be built as modules.' > bool 'IP: ICMP masquerading' CONFIG_IP_MASQUERADE_ICMP
Mhhh... I should prefer a more drastic if (MASQ==y) then DEFRAG=y ... just to avoid "What happened to masq option?? it desappeared!" spaming :>
Another way may be #ifdef approach (like TRANSPARENT_PROXY in ip_input.c), which has the same result as above, except that .config will still show DEFRAG=n.
Another (the best IMO) would be to call ip_defrag() is ip_fw_masquerade() output path (input path is Ok, already ALWAYS defragged in ip_local_deliver); I don't know "context funnies" that could arise if ip_defrag() is called inside ip_masq.o ...
So, for "fast,around-the-corner-2.2" I should select 1st or 2nd approach.
Regards... -- -- Juanjo http://juanjox.home.ml.org/
== free collective power ==---. Linux <------------'
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |