[supernode] "kernel: device br0 left promiscuous mode"

Irgendeine Idee? Das führt hier auf Supernodes dazu, dass Prefixe (nach meinem Gefühl) nur sehr sporadisch announced werden.

kernel: device br0 left promiscuous mode
radvd: br0 does not support multicast, forcing UnicastOnly

Ich habe vermutlich alles FAQs und Google-Resultate der ersten 3 Seiten „durch“.
Meist geht es um Leute, die im laufe des Threads feststellen, dass ihnen der Server geownt wurde und darüber dann die nächsten 3 Seiten diskutieren.
oder Leute die irgendwelche Desktop-Linuxe mit Wifi benutzen wollen.

Ich ahbe schon ein paar kombinationen durch, sowohl mit „ip link“ und auch was man so in im /sys/devices an optionen findet.

ip link set dev br0 multicast on promisc on
echo 0 > /sys/devices/virtual/net/br0/bridge/multicast_snooping

btw: Ubuntu16.4.3LTS, egal ob Kernal „4.4.0-93-generic“ oder „4.10.0-24“
Andere Vorschläge?

Hallo adorfer kannst du uns auch deine network config da lassen? Und ich dachte für enable ist ein echo 1 > zuständig

Welche von den vielen?

Das Problem ist, dass der Promiscous-Mode immer nur Sekundenbruchteile hält… erkommt etwa einmal pro Minute kurz.
Sep 9 07:23:43 hld-2 kernel: [ 7859.825208] device br0 entered promiscuous mode
Sep 9 07:23:43 hld-2 kernel: [ 7859.826557] device br0 left promiscuous mode

Und wenn der verloren geht erstmalig, schaltet der radvd um:
Sep 9 07:23:37 hld-2 kernel: [ 7853.168085] device br0 left promiscuous mode
Sep 9 07:23:38 hld-2 radvd[15851]: br0 does not support multicast, forcing UnicastOnly

Config z.B.

auto br0
iface br0 inet static
        address 10.11.128.1
        netmask 255.255.240.0
        bridge_ports none
        bridge_stp yes
        post-up ip link set $IFACE promisc on multicast on

mir fehlt gefühlt irgendwie welche ports du Bridget bei uns sieht das so aus. ce: bat0
iface br0 inet manual
post-up ifconfig $IFACE up
post-up ifconfig $IFACE up
bridge_ports bat0 eth1
##Einschalten post-up:
# IP des Gateways am B.A.T.M.A.N interface:
post-up ip addr add 10.50.32.5/21 dev $IFACE
# Regeln, wann die fff Routing-Tabelle benutzt werden soll:
post-up ip rule add iif $IFACE table fff
post-up ip rule add from 10.0.0.0/8 table fff
post-up ip rule add to 10.0.0.0/8 table fff
# Route in die Fuerther Hood:
post-up ip route add 10.50.32.0/21 dev $IFACE table fff
# Start des DHCP Servers:
post-up invoke-rc.d isc-dhcp-server restart.

br0 enthält nur bat0, das batman-adv interface.

Frage: radvd-Interface auf br0 oder bat0, also bridge oder das batman-client selbst?

Wir haben bei der config dem DHCP Damm auf br0

Was bedeutet das?

wir haben den DHCP dann auf br0; story Finger zu fett für Handy und Decks auto Korrektur

Hallo Adorfer,

ist das eine Virtuelle Maschine ?
Passiert zufällig im gleichen Zeitfenster etwas auf dem darunter liegendem Host?
Welchen Netzwerk Treiber benutzt ihr falls es eine VM in benutzung von LibvirtD ist?
Was sagt „dmesg“ bevor diese Meldungen kommen ?
Funktionieren noch Programme wie tcpdump / iftop, die den promiscuous auch brauchen/aktivieren?

Mag ja durchaus sein.
Hat das einen Einfluss auf die hier beschriebenen Effekte?

Schon,
Nur wäre das für mich rätselhaft, weil doch die br0 eine rein „vm-lokaler“ virtueller Switch ist auf dem (mit dem Batman) auch nur ein vm-lokales virtuelles Interface hängt.
Es ist also keine Verbindung irgendwo zu einer paravirt-Lankarte vorhanden bei diesen Geräten.
(Wenn das auf eth0/ens18 etc passieren würde: gekauft! Aber gerade die sind nicht betroffen.)

hi, vielleicht hilft das bei dem multicast Problem weiter nux: Enabling Multicast querier on bridges
If your router or switch does not support enabling a multicast querier, and you are using a classic linux bridge (not Open vSwitch), then you can enable the multicast querier on the Linux bridge by adding this statement to your /etc/network/interfaces bridge configuration:
post-up ( echo 1 > /sys/devices/virtual/net/$IFACE/bridge/multicast_querier ).

Ja, den hatte ich leider auch schon zu fassen:
auch bei direktem, sofortigen Neustart des Radvd:
Sep 9 23:27:52 Flingern-2 radvd[2315]: interface br0 does not support multicast
Sep 9 23:27:52 Flingern-2 radvd[2315]: do you need to add the UnicastOnly flag?

Hmk ja das hatte ich wohl beim Lesen ignoriert…

In der Bridge hängen aber nicht die L2TP Tunnel drin oder?
Wenn nein, hast Du schon mal versucht ob Du mit „macvlan“ Devices evt. das Problem umschiffen kannst ?
(Ähnlich wie mit dem Alfred Interface früher)

Gruß

Entweder ein eher komplexes setup: (tap geht zu einem anderen Supernode, die taps sind die verschiedenen Batman-Netze), die ifs eth1 und eth2 gehen zu lokalen VMs, die via batman und als ip-client im Netz hängen für Monitoring)
(Also nicht der Ort in dem man debuggen möchte, weil so viele Szenarien denkbar.)

root@Flingern-2:/home/adorfer# batctl if
eth2: active
tap-ffdus-fl3: active
tap2: active
tap1: active
tap0: active
root@Flingern-2:/home/adorfer# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.cab1e1326564       no              bat0
                                                        eth1

Aber hier ein eher einfaches Setup, das genauso betroffen ist:

root@hld-2:/home/adorfer# uname -a
Linux hld-2 4.4.0-93-generic #116-Ubuntu SMP Fri Aug 11 21:17:51 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
root@hld-2:/home/adorfer# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.02eeefca1175       yes             bat0
root@hld-2:/home/adorfer# batctl if
tap0: active

Kunden frage ich ja normalerweise erst mal:
Ging das schon mal ?
Ab wann nicht mehr ?
Gilt das fuer alle Supernodes oder sind welche nicht betroffen ?

fand ich ganz interessant vom Ansatz, aber man hat da wohl auch keine Prozessinfos an der Hand.
(>>auditing)

Wenn der Modus wieder sehr schnell abgestellt wird, muesste es ja auch ein Mechanismus sein, der
dern Zustand dauernd polled. Das muesste sich ja auch nachweisen lassen. Also vermutlich eher ein Prozess, der dauernd laeuft und nichts, was im Shell accounting vorbeifliegt zeitnah.

Auch wenn Du den lokalen virtuellen Switch fuer unverdaechtig haeltst, das es den trifft, so koennte es ja auch noch ein Bug sein im Bereich Virtualisierung.

Hth,
Holgi

Tja… es ging mal als der Kernel noch ein 3.x irgendwas war beim einem relativ jungen Install von Ubuntu14.4LTS…
Oder damals hat der Kernel das noch nicht gemeldet im Syslog?

Wie auch immmer… ich habe den radvd jetzt von br0 auf bat0 (also von vom switch auf das Batman-Interface) umgestellt.

hehe also das Problem ist eigentlich ein relativ alter Hut, den Du jetzt mal in Angriff nehmen wolltest und die bat0 Alternative hattest Du schon in petto und bist guter Hoffnung, dass das Problem nicht wandert. :slight_smile:
toi toi toi