NM-Verhalten – Abgetrennt aus "Android-Smartphone als Modem…"

[dufty2]

USB hat Vorrang

Nein. Es gilt wie überall anders auch longest prefix first.

nö, ich habe bei der Ausgabe von "ip a" sie unterschlagen, ist aber in beiden Fällen /24 und ergo kann das hier nicht gelten, es liegt an der Metrik (vgl. "ip r").

Mal abgesehen davon hat die "default-route" die kürzeste

[wanne]

USB hat Vorrang

Nein. Es gilt wie überall anders auch longest prefix first.

nö, ich habe bei der Ausgabe von "ip a" sie unterschlagen, ist aber in beiden Fällen /24 und ergo kann das hier nicht gelten.

Dann gilt (bei gleicher metrik) typischerweise das, was du zuerst hinzugefügt wurde. Man kann den kernel aber auch irgend wie dazu bringen, dass er es über beide routen verteilt, wenn ich mich richtig erinnere.

Mal abgesehen davon hat die "default-route" die kürzeste

Deswegen wird die ja auch nur genommen. Wenn es nichts anderes gibt.

[dufty2]

Dann gilt (bei gleicher metrik) typischerweise das, was du zuerst hinzugefügt wurde. Man kann den kernel aber auch irgend wie dazu bringen, dass er es über beide routen verteilt, wenn ich mich richtig erinnere.

Nö, das hat nix mit der Anschlußreihenfolge der Geräte zu tun.
Der Netzwerkmanager präferiert usb ("wired over wireless"), somit:

wlan an:
$ ip r
default via 192.168.3.1 dev wlan0 proto static
192.168.3.0/24 dev wlan0 proto kernel scope link src 192.168.3.198 metric 9

usb dazu:
$ ip r
default via 192.168.2.129 dev usb0 proto static
192.168.2.0/24 dev usb0 proto kernel scope link src 192.168.2.158 metric 1
192.168.3.0/24 dev wlan0 proto kernel scope link src 192.168.3.198 metric 9

wlan weg:
$ ip r
default via 192.168.2.129 dev usb0 proto static
192.168.2.0/24 dev usb0 proto kernel scope link src 192.168.2.158 metric 1

wlan dazu:
$ ip r
default via 192.168.2.129 dev usb0 proto static
192.168.2.0/24 dev usb0 proto kernel scope link src 192.168.2.158 metric 1
192.168.3.0/24 dev wlan0 proto kernel scope link src 192.168.3.198 metric 9

[dufty2]

Der Netzwerkmanager

Keine Ahnung was irgend welche verrükte Software macht. Ich kann auch in 5min ein Script basteln, dass die Route austauscht, wenn der bildschirm angeht.
Das gezeigte verhalten ist swieso einmal mehr ein Grund dafür, warum man das Ding nicht verwenden will. Das der die Route von nem anderen Interface zur hälfte wegwirft, wenn er ein neues aufmacht ist einfach nur kaputt. Für sowas gibt's metriken.

Da ist gar nichts verrückt daran, der default (wired over wireless) klappt für den Hausgebrauch beim Surfen zufriedenstellend. Anders (wireless over wired) wäre es, wenn man über AP surfen möchte, man aber NAS etc. am Kabel hängen hat.
Nebenbei bemerkt verwendet Linux (zuminderst der kernel selbst) gar keine Metriken ...

Außerdem bin ich mit HSDPA und E-Plus eigentlich nirgends a die 2 MBit/s rangekommen.

Die Werte, welche ich habe, schwanken zwischen 2 Mbit/s und 5 Mbit/s (das ist ein wirklicher Nachteil von wireless, die großen Schwankungen selbst bei einem ruhenden Handy).
Die 7,2 Mbit/s Maximum hab' ich noch nie erreicht. Spitze war bisher knapp über 6 Mbit/s (an einen Sonntag früh um Sechs),

[wanne]

Da ist gar nichts verrückt daran, der default (wired over wireless) klappt für den Hausgebrauch beim Surfen zufriedenstellend.

Naja er bekommts aber offensichtlich nicht hin. zumindest habe ich bei meinem Handy noch kein Kabel zum Internet gefunden. Er macht eher sowas wie IEEE 802.3 over IEEE 802.11. Ist aber nur indirekt das was ich bemängele.

Bemängeln tue ich, wie er das macht:
Er schmeißt die eine default route weg und nimmt die andere dafür her. Das lokale Netzwerk behöt er aber. Obwohl er vermutlich kein dhcp mehr laufen lässt. => Nach einer weile kann der dhcpserver wieder meine Adresse verteilen. Dmmerweiße behällt sie aber die aktuelle Schnittstelle sodass die hälfte der Pakete bei mir statt beim richtigen Empfänger ankommen. – Toll!
Die meisten dhcp-Server fixen das Serverseitig darüber dass sie möglichst lange mit der wiedervergabe von addressen warten aber bei größeren Netzwerken oder weil man einen Server hat der sich zwar standardkonform aber anders wie die meisten andern verhällt knallts.

Außerdem wäre es ganz nett wenn in der routingtabelle das steht was ich wirklich per dhcp bekommen habe. Statt irgend einem vom networkmanager verkrüppelten bullshit.

Als letztes wird es lustig, wenn ich eine route von Hand eintrage dann löscht der networkmanager die auch. Auch wenn ich ausdrücklich gesagt habe, dass ich das Zeug, dass ich von Hand eingetragen habe dem von dhcp-gelernten vorzuziehen ist. (Wie das auch sinnvoll ist.) Der networkmanager weiß es halt besser und setztsich über solch abstruse Nutzerwillen hinweg.

Sinnvoll währe es wenn er einfach WLAN interfaces z.B. mit metrik 3 und LAN interfaces mit 1 oder so eintragen würde. Dann hätt man für einfache konfigurationen den gleichen Effekt, aber jegliche andere konfiguration würde eben weiterhin funktionieren. Und ganz toll: Wenn ich weiß dass mein Handy eben kein gewöhnliches Kupferkabel ist, kann ich das mit metrik 4 hintendranschieben. Oder wenn ich ne strecke Wlan vor meinem Lankabel habe, könnte ich mit dem Microsoft dhcp-Server doch die metrik 3 mitgeben um zu erklären, dass das eben doch WLAN ist, auch wenn da am Ende IEEE 208.3 ankommt. (Auch wenn das nicht ganz standardkonform ist.)

Nebenbei bemerkt verwendet Linux (zuminderst der kernel selbst) gar keine Metriken ...

Na dann guck dir mal /usr/include/linux/rtnetlink.h an...
Ob das jetzt wirklich der Kernel umsetzt oder nur die Linux-glibc ist mir dann auch wurst. Es funktioniert. Auf jedem System auf dem auch der networkmanager läuft. Weil der braucht die glibc auch.

Außerdem bin ich mit HSDPA und E-Plus eigentlich nirgends a die 2 MBit/s rangekommen.

Die Werte, welche ich habe, schwanken zwischen 2 Mbit/s und 5 Mbit/s (das ist ein wirklicher Nachteil von wireless, die großen Schwankungen selbst bei einem ruhenden Handy).
Die 7,2 Mbit/s Maximum hab' ich noch nie erreicht. Spitze war bisher knapp über 6 Mbit/s (an einen Sonntag früh um Sechs),

Ich muss nochmal messen wenn ich nicht gerade aus meinem Datenvolumen bin. (Normalerweiße reichts mir immer Gut aber diesen Monat war einfach viel zu viel los, solange ich nicht zuhause war.)
Aber ich meine meist so um die 400kbit/s gehabt zu haben. Allerdings benutze ich HSDPA in erster Linie im Zug, und da kommt man schon wegen der Geschwindigkeit nie auf vernünftige Datenraten. Auch nicht auf die 400kbit/s. Oft ist man mit GPRS sogar schneller als mit HSDPA, weil die Zellen größer sind und man so weniger DCs hat.

[dufty2]

Er schmeißt die eine default route weg und nimmt die andere dafür her. Das lokale Netzwerk behöt er aber. Obwohl er vermutlich kein dhcp mehr laufen lässt. => Nach einer weile kann der dhcpserver wieder meine Adresse verteilen. Dmmerweiße behällt sie aber die aktuelle Schnittstelle sodass die hälfte der Pakete bei mir statt beim richtigen Empfänger ankommen. – Toll!

