Bitte um Nachhilfe: Ein WLAN-Router plus 1 Linux-PC und 1 FreeBSD-PC

Okay, ich werde das testen mit der Direktverbindung. Das geht aber erst später heute nachmittag, dann schicke ich Dir auch die gewünschten Ausgaben von systemctl etc... Danke!
 
Und, hehe, ich habe noch einen zweiten Switch auftreiben können, einen kleinen 8-Port TP-Link, TL-SG108S, der seine Funktionsfähigkeit bereits unter Beweis gestellt hat. Bin gespannt...
 
So, erste Ergebnisse mit einem anderen Switch und einem anderen Ethernet-Kabel:

Den arping-Befehl habe ich fünfmal in kurzer Folge nacheinander eingegeben, ein Timeout nach dem anderen. Beim sechsten Mal dann Antwort, 1,8 ms.

Ich habe auch ein kleines Testprogramm, ptest.sh, geschrieben, das nacheinander 10.10.10.1, 10.0.0.100, 10.0.0.1, 8.8.8.8 und google.com anpingt. Bei einem Durchlauf war das erste Ergebnis Host down, das zweite no route to host, das dritte auch, die letzten beiden dann erfolgreich.

Das Problem dabei ist, daß auch ganz praktische Anwendungen auf Grund von Timeouts scheitern, so z. B. der Versuch, pkg install xfe auszuführen. Für so etwas muß ich dann umschalten, damit der FreeBSD sich über wlan0 direkt mit dem NR2301 verbindet.

Und ich verstehe nach wie vor folgendes nicht: Braucht ein Rechner mit einem Interface (em0) überhaupt eine Default-Route? Das ergibt für mich wenig Sinn. Wenn ich den Befehl route add default 10.10.10.1 aber weglasse, habe ich Null Verbindung zum Linux-Rechner.

Nach dem Booten zeigt mir ifconfig auf FreeBSD nur em0 mit der Adresse 10.10.10.10., netmask 0xffffff00, up und active. Ein ping von Linux auf 10.10.10.10 gibt Antwort!

Auf FreeBSD ergibt time ping -c 1 10.10.10.1 11 s im Mittel.

Jetzt teste ich mal die direkte Kabelverbindung...

Von Linux aus ist ping 10.10.10.10 okay, auf FreeBSD sehr verzögerte Antwort auf ping 10.10.10.1.

Ohne route add default 10.10.10.1 bekomme ich höchstens eine Antwort von 10.10.10.1, alles andere geht nicht durch bzw. kommt nicht zurück. Mit der Default-Route kommt dann auch Antwort von google.com, aber es ändert sich nichts an der Unzuverlässigkeit der Verbindung, egal ob über Switch oder direkt.
 
Ich habe jetzt eine externe USB-NIC an den FreeBSD angeschlossen. Ganz neues Interface ue1. Mein oben beschriebenes ptest.sh hat nur beim ping auf 10.10.10.1 ab und zu Probleme mit 100% oder auch mal 34% packet loss, der Rest saust gerade so durch mit 0% packet loss.

Das mal als Zwischenergebnis. Mir persönlich ist damit immer noch nicht klar, ob da ein technisch-physikalisches Problem mit hineinspielt. Der onboard NIC könnte eine Macke haben, so etwas habe ich schon an anderen Rechnern erlebt. Aber mit dem USB-NIC sieht es zwar etwas besser aus, aber nicht alle Probleme sind beseitigt. Also, immer noch irgendwie unklar, was da abgeht.
 
Encabulator schrieb:
Auf dem Linux-Rechner verwende ich Kali. Das Netzwerkmanagement läuft über systemd, networking.service. Über das Applet in der Taskbar habe ich eth0 konfiguriert mit der statischen Adresse 10.10.10.1/24.

Ich bin zur Zeit nicht zu Hause, daher habe ich nur zwei Rechner plus diesen Switch dabei, um die Versuche zu machen.

Das NAT/Masquerading führe ich nach dem Booten von Hand aus:
iptables -t nat -A POSTROUTING -o 10.0.0.1 -j MASQUERADE

10.0.0.1 ist der Zyxel-Router. Ich hoffe, das ist die korrekte Adresse an dieser Stelle.

