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-disc...@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss
_______________________________________________
networking-discuss mailing list
networking-discuss@opensolaris.org