Stellst Du gerne Behauptungen auf?
Fakt ist, dass der NM zwei dhclient-prozesse startet, für je usb0 und wlan0.
Und beide bekomme auch auf ihren jeweiligen Interfaces ihre DHCPACKs erneut zugewiesen;
überprüft mit 2 wiresharks.

Na dann guck dir mal /usr/include/linux/rtnetlink.h an...
Ob das jetzt wirklich der Kernel umsetzt oder nur die Linux-glibc ist mir dann auch wurst. Es funktioniert. Auf jedem System auf dem auch der networkmanager läuft. Weil der braucht die glibc auch.

Metriken werden für die Routing-Daemonen bereitgehalten, von "sich aus" benutzt der Kernel sie nicht.

Aber ich meine meist so um die 400kbit/s gehabt zu haben.

400 kbit/s = 50 kByte/s war vor Jahren, mittlerweile könnte man HSPA+ ( und teils sogar LTE) haben (falls das Handy mitspielen würde, meins leider nicht )

[wanne]

Stellst Du gerne Behauptungen auf?
Fakt ist, dass der NM zwei dhclient-prozesse startet, für je usb0 und wlan0.
Und beide bekomme auch auf ihren jeweiligen Interfaces ihre DHCPACKs erneut zugewiesen;
überprüft mit 2 wiresharks.

Ok, dann macht er das mittlerweile besser. (War aber garantiert nicht immer so.) Aber bei weitem nicht richtig. Ein ACK zu übergeben ohne die route wirklich hinzuzufügen ist auch ordentlicher quatsch. Vor allem weil ich danach nicht mehr überprüfen kann, was jetzt die richtige Route gwesen wäre.

Metriken werden für die Routing-Daemonen bereitgehalten

Und was ist dhclient? Ja: Der mit abstand dümmste routing deamon. Ist aber eben nicht nur für routing deamons sondern auch für statisch konfigurierte routen.

von "sich aus" benutzt der Kernel sie nicht.

Ich weiß nicht, was du mit von "sich aus" meinst aber wenn man die entsprechende API richtig benutzt funktioniert das richtig. Schönes Beispiel für was, dass das richtig macht ist route:

Code: Alles auswählen

route add -net 0.0.0.0/0 gw 141.0.0.7 metric 5
route add -net 0.0.0.0/0 gw 141.0.0.8 metric 3
route add -net 0.0.0.0/0 gw 141.0.0.9 metric 7

Genutzt wird am Ende schön 141.0.0.8 weil das die kleinste Metrik hat.
Per default einfach 0 zu nutzen ist auf jeden Fall besonders dumm, weil man das dann nicht mehr unterbieten kann.

Fakt ist, dass der NM zwei dhclient-prozesse startet

Dann liegt das zum teil wohl auch weniger am networkmanager als am dhclient dessen verhalten ist vorsichtig formuliert recht gewöhnungsbedürftig. Wenn man sich aber dazu entscheidet sowas zu nutzen, sollte man halt gucken dass man das dan richtig hinbekommt.

[dufty2]

Schönes Beispiel für was, dass das richtig macht ist route:

Code: Alles auswählen

route add -net 0.0.0.0/0 gw 141.0.0.7 metric 5
route add -net 0.0.0.0/0 gw 141.0.0.8 metric 3
route add -net 0.0.0.0/0 gw 141.0.0.9 metric 7

Genutzt wird am Ende schön 141.0.0.8 weil das die kleinste Metrik hat.

Schönes Beispiel für was, wie man es gerade NICHT macht

Der Network-Manager ist nicht für Power-User ala wanne konzipiert, die gerne an ihren Rechner resp. Routingtabelle(n) rumspielen, sondern für _dynamische_ Umgebungen.
D. h., für Menschen, welche ohne großes Fachwissen einfach mal ein Kabel reinstecken und auch mal wieder auf die Schnelle rausreißen und/oder den AP abknipsen.
Das LETZTE was man diesen Leute beibringen will, ihnen dabei drei Befehle einklopfen zu lassen, wobei 2 Zeilen überflüssig wären, wenn anstatt "Kabeltausch" der Rechner einfach runtergefahren wird (was man zuvor gar nicht weiß) ...