bridge interface mit usb-ethernet

ababab

Member
Ich habe eine bhyve-vm, diese erzeugt beim Start ein tap0, ich erzeuge ein bridge0:
Code:
# ifconfig bridge0 create
# ifconfig bridge0 addm re0 addm tap0 up
und schon kann ich zur vm unter der bekannten IP-Adresse verbinden.
Jetzt versuche ich das re0 durch ein ue0-Interface von einem USB-C-Adapter zu ersetzen, das normale Netzwerk funktioniert
problemlos, mache obiges unter Ersetzung von re0 durch ue0, aber die vm erreiche ich nicht. Gibt's dafür einen speziellen Grund?

... und wie verschiebe ich das hier nach "-Netzwerk"? ...
 
... und wie verschiebe ich das hier nach "-Netzwerk"? ...
Das wichtigste zuerst: Hab ich erledigt :)

Ich habe eine bhyve-vm, diese erzeugt beim Start ein tap0, ich erzeuge ein bridge0:
# ifconfig bridge0 create
# ifconfig bridge0 addm re0 addm tap0 up
und schon kann ich zur vm unter der bekannten IP-Adresse verbinden.
Jetzt versuche ich das re0 durch ein ue0-Interface von einem USB-C-Adapter zu ersetzen, das normale Netzwerk funktioniert
problemlos, mache obiges unter Ersetzung von re0 durch ue0, aber die vm erreiche ich nicht. Gibt's dafür einen speziellen Grund?

Also ue0 funktioniert auch bis du ihn zur bridge hinzufügt?

(Ich find den gerade nicht in den manuel pages, hast du evtl. da den link einmal für mich?)
 
Jep, die wichtigste Frage: Funktioniert ue0 vorher? Ist ue0 up? Ist ue0 nach dazupacken in bridge0 noch up? Ist bridge0 dann noch up?
Hast du re0 aus bridge0 vorher entfernt, bzw. bridge0 komplett gelöscht, bevor du ue0 reinpackst? Überall MTU1500?
Hast du mal alles rückgängig gemacht und mit Neustart versucht? Netzwerk über USB ist manchmal doch wackelig.
 
Jep, die wichtigste Frage: Funktioniert ue0 vorher? Ist ue0 up? Ist ue0 nach dazupacken in bridge0 noch up? Ist bridge0 dann noch up?
Hast du re0 aus bridge0 vorher entfernt, bzw. bridge0 komplett gelöscht, bevor du ue0 reinpackst? Überall MTU1500?
Hast du mal alles rückgängig gemacht und mit Neustart versucht? Netzwerk über USB ist manchmal doch wackelig.

Jetzt wo du das schreibst bin ich mir gerade auch nicht zu 100% sicher ob er ue plus re0 zur bridge hinzufügt oder nur ue0 und re0 nur ein Beispiel war das funktioniert
 
Ja. Hatte ich direkt verworfen, weil er ersetzen schrieb.
Ich weiß jetzt aber nichts über die Verkabelung bzw. wie sie aussehen soll, nicht dass man am Ende re0 ebenfalls noch in bridge0 braucht. Aber schaun wir mal :)
 
ue0 soll statt re0 laufen, und das tut auch alles einwandfrei, bis eben auf die bridge bzw. das anpingen der vm.
(Das Kabel wird einfach umgesteckt von der Laptop-Buchse auf die USB-Hub-Buchse)
 
Jep, die wichtigste Frage: Funktioniert ue0 vorher? Ist ue0 up? Ist ue0 nach dazupacken in bridge0 noch up? Ist bridge0 dann noch up?
Hast du re0 aus bridge0 vorher entfernt, bzw. bridge0 komplett gelöscht, bevor du ue0 reinpackst? Überall MTU1500?
alles ja
Hast du mal alles rückgängig gemacht und mit Neustart versucht?
nein, das führt zu der Frage, welche versteckten Parameter evtl. noch umgestellt werden müssen ...
 
Also ue0 funktioniert auch bis du ihn zur bridge hinzufügt?
ja auch danach
(Ich find den gerade nicht in den manuel pages, hast du evtl. da den link einmal für mich?)
gute Frage ...

ure(4):
Code:
ure0: <Realtek USB 10/100 LAN, class 0/0, rev 2.00/20.00, addr 4> on usbus0
miibus1: <MII bus> on ure0
ue0: <USB Ethernet> on ure0
anderer USB-Hub mit 1000er ure: gleiches Ergebnis.

Code:
re0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=82099<RXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE>
ue0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=68009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
 
Ich erinnere mich dunkel, dass man IPs immer auf der Bridge und nicht auf den member Interfaces Konfigurieren soll, weil das in bestimmten Konstellationen nicht funktioniert. Vielleicht liegt da dein Problem? Hast du eine IP auf ue0 gebunden?
 
Ja klar, ich mache das Gleiche mit ue0 wie vorher mit re0, also feste IP im lokalen Netz, und da ist das ja auch kein Problem.
 
Ich hatte vor längerer Zeit auch mal ein USB-Network-Interface über eine Bridge benutzt. Das war noch zu Zeiten von FreeBSD 9 und ist schon fast nicht mehr wahr. Ich kann mich aber sehr deutlich erinnern, daß bei mir das Problem war, daß das USB-Interface noch nicht geladen war, in dem Moment als das RC-Script die Bridge aufsetzen wollte. Das hatte ich erkannt, weil das manuelle Ausetzen der Bridge einwandfrei funktionierte, nur eben beim Hochfahren des Rechners nicht. Bei mir hatte es geholfen, alle zu meinem AXE ue0-Interface zugehörigen KLD's in der /boot/loader.conf einzutragen, so daß sie beim Bootvorgang frühzeitig geladen werden, denn devd lädt das zu spät.
 
(Das Kabel wird einfach umgesteckt von der Laptop-Buchse auf die USB-Hub-Buchse)
Hängt die defaultroute eventuell danach noch 'auf dem alten'? netstat -rn

welche versteckten Parameter evtl. noch umgestellt werden müssen
Als ich zuletzt was mit ue0 fummelte, war die geheime Zutat einfach der Neustart. Genauer untersucht hatte ich das nicht, das waren die 100Mbit via USB2.0 einfach nicht wert gewesen.
@obsigna Klingt gut.
 
Ich mache ja bei der bridge alles händisch, also irgendwelche rc-skripte haben damit nichts zu tun. Außer eben die geheimen Parameter, die man sonst noch braucht?
Die defaultroute wird jeweils gelöscht und neu gesetzt. Internet geht ja.
Ich habe sogar das vmm-Modul entladen und neu geladen.
 
Können wir mal bitte den ganzen output von ifconfig bridge0 sehen und nicht nur Ausschnitte davon, dann muß man den Rest nicht dazu erfinden.

Meine Brige sieht so aus:
Code:
bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1492
    description: LAN
    ether 00:11:0b:75:31:48
    inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
    inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255
    inet6 fd7d:ea40:4a0b:7b49::52 prefixlen 64
    id 00:11:0b:75:31:48 priority 32768 hellotime 2 fwddelay 15
    maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
    root id 00:11:0b:75:31:48 priority 32768 ifcost 0 port 0
    member: em1 flags=1e7<LEARNING,DISCOVER,STP,EDGE,AUTOEDGE,PTP,AUTOPTP>
            ifmaxaddr 0 port 3 priority 128 path cost 2000000 proto rstp
            role disabled state discarding
    member: em0 flags=1e7<LEARNING,DISCOVER,STP,EDGE,AUTOEDGE,PTP,AUTOPTP>
            ifmaxaddr 0 port 2 priority 128 path cost 2000000 proto rstp
            role designated state forwarding
    groups: bridge
    nd6 options=1<PERFORMNUD>
 
Code:
ue1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=280099<RXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE,RXCSUM_IPV6>
    ether 00:e0:4c:68:1c:c9
    inet 192.168.0.3 netmask 0xffffff00 broadcast 192.168.0.255
    media: Ethernet autoselect (1000baseT <full-duplex>)
    status: active
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
tap0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
    description: vmnet/arch/0/public
    options=80000<LINKSTATE>
    ether 58:9c:fc:10:3f:59
    groups: tap vm-port
    media: Ethernet autoselect
    status: active
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
    Opened by PID 8743
bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    ether 58:9c:fc:10:60:6a
    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: tap0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
            ifmaxaddr 0 port 4 priority 128 path cost 2000000
    member: ue1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
            ifmaxaddr 0 port 5 priority 128 path cost 20000
    groups: bridge
    nd6 options=9<PERFORMNUD,IFDISABLED>

-> ping zu google.de ja, ping zur vm nein

Code:
Destination        Gateway            Flags     Netif Expire
default            192.168.0.1        UGS         ue1
127.0.0.1          link#2             UH          lo0
192.168.0.0/24     link#5             U           ue1
192.168.0.3        link#5             UHS         lo0

es könnte mit der vm-switch zu tun haben:
Code:
> vm switch list
NAME    TYPE      IFACE  ADDRESS  PRIVATE  MTU  VLAN  PORTS
public  standard  -      -        no       -    -     ue0 re0
aber wenn ich versuche, ue1 hinzuzufügen, gibt es
> vm switch add public ue1 /usr/local/sbin/vm: ERROR: unable to locate switch id

entfernen geht auch nicht
> vm switch destroy public /usr/local/sbin/vm: ERROR: failed to remove virtual switch

..... ok die stehen in switch.conf und kann man ändern, bringt aber nichts.

Bei Umstecken+Umstellen auf re0 und hinzufügen zur bridge geht alles wunderbar.
 
Zuletzt bearbeitet:
Die info über vm-bhyve wäre vorher nützlich gewesen. :D
Wenn ue0 noch 'drinhängt', dann ebenfalls die MAC-Adresse, also kann das nicht klappen, wenn du nochmal ue1 mit der gleichen MAC reinhängen willst.

