On Wed, 2008-10-22 at 23:58 -0400, Peter Memishian wrote: > > Snooping while connected to the Sun WiFi networks results in hundreds of > > martian packets being bombarded at the system. It turns out that the ip > > module actually doesn't do all of the inbound martian packet checks that > > the ipnet_accept() function was ASSERTing should never make it up the > > stack. This resulted in the following ASSERT() panic when we received > > an IPv4 packet with a multicast source address: > > > > 6762537 martian ASSERT() failure in ipnet_accept() is too aggressive > > > > I'm removing the ASSERT() in ipnet_accept(), as we're not in a position > > at this point to go and fix ip to make all of the proper martian packet > > checks that it should have been doing. The webrev is here: > > > > http://zhadum.east/ws/seb/seb-ipobs/webrev.martian/ > > I'm confused why the code was changed to accept these martians, rather > than ignoring them. Is the thinking that since IP got them, we should > hand them off to snoop? And has a bug been logged on IP allowing these > martians to float up the stack? If not, seems like one should as these > martians may lead to unexpected behavior and perhaps security issues.
My intent is to file a bug against IP (and I'm doing that now), as it's probably not a good thing that it's letting these go up to the fanouts. They're relatively harmless since they'll get dropped eventually, and maybe that's why there are no explicit checks early in the data-path. I don't know if this is deliberate (for performance maybe?), and that's why I don't want to fix IP here and now to appease an unnecessary check in ipnet. I chose not to drop these in ipnet simply because IP is in fact receiving and processing them, and ipnet is meant to transparently offer observability into the packets at the IP layer. -Seb