Verstehe ich das richtig, daß der iptables-Befehl auch für die entsprechende Rückroute sorgen würde? (Wäre ja auch sinnvoll, denn wenn er maskiert, müßte er ja auch zurückübersetzen könnten...)
Zum Vergrößern anklicken....
Ich hab gerade nicht den Kopf mich hier im Thread zu engagieren, aber ihr habt ja ein bisschen Probleme schon eine saubere Verbindung nur zwischen dem FreeBSD und dem Linux zustande zu pringen. Da sollte es eigentlich auf anhieb beim ping und ohne verluste funktionieren, sonst ist da etwas schief.

Ein Crossoverkabel sollte nicht benötigt werden sofern mindestens gigabitadapter verwendet werden da die im Standard Autosensing können sollten.

Nur ein Gedankengang: Du schreibst von "systemd" "networking.service"
Networking Service ist aber nun gerade nicht systemd-networkd.

Nicht sehr belastbar, aber funkt dir beim Linux da villeicht was in der Netzwerkconfig rum? Es ist unter Linux sehr leicht mehrere Dienste zu starten die sich gegenseitig das Netzwerk zerschießen, oft erst bemerkbar wenn man nicht-standard-configs macht wie hier.

"Über das Applet in der Taskbar" ist für mich ein hint dadrauf das es NetworkManager sein könnte, aber das wäre mein erster Ansatz - herauszufinden welche Dienste da laufen, sicherzustellen das nur EINER wirklich was am netzwerk rumkonfiguriert und dann noch in dessen doku zu schauen ob man da etwas bestimmtes machen muss für eine einfache, statische konfiguration ohne route und ohne firewall.

Oh: Und du verwendest Kali-Linux und das ist ja auch unter anderem irgendwo son gehärtetes ding, oder? Kann da evtl. irgend ein Firewalldienst dir irgendwie Querschießen?
 
Encabulator schrieb:
..., auf FreeBSD sehr verzögerte Antwort auf ping 10.10.10.1.
Zum Vergrößern anklicken....
Das sollte geklärt werden, ... was aber schwierig ist, wenn Du nur beschreibst, aber die vollständigen Ausgaben von:
Code: 
ifconfig
netstat -4nr
arp -a
ip a
ip r
ip n s
ping -c 3 <IP-Adresse>
arping -c 3 -I <Interface> <IP-Adresse>
iptables -nvx -L
pfctl -v -s rules
hier nicht postest bzw. nicht zeigst.
 
Ergebnisse vom FreeBSD:

Code: 
T420s% ifconfig
em0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=4e524bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG>
        ether f0:de:f1:80:3a:be
        media: Ethernet autoselect
        status: no carrier
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
lo0: flags=1008049<UP,LOOPBACK,RUNNING,MULTICAST,LOWER_UP> metric 0 mtu 16384
        options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
        inet 127.0.0.1 netmask 0xff000000
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
        groups: lo
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
ue0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=80000<LINKSTATE>
        ether 02:80:37:ec:02:00
        media: Ethernet autoselect
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
ue1: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
        options=8000b<RXCSUM,TXCSUM,VLAN_MTU,LINKSTATE>
        ether f8:e4:3b:92:8b:b5
        inet 10.10.10.10 netmask 0xffffff00 broadcast 10.10.10.255
        inet6 fe80::fae4:3bff:fe92:8bb5%ue1 prefixlen 64 scopeid 0x4
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>

Code: 
T420s% netstat -4nr

Routing tables

Internet:
Destination        Gateway            Flags         Netif Expire
default            10.10.10.1         UGS             ue1
10.10.10.0/24      link#4             U               ue1
10.10.10.10        link#2             UHS             lo0
127.0.0.1          link#2             UH              lo0

Code: 
root@T420s:~ # arp -a
? (10.10.10.10) at f8:e4:3b:92:8b:b5 on ue1 permanent [ethernet]
? (10.10.10.1) at c8:a3:62:b4:d4:ae on ue1 expires in 927 seconds [ethernet]

Hier kommen jetzt die ip-Befehle, aber ip gibt's ja nicht auf FreeBSD. Ich lasse die jetzt mal aus und schicke Dir den Rest vom FreeBSD. Soll ich dann alles auch noch vom LInux-Rechner schicken?
 
Code: 
root@T420s:~ # ping -c 3 10.10.10.1
PING 10.10.10.1 (10.10.10.1): 56 data bytes
64 bytes from 10.10.10.1: icmp_seq=0 ttl=64 time=1.544 ms
64 bytes from 10.10.10.1: icmp_seq=1 ttl=64 time=1.585 ms
64 bytes from 10.10.10.1: icmp_seq=2 ttl=64 time=1.478 ms

--- 10.10.10.1 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.478/1.536/1.585/0.044 ms

Code: 
root@T420s:~ # arping -c 3 -I ue1 10.10.10.1
ARPING 10.10.10.1
60 bytes from c8:a3:62:b4:d4:ae (10.10.10.1): index=0 time=1.552 msec
60 bytes from c8:a3:62:b4:d4:ae (10.10.10.1): index=1 time=1.506 msec
60 bytes from c8:a3:62:b4:d4:ae (10.10.10.1): index=2 time=1.612 msec

--- 10.10.10.1 statistics ---
3 packets transmitted, 3 packets received,   0% unanswered (0 extra)
rtt min/avg/max/std-dev = 1.506/1.556/1.612/0.043 ms
 

Anhänge

CommanderZed schrieb:
Ich hab gerade nicht den Kopf mich hier im Thread zu engagieren, aber ihr habt ja ein bisschen Probleme schon eine saubere Verbindung nur zwischen dem FreeBSD und dem Linux zustande zu pringen. Da sollte es eigentlich auf anhieb beim ping und ohne verluste funktionieren, sonst ist da etwas schief.

Ein Crossoverkabel sollte nicht benötigt werden sofern mindestens gigabitadapter verwendet werden da die im Standard Autosensing können sollten.

Nur ein Gedankengang: Du schreibst von "systemd" "networking.service"
Networking Service ist aber nun gerade nicht systemd-networkd.

Nicht sehr belastbar, aber funkt dir beim Linux da villeicht was in der Netzwerkconfig rum? Es ist unter Linux sehr leicht mehrere Dienste zu starten die sich gegenseitig das Netzwerk zerschießen, oft erst bemerkbar wenn man nicht-standard-configs macht wie hier.

"Über das Applet in der Taskbar" ist für mich ein hint dadrauf das es NetworkManager sein könnte, aber das wäre mein erster Ansatz - herauszufinden welche Dienste da laufen, sicherzustellen das nur EINER wirklich was am netzwerk rumkonfiguriert und dann noch in dessen doku zu schauen ob man da etwas bestimmtes machen muss für eine einfache, statische konfiguration ohne route und ohne firewall.

Oh: Und du verwendest Kali-Linux und das ist ja auch unter anderem irgendwo son gehärtetes ding, oder? Kann da evtl. irgend ein Firewalldienst dir irgendwie Querschießen?
Zum Vergrößern anklicken....
Ich muß mich da erstmal wirklich schlau machen. Kali-Linux verwende ich eigentlich nur, weil ich sehr gute Erfahrungen bei der Installation gemacht habe und weil ich die rolling distribution mag, das bietet außer Kali niemand. Bislang mußte ich mich mit der Netzwerkkonfiguration nicht groß beschäftigen, schon gar nicht auf Ebene von iptables oder nftables. Aber anscheinend ist der Zeitpunkt gekommen, das zu tun. - Das Kali speziell gehärtet wäre, wüßte ich nicht, aber was weiß ich schon :) Hab' jedenfalls nichts in der Richtung bemerkt. Ich werde also in der Richtung auch weiterarbeiten, im Moment komme ich mir sowieso ziemlich blöd vor, denn ich weiß mir keinen Rat. Das Verhalten ist so komisch, als wenn da eine Zeitschaltuhr mitlaufen würde: Jetzt darfste, jetzt darfste wieder nich...
 
morromett schrieb:
Das
Code: 
ip a
ip r
ip n s
ping -c 3 IP-Adresse
arping -c 3 -I Interface IP-Adresse
iptables -nvx -L
betrifft Linux und ist auch so für Linux gemeint.
Zum Vergrößern anklicken....
Ich habe Dir zwei Textdateien geschickt, die eine beinhaltet die Informationen des Linux-Rechners, die andere die des BSD-Rechners. Wenn Du mehr brauchst, sag's, ich wandele das dann in Skripte um und schicke die Dateien, das ist einfacher, als hier hundertmal copy and paste zu machen...
 
Encabulator schrieb:
Code: 
root@T420s:~ # ping -c 3 10.10.10.1
PING 10.10.10.1 (10.10.10.1): 56 data bytes
64 bytes from 10.10.10.1: icmp_seq=0 ttl=64 time=1.544 ms
64 bytes from 10.10.10.1: icmp_seq=1 ttl=64 time=1.585 ms
64 bytes from 10.10.10.1: icmp_seq=2 ttl=64 time=1.478 ms