Geraten: Weil ue0 (bzw. das USB Gerät) nicht mehr existiert, kannst du den switch public nicht löschen.
Aus meiner Erinnerung, wenn das hängt: ue0 und re0 müssen aus dem switch raus. vm switch public rm ue0 oder so. Leermachen, dann switch löschen. Reboote zur Sicherheit, damit kein geisterndes USBGerät mehr rumfliegt.
Dann
Code:
vm switch create public
vm switch add public ue0
 
Muss sie nicht zwangsläufig haben. Entweder IP auf den members oder auf der bridge, aber auf keinen Fall beide.
 
ue0 ist ein anderes USB-Ethernet (mit 100 MBit) das aber i.M. gar nicht geht (wohl kaputt), darum zusätzlich ue1 angehängt.
Die bridge hatte noch nie eine IP-Adresse.
 
Nochmal der Reihe nach. Dein Netz ist 192.168.0.0/24, die routerbox 192.168.0.1/24, somit der gw und dns für deine physische Maschine und für die vm. Oder gibt es noch andere Netze?

Wenn der public switch sich nicht löschen lässt, dann ist da irgendwas verbogen und grätscht natürlich dazwischen für einen sauberen Anfang.
Falls jemand unbedarft via Suchmaschine herkommt: Ein switch ist eine bridge und eine bridge ist ein switch. :)

Vorschlag für sauberen Start und IP auf bridge/switch:
switch public löschen, egal über welchen Umweg
IPs von re0 und ue0 wegputzen (auch aus rc.conf rausnehmen)
reboot (auch wenn es wehtut :D)

Code:
vm switch create -a 192.168.0.3/24 public
#jetzt solltest du deine vm auch ohne gw pingen können, sofern die auch im netz 192.168.0.0/24 ist
vm switch add public ue0
#jetzt sollten host und vm 192.168.0.1 sowie 'raus' z.B. 8.8.8.8 pingen können, vorausgesetzt beide haben 192.168.0.1 als gw/default route
vm switch add public re0
#sahnehäubchen-test, damit sollte alles weiterlaufen, während man wild hin- und hersteckt

Nochmal Idee zu ue0: Es kann sein, dass der Part RJ-45 gesteckt und aktiv sein muss. Also Lämpchen an, bevor man dem irgendne config übergibt, so genau kenne ich das Chipverhalten nicht.
 
Muss sie nicht zwangsläufig haben. Entweder IP auf den members oder auf der bridge, aber auf keinen Fall beide.
Die Adresse muss unter FreeBSD bei verketteten / gestackten (tolles Wort) Interfaces immer auf dem letzten also obersten Interface liegen. :) Denn sonst: Die IP liegt auf ue0 -> Eingehendes Pakete werden auf ue0 getagt, kommen aber aus bridge0 raus und umgekehrt für ausgehende Pakete -> undefiniertes Verhalten. Wenn die IP auf bridge0 umzieht, wird es wahrscheinlich direkt oder (wenn sich ein dahinter liegender physischer Switch mit fragwürdiger Firmware verkackt hat) nach dem ARP-Timeout gehen. Das es mit IPs auf den Membern mit einer anderen NIC geht, kann gut sein, denn das Fiese bei undefiniertem Verhalten ist leider, dass es undefiniert ist...

Oder als Beispiel:
  • Die VM hinter tap0 hat (unsichtbar für den Kernel) 192.168.0.2/24 und ue0 hat 192.168.0.3/24.
  • Der Kernel sieht, dass beide Adressen im gleichen Netz liegen. Da Netz vor Routing gilt, wird ein an 192.168.0.2 gerichtetes Paket über 192.168.0.3 dorthin geschickt. Die Adresse liegt aber auf ue0, also unter bridge0. Der NIC-Treiber und die Firmware machen ihren Job, können den Weg aber nicht finden.
  • Was jetzt passiert ist undefiniert. Idealerweise findet das Paket irgendwie ihren Weg in die Bridge zurück. Das kann zum Beispiel passieren, indem der NIC-Treiber intelligent genug ist es doch noch auf bridge0 zurückzuschleifen. Oder indem es auf den Switch geschickt wird, der tap0 auf seiner ARP-Liste hat und es darüber über ue0 auf bridge0 schickt. Aber findet es den Weg nicht, landet es als unzustellbar im Nirvana.
 
Ah na klar...ich hab da rumgeeiert und gedanklich pingpong über Bande vom Router zurück gedacht. Jedenfalls hab ich das ausgedruckt, du hängst jetzt an meiner Pinnwand.
Einmal falsch gelernt ist immer schwerer. ;)
 
Ich persoenlich bin kein Fan von bridges. Die haben bei mir in der Vergangenheit immer irgendwelche Probleme gemacht. Daher gebe ich jedem Interface ein eigenes Netz und route / filter die dann uber die Firewall, wie z.B. pf. Wenn es bridges sein muessen, wuerde ich dort dann vether als bridge member nutzen und dieses virtuelle Interface an die vm binden und dort dann die IP konfigurieren und vether ueber die Firewall routen / filtern.
 
Zurück
Oben