[Abgebrochen] Laptop kein Internet (LAN/WLAN/USB Tethering)

[psyca]

Dann ist doch der PC der Router und nicht die Broadcast-Adresse? Als erstes würde ich mal versuchen, den Laptop direkt per Kabel an den Router anzuschließen, um mal generelle Verbindungsprobleme (wie von alf berichtet) auszuschließen

Naja. Broadcast = Gateway. In dem Fall eben die "Weiterschleif-IP" des PCs, oder verstehe ich da gerade etwas nicht? Sollte doch im "Normalfall" die IP des Routers sein?

Werde den Direktanschluss am Router probieren wenn der Laptop neu aufgesetzt ist.

[alf]

Da scheint noch jemand ein vor einem ähnlichen Problem zu stehen: https://forums.mageia.org/en/viewtopic.php?f=25&t=10840

[man-draker]

Naja. Broadcast = Gateway. In dem Fall eben die "Weiterschleif-IP" des PCs, oder verstehe ich da gerade etwas nicht? Sollte doch im "Normalfall" die IP des Routers sein?

Grundlegendes Missverständnis!

Ein Gateway ist die Angabe, wohin mit Paketen, die den Rechner verlassen sollen und für die es keine dezidierte Route gibt.
Also so ungefähr, "alles wo du nicht so genau weißt, wohin damit, schick mal ans Gateway".
Als Ziel ist immer die Adresse eines einzelnen Gerätes anzugeben.
In deinem Fall ist das die Adresse des PC zum Notebook hin.

Ein Broadcast ist ein Rundruf an alle, die zuhören. Die dafür genutzte Adresse darf keinem einzelnen Gerät im Netz zugeordnet sein.

Mithin sind die von dir geposteten manuellen Eingaben nicht zielführend. Der Laptop hat zwar eine Broadscastadresse aber keinen Gateway. Also weiß er nicht wohin mit den Päckchen.

[man-draker]

Also so sieht die Konfiguration aus:
Router ---WLAN---> PC ---LAN---> Laptop

Was gibt denn der Befehl "route" auf dem Laptop aus?

[man-draker]

Irgendwie weigert sich mein Laptop mit Cauldron ans Netz zu gehen.

... habe ich die vollständige Installation über das LAN mit der boot-nonfree.iso durchführen können. Nun startet Mageia 6 doch irgendetwas stimmt nicht.

• Hattest du eine boot-nonfree.iso für MGA6,
• oder hast du die Quellverzeichnisse angepasst,
• oder hast du erst MGA5 installiert und dann, wie im Wiki beschrieben, auf Cauldron upgedated?

[psyca]

• Hattest du eine boot-nonfree.iso für MGA6,
• oder hast du die Quellverzeichnisse angepasst,
• oder hast du erst MGA5 installiert und dann, wie im Wiki beschrieben, auf Cauldron upgedated?

Eine boot-nonfree.iso für MGA6. Die liegen auf den Servern unter
Mageia/distrib/cauldron/x86_64/install/images/
bzw. Mageia/distrib/cauldron/i586/install/images/
Habe es gerade mit der aktuellen vom 10.03 versucht. Jetzt wird der Bildschirm während dem installer direkt schwarz nach einer gewissen Zeit und es passiert nichts
Mache jetzt wieder MGA 5 drauf.

Was gibt denn der Befehl "route" auf dem Laptop aus?

Kann ich leider nichtmehr schreiben, aber mit der routing Tabelle war auch irgendwas nicht in Ordnung. Manuell anpassen hat nicht so wirklich funktionert.

[man-draker]

Ich habe die Installation nachvollzogen und das Problem tritt auch hier auf.

Der Rechner bekommt zwar noch seine IP per DHCP, route und resolv.conf sind vorhanden, aber es ist keine Verbindung nach außen möglich.

Code: Alles auswählen

[root@localhost ~]# systemctl status network.service
● network.service - LSB: Bring up/down networking
   Loaded: loaded (/etc/rc.d/init.d/network; bad; vendor preset: enabled)
   Active: failed (Result: exit-code) since So 2016-03-13 08:15:42 CET; 8min
