On Mon, 2009-12-14 at 12:24 -0800, Garrett D'Amore wrote: > Sebastien Roy wrote: > > Snoop was able to deal with such packets and decode them just fine. > > Wireshark and tcpdump, however, are much more picky and do not decode > > such packets. We need to fix this case. > > > > One idea I had was to have an optional MAC-type plugin callback to > > process MAC headers on transmit. The mac_ipv4, mac_ipv6, and mac_6to4 > > plugins would use this callback to fill in the length field. This would > > be the most simple option. I don't think that ignoring that the problem > > exists in an option. :-} > > > > If snoop can deal with it, but tcpdump and wireshark can't, can they be > fixed?
It's unclear, but likely not. Those tools treat these packets as erroneous (and have good reason to) and print warnings that users might depend on to flag bogus packets on the wire. I'd be weary of changing this simply because of some Solaris implementation artifact. > A type-specific solution, that coordinates with the tunneling code or > plugins might work; I just don't really want to see yet another > "if-this-poiner-is-set then execute through it" sort of branch added > (especially to shared hot code paths) if we can help it. Every branch > added has a measureable negative impact on the total packets-per-second > that Solaris can drive using small MTUs. (And hence negative impact on > VoIP, routing, and other non-TCP based applications.) Perhaps this solution could be prototyped and performance tested. -Seb _______________________________________________ networking-discuss mailing list networking-discuss@opensolaris.org
