Re: Buster 10 - Labtop Mobilfunk Verbindungsproblem
Hallo,
> Ich hab nat. auch eure Vorschläge durchprobiert, incl. "tcpdump" während dem
> "traceroute -n 8.8.8.8":
Jetzt wird es spannend...
> root@dorsy1:~# tcpdump -n -i enx021e101f0000
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on enx021e101f0000, link-type EN10MB (Ethernet), capture size
> 262144 bytes
> 22:32:13.159558 IP 100.93.124.248.1716 > 255.255.255.255.1716: UDP, length
> 1007
Dein Rechner sendet ein UDP Paket auf Port 1716 an die Broadcast-Adresse.
Laut diverser Suchtreffer ein Hinweis, dass kdeconnect läuft. Soweit erstmal
nichts besonderes.
> 22:32:13.159818 IP 100.93.124.248.32859 > 8.8.8.8.53: 35268+ PTR?
> 248.124.93.100.in-addr.arpa. (45)
Offenbar als Reaktion auf das Paket (jedenfalls in engem zeitlichen
Zusammenhang, 0,3ms später) fragt dein Rechner beim Google DNS (8.8.8.8)
nach dem Hostnamen zu seiner eigenen IP-Adresse.
> 22:32:13.248211 IP 100.93.124.248.47287 > 8.8.8.8.33450: UDP, length 32
> 22:32:13.248289 IP 100.93.124.248.42022 > 8.8.8.8.33451: UDP, length 32
> 22:32:13.248337 IP 100.93.124.248.56224 > 8.8.8.8.33452: UDP, length 32
[...]
Das sind ausgehende Traceroute Pakete.
> 22:32:13.264554 00:00:75:11:dd:1f > 45:00:00:82:76:e6, ethertype Unknown
> (0x0808), length 130:
> 0x0000: 0808 645d 7cf8 0035 805b 006e 9ec4 89c4 ..d]|..5.[.n....
> 0x0010: 8183 0001 0000 0001 0000 0332 3438 0331 ...........248.1
> 0x0020: 3234 0239 3303 3130 3007 696e 2d61 6464 24.93.100.in-add
> 0x0030: 7204 6172 7061 0000 0c00 01c0 1400 0600 r.arpa..........
> 0x0040: 0100 0007 0700 2d03 736e 7303 646e 7305 ......-.sns.dns.
> 0x0050: 6963 616e 6e03 6f72 6700 036e 6f63 c03d icann.org..noc.=
> 0x0060: 7859 5894 0000 1c20 0000 0e10 0009 3a80 xYX...........:.
> 0x0070: 0000 0e10 ....
Und hier wird es richtig interessant. Das Paket wird zwar von Tcpdump als
reichlich kaputtes Ethernet-Frame mit erfundenen MAC Adressen und einem
unbekannten Ethertype (0x0808) angezeigt. Dem Inhalt nach ist es aber die
Antwort von Google DNS auf den obigen DNS Request. Die ersten beiden Bytes
des Payload zusammen mit dem Ethertype (0808 0808) ergeben die Google DNS
Adresse 8.8.8.8. Danach kommt 645d 7cf8 = 100.93.124.248, die Adresse deines
Rechners im WAN. Der restliche Payload sieht im Hexdump sehr nach einer
DNS Antwort aus, er enthält die Anfrage (248.124.93.100.in-addr.arpa) und
die Antwort (sns.dns.icann.org, der SOA Record zu 100.93).
Offenbar kommt also eine Antwort in Form eines IP-Pakets zurück, dessen
Anfang Tcpdump aber für ein Ethernet-Frame hält. Ob das jetzt ein
Interpretations- und Anzeigefehler von Tcpdump ist oder das Paket bereits
vom Kernel falsch interpretiert wird, kann ich so nicht sagen. Sicher ist
jedenfalls, dass vom DNS Server eine Antwort zurück kommt, die Internet-
Verbindung also funktioniert.
> 22:32:13.288081 40:00:f8:01:d8:ac > 45:00:00:38:9b:37, ethertype Unknown
> (0x0ad8), length 56:
> 0x0000: 22b3 645d 7cf8 0b00 e9af 0000 0000 4500 ".d]|.........E.
> 0x0010: 003c 239d 0000 0111 a4af 645d 7cf8 0808 .<#.......d]|...
> 0x0020: 0808 b8b7 82aa 0028 cfc5 .......(..
Nach obiger Logik dürfte das eine Antwort auf das Traceroute Paket sein.
Der Ethertype und die ersten Bytes des Payload 0ad8 22b3 ergeben
10.216.34.179, offenbar der erste Hop der Traceroute-Abfrage. Dahinter
wieder deine eigene IP-Adresse (645d 7cf8).
> 22:32:13.288083 40:00:f6:01:61:92 > 45:00:00:38:ad:05, ethertype Unknown
> (0x91fe), length 56:
> 0x0000: 02d9 645d 7cf8 0b00 e9af 0000 0000 4500 ..d]|.........E.
> 0x0010: 003c 23a2 0000 0111 a4aa 645d 7cf8 0808 .<#.......d]|...
> 0x0020: 0808 a100 82af 0028 e777 .......(.w
Wahrscheinlich der zweite Hop. 91fe 02d9 = 145.254.2.217, eine Adresse aus
dem Netz von Arcor.
> (0x480e), length 56:
> 0x0000: c28a 645d 7cf8 0b00 e9af 0000 0000 4500 ..d]|.........E.
> 0x0010: 003c 23a9 0000 0111 a4a3 645d 7cf8 0808 .<#.......d]|...
> 0x0020: 0808 d1ed 82b6 0028 b683 .......(..
Ein weiterer Hop. 480e c28a = 72.14.194.138, gehört bereits Google.
> 22:32:20.902361 IP 100.93.124.248.59247 > 8.8.8.8.53: 38032+ SOA? local.
> (23)
> 22:32:21.016196 00:00:74:11:83:37 > 45:00:00:7e:d1:d2, ethertype Unknown
> (0x0808), length 126:
> 0x0000: 0808 645d 7cf8 0035 e76f 006a d8f6 9490 ..d]|..5.o.j....
> 0x0010: 8183 0001 0000 0001 0000 056c 6f63 616c ...........local
> 0x0020: 0000 0600 0100 0006 0001 0001 5126 0040 ............Q&.@
> 0x0030: 0161 0c72 6f6f 742d 7365 7276 6572 7303 .a.root-servers.
> 0x0040: 6e65 7400 056e 7374 6c64 0c76 6572 6973 net..nstld.veris
> 0x0050: 6967 6e2d 6772 7303 636f 6d00 7868 2415 ign-grs.com.xh$.
> 0x0060: 0000 0708 0000 0384 0009 3a80 0001 5180 ..........:...Q.
Ein weiterer DNS Request nach dem SOA von "local", und die Antwort des
Google DNS Servers.
> 22:32:23.756519 IP 100.93.124.248.38779 > 131.188.3.222.123: NTPv4, Client,
> length 48
> 22:32:23.811654 00:00:73:11:c5:a6 > 45:00:00:4c:19:0b, ethertype Unknown
> (0x83bc), length 76:
> 0x0000: 03de 645d 7cf8 007b 977b 0038 2588 2401 ..d]|..{.{.8%.$.
> 0x0010: 00e6 0000 0000 0000 0001 4d42 4768 e303 ..........MBGh..
> 0x0020: ba57 0000 0000 e303 ba57 2d16 d30d e303 .W.......W-.....
> 0x0030: ba57 cadb 673f e303 ba57 cadb acf3 .W..g?...W....
Hier eine NTP Anfrage an den Server 131.188.3.222 = ntp2.rrze.uni-erlangen.de,
und dessen Antwort.
Fazit: die ausgehende Kommunikation funktioniert, es kommen auch Antworten,
aber die kommen irgendwie falsch bei dir an. Für mich gibt es vier mögliche
Erklärungen:
- NetworkManager setzt das Device (enx021e101f0000) irgendwie falsch auf, so
dass der Kernel es für Ethernet hält, obwohl es direkt IP ohne
darunterliegendem Layer 2 Protokoll ist.
- NetworkManager setzt oder erwartet irgendwelche Optionen, die die Gegenseite
nicht versteht bzw. unterstützt (z.B. VJ Header Compression)
- Der Provider macht beim Enkapsulieren der eingehenden Pakete irgendwas
falsch. (Das dürfte dann wohl mehrere Kunden betreffen...)
- Die Pakete kommen richtig an, werden nur von Tcpdump falsch angezeigt, und
aus irgend einem anderen Grund gefiltert.
Ich würde als nächstes
- die verschiedenen Optionen bei der Konfiguration des Interface im
NetworkManager durchprobieren. Da gibt ja einige Häkchen, die man setzen
oder Löschen kann, z.B. BSD Data Compression oder Header Compression.
- eine andere Software als NetworkManager ausprobieren, z.B. pppd.
Gruß, Harald
Reply to: