Darren Reed wrote: > At present the delivery of packets, on the transmit side, to promiscuous > receivers is handled by GLD before the packet is handed to the driver. > > In some cases the driver makes few, if any, changes to the packet (such > as ethernet) but in others (such as IP tunneling), substantial changes > are > made. > > The problem is most easily seen when using a tool such as snoop on a > network interface that is doing hardware checksum offload: checksum > validation of the IP or TCP headers by programs such as snoop fails. > > For network devices where the updates to header fields in the packet > are made by hardware, there is little that we can do to improve the > situation. > > But this does not apply to network devices such as the IP tunnel device. > > 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. -- Garrett > > Thoughts? > > Darren > > _______________________________________________ > crossbow-discuss mailing list > crossbow-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss
