-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I have an ADSL (PPPoE) router running oi_148. Over the last couple I've
days I've been trying to track down an odd network problems: sometimes,
when two packets arrive close together, the second packet would be
dropped. The problem would appear for a few minutes, then disappear,
seemingly randomly.
Dan McDonald was able to trace the drop to ire_recv_forward_v4();
specifically, the packet had MAC_ADDRTYPE_MULTICAST set, so it was
dropped ("l2 multicast not forwarded");
After examining the code, I believe the problem is as follows:
ip_mdata_to_mhi is responsible for receiving the IP packet, and looking
at the Ethernet frame to determine if it's a broadcast/multicast packet,
based on the broadcast bit in the destination address. It assumes the
data is structured as follows:
<Ethernet header> -> [optional VLAN headers] -> <IP packet>
To find the Ethernet header, it first looks directly before the IP
packet (line 7836). If the ethertype field is neither ETHERTYPE_IP nor
ETHERTYPE_IPV6, it assumes there's a VLAN header, shifts the pointer 4
bytes backward, and starts again.
However, in the PPPoE case, the Ethernet frame looks like this:
<ethernet header> -> <pppoe header> -> <ppp header> -> <IP packet>
This frame format is passed unmodified to ip_mdata_to_mhi (I have
confirmed this using DTrace). It therefore looks at the PPP header for
the ethertype, doesn't find one, and starts scanning backwards over junk
data (the PPPoE header) until it finds a match -- i.e., two bytes which
are either ETHERTYPE_IP or ETHERTYPE_IPV6. In most cases, it never
will, so it returns (line 7837) without marking the packet as multicast.
However, sometimes (effectively randomly), it will find what it thinks
is an ethernet header, and then try to interpret the garbage data as the
ethernet dst address. If the garbage happens to have the right bit set,
it will mark the packet as multicast, and it will be dropped in
ire_recv_forward_v4.
I believe the fix is for sppp (or sppptun) to mark the packet as IFT_PPP
rather than IFT_ETHER. This would cause ip_mdata_to_mhi to ignore it
entirely, and since at this point the PPPoE frame cannot be multicast or
broadcast, there would be no loss of functionality.
- river.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (SunOS)
iEYEARECAAYFAk2Cfw4ACgkQIXd7fCuc5vIW+ACdFBOhk4U3N3pxl2TI7yENqWou
M8MAmweNDWGePAzFpPXMF7mxmDeo6WXC
=e3bF
-----END PGP SIGNATURE-----
_______________________________________________
networking-discuss mailing list
networking-discuss@opensolaris.org
