Ticket #66 (closed defect: fixed)

Opened 5 years ago

Last modified 4 years ago

Avahi can not send queries on FreeBSD VLAN Interfaces

Reported by: lathiat Owned by: lennart
Milestone: Avahi 0.6.22 Component: avahi-core
Keywords: Cc:

Description

It appears that Avahi does not operate correctly with VLAN interfaces on a FreeBSD setup

It can receiving information passively but outgoign queries are not recorded.

The reporter is able to use Avahi normally on non-vlan interfaces successfully on the same machine.

See this thread for discussion http://lists.freedesktop.org/archives/avahi/2006-October/000904.html

Change History

Changed 5 years ago by lathiat

  • milestone Avahi 0.7 deleted

Changed 5 years ago by lennart

This really smells like a FreeBSD issue to me.

Changed 5 years ago by lennart

I am sorry, we cannot do anything about this, since none of use Avahi maintainers is a FreeBSD guy. If this is still a problem, please contact the FreeBSD ports maintainer of Avahi.

Might be related to the newly created #114.

Changed 4 years ago by zml

It looks to me like the pcap code in autoipd isn't using the correct size for VLAN packets, but I'm not comfortable enough with pcap to fix it (yet).

Changed 4 years ago by zml

Ignore my previous comment. However, I just opened ticket #163, which may explain this bug. I looked through the thread, but I never saw 'netstat -rn' output. If there's a default route in place, the packets may be going out some random interface into the void because of the use of IP_SENDSRCADDR (and sendmsg won't even complain).

I'm not certain that's the explanation for this bug, though, but if I have some time I'll futz with VLANs on BSD.

Changed 4 years ago by zml

I've confirmed that using the patch from ticket #163, I can browse in a pure-VLAN environment:

1# ifconfig
em0: flags=408802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
        options=30b<RXCSUM,TXCSUM,VLAN_MTU,TSO4,TSO6>
        ether 00:0c:29:60:3f:55
        media: Ethernet autoselect
        status: no carrier
        flexnet: internal
em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        options=30b<RXCSUM,TXCSUM,VLAN_MTU,TSO4,TSO6>
        ether 00:0c:29:60:3f:5f
        media: Ethernet autoselect (1000baseTX <full-duplex>)
        status: active
        flexnet: unused
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
        inet 127.0.0.1 netmask 0xff000000 
        flexnet: unused
vlan1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 (realmtu zero!)
        inet 192.168.1.100 netmask 0xffffff00 broadcast 192.168.1.255
        ether 00:0c:29:60:3f:5f
        media: Ethernet autoselect (1000baseTX <full-duplex>)
        status: active
        vlan: 1 parent interface: em1
        flexnet: unused
vlan2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 (realmtu zero!)
        inet 192.168.2.100 netmask 0xffffff00 broadcast 192.168.2.255
        ether 00:0c:29:60:3f:5f
        media: Ethernet autoselect (1000baseTX <full-duplex>)
        status: active
        vlan: 2 parent interface: em1
        flexnet: unused

Please note, on my BSD box it's important to add a route for the IP multicast network, and it's import that address be routed to lo0! Example:

# route add 224./4 -iface lo0
# netstat -rn                
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
127.0.0.1          127.0.0.1          UH          0      744    lo0
192.168.1          link#4             UC          0        0  vlan1
192.168.1.101      00:0c:29:e1:50:9c  UHLW        1       34  vlan1     91
192.168.2          link#5             UC          0        0  vlan2
192.168.2.101      00:0c:29:e1:50:9c  UHLW        1       27  vlan2    143
224.0.0/4          lo0                US          0        0    lo0

If you don't have a multicast route configured, and you do have a default route configured, older BSD kernels will first route the packet to the default route. If you configure the multicast route to the loopback address, though, it'll tickle the multicast-bind-to-interface code into working:

+ vlan2 IPv4 zc-2                                          _ssh._tcp            local
+ vlan2 IPv4 zc-1                                          _ssh._tcp            local
+ vlan1 IPv4 zc-2                                          _ssh._tcp            local
+ vlan1 IPv4 zc-1                                          _ssh._tcp            local
= vlan2 IPv4 zc-2                                          _ssh._tcp            local
   hostname = [zc-2.local]
   address = [192.168.1.101]
   port = [22]
   txt = []
= vlan2 IPv4 zc-1                                          _ssh._tcp            local
   hostname = [zc-1.local]
   address = [192.168.2.100]
   port = [22]
   txt = []
= vlan1 IPv4 zc-2                                          _ssh._tcp            local
   hostname = [zc-2.local]
   address = [192.168.2.101]
   port = [22]
   txt = []
= vlan1 IPv4 zc-1                                          _ssh._tcp            local
   hostname = [zc-1.local]
   address = [192.168.1.100]
   port = [22]
   txt = []

Hope this helps!

Changed 4 years ago by lennart

  • owner changed from lathiat to lennart
  • status changed from new to assigned
  • milestone set to Avahi 0.6.22

Changed 4 years ago by lennart

  • status changed from assigned to closed
  • resolution set to fixed

Following zml suggestions I will now assume that this bug is fixed by the patch from #163 which I just commited. I will close this bug now. If the problem persists, feel free to reopen.

Note: See TracTickets for help on using tickets.