Ungereimtheiten im Netzwerk nach Update auf 13.0-BETA2

jmt

Well-Known Member
Da das kommende 13. Release von FreeBSD vor der Tür steht habe ich beschlossen, es mal auf meinem "Server" auszuprobieren. Erste kleinere Tests waren ganz vielversprechend. Aber ich bin auf ein Problem gestoßen bei dem ich Eure Hilfe brauche. Der Reihe nach: Meine Netzwerkumgebund besteht aus einem Switch an dem sich alle physisch angeschlossenen Geräte befinden. Das WLAN ist über 2 Access-Points mit diesem Switch verbunden. Und natürlich mein FreeBSD Server, auf dem verschiedene Jails laufen, teils mit VNET, teils ohne. Zur Heimautomatisierung betreibe ich eine VNET Jail mit homebridge. Diese kann ich sowohl per LAN über meinen Mac als auch per WLAN über Tablets und Telefone verwenden. Nach dem Update des Servers auf 13.0-BETA2 schien das System ganz normal zu laufen. Allerdings konnte ich meine Homebridge nicht ansprechen. Bei der Fehlersuche dachte ich auch erst gar nicht an den Server selbst, bzw. das Update. Es stellte sich aber heraus, dass man Homebridge über das LAN ansprechen kann, nicht jedoch über das WLAN! Das kann ich sogar wunderbar mit meinem Mac testen. Ziehe ich dort das Netzwerkkabel, dann kann die Home-App nicht mehr mit der Homebridge kommunizieren. Stecke ich das Kabel wieder an, so ist die Verbindung wieder da. Interessanter Weise kann ich aber alle Geräte von dem Homebridge-Jail aus anpingen und auch vom Telefon auf die Homebridge zugreifen. Nur Homebridge selbst läuft nicht. Nachdem ich auf dem Server wieder 12.2 gebootet habe läuft auch dei Homebridge wieder über das WLAN. Hat jemand von Euch eine Idee, was denn eine Verbindung über WLAN anders macht als eine über LAN? Es befindet sich auch keine Firewall dazwischen. Access-Points und Switch sind von Unifi. Auf dem Server habe ich eine Bridge, an der die Netzwerkkarte (em0) und die epair Devices der VNET-Jails hängen. Ich habe gerade keine Idee, wo ich suchen soll...
 
Womit kann man so etwas denn quick&dirty grafisch darstellen?

Mal ein Versuch mit ASCII:
Code:
Switch <-> AccesPoint <-> Handy
       <-> Mac
       <-> FreeBSD 12/13 <-> em0 <-> lanBridge <-> e0a_haus <-> e0b_haus in der Jail

Handy und Mac bekommen ihre statische IP über DHCP. Die IP des FreeBSD ist am Interface em0 und die Jail konfiguriert ihre IP auch statisch. Alles mit ipv4 in einem Class-C Netz.

Meine jail.conf
Code:
exec.system_user = "root";
exec.jail_user = "root";
mount.devfs;
devfs_ruleset="11";    #devfs ruleset for this jail
allow.raw_sockets;    #allow ping-pong
allow.set_hostname = 1;
allow.sysvipc = 1;

# Dynamic wildcard parameter:
# Base the path off the jail name.
exec.consolelog = "/var/log/jail_${name}_console.log";
path = "/jails/$name";
host.hostname = "$name.local";
vnet.interface="";

exec.clean;
exec.start        = "/bin/sh /etc/rc";
exec.stop         = "/bin/sh /etc/rc.shutdown";

unifi {
        vnet;
        vnet.interface  = "e0b_${name}";
        exec.created    = "jib addm ${name} em0";
        exec.poststop   = "jib destroy ${name}";
}

haus {
        vnet;
        vnet.interface  = "e0b_${name}";
        exec.created    = "jib addm ${name} em0";
        exec.poststop   = "jib destroy ${name}";
}

Die Bridge wird durch jib erzeugt. Die Jail hat noch ein 12.2 Userland. Kann das zu solchen Problemen führen?
 
