Sebastien Roy wrote:
> 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. :-}
>
If snoop can deal with it, but tcpdump and wireshark can't, can they be
fixed?
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.)
-- Garrett
