On Mon, 2009-12-14 at 08:22 -0800, Garrett D'Amore wrote: > Darren Reed wrote: > > One option to handle this would be to have a function that could be > > called by mac to "fill in" the header details before the packet is > > delivered > > to the promiscuous callback. > > > > Another option is to not deliver the packet to the promiscuous callback > > from GLD, but from the driver itself, after the driver has finished > > filling > > in the header - a delayed promiscuous callback. > > > > My prefernce is for the latter approach as the changes do not appear to > > be as frought as the former. > > I don't think this is a good plan. Adding a lot of complexity for the > snoop case seems like it will be painful... there are no "completion" > callbacks in the networking framework today, so upper layers know > nothing about when a packet is completed. (The underlying driver just > calls freemsg(), but all that means is that it no longer needs the > original msgb. The data may have been copied into another buffer, e.g. > msgpullup, etc. So it might not have been modified yet, etc.) > > All of the various test cases associated with the upteen bazillion > different ways of monitoring network traffic (snoop, packet filter, > packet events, socket filter, etc. ... I can't keep track) seem to me to > just add complexity and reduce performance by adding test cases on hot > code paths. I'm loathe to see yet another special case added for an edge > monitoring case, at least not without a compelling reason why this new > one is needed. (And knowing that we can't solve the problem generically > for hardware devices, adding a special case for software devices seems > questionable to me.) > > One more note: promiscuous mode transmits are *not* guaranteed to work > on all hardware. For example, PRISM WiFi devices are physically > incapable of transmitting while in promiscuous mode.
This is all well and good, but there is actually a problem that needs solving. The outer IP header used in tunneling is stored in the IP fast-path for transmit on IP tunnel links. The length field is obviously uninitialized in fast-path headers since each packet transmitted using the fast-path will have different lengths. The iptun driver currently fills in the length prior to transmitting each packet to the lower IP instance, but that occurs after the promiscuous transmit loopback path. 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. :-} -Seb _______________________________________________ networking-discuss mailing list networking-discuss@opensolaris.org