Kann das zu solchen Problemen führen?
Nein. Eigentlich nicht. Älteres Userland auf neuerem Kernel muss funktionieren. Nur umgekehrt ist es problematisch.

Die IP des FreeBSD ist am Interface em0
Das ist offensichtlich falsch und funktionierte bisher nur aus Glück. :) IP-Adressen müssen immer auf der Bridge liegen, niemals auf den Member-Interfaces. Andernfalls kann der Kernel eingehendes und ausgehendes Interface nicht eindeutig bestimmen, was eine ganze Reihe obskurer Nebenwirkungen haben kann. Es kann unter anderem die ARP-Tabellen des Switches durcheinanderbringen, was deine Probleme erklären könnte.

Ich würde auch gleich noch schauen, ob die MAC-Adressen der Bridge und der epair-Interfaces eindeutig sind. Wenn du mehrere FreeBSD-Maschinen mit Bridges und epair-Interfaces hast, auch über Maschinen hinweg. Denn die zufällig generierten MAC-Adressen sind (prinzipbedingt) nur auf einer Maschine garantiert eindeutig. Auf mehreren Maschinen kann es zu MAC-Kollissionen kommen, die wieder sehr interessante Nebenwirkungen haben.
 
Womit kann man so etwas denn quick&dirty grafisch darstellen?
Mal grob mit Gimp ein paar Rechtecke kritzeln, IP-Adressen dran und sowas reicht völlig, aber ASCII geht natürlich auch. :)

Da fällt es dann leichter abzugleichen (mir zumindest), ob das Visuelle dem Text gleicht und nicht eins davon was anderes meint und umgekehrt. Mja und es erhöht dann die Chance, dass einem der Fehler dann schneller ins Auge sticht. ;)
 
Nein. Eigentlich nicht. Älteres Userland auf neuerem Kernel muss funktionieren. Nur umgekehrt ist es problematisch.


Das ist offensichtlich falsch und funktionierte bisher nur aus Glück. :) IP-Adressen müssen immer auf der Bridge liegen, niemals auf den Member-Interfaces. Andernfalls kann der Kernel eingehendes und ausgehendes Interface nicht eindeutig bestimmen, was eine ganze Reihe obskurer Nebenwirkungen haben kann. Es kann unter anderem die ARP-Tabellen des Switches durcheinanderbringen, was deine Probleme erklären könnte.

Ich würde auch gleich noch schauen, ob die MAC-Adressen der Bridge und der epair-Interfaces eindeutig sind. Wenn du mehrere FreeBSD-Maschinen mit Bridges und epair-Interfaces hast, auch über Maschinen hinweg. Denn die zufällig generierten MAC-Adressen sind (prinzipbedingt) nur auf einer Maschine garantiert eindeutig. Auf mehreren Maschinen kann es zu MAC-Kollissionen kommen, die wieder sehr interessante Nebenwirkungen haben.
Ok, ich habe meine Jails jetzt umgebaut. Es läuft nun über jib mit em0bridge, etc. Also alles im default für jib. Unter 12.2 funktioniert es nach wie vor, aber bei 13.0 bekomme ich keinen Kontakt zum homebridge. Meinen Unifi-Controller kann ich hingegen per http erreichen. Auch ein ping zur homebridge jail funktioniert. Auf dem jail läuft auch ein HTTP Service, den ich ebenfalls erreiche. Aber laut tcpdump auf der bridge am Host kommen keine Requests zur homebridge. Soweit ich weiß, macht Apple da Multicast. Muss man den jetzt freischalten? Wobei es über LAN nach wie vor funktioniert. Hier noch mal die Skizze:
Code:
Switch <-> AccesPoint <-> Handy
       <-> Mac
       <-> FreeBSD 12/13 <-> em0 <-> em0bridge (mit IP) <-> e0a_haus <-> e0b_haus in der Jail

und meine angepasste jail.conf
Code:
exec.system_user = "root";
exec.jail_user = "root";
mount.devfs;
devfs_ruleset="11";    #devfs ruleset for this jail
allow.raw_sockets;    #allow ping-pong
allow.set_hostname = 1;
allow.sysvipc = 1;

# Dynamic wildcard parameter:
# Base the path off the jail name.
exec.consolelog = "/var/log/jail_${name}_console.log";
path = "/jails/$name";
host.hostname = "$name.local";
vnet.interface="";

exec.clean;
exec.start        = "/bin/sh /etc/rc";
exec.stop         = "/bin/sh /etc/rc.shutdown";

unifi {
        vnet;
        vnet.interface  = "e0b_${name}";
        exec.created    = "jib addm ${name} em0";
        exec.poststop   = "jib destroy ${name}";
}

haus {
        vnet;
        vnet.interface  = "e0b_${name}";
#       exec.created    = "/root/bin/jail.created ${name} lanBridge";
#       exec.prestop    = "/root/bin/jail.prestop";
        exec.prestart   = "jib addm ${name} em0";
        exec.poststop   = "jib destroy ${name}";
}
 
Zusatz: Ich habe mal jng ausprobiert. Das Ergenis ist das gleiche wie bei jib. Zugriff via http und icmp geht, aber homebridge funktioniert nicht über WLAN.
 
Können wir mal die vollständige Ausgabe von ifconfig sehen? Ich glaube, das würde alles etwas klarer machen.
 
Beispiel:
Code:
hunderteins {
                host.hostname = "$name.domain.org";
                $id     = "101";
                jid     = ${id};

                vnet;
                vnet.interface = "epair${id}b";

                exec.prestart   = "ifconfig epair${id} create up";
                exec.prestart  += "ifconfig epair${id}a up descr vnet-${name}";
                exec.prestart  += "ifconfig meinebridge addm epair${id}a up";

                exec.prestop    = "ifconfig epair${id}b -vnet ${name}";

                exec.poststop   = "ifconfig meinebridge deletem epair${id}a";
                exec.poststop  += "ifconfig epair${id}a destroy";

}

Und dann ganz klassisch die rc.conf in der jail:

Code:
ifconfig_epair101b="inet x.x.x.x/24"
defaultrouter="x.x.x.1"
 
Können wir mal die vollständige Ausgabe von ifconfig sehen? Ich glaube, das würde alles etwas klarer machen.
Gerne. Zuerst mal FreeBSD 12.2
ifconfig
Code:
root@mcp:~ # ifconfig
em0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=812099<RXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,VLAN_HWFILTER>
    ether 00:1b:21:92:90:53
    media: Ethernet autoselect (1000baseT <full-duplex>)
    status: active
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
em1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=81209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,VLAN_HWFILTER>
    ether 70:85:c2:21:7f:dc
    media: Ethernet autoselect
    status: no carrier
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
    options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
    inet6 ::1 prefixlen 128
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
    inet 127.0.0.1 netmask 0xff000000
    groups: lo
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
em0bridge: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    ether 02:68:ec:86:84:00
    inet 192.168.21.4 netmask 0xffffff00 broadcast 192.168.21.255
    id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
    maxage 20 holdcnt 6 proto stp-rstp maxaddr 2000 timeout 1200
    root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
    member: e0a_haus flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
            ifmaxaddr 0 port 6 priority 128 path cost 2000
    member: em0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
            ifmaxaddr 0 port 1 priority 128 path cost 20000
    groups: bridge
    nd6 options=9<PERFORMNUD,IFDISABLED>
em1bridge: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    ether 02:68:ec:86:84:01
    inet 192.168.10.3 netmask 0xffffff00 broadcast 192.168.10.255
    id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
    maxage 20 holdcnt 6 proto stp-rstp maxaddr 2000 timeout 1200
    root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
    member: em1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
            ifmaxaddr 0 port 2 priority 128 path cost 2000000
    groups: bridge
    nd6 options=9<PERFORMNUD,IFDISABLED>
e0a_haus: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=8<VLAN_MTU>
    ether 02:c0:d2:92:90:53
    hwaddr 02:79:ea:c0:86:0a
    groups: epair
    media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
    status: active
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
Und in der Jail
Code:
root@mcp:~ # jexec haus ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
    options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
    inet6 ::1 prefixlen 128
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
    inet 127.0.0.1 netmask 0xff000000
    groups: lo
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
e0b_haus: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=8<VLAN_MTU>
    ether 0e:c0:d2:92:90:53
    hwaddr 02:79:ea:c0:86:0b
    inet 192.168.21.5 netmask 0xffffff00 broadcast 192.168.21.255
    groups: epair
    media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
    status: active
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

Nun selbiges mit FreeBSD 13.0-BETA2
ifconfig
Code:
root@mcp:~ # ifconfig
em0: flags=8963<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=4812099<RXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,VLAN_HWFILTER,NOMAP>
    ether 00:1b:21:92:90:53
    media: Ethernet autoselect (1000baseT <full-duplex>)
    status: active
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
em1: flags=8963<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=481209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,VLAN_HWFILTER,NOMAP>
    ether 70:85:c2:21:7f:dc
    media: Ethernet autoselect
    status: no carrier
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
    options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
    inet6 ::1 prefixlen 128
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
    inet 127.0.0.1 netmask 0xff000000
    groups: lo
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
em0bridge: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    ether 58:9c:fc:10:ff:9c
    inet 192.168.21.4 netmask 0xffffff00 broadcast 192.168.21.255
    id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
    maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
    root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
    member: e0a_haus flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
            ifmaxaddr 0 port 7 priority 128 path cost 2000
    member: em0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
            ifmaxaddr 0 port 1 priority 128 path cost 20000
    groups: bridge
    nd6 options=9<PERFORMNUD,IFDISABLED>
em1bridge: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    ether 58:9c:fc:10:16:44
    inet 192.168.10.3 netmask 0xffffff00 broadcast 192.168.10.255
    id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
    maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
    root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
    member: em1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
            ifmaxaddr 0 port 2 priority 128 path cost 2000000
    groups: bridge
    nd6 options=9<PERFORMNUD,IFDISABLED>
e0a_haus: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=8<VLAN_MTU>
    ether 02:c0:d2:92:90:53
    hwaddr 02:b6:ce:af:fe:0a
    groups: epair
    media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
    status: active
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
und in der Jail
Code:
root@mcp:~ # jexec haus ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
    options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
    inet6 ::1 prefixlen 128
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
    inet 127.0.0.1 netmask 0xff000000
    groups: lo
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
e0b_haus: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=8<VLAN_MTU>
    ether 0e:c0:d2:92:90:53
    hwaddr 02:b6:ce:af:fe:0b
    inet 192.168.21.5 netmask 0xffffff00 broadcast 192.168.21.255
    groups: epair
    media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
    status: active
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
 
Beispiel:
Code:
hunderteins {
                host.hostname = "$name.domain.org";
                $id     = "101";
                jid     = ${id};

                vnet;
                vnet.interface = "epair${id}b";

                exec.prestart   = "ifconfig epair${id} create up";
                exec.prestart  += "ifconfig epair${id}a up descr vnet-${name}";
                exec.prestart  += "ifconfig meinebridge addm epair${id}a up";

                exec.prestop    = "ifconfig epair${id}b -vnet ${name}";

                exec.poststop   = "ifconfig meinebridge deletem epair${id}a";
                exec.poststop  += "ifconfig epair${id}a destroy";

}

Und dann ganz klassisch die rc.conf in der jail:

Code:
ifconfig_epair101b="inet x.x.x.x/24"
defaultrouter="x.x.x.1"
So ähnlich hatte ich das vorher auch, nur dass ich dafür ein Script verwendete. Das hat dann auch noch die Interfaces renamed. Mittels des Scriptes war der Erfolg ähnlich. D.h. mitt LAN an die Homebridge, mit WLAN nicht.

Ich habe Deinen Ansatz mal schnell ausprobiert. Leider ändert auch das nichts. Ich habe das Gefühl, dass es nicht daran liegt, wie ich die Jail erzeuge. Ich glaube eher, dass ich sich eine Einstellung geändert hat. Wobei ich nach wie vor nicht nachvollzeihen kann, warum LAN geht und WLAN nicht. :confused:
 
Die Hombridge Software und Konfiguration ändern sich während des Betriebssystemswechsels nicht.
 
Danke für das ifconfig. Das macht einiges klarer. Führt aber du einer weiteren Frage: Was ist 192.168.10.0/24 auf em1bridge für ein Netz? Hat das irgendwas mit der ganzen Sache zu tun?
 
Das wird mal der Anschluss zum Modem. Das liegt in diesem Netz. Sowohl der Mac als auch die Handys sind im 192.168.21.0/24 Netz. Dort ist auch die Homebridge (Haus).
 
Ich bin dem Rätsel auf der Spur. Ein avahi-browse -a unter FreeBSD 13 zeigt kaum Resourcen an. Unter FreeBSD 12 ist das anders. Hier befindet sich dann auch meine Homebridge unter den gefundenen Resourcen. Starte ich nun den avahi-daemon unter FreeBSD 13 erneut, so findet er alle Resourcen und auch die Handys können sich mit der Homebridge verbinden. Hat sich beim Startup unter FreeBSD 13 etwas verändert? Gibt es andere Sysctls? Ich habe schon einige Einträge aus sysctl zwischen 13 und 12 verglichen aber keine Unterschiede festgestellt. Es wäre schön, wenn ich den avahi-daemon nach einem Neustart nicht neu starten müsste.

