Wer hat da routing gedreht?

Sun Nov 4 02:23:52 CET 2007

Nabend!

Ich werd hier noch zum Elch...
Da hier eine paar Backbonequaehler mitlesen, hoffe ich, es kann mir wer
das gesehene beschreiben...

Hmmm, wo fang ich an, ok vorne.

Die Telekom moechte ab naechstes Jahr ihre DSL-Anschluesse endlich auch
auf adaptive Ratenanpassung stellen, zu deutsch: Modem und DSLAM handeln
auf der Leitung aus, soviel geht, nix mehr fixed rate.

Eigentlich ein Grund zum feiern, wenn das nicht ein wenig mit meinem
traffic shaping kollidieren wuerde, damit das richtig funzt muss ich die
Verbindungsgeschwindigkeit kennen.

Nungut, die laesst sich aus dem Modem fischen. Nur leider nicht aus
jedem (verdongelt, verjavascriptet, was auch immer).
Also hab ich mir ein neues Modem besorgt, von dem Ich wusste das es eine
Software vom Hersteller gibt, das die Geschwindigkeit anzeigt.

Also, angeschlossen, Wireshark gestartet, Software gestartet, aha.
Ein UDP-Broadcast um das Modem zu finden, das broadcastet zurueck wo es
zu finden ist, und dann holt die Software eine XML-Seite mit dem
aktuellen status ab -> Schoen!

Flux hingesetzt eine Software zu schreiben die das unter Linux macht und
meine shaping raten anpasst.

Nun, nur irgendwie bin auf DAS MERKWUERDIGSTE WAS ICH JE GESEHEN HABE
getroffen...

Meine Software sendet, wie das orginal, einen Broadcast richtung Modem,
also auf das Ehternetsegment richtung DSLAM.

Ich bekam nur ploetzlich zwei verschiedene Antworten?
Huh?
Ein traceroute verschwand in den untiefen des T-Backbone, irgendwas mit
KI (Kiel?)
Fall von zusammen geschaltetem Ethernetsegment? Aber wie wo was? Sonst
funzt das eigentlich mit der abtrennung sehr gut (ich seh ja auch keine
anderen komischen broadcasts).
Dann war es weg und ich hab mir nix mehr bei gedacht.

Kurze Zeit spaeter tauchte eine IP mit 199 am Anfang auf.
CANADA!
Ja! Die IP sagt CANADA. Sogar die Daten die das Modem IN seinem Packet
schickt sprechen von einer Canadischen IP. Das ist nicht mehr das
gleiche Ethernetsegment. Das ist nicht mal mehr das gleiche verf***te
Stadion.
WAS geht?

> marvin ~ # traceroute 199.185.133.254
> traceroute to 199.185.133.254 (199.185.133.254), 30 hops max, 40 byte packets
>  1  * * *
>  2  217.0.76.182 (217.0.76.182)  42.081 ms  41.036 ms  41.613 ms
>  3  62.154.32.230 (62.154.32.230)  50.997 ms  50.957 ms  54.605 ms
>  4  so-6-0.hsa2.Hamburg1.Level3.net (4.68.127.241)  47.771 ms  48.601 ms  47.764 ms
>  5  so-5-0-0.mp2.Hamburg1.Level3.net (4.68.115.242)  50.739 ms  51.637 ms  50.730 ms
>  6  ae-1-0.bbr1.London1.Level3.net (212.187.128.58)  64.794 ms as-2-0.bbr2.London1.Level3.net (4.68.128.213)  64.740 ms  64.888 ms
>  7  ae-0-0.bbr2.Chicago1.Level3.net (64.159.1.34)  154.248 ms  154.544 ms  154.451 ms
>  8  ae-21-52.car1.Chicago1.Level3.net (4.68.101.34)  200.610 ms ae-21-54.car1.Chicago1.Level3.net (4.68.101.98)  280.892 ms ae-21-56.car1.Chicago1.Level3.net (4.68.101.162)  294.618 ms
>  9  BIG-PIPE-IN.car1.Chicago1.Level3.net (4.79.208.150)  154.920 ms  154.968 ms  156.047 ms
> 10  rc2nr-pos10-0-0.wp.shawcable.net (66.163.77.93)  173.093 ms  173.620 ms  173.739 ms
> 11  rc1so-pos13-0.cg.shawcable.net (66.163.76.85)  210.669 ms  210.695 ms  210.838 ms
> 12  ra1so-ge3-3.cg.shawcable.net (66.163.71.50)  211.990 ms  211.451 ms  211.381 ms
> 13  rx0so-enmax.cg.bigpipeinc.com (66.244.207.158)  190.155 ms  189.760 ms  190.122 ms
> 14  a72-29-228-131.figment.ca (72.29.228.131)  193.636 ms  190.614 ms  189.831 ms
> 15  * * *
> 16  * * *
> 

Ich wende mich jetzt an euch, da nun eine Antwort aus Korea dem Fass den
Boden ausschlaegt.

> marvin ~ # tcpdump -i eth0 -nvvvv
> tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
> 01:42:29.166297 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 67) 192.168.5.254.19375 > 192.168.5.255.19375: [bad udp cksum 72b9!] UDP, length 39
> 01:42:29.168009 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 148) 192.168.5.253.19375 > 255.255.255.255.19375: UDP, length 120
mein Modem, OK
> 01:42:29.176143 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 150) 211.234.29.254.19375 > 255.255.255.255.19375: UDP, length 122
WTF???
> 01:42:30.161862 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 148) 192.168.5.253.19375 > 255.255.255.255.19375: UDP, length 120
> 01:42:30.172424 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 150) 211.234.29.254.19375 > 255.255.255.255.19375: UDP, length 122
> 01:42:31.161828 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 148) 192.168.5.253.19375 > 255.255.255.255.19375: UDP, length 120
> 01:42:31.172424 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 150) 211.234.29.254.19375 > 255.255.255.255.19375: UDP, length 122

> recvd from: 192.168.5.253:19375
> name:   "dsl+ 1100 LAN" mac:    00:0B:3B:21:C1:FF
> ip:     192.168.5.253 nwmask:   255.255.255.0
> web:    "http://192.168.5.253/cgi-bin/webcm?sysinfo"
> einfo:  "00238a9ad8"
> recvd from: 211.234.29.254:19375
> name:   "dsl+ 1100 LAN" mac:    00:0B:3B:21:C1:FF
> ip:     211.234.29.254 nwmask:  255.255.255.0
> web:    "http://211.234.29.254/cgi-bin/webcm?sysinfo"
> einfo:  "006e72b1bd"

Die Daten sind die sachen, die das Modem in seinem Packet schickt.

WIE in drei teufels Namen kommen diese Packete zu mir?
Multicast und IPv6 kriegen sie nicht auf die Stange aber ich kann mit
ff:ff:ff:ff:ff:ff bis nach Korea Broadcasten?

Entweder ist das komplette Internet falsch eingestellt, oder das ist die
bugigste Firmware, die die Welt je gesehen hat.
Falls mein Modem den Unfug sendet, ich wuesste noch nicht mal, wie es
auf Canada und Korea kommt, waehrend ich hier am coden war hatte mein
pppd die Inet-verbindung eigentlich abgebaut.

*ratlos*

Gruss
	Jan

-- 
	"Where small clearances exist, controls are required to
	 prevent these clearances becoming negative"
			- How a standards body describes "not crashing"