Would it perhaps not be preferable to debug using a program that registers just one socket?
By the way, are there any sockets created by kmod-appletalk
as well? Maybe not important, I guess we could just unload that module while testing.
Awesome, would love to compare frames and verify that they do not get mangled by DSA or what not, however unlikely. And would love to tcpreplay
them into my own Marvell DSA switch.
If the function tracer turns out to be more trouble than it's worth, put it on the back-burner?
There are other options if we need tracing. For example a more modern BPF tracer.
I personally quite like ply.
It should be a much easier build than a whole kernel.
(In fact, it would be really nice to have an opkg / apk for ply, I might attempt that at some point.)
More dumb ideas:
+ make lanX into a standalone interface by removing it from the bridge, test again
As long as the interface is a DSA master, inbound frames will not actually reach any socket bound to a DSA master interface, frames being handled by DSA instead and what not. Any outbound datagrams could end up being dropped by switch hardware because it's missing the DSA tag.
But sure, it's possible, just bind to the DSA master interface (ethX) instead of the DSA user interface (lanX).
Is there any reason to suspect that atalkd
wrongly binds a socket to ethX
rather than lanX
?
An unaware application can still bind to a DSA master interface that carries proprietary-tagged frames rather than EthernetII or 802.3 frames; just a question of code in question happening to have a setsockopt(, SOL_SOCKET, SO_BINDTODEVICE, )
call or something similar.
Since the DSA master interface runs on top of a completely standard eth driver. DSA just hooks in to grab the frames for detagging, and then it uses a side-channel to tell the switch to start tagging stuff.
Haven't tried but you could probably unload the DSA module, and it should tell the switch to stop tagging.
In that case, the interface would probably start working like a normal port in the hardware switch, and having a socket bound to it would be a perfectly sane thing to do.
The "unaware application" probably won't know whether one told it to bind to ethX because one disabled the DSA module and it's just a port in a switch now. Or if one told it to bind to ethX by mistake while DSA is mastering the interface and tagging is on.