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" -- Linux mailing list [email protected] subscribe/unsubscribe: http://lug-owl.de/mailman/listinfo/linux Hinweise zur Nutzung: http://www.lug-owl.de/Mailingliste/hints.epo
