Subject: IFF_SIMPLEX and multicast
To: None <email@example.com>
From: Ben Harris <firstname.lastname@example.org>
Date: 04/06/2001 17:14:54
[ Please CC me on replied -- I'm not yet subscribed to tech-net ]
A week or two ago, you may remember I was having fun making a SEEQ 8005
survive IPv6 DAD. I've dealt with all the really serious bugs in that
driver, so I can now get back to this one.
The problem seems to be that the 8005's receiver sees its own outgoing
packets (subject, of course, to the normal filters it applies to
reception). The IFF_SIMPLEX flag (or rather, its absence) seems to be
intended to allow me to communicate this fact to the rest of the kernel,
but it doesn't seem to work correctly.
As far as I can see, the only uses of IFF_SIMPLEX in if_ethersubr.c are to
ensure that broadcast packets transmitted over an IFF_SIMPLEX interface
are fed back into the kernel's receive path. Multicast and unicast
packets don't get this special treatment even if they're to addresses the
local system is listening for.
A consequence of this seems to be that the rest of the network system
(which seems to ignore IFF_SIMPLEX) doesn't expect to get its own
multicast and unicast packets echoed back to it, so when (on a
non-IFF_SIMPLEX interface) they do, it gets confused.
To me, the obvious solution is to get ether_output() to spot all outgoing
packets that we should receive, and to loop them back if IFF_SIMPLEX is
not set. I suspect this would confuse the rest of the kernel, though, and
there may be good reasons for the way things currently work.
Ben Harris <email@example.com>
Portmaster, NetBSD/arm26 <URL:http://www.netbsd.org/Ports/arm26/>