pppoe/padi/pado

dettus

dettus

Bicycle User
wow.

erstaunlicherweise hatte ich eben dochmal eine gute hotline erwischt.

ich habe bei mir immer das problem, dass meine internetverbindung oefter mal zusammenbricht, seitdem ich meinen pppoe auf den kernel pppoe umgestellt habe.
wie sich herrausgestellt hat, schickt mir nefkom in regelmaessigen abstaenden ein PADI-signal, und als antwort erwarten die ein PADO.

kommt das nicht, machen die die leitung dicht. (WIRKLICH erstaunlich dass die einem sowas an der hotline erzaehlen. ich bin voellig begeistert)

naja... ich hab zum ersten mal davon gehoert.
auf jeden fall... kann man das irgendwie debuggern? OHNE dass ich den netzwerkverkehr mitsniffe? irgendwie einschalten?
 
so...
das hab ich mir mal gedumpt...

Code: 
01:47:57.560160 PPPoE-Session
        code Session, version 1, type 1, id 0x1b23, length 10
        LCP: Echo-Request, Magic-Number=1409259721
01:47:57.565543 PPPoE-Session
        code Session, version 1, type 1, id 0x1b23, length 10
        LCP: Echo-Reply, Magic-Number=5829473
01:48:17.559221 PPPoE-Session
        code Session, version 1, type 1, id 0x1b23, length 10
        LCP: Echo-Request, Magic-Number=1409259721
01:48:17.564689 PPPoE-Session
        code Session, version 1, type 1, id 0x1b23, length 10
        LCP: Echo-Reply, Magic-Number=5829473
01:48:37.558294 PPPoE-Session
        code Session, version 1, type 1, id 0x1b23, length 10
        LCP: Echo-Request, Magic-Number=1409259721
01:48:37.563533 PPPoE-Session
        code Session, version 1, type 1, id 0x1b23, length 10
        LCP: Echo-Reply, Magic-Number=5829473
01:48:57.557428 PPPoE-Session
        code Session, version 1, type 1, id 0x1b23, length 10
        LCP: Echo-Request, Magic-Number=1409259721
01:49:07.556995 PPPoE-Session
        code Session, version 1, type 1, id 0x1b23, length 10
        LCP: Echo-Request, Magic-Number=1409259721
01:49:17.556582 PPPoE-Session
        code Session, version 1, type 1, id 0x1b23, length 10
        LCP: Echo-Request, Magic-Number=1409259721
01:49:27.561601 PPPoE-Session
        code Session, version 1, type 1, id 0x1b23, length 6
        LCP: Terminate-Request
01:49:27.576137 PPPoE-Discovery
        code Terminate, version 1, type 1, id 0x1b23, length 0
01:49:27.576183 PPPoE-Discovery
        code Initiation, version 1, type 1, id 0x0000, length 12
        tag Service-Name, length 0
        tag Host-Uniq, length 4 \011r~ú
01:49:32.575916 PPPoE-Discovery
        code Initiation, version 1, type 1, id 0x0000, length 12
        tag Service-Name, length 0
        tag Host-Uniq, length 4 \011r~ú
01:50:22.503936 PPPoE-Session
        code Session, version 1, type 1, id 0x1b23, length 10
        LCP: Echo-Request, Magic-Number=5829473
01:50:32.573323 PPPoE-Discovery
        code Initiation, version 1, type 1, id 0x0000, length 12
        tag Service-Name, length 0
        tag Host-Uniq, length 4 \011r~ú
01:50:32.580242 PPPoE-Discovery
        code Offer, version 1, type 1, id 0x0000, length 45
        tag AC-Name, length 9 ERX2.nue2
        tag Host-Uniq, length 4 \011r~ú
        tag Service-Name, length 0
        tag AC-Cookie, length 16 ßø$î\212Æ¿\222uo,ʲ\217b
01:50:32.580321 PPPoE-Discovery
        code Request, version 1, type 1, id 0x0000, length 32
        tag Service-Name, length 0
        tag AC-Cookie, length 16 ßø$î\212Æ¿\222uo,ʲ\217b
        tag Host-Uniq, length 4 \011r~ú

anscheinend gehen ein paar echo-requests gut, aber dann auf einmal nicht mehr.
warum auch immer.
 
Ich bin zwar kein Experte auf dem Gebiet, aber aus dem Bauch heraus würde ich auf ein physikalisches Problem tippen.

Von 1:48:57 - 1:49:17 versucht deine Maschine per Request mit der eigenen Magic-Number sein Gegenüber zu erreichen, aber bekommt keine Antwort mehr.

Vielleicht sind die Pakete durch mangelnde Linkqualität/Wackelkontakt/starke Sonnenwinde;) entstellt.
 
Wenn der dump von deiner Maschine ist, gehe ich davon aus, dass zumindest die selbst gesendeten Pakete aufgezeichnet werden.

Der Unterschied zwischen Sender und Empfänger ergibt sich dann aus den verschiedenen Magic-Numbers:

Magic-Number=1409259721 (deine Eigene)
Magic-Number=5829473 (die der Gegenseite)

Davon ausgehend, dass selbst erzeugt Pakete immer korrekt im dump auftauchen, folgt die Schlussfolgerung, dass die Pakete der Gegenseite irgendwo verloren gegangen sind.
 
hmm... wie kann ich mir bei tcpdump sicher ueber die richtung sein?

warum sollte meine maschine ein echo request schicken?
 
In tcpdump machst du das am besten über die expressions.

tcpdump -netttvvi interface dir inbound

oder outbound.

mfg
morph
 
hey, egal was es ist....

auf nachfrage im supportforum haben mir die admins gesagt dass sie besagte echo replys schicken, wenn 30 sekunden lang kein "traffic" ueber die leitung geht.

dass fuer die "traffic" ausschliesslich verkehr auf port 80 ist haben die zwar nicht gesagt, aber mit folgendem winz-skript kann ich mir meinte leitung jetzt doch offen halten:
Code: 
#!/usr/local/bin/bash
while (true)
do
       sleep 27
       wget -O /dev/null http://www.nefkom.de
done

weil ich mir die ganze zeit nur die homepage von denen abhole sollte das ja theoretisch auch nur internen traffic erzeugen.

trotzdem hoffe ich mal drauf dass es mit dem kernel 4.3 besser wird!
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben