On Tue, 2008-11-11 at 18:44 -0500, Peter Memishian wrote: > So am I missing something here, or do none of the primitives in > snoop_filter.c know about IP observability devices? For instance, > I tried to use "snoop -I ipmp0 dhcp", which didn't work -- but > "snoop -I ipmp0 udp port 67 or udp port 68" worked fine. Looking at > snoop_cature.c, it seems that most of the cases in primary() assume > a link-layer header (indeed, many of the options make no sense *without* a > link-layer header) and thus get confused.
As far as snoop is concerned, the ipnet header is the link-layer header. I'll need to look further into this, but it doesn't seem to be broken for all filters. For example, the following works just fine: bash-3.2# snoop -I bge0 -U tcp port 22 Using device ipnet/bge0 (promiscuous mode) strat.East.Sun.COM -> whitestar1-6.East.Sun.COM TCP D=22 S=64519 Syn Seq=2995106985 Len=0 Win=49640 Options=<mss 1460,nop,wscale 0,nop,nop,sackOK> whitestar1-6.East.Sun.COM -> strat.East.Sun.COM TCP D=64519 S=22 Syn Ack=2995106986 Seq=3047980435 Len=0 Win=49640 Options=<mss 1460,nop,wscale 0,nop,nop,sackOK> (-U forces user-space filtering) Something seems to be broken with some set of filters, but not all. On a related note (but not exactly this problem), kernel filters are in fact broken, and the fix that I'd like to RTI (asap) is: http://zhadum.east/ws/seb/seb-onfix/webrev/ This has a good chance to muck up some tests in PIT, so I'm considering asking the ON c-team to respin 103 with this fix... Phil has already reviewed the fix, but I wouldn't refuse additional reviewers. -Seb