--- 10.10.10.1 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.478/1.536/1.585/0.044 ms

Code: 
root@T420s:~ # arping -c 3 -I ue1 10.10.10.1
ARPING 10.10.10.1
60 bytes from c8:a3:62:b4:d4:ae (10.10.10.1): index=0 time=1.552 msec
60 bytes from c8:a3:62:b4:d4:ae (10.10.10.1): index=1 time=1.506 msec
60 bytes from c8:a3:62:b4:d4:ae (10.10.10.1): index=2 time=1.612 msec

--- 10.10.10.1 statistics ---
3 packets transmitted, 3 packets received,   0% unanswered (0 extra)
rtt min/avg/max/std-dev = 1.506/1.556/1.612/0.043 ms
Zum Vergrößern anklicken....
Das ist doch der ping und arping von FreeBSD zu Linux. In diesen Ausgaben kann man keine Verzögerung bzw. Probleme sehen.

EDIT:

Auch in beiden Textdateien sind arping und ping OK. BTW: arping immer vor dem ping ausführen.
Du könntest jetzt auch auf beiden Seiten (Linux und FreeBSD) persistente statische arp-/neighbor-cache-Eintragungen machen und auf beiden Seiten (Linux und FreeBSD), in der systemweiten crontab, cronjobs mit minütlichen arpings eintragen.
 
Dieses Foto habe ich von einem ping auf T420s (FreeBSD) gemacht, ist schon einen Tag her, zeigt aber, was passiert. Auf einmal kommt eine Antwort, ohne daß ich mich auch nur bewegt hätte...
 

Anhänge

  • photo_2026-02-03_19-36-25.webp
    photo_2026-02-03_19-36-25.webp
    201,2 KB · Aufrufe: 14
Encabulator schrieb:
..., ist schon einen Tag her, zeigt aber, was passiert. Auf einmal kommt eine Antwort, ohne daß ich mich auch nur bewegt hätte...
Zum Vergrößern anklicken....
Das war aber noch mit dem anderen Switch, oder?
Mach mal folgenden Eintrag:
Code: 
* *    * * *   root    /usr/bin/arping -q -c 2 -w 2 -b -f -I eth0 -s 10.10.10.1 10.10.10.10 > /dev/null 2>&1
# - - -
ans Ende der /etc/crontab in deinem Linux und beobachte ob es noch solche Verzögerungen gibt. Wenn ja, dann auch in FreeBSD so einen cronjob eintragen.
Beobachten kannst Du dann auch in FreeBSD, mit z. B.:
Code: 
tcpdump -c 500 -vvveni ue1 arp and host 10.10.10.1
 
Ich habe eben als erstes ein Foto von meinem Ping-Test-Programm auf FreeBSD gemacht, siehe Foto_FBSD. Sofort danach habe ich in einer SSH-Session, die ich auf dem Linux-Rechner mit ssh hmb@10.10.10.1 eröffnet wurde, das gleiche Programm gestartet, siehe Foto_ZB14. Ich kann mir keinen Reim darauf machen.
 

Anhänge

  • Foto_FBSD.webp
    Foto_FBSD.webp
    201,3 KB · Aufrufe: 12
  • Foto_ZB14.webp
    Foto_ZB14.webp
    263,6 KB · Aufrufe: 15
morromett schrieb:
Das war aber noch mit dem anderen Switch, oder?
Mach mal folgenden Eintrag:
Code: 
* *    * * *   root    /usr/bin/arping -q -c 2 -w 2 -b -f -I eth0 -s 10.10.10.1 10.10.10.10 > /dev/null 2>&1
# - - -
ans Ende der /etc/crontab in deinem Linux und beobachte ob es noch solche Verzögerungen gibt. Wenn ja, dann auch in FreeBSD so einen cronjob eintragen.
Beobachten kannst Du dann auch in FreeBSD, mit z. B.:
Code: 
tcpdump -c 500 -vvveni ue1 arp and host 10.10.10.1
Zum Vergrößern anklicken....
Werde ich machen! Kann ich aber erst morgen umsetzen. Vielen Dank, Rückmeldung folgt ;)
 
Encabulator schrieb:
Ich muß mich da erstmal wirklich schlau machen. Kali-Linux verwende ich eigentlich nur, weil ich sehr gute Erfahrungen bei der Installation gemacht habe und weil ich die rolling distribution mag, das bietet außer Kali niemand.
Zum Vergrößern anklicken....
Nur fürs Protokoll - es gibt doch seit ewigkeiten rolling-release distros wie Gentoo oder Archlinux, etwas neuer auch zb Opensuses Tumbleweed und so und letztlich kann man Debian-Testing im weiteren sinne auch so bezeichnen. Ich dachte Kali wäre als Besonderheit für so diverse Security und so sachen speziell zugeschnitten.

Ansonsten viel erfolg beim suchen, ein guter einstieg könnte sein sich mal per systemd anzuschauen welche dienste so laufen.
 
Ich habe ein kleines Testprogramm geschrieben, ptest.sh:

Code: 
#!/bin/sh
echo
echo "ptest.sh starting: <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<"
date +"%Y-%m-%d@%H:%M:%S"
echo --------------------------------------------------------------
ping -c 1 10.10.10.1
echo --------------------------------------------------------------
ping -c 1 10.0.0.100
echo --------------------------------------------------------------
ping -c 1 10.0.0.1
echo --------------------------------------------------------------
ping -c 1 8.8.8.8
echo --------------------------------------------------------------
ping -4 -c 1 google.com
echo --------------------------------------------------------------
date +"%Y-%m-%d@%H:%M:%S"
echo "ptest.sh finished <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<"
echo

Ich kann dieses Programm mehrmals hintereinander 100% erfolgreich ausführen. Wenn ich dann 10 oder 20 Sekunden warte und es noch einmal starte, funktioniert nichts davon, kein einziger ping geht durch. Wenn ich dann einfach mehrmals erneut versuche, es auszuführen, klappt es irgendwann. Zu allem Überfluß gibt es Fälle, in denen die ersten pings fehlschlagen, die auf 8.8.8.8 und google.com jedoch gelingen.

Ich habe heute mal ChatGPT bemüht, er erzählt ja im Prinzip dasselbe wie Morrometts Lösung, es ändert alles nichts an diesem Zeitscheibenproblem.

Er hat auch erzählt, jaja, das liege am STP-Protokoll auf meinem Switch. Ich habe dann die Direktverbindung wieder geschaltet, und das Ergebnis war exakt das gleiche. Davon abgesehen: Das mit dem Switch ergibt doch keinen Sinn, das Ding ist dumm und dämlich, ein simpler, unmanageable plug-and-play Switch, da müßten ja dann ganze Serien von buggy sein, das ist keine vernünftige Theorie. Zumal ich ja hier schon zwei Switches ausprobiert habe, einen von HP, einen von TP-Link. UND ich habe das Direktkabel getestet! UND ich habe die Netzwerkschnittstelle auf dem FreeBSD getauscht. Egal, was ich auf der physischen Ebene geändert habe: Das Problem ist und bleibt das gleiche.

Ich sag's ehrlich, wie's ist: Ich kann nicht mehr. Ich habe sogar überlegt, mir einen neuen Rechner zu kaufen, irgendso ein gebrauchtes, olles ThinkPad. Habe ich aber zu Hause, haha. Also, das werde ich nicht tun. Ich mache jetzt folgendes: Ich werde mal wieder produktiv, schalte den FreeBSD wieder so, daß er direkt über den NR2301 geht, und wenn ich wieder zu Hause bin, setze ich einen zweiten FreeBSD-Rechner auf und schaue mir das ganze dort mal an. Dann werden wir ja sehen, ob der T420s irgendwie krank ist (obwohl der bei mir im lokalen Netzwerk zu Hause top funktioniert hat, keinerlei Anzeichen von Netzwerkproblemen), oder was sonst hinter dem Problem stecken könnte.

Ich habe so etwas noch nie erlebt (und ich habe beruflich jahrzehntelang mit Computer-Netzen zu tun gehabt), und im Moment stehe ich vor einer Wand.
 
CommanderZed schrieb:
Und einmal ... ein traceroute als ausgabe hier
-> Linux -> Zyxel (nur ping)
-> Linux 8.8.8.8
-> FreeBSD Linux (Nur ping)
-> FreeBSD Zyxel
-> FreeBSD 8.8.8.8
Zum Vergrößern anklicken....
Vielleicht habe ich es überlesen, aber hast du irgendwo die Ausgabe von traceroute gezeigt? Der Vorteil von traceroute ist, dass du siehst, bei welchem "hop" es ggfls. klemmt.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben