Difference between vlan pseudo interfaces and physical interfaces?

[Hauke Fath]

Hi,

are there any differences in application between vlans and physical
network interfaces when it comes to non-IP protocols?

I just rototilled my home network for a vlan capable switch, and found
that the Netatalk 2 atalkd refuses to work with vlan interfaces:

# kdump
[...]
19528 1 atalkd CALL ioctl(4,SIOCGIFADDR,0x7f7fffdbb950)
19528 1 atalkd GIO fd 4 wrote 144 bytes

"vlan11\0\0\240h\M-}\M-Q\^Cs\0\0\M^@p\M^@\M-Q\^Cs\0\0\M-VV\M--\M-Q\^Cs\0\0\M^H\M-9\M-[\M^?\^?\^?\0\0\0\^P\0\0\0\0\0\0\M-8\^^I\M-Q\^Cs\0\0\M-8\^^I\M-Q\^Cs\0\0\^A\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\

\^A\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\^A\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\^A\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\^A\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
19528 1 atalkd RET ioctl -1 errno 49 Can't assign requested
address
[...]

-- is atalkd being too picky here, or is there a fundamental
incompatibility for ddp packets?

Cheerio,
Hauke

[Mouse]

Post by Hauke Fath
are there any differences in application between vlans and physical
network interfaces when it comes to non-IP protocols?

You may have found one (but also may not; see below). In my opinion
there should not be any, excepting being capable of being the
underlying interface for a vlan instance, and that much only because
(AIUI) 802.1q is broken (it doesn't do vlan-in-vlan the sensible way).

Post by Hauke Fath
I just rototilled my home network for a vlan capable switch, and
found that the Netatalk 2 atalkd refuses to work with vlan
19528 1 atalkd CALL ioctl(4,SIOCGIFADDR,0x7f7fffdbb950)
19528 1 atalkd RET ioctl -1 errno 49 Can't assign requested address

I don't know Appletalk. But it does occur to me that vlans do one
thing that, while entirely permissible, is rare, and thus may not have
been correctly handled by the atalkd authors: it uses the same MAC as
its underlying interface. It is entirely permissible for multiple
interfaces on the same host to use the same MAC (provided, of course,
they're not connected to the same Ethernet-level addressing domain -
approximately, the same broadcast domain), and indeed some OSes do that
on some Suns where the MAC a property of the machine rather than the
interface hardware. But it is comparatively rare, especially in the
peecee world, and, depending on how AARP is implemented, it might break
the NetBSD EtherTalk implementation.

It might help debug this if you try real interfaces which support
setting the MAC, and configure two of them to use the same MAC. If you
can, of course.

Mind you, I don't see why a failure would show up as SIOCGIFADDR
errors. Personally, I'd treat this as a routine debugging task: is
atalkd broken, is the underlying system broken, or is atalkd doing
something that isn't necessarily expected to work (like expecting all
interfaces' MACs to be distinct)?

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Robert Swindells]

Post by Hauke Fath
are there any differences in application between vlans and physical
network interfaces when it comes to non-IP protocols?
I just rototilled my home network for a vlan capable switch, and found

[snip]

Post by Hauke Fath
-- is atalkd being too picky here, or is there a fundamental
incompatibility for ddp packets?

Have you tried building the kernel with the NETATALKDEBUG option ?

I would try adding some more debug to find out where the EADDRNOTAVAIL
is being generated.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Hauke Fath]

Post by Robert Swindells

Post by Hauke Fath
-- is atalkd being too picky here, or is there a fundamental
incompatibility for ddp packets?

It looks like atalkd is getting an error as soon as it tries to use the
interface name it extracted from atalkd.conf, so...

Post by Robert Swindells
Have you tried building the kernel with the NETATALKDEBUG option ?

... that sounds like a good idea.

Cheerio,
Hauke

[Hauke Fath]

Post by Hauke Fath
I just rototilled my home network for a vlan capable switch, and found

On the command line, it says

# ktrace -di /usr/pkg/libexec/netatalk/atalkd -f
/etc/pkg/netatalk/atalkd.conf
vlan11: Invalid argument
Can't configure multicast.
#

[Hauke Fath]

[A duplicate MAC] is comparatively rare, especially in the
peecee world, and, depending on how AARP is implemented, it might break
the NetBSD EtherTalk implementation.
It might help debug this if you try real interfaces which support
setting the MAC, and configure two of them to use the same MAC. If you
can, of course.

Good thinking, but no. I have a second (now unused) re(4) in the
machine, and set its MAC to the main interface's, then started atalkd
on it without a problem.

Cheerio,
Hauke

[Hauke Fath]

Post by Hauke Fath
19528 1 atalkd RET ioctl -1 errno 49 Can't assign requested
address

This is actually a red herring: atalkd basically checks if the
configured network interface supports appletalk, all errors but ENODEV
are ignored here.

The actual failure happens during multicast setup, where an appletalk
datagram socket is created, and the ioctl SIOCADDMULTI on it fails.

Are vlans supposed to work with multicast, identically to physical
interfaces?

Cheerio,
Hauke

[Manuel Bouyer]

Post by Hauke Fath

Post by Hauke Fath
19528 1 atalkd RET ioctl -1 errno 49 Can't assign requested
address

This is actually a red herring: atalkd basically checks if the
configured network interface supports appletalk, all errors but ENODEV
are ignored here.
The actual failure happens during multicast setup, where an appletalk
datagram socket is created, and the ioctl SIOCADDMULTI on it fails.
Are vlans supposed to work with multicast, identically to physical
interfaces?

Yes. I do use mdnsd in such a setup, for example.

[Mouse]

[...] the appletalk multicast (actually: broadcast?) MAC address [...]
=09 * 09:00:07:ff:ff:ff
=09 * AppleTalk ethernet broadcast address

That may be broadcast in an EtherTalk sense, but from an Ethernet
perspective it is a non-broadcast multicast address.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mouse]

[I've deleted what I think are incorrectly-inserted line breaks]

lo0: ioctl SIOCADDMULTI on appletalk datagram socket failed: Address family not supported by protocol family
vlan11: ioctl SIOCADDMULTI on appletalk datagram socket failed: Invalid argument
where EINVAL is a very generic error, and I haven't the slightest
idea how to track down the origin. I looked at if_vlan.c, but its
multicast routine does not appear to be the culprit.
Any hints?

What I'd probably do in this case is to add printfs to every error path
I can find in the generic network-interface ioctl code to see which
path is erroring. Then remove those printfs and add printfs inside the
code which is failing. If a call is through a pointer, then print the
pointer and compare it against the symbol table to see what function to
add the next set of printfs to. I'd drill down this way until I found
some relevant difference between the real-hardware and vlan code paths.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Hauke Fath]

Post by Mouse

Post by Hauke Fath
Any hints?

What I'd probably do in this case is to add printfs to every error path
I can find in the generic network-interface ioctl code to see which
path is erroring.

That's what I figured, and what I started to do (without success) in
if_vlan.c.

Post by Mouse
Then remove those printfs and add printfs inside the
code which is failing. If a call is through a pointer, then print the
pointer and compare it against the symbol table to see what function to
add the next set of printfs to. I'd drill down this way until I found
some relevant difference between the real-hardware and vlan code paths.

Looks like this text adventure does not come with cheat codes...

I'll keep digging.

Cheerio,
Hauke

[Robert Elz]

Date: Sun, 13 Sep 2020 22:50:53 +0200
From: Hauke Fath <***@Espresso.Rhein-Neckar.DE>
Message-ID: <***@Espresso.Rhein-Neckar.DE>

| Are vlans supposed to work with multicast, identically to physical
| interfaces?

Yes, and if they didn't, v6 wouldn't work on them.

kre


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Hauke Fath]

Post by Manuel Bouyer

Post by Hauke Fath
Are vlans supposed to work with multicast, identically to physical
interfaces?

Yes. I do use mdnsd in such a setup, for example.

I should have been clearer: AppleTalk uses ethernet multicast, not ip
multicast. Maybe that makes a difference?

Cheerio,
Hauke

[Manuel Bouyer]

Post by Hauke Fath

Post by Manuel Bouyer

Post by Hauke Fath
Are vlans supposed to work with multicast, identically to physical
interfaces?

Yes. I do use mdnsd in such a setup, for example.

I should have been clearer: AppleTalk uses ethernet multicast, not ip
multicast. Maybe that makes a difference?

IP multicast uses ethernet multicast, so the interface is capable of
doing it.
I suspect the issue is more in the appletalk layer.

[Hauke Fath]

Post by Manuel Bouyer

Post by Hauke Fath

Post by Manuel Bouyer
Yes. I do use mdnsd in such a setup, for example.

I should have been clearer: AppleTalk uses ethernet multicast, not ip
multicast. Maybe that makes a difference?

IP multicast uses ethernet multicast, so the interface is capable of
doing it. I suspect the issue is more in the appletalk layer.

Either that, or the if_vlan driver missing appletalk specific bits...

I have broken down the relevant Netatalk code bits to the attached -
essentially, create an appletalk socket, and attempt to set the
appletalk multicast (actually: broadcast?) MAC address on it.

This gives:

[***@pizza] /<2>src/atalk_multicast # ./atalk_multicast -i lo0
lo0: ioctl SIOCADDMULTI on appletalk datagram socket failed: Address
family not supported by protocol family
[***@pizza] /<2>src/atalk_multicast # ./atalk_multicast -i vlan11
vlan11: ioctl SIOCADDMULTI on appletalk datagram socket failed: Invalid
argument
[***@pizza] /<2>src/atalk_multicast #

where EINVAL is a very generic error, and I haven't the slightest idea
how to track down the origin. I looked at if_vlan.c, but its multicast
routine does not appear to be the culprit.

Any hints?

Cheerio,
Hauke

[i***@netbsd.org]

Hi,

Post by Hauke Fath
I should have been clearer: AppleTalk uses ethernet multicast, not ip
multicast. Maybe that makes a difference?

Can't. IP multicast and IPv4 multicast are both translated to Ethernet
multicasts.

-is

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de