Hier die Ausgaben:
Code:
root@mcp:~ # avahi-browse -a
+ em1bridge IPv4 RFG SP1210N @ mcp                             _ipp._tcp            local
+ em0bridge IPv4 RFG SP1210N                                   _ipp._tcp            local
+ em0bridge IPv4 RFG SP1210N @ mcp                             _ipp._tcp            local
+    lo0 IPv6 RFG SP1210N @ mcp                             _ipp._tcp            local
+    lo0 IPv4 RFG SP1210N @ mcp                             _ipp._tcp            local
+    em0 IPv4 RFG SP1210N @ mcp                             _ipp._tcp            local
+ em1bridge IPv4 RFG SP1210N @ mcp                             _ipps._tcp           local
+ em0bridge IPv4 RFG SP1210N @ mcp                             _ipps._tcp           local
+    lo0 IPv6 RFG SP1210N @ mcp                             _ipps._tcp           local
+    lo0 IPv4 RFG SP1210N @ mcp                             _ipps._tcp           local
+    em0 IPv4 RFG SP1210N @ mcp                             _ipps._tcp           local
+ em1bridge IPv4 RFG SP1210N @ mcp                             _printer._tcp        local
+ em0bridge IPv4 RFG SP1210N                                   _printer._tcp        local
+ em0bridge IPv4 RFG SP1210N @ mcp                             _printer._tcp        local
+    lo0 IPv6 RFG SP1210N @ mcp                             _printer._tcp        local
+    lo0 IPv4 RFG SP1210N @ mcp                             _printer._tcp        local
+    em0 IPv4 RFG SP1210N @ mcp                             _printer._tcp        local
+ em1bridge IPv4 mcp                                           _ssh._tcp            local
+ em0bridge IPv4 vuuno4kse                                     _ssh._tcp            local
+ em0bridge IPv4 mcp                                           _ssh._tcp            local
+    lo0 IPv6 mcp                                           _ssh._tcp            local
+    lo0 IPv4 mcp                                           _ssh._tcp            local
+    em0 IPv4 mcp                                           _ssh._tcp            local
+ em1bridge IPv4 mcp                                           _sftp-ssh._tcp       local
+ em0bridge IPv4 vuuno4kse                                     _sftp-ssh._tcp       local
+ em0bridge IPv4 mcp                                           _sftp-ssh._tcp       local
+    lo0 IPv6 mcp                                           _sftp-ssh._tcp       local
+    lo0 IPv4 mcp                                           _sftp-ssh._tcp       local
+    em0 IPv4 mcp                                           _sftp-ssh._tcp       local
+ em1bridge IPv4 mcp                                           _device-info._tcp    local
+ em0bridge IPv4 mcp                                           _device-info._tcp    local
+    lo0 IPv6 mcp                                           _device-info._tcp    local
+    lo0 IPv4 mcp                                           _device-info._tcp    local
+    em0 IPv4 mcp                                           _device-info._tcp    local
+ em1bridge IPv4 mcp                                           _adisk._tcp          local
+ em0bridge IPv4 mcp                                           _adisk._tcp          local
+    lo0 IPv6 mcp                                           _adisk._tcp          local
+    lo0 IPv4 mcp                                           _adisk._tcp          local
+    em0 IPv4 mcp                                           _adisk._tcp          local
+ em1bridge IPv4 mcp                                           _smb._tcp            local
+ em0bridge IPv4 VUUNO4KSE                                     _smb._tcp            local
+ em0bridge IPv4 mcp                                           _smb._tcp            local
+    lo0 IPv6 mcp                                           _smb._tcp            local
+    lo0 IPv4 mcp                                           _smb._tcp            local
+    em0 IPv4 mcp                                           _smb._tcp            local
soviel steht nach dem Boot. Nach einem Neustart folgt:
Code:
+ em0bridge IPv4 70-35-60-63.1 B__ro Markus                    _sleep-proxy._udp    local
+ em0bridge IPv4 Homebridge CAD8                               _hap._tcp            local
+ em0bridge IPv4 AS-AFTMM[AirPlay]                             _airplay._tcp        local
+ em0bridge IPv4 B__ro Markus                                  _airplay._tcp        local
+    em0 IPv4 AS-AFTMM[AirPlay]                             _airplay._tcp        local
+ em0bridge IPv4 74D63729B48D@AS-AFTMM[AirPlay]                _raop._tcp           local
+ em0bridge IPv4 E02B96AFF0D5@B__ro Markus                     _raop._tcp           local
+    em0 IPv4 74D63729B48D@AS-AFTMM[AirPlay]                _raop._tcp           local
+ em0bridge IPv4 CB35512C-FDE0-51B7-8800-F87816516F12          _homekit._tcp        local
+    em0 IPv4 CB35512C-FDE0-51B7-8800-F87816516F12          _homekit._tcp        local
+ em0bridge IPv4 MyHome70                                      _meshcop._udp        local
+ em0bridge IPv4 AS-AFTMM[Cast]                                _googlecast._tcp     local
+    em0 IPv4 AS-AFTMM[Cast]                                _googlecast._tcp     local
+ em0bridge IPv4 amzn.dmgr:A2F9398B311F3C9D7ACA688666A798C4:xnVDMM+4u1:302587 _amzn-wplay._tcp     local
+ em0bridge IPv4 vuuno4kse [00:1d:ec:13:52:0d]                 _workstation._tcp    local
+ em0bridge IPv4 RFG SP1210N                                   _http._tcp           local
+ em0bridge IPv4 RFG SP1210N                                   _pdl-datastream._tcp local
+ em0bridge IPv4 iPad von Daniela (2)                          _companion-link._tcp local
+ em0bridge IPv4 MacBook Air von Tom                           _companion-link._tcp local
+ em0bridge IPv4 B__ro Markus                                  _companion-link._tcp local
+ em0bridge IPv4 tron                                          _companion-link._tcp local
+    em0 IPv4 B__ro Markus                                  _companion-link._tcp local
+    em0 IPv4 MacBook Air von Tom                           _companion-link._tcp local
+    em0 IPv4 RFG SP1210N                                   _pdl-datastream._tcp local
+    em0 IPv4 RFG SP1210N                                   _printer._tcp        local
+    em0 IPv4 RFG SP1210N                                   _ipp._tcp            local
+    em0 IPv4 RFG SP1210N                                   _http._tcp           local
+    em0 IPv4 vuuno4kse                                     _ssh._tcp            local
+    em0 IPv4 vuuno4kse [00:1d:ec:13:52:0d]                 _workstation._tcp    local
+    em0 IPv4 VUUNO4KSE                                     _smb._tcp            local
+    em0 IPv4 vuuno4kse                                     _sftp-ssh._tcp       local
+    em0 IPv4 tron                                          _companion-link._tcp local
+    em0 IPv4 iPad von Daniela (2)                          _companion-link._tcp local
+    em0 IPv4 70-35-60-63.1 B__ro Markus                    _sleep-proxy._udp    local
+    em0 IPv4 MyHome70                                      _meshcop._udp        local
+    em0 IPv4 B__ro Markus                                  _airplay._tcp        local
+    em0 IPv4 E02B96AFF0D5@B__ro Markus                     _raop._tcp           local
+ em0bridge IPv4 35A92726-A1CB-5D74-BC81-9A237A82AA69          _homekit._tcp        local
+    em0 IPv4 35A92726-A1CB-5D74-BC81-9A237A82AA69          _homekit._tcp        local
 
Ich habe es gestern leider nicht mehr geschafft zu antworten. Soweit ich das sehe, ist deine Konfiguration korrekt. Auch die Randfälle, die auf 12.x vielleicht noch aus irgendwelchen Gründen funktioniert hätten, aber das Potential haben unter 13.x kaputt zu sein. Kurz gesagt, ich habe keine Ahnung, was das Problem ist. Es schaut aus, als würde die Bridge Pakete fressen. Und das wäre dann eventuell ein Bug. Eine zugegeben etwas kurze Suche auf freebsd-net@ und im Bugtracker zeigt keine ähnlichen Probleme. Tja, damit wären die nächsten möglichen Schritte die Pakete mit tcpdump / wireshark an verschiedenen Stellen mitzuschneiden und zu schauen, was genau schief geht. Oder gleich eine Mail an freebsd-net@.
 
Ich habe mit Argusaugen deine configs nebeneinander gelegt, verglichen und so gut wie es ging nachvollzogen. Der einzige Unterschied ist beim 13er, dass deine NICs die Funktion NOMAP bekamen. Damit weiß ich aber gerade nichts anzufangen.
Könnte sein, dass dein Switch damit was verbumselt.

Edit: Funktioniert meine config, wenn du der bridge keine IP gibst? Ist jetzt gegen die Logik, aber man weiß ja nie.
 
Ich habe NOMAP auf dem em0 disabled, aber das scheint nicht as Problem zu sein. Der Avahi-daemon findet die Jail nicht. Mir ist aber noch nicht klar, warum das nach einem Neustart des Daemons funktioniert, wenn die Bridge Pakete verschlucken sollte. Ich habe die 13er Version schon einen Tag lang laufen lassen und es scheint nach dem Neustart von Avahi alles zu funktionieren.
 
Ich denke, wir können den Thread jetzt auf "gelöst" stellen. Für FreeBSD 13 braucht der avahi-daemon eine zusätzliche Konfigurationseinstellung:
Code:
allow-interfaces=em0bridge
Vorher lauschte er auf allen Devices, insbesonders auf em0bridge und em0. Das scheint mit FreeBSD 13 zu Konflikten zu führen. Evtl. liegt es einfach an der Reihenfolge in der Devices AVAHI übergeben werden oder ähnlichen kleinen Details. Wie auch immer, mit der Einschränkung auf das Interface, auf dass er ja eh nur lauschen soll, funktioniert es gleich beim Start.
 
Zurück
Oben