ago
     Docs: man:systemd-sysv-generator(8)
  Process: 1072 ExecStart=/etc/rc.d/init.d/network start (code=exited,
status=1/FAILURE)
   CGroup: /system.slice/network.service
           ├─1361 /sbin/ifplugd -I -b -i enp2s0
           └─1630 /sbin/dhclient -1 -q -lf
/var/lib/dhclient/dhclient--enp2s0.lease -pf /var/run/dhclient-enp2s0

Mär 13 08:15:42 localhost systemd[1]: network.service: Control process exited,
code=exited status=1
Mär 13 08:15:42 localhost systemd[1]: Failed to start LSB: Bring up/down
networking.
Mär 13 08:15:42 localhost systemd[1]: network.service: Unit entered failed
state.
Mär 13 08:15:42 localhost systemd[1]: network.service: Failed with result
'exit-code'.
Mär 13 08:15:44 localhost dhclient[1427]: DHCPDISCOVER on enp2s0 to
255.255.255.255 port 67 interval 3
Mär 13 08:15:44 localhost dhclient[1427]: DHCPREQUEST on enp2s0 to
255.255.255.255 port 67
Mär 13 08:15:44 localhost dhclient[1427]: DHCPOFFER from 10.0.0.1
Mär 13 08:15:44 localhost dhclient[1427]: DHCPACK from 10.0.0.1
Mär 13 08:15:44 localhost ifplugd(enp2s0)[1361]: client: Determining IP
information for enp2s0... done.
Mär 13 08:15:44 localhost ifplugd(enp2s0)[1361]: Program executed successfully

[root@localhost ~]# ifconfig
enp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.0.40  netmask 255.0.0.0  broadcast 10.0.0.255
        inet6 fe80::226:18ff:fe88:7089  prefixlen 64  scopeid 0x20<link>
        ether 00:26:18:88:70:89  txqueuelen 1000  (Ethernet)
        RX packets 412  bytes 50604 (49.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 22  bytes 2382 (2.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 1  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1  (Lokale Schleife)
        RX packets 79809  bytes 8916636 (8.5 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 79809  bytes 8916636 (8.5 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[root@localhost ~]# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 10.0.0.1

[root@localhost ~]# route
Kernel IP Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
default         gateway         0.0.0.0         UG    0      0        0 enp2s0
10.0.0.0        0.0.0.0         255.0.0.0       U     0      0        0 enp2s0
link-local      0.0.0.0         255.255.0.0     U     1002   0        0 enp2s0

[alf]

Einen workaround für dieses Problem hab ich ja bereits in meinem ersten Beitrag gepostet. Nimm in der Konfiguration den Haken bei "DNS über DHCP beziehen weg" und setz die IP des Routers als DNS ein.

[man-draker]

Gut, klappt. Ist das schon als Bug gemeldet?

[doktor5000]

Die Standardroute sieht seltsam aus. Schau mal ggf. ob dir da der systemd-Dienst für automatische Gateway-Auflösung reinfunkt,
kuck mal nach systemd-resolved.service und siehe auch https://wiki.archlinux.org/index.php/systemd-networkd

[alf]

Hab noch nicht intensiv danach geschaut, aber ich glaube nicht. Soweit ich das mitbekommen habe ist das Problem in dieser Form auch noch nicht in der qa-discuss ML thematisiert worden.

[alf]

Die Standardroute sieht seltsam aus.

Wobei

Code: Alles auswählen

route -n

bzw.

Code: Alles auswählen

netstat -rn

die richtige IP des Routers anzeigt. Allerdings gibt

Code: Alles auswählen

route

/

Code: Alles auswählen

netstat -r

dann den Namen des Routers mit "gateway" statt "fritz.box" aus.

[doktor5000]

Ja, das mit dem Hostname "gateway" meine ich. Soweit ich mich erinnere, gibt es einen systemd-Automatismus, welcher automatisch den Pseudo-Hostnamen "gateway" verbindungsabhängig korrekt aufzulösen versucht und auch versucht das Standard-Gateway zu bestimmen.

Wobei ich prinzipiell das Problem gar net nachvollziehen kann. Installiert am Donnerstag von Mageia-6-dev1-x86_64-DVD.iso und anschließend per drakconnect WLAN-Verbindung eingerichtet, per DHCP. Alles normal.
Per boot-nonfree Image kann ich nicht installieren, da während der Installation nur WPA2-verschlüsselte WLAN-Verbindung vorhanden ist.

[psyca]

Gut, klappt. Ist das schon als Bug gemeldet?

Von mir jedenfalls nicht Wäre gut wenn das (falls noch nicht vorhanden im Bugtracker) jemand von euch machen könnte, da ich keinen Zugriff auf Cauldron mit dem Laptop habe, auf dem das Problem aufgetreten ist.

[alf]

Installiert am Donnerstag von Mageia-6-dev1-x86_64-DVD.iso

Ja, das ist auch genau mein Installationsmedium. Aber bei mir tritt halt dieses Phänomen auf. Die Konfiguration per drakconnect funktioniert problemlos, bis auf den Namen des gateway und damit zusammenhängend funktioniert dann die Namensauflösung nicht.

[doktor5000]

Spannend, bei mir funkt die Namensauflösung ganz normal. Was für einen Router hast du, auch eine Fritzbox?
Natürlich net so schön, wenn man das Problem nicht 100% reproduzieren kann ...

[alf]

Ja, genau eine FritzBox. Und bei dir funktioniert der Aufruf einer beliebigen URL direkt nach dem Einrichten der Schnittstelle?

[man-draker]

Hier ist es ein unter Centos 6 laufender Server, von dem alle Linux- und Windows -PC sowie alle Smartphones ihre Konfiguration über DHCP beziehen.
Das gilt auch für Cauldrons, die von MGA5 hochgezogen wurden.

[man-draker]

@alf: Wie bist du auf die Idee mit dem DNS-Eintrag gekommen?
Hier ging nicht mal ein Ping auf die IP des Gateways.

[alf]

Hier ging nicht mal ein Ping auf die IP des Gateways.

Genau das schrieb ich ja in meinem ersten Beitrag. Daraufhin hab ich mir die Ausgabe von route/netstat angeschaut. Und da stand dann als Router "gateway" statt "fritz.box" obwohl die IP völlig korrekt war. Auch wurde ja der Name und die IP der Wlan-Schnittstelle korrekt vom DHCP-Server(FritzBox) zugewiesen.Einen Host Namens gateway gibt es in meinem Netzwerk nicht, also schloss ich messerscharf auf fehlenden DNS.

[alf]

BTW es gibt da 2 bugs die in etwa in die Richtung gehen: https://bugs.mageia.org/show_bug.cgi?id=17377 und https://bugs.mageia.org/show_bug.cgi?id=17683

[man-draker]

Interessant: Zurückstellen der Option auf "DNS per DHCP" reaktiviert den Fehler nicht wieder.

[alf]

Stimmt, offensichtlich wird durch den workaround der Fehler in der Namensauflösung dauerhaft behoben.

[doktor5000]

BTW es gibt da 2 bugs die in etwa in die Richtung gehen: https://bugs.mageia.org/show_bug.cgi?id=17377 und https://bugs.mageia.org/show_bug.cgi?id=17683

Ersterer trifft nur zu wenn du zwei Interfaces gebrückt hast per drakgw.

[man-draker]

Stimmt, offensichtlich wird durch den workaround der Fehler in der Namensauflösung dauerhaft behoben.

Evtl. liegt es daran, dass durch die Umstellung die Adresse des DNS-Servers in der
/etc/sysconfig/network-scripts/ifcfg-<Schnittstellenname> hinterlegt wird.

So kann darauf zurück gegriffen werden, wenn die DHCP-Informationen nicht richtig verarbeitet werden - was ja wohl der Auslöser des ganzen Problems ist.

Der Spuk verschwindet übrigens im laufenden Betrieb, wenn man Shorewall ausschaltet

Code: Alles auswählen

systemctl stop shorewall.service

und auf einmal fluppt es.