[1] Die Piraten sind in Berlin in den Landtag eingezogen, einen interessanten Kommentar dazu fand Jan hier:
"Erfolg der Piraten bleibt Ausnahme"
Laut Forschungsgruppe Wahlen
http://www.forschungsgruppe.de/Wahlen/Wahlanalysen/Newsl_Berl11.pdf
haben die wenigsten die Piraten wegen Ihrer Wahlkampfthemen gewählt:
Die Piraten, die für 80% der Befragten "aus Unzufriedenheit mit den
anderen Parteien", und nur für 10% "wegen der Inhalte" gewählt werden,
bleiben wie die FDP bei den Kompetenzen praktisch unsichtbar.
Interessant ist auch, dass der größte Anteil der Wähler bei den Arbeitslosen liegt.
Oder wie es im Spiegel steht:
Die Piraten sind die ideale Partei für alle Jungwähler und solche,
die sich dafür halten: freier Zugang zu Drogen (was "Hilfe statt
Kriminalisierung" bedeutet, weiß jeder Hauptschüler zu übersetzen);
freies Kopieren von allem, was einem im Netz gefällt. Gegen dieses
Angebot kommt auch die Angst vor dem Atomtod nicht an.
Die angeblich aktivierten Nichtwähler ist dabei wohl nur eine Ausrede der Wahlforscher um zu erklären, warum die Piraten mit fast 9% deutlich mehr Stimmen bekamen als es prognostiziert wurde.
Immerhin hat die FDP ihr Projekt 18 verwirklicht: Es waren 18 Promille...
[2] Die TAZ hatte einen Artikel zu 20 Jahre Linux veröffentlicht der voller Fehler steckte:
Ziemlich viel Unfux
Aus der daran anschließenden Diskussion folgte, dass die Bezahlung für Journalisten eher als bescheiden anzusehen ist. Dennoch halte ich es für nicht nachvollziehbar wie man so viele Fehler machen kann. Das kann im Grunde nur durch massiven Zeitmangel für den Artikel erklärt werden. Aber wo ist da der Vorteil, wenn man Häme für die Fehler bekommt und diese dann anschließend doch korrigieren muss?
[3] Die Tagesschau-App ist mal wieder in der Diskussion:
Merkel: ARD und ZDF sollen ihre Apps genau prüfen
Rundfunk, also Fernsehen und Radio sind aus Gebühren zu finanzieren, Artikel jedoch nicht?
Allerdings finde ich das dann doch beunruhigend:
Die Kanzlerin stellte den Verlagen eine Reform des Urheberrechts
in Aussicht. Das Leistungsschutzrecht soll die Online-Angebote der
Zeitungen vor gewerblicher Nutzung durch andere - etwa durch
Suchmaschinen - schützen.
Das heißt doch letztendlich, dass man das noch nicht einmal mehr zitieren dürfte. Und wer legt dann fest, was unter Leistungschutzrecht fällt? Oder ist das dann jeder Artikel, Blogeintrag, Kommentar,...?
[4] RMS weist darauf hin, dass Android keine freie Software ist:
Android ist keine freie Software
Ich denke, er liegt mit der Ansicht durchaus richtig. Was nützen da freie Lizenzen wenn der Source Code unter Verschluss ist?
[5] Dazu passt dann diese Meldung, vermutlich wird Bada dadurch gegen Android in Stellung gebracht. Schließlich ist noch unklar wie es mit dem Google-OS weitergehen wird nachdem Google Motorola akquiriert hat:
Bada soll Open Source werden
Bada baut auch auf den Linux-Kernel auf...
[6] Das 99-Euro-Huwai-Android-Smartphone ist jetzt bei Fonic zu bestellen:
Android Smartphone für 99,95
Bei Lidl war es ja gleich ausverkauft...
[7] HP kauft erst WebOS, dann stellen sie über Nacht das Tablet ein. Dann wollen sie WebOS verkaufen, nein Samsung will es nicht, und nun kommt das:
HP entlässt seine WebOS-Abteilung
Im einem Interview der Wirtschaftwoche sagte Todd Bradley:
"Märkte ändern sich schnell. Darauf müssen wir reagieren und das
Partnern und Kunden erklären. Wir haben nie gesagt, dass wir das
Tabletgeschäft aufgeben. Wir werden nur selbst keine WebOS-Tablets
mehr herstellen. Wir wollen und werden definitiv eine führende Rolle
im Tabletmarkt spielen." HP wolle das Potenzial, das in WebOS stecke,
unbedingt nutzen und das WebOS-Ökosystem weiter stärken, betonte
Bradley. "Wir unterstützen die Nutzer-Communitys, unsere Software-
spezialisten sprechen auf Entwicklerkonferenzen. Wir haben viel Geld
für Palm in die Hand genommen, um Zugriff auf die extrem innovative
WebOS-Plattform zu bekommen - und wir geben das nicht auf."
Irgendwie passt das für mich nicht so recht zusammen...
[8] Und dann überschlugen sich die Meldungen zu HP:
Deutscher Konzernchef vor Aus bei Hewlett-Packard
Da wurde noch diskutiert um kurz darauf zur Realität zu werden:
Whitman löst Apotheker an HP-Spitze ab
Ob sie das Ruder noch einmal herumreißen kann? Oder ist da schon zu viel Erde verbrannt worden? Zumindest schlingern sie im Kurs, das sieht auch Heise so:
Stümperei beim Weltkonzern: "HP zerstört sich selbst"
[9] Hier gibt es ein seltsam kurzes Howto zur Kernelkonfiguration:
In-depth HOWTO on Linux kernel configuration
Da ist wohl so manches weggelassen worden. Einen deutlich besseren Ratgeber gibt es als Nutshellbuch oder auch Online:
Linux Kernel in a Nutshell
Die Quelle ist deutlich besser...
[10] DigiNotar hat es geschafft:
Diginotar meldet Insolvenz an
Es ist mir unbegreiflich wie man die Lizenz zum Gelddrucken so leicht- fertig aufs Spiel setzen kann...
Einen guten Vortrag rund um Zertifikate kann man hier finden:
https://media.blackhat.com/bh-us-11/Marlinspike/BlackHat-USA-2011-Marlinspike-SSL-Future-Authenticity-SlidesOnly.mov
[11] pfSense ist in der Version 2.0 erschienen. Es ist schon erstaunlich was mittlerweile da alles eingebaut wurde:
2.0 Release Now Available!
Die Liste der Features ist hier zu finden:
2.0 New Features and Changes
[12] The Empire Strikes Back: M$ will den Bootloader mit Windoze 8 per Zertifikat signieren, damit wird ein Dual-Boot etwas problematisch:
Bootloader per Zertifikat gesperrt
Der Punkt ist, dass sie die Secure-Boot-Variante vorschreiben, damit das Windoze-8-Logo auf einem System prangen darf. Heise hat dem auch einen Artikel gewidmet:
Linux-Community fürchtet Windows-"Verdongelung"
Ein netter Artikel zum Secure-Boot kann man hier finden:
UEFI secure booting
Wobei man die Hardware nun leicht erkennen kann:
Microsoft requires that machines conforming to the Windows 8 logo
program and running a client version of Windows 8 ship with secure
boot enabled.
[13] Es hat ein paar Tage gedauert, dann kam ein Dementi aus Redmond. Ich deute das mal so, dass sie diese Option durchaus in Erwägung gezogen hatten:
Microsoft will Parallelinstallationen nicht verhindern
[14] M$ hat wohl massive Probleme mit Bing: Entweder fehlen die Werbekunden oder sie machen da etwas falsch:
Bing macht pro Quartal 1 Milliarde Dollar Verlust
Da stellt sich einem die Frage: Wieviel Gewinn macht M$ dann mit Windoze wirklich?
[15] Firefox und der Releasezyklus - Manche denken tatsächlich über eine weitere Verkürzung nach:
Mozilla diskutiert weitere Verkürzung von Firefox-Veröffentlichungszyklen
Sie könnten auch gleich für jeden Change eine neue Version herausbringen. Statt Versionsnummer könnten sie doch gleich die Sekunden seit der Unix Epoche als Wert nehmen...
[16] Alex hat eine Alternative zu Mediatomb gesucht. Im Open Source Bereich scheint es da nicht so gut auszusehen. Kai verweist da auf TwonkyServer:
TwonkyServer 6.0.34
Das Teil kostet lediglich 15 Euro.
[17] Das ist zwar ein ubequemes aber cooles Teil:
Tron-Motorrad nun mit Elektroantrieb
Damit hat man zumindest die Show im Kasten...
[18] Diese Load hatte ich letzt auf einem Linux-Server gesehen:
14:14:16 up 35 days, 21:22, 30 users, load average: 234.87, 250.43, 282.36
Dabei reagierte das System noch recht normal!
[19] Nokia forciert nun den Niedergang:
Nokia ernennt neuen Technik-Chef
Der neue Technik-Chef soll in Kalifornien sitzen, die meisten Entwickler sind derzeit wohl in Europa zu finden. Was der Vorteil von Kalifornien ist, bleibt wohl eher Nebulös. Die Hardwarehersteller sind wohl eher in Fernost zu finden. Das hätte dann doch mehr Sinn ergeben...
[20] Google+ könnte Facebook durchaus gute Konkurrenz machen:
Google+ hat demnächst 50 Millionen Nutzer
Dabei ist Google+ erst vor ein paar Tagen für die Allgemeinheit geöffnet worden. Die Nutzer kann es freuen: Konkurrenz belebt das Geschäft, sie sorgt auch dafür, dass die Qualität besser wird.
[21] Mittwoch ist wieder Stammtisch beim Lindenwirt! Da es mir gelungen ist dem Wirt davon zu überzeugen, dass wir weder rechts noch radikal sind - er hat keinen blassen Schimmer davon was Linux ist - bekommen wir auch einen Nebenraum!
[22] Zocken ist angesagt: Ich hoffe wir bekommen genug Nasen für eine Zocker- runde am 15.10. beisammen. Wir haben wieder beim BRK eine Heimat gefunden.
[23] Es gab eine Spende vom Weißbräu: 2 Tragerl Freibier und 12 Gläser. Das war dann recht passend zum ersten Zockerabend der kurz darauf folgte. Dazu gab es dann auch noch etliche E-Mails bis wir alles zusammen hatten.
[24] Bei Real gab es einen billigen PC mit Linux vorinstalliert:
Real gibt Linux zweite Chance
Dabei war die Ausstattung damals gar nicht so schlecht:
Grafik und Firewire onboard,
LAN 10/100,
Cardreader 8 in 1,
Tastatur und Maus,
DSL-ready,
Linspire Linux (OEM-Version),
Softwarepaket Open Office-Suite 2.0,
4x USB 2.0,
Video- und Scart-out,
200-GB-Festplatte,
512-MB-DDRRAM,
Multinorm-DVD-Brenner,
24 Monate Garantie
[25] Dann gab es noch die Episode aus dem Leben eines Admins von mir:
In diesem Fall betrifft es den Upgrade eine DSL-Leitung auf
symmetrisch mit höherem Durchsatz durch die France Telecom, ja
die sind noch besser als die deutsche Variante:
+ Sie kamen 2 Stunden später als vereinbart.
+ Stellten fest, daß der mitgebrachte Router garnicht funktioniert.
+ Sie sind zurückgefahren und haben einen neuen Router geholt.
+ Dann haben sie endlich festgestellt, daß die Leitung die geforderte
Übertragungsrate garnicht hergibt.
-> Montag wird ein neuer Termin vereinbart.
[26] ...und dann gab es noch eine Episode mit einem ISP aus der Schweiz. Den muss ich einfach in voller Schönheit noch einmal posten:
Durch eine VPN-Umstellung ist es nun möglich, daß sowohl Path-MTU
Discovery (also das herausfinden der optimalen MTU für eine Verbindung)
mit VPN funktioniert und gleichzeitig die maximale Paketgröße erhöht
wurde.
Path-MTU:
---------
Wer bei meinem Netzwerkvortrag aufgepaßt hat, der weiß was es ist
und wie es funktioniert. Daher brauche ich das wohl nicht mehr
erklären, oder?
Ok, einen kleinen Reminder gibt es noch:
Wenn im Internet Netzwerkpakete versendet werden, dann kann es
passieren, daß auf einem Abschnitt der Route eine kleinere
MTU (Maximum Transfer Unit) verwendet wird als am Ausgangspunkt
des Paketes.
Z.B. erlaubt Ethernet normalerweise eine größe von 1500 Bytes,
DSL hingegen nur 1492 weil sie pppoE (Point-to-Point Protocol
over Ethernet) verwenden, da werden von den 1500 Bytes noch 8
Bytes für dieses Protokol mißbraucht.
Klassische Modemverbindungen haben noch kleinere MTUs.
Damit nun größere Pakete auch transportiert werden können dürfen
Router diese Pakete framgentieren, also in kleinere Paketer zerlegen.
Also werden z.B. die ursprünglichen 1500 Bytes in zwei Pakete
zerlegt, eines mit 1492 Bytes und eines mit 8 Bytes + neuem
IP-Header (+ Padding).
Bei lediglich einem Paket ist es nicht sonderlich störend,
werden aber große Datenmengen transportiert verdoppelt sich
die Anzahl der Netzpakete und viele sind nahezu leer. Da wäre
es besser von vornherein nur 1492 Bytes große Daten zu versenden.
Nur die Frage ist: Woher weiß ich was die maximale mögliche MTU
(ohne Fragmentierung) auf meiner Netzwerkstecke ist?
Hier setzt Path-MTU Discovery ein:
Im IP-Header gibt es ein DF-Bit. DF steht für Don't Fragment und
bedeutet, daß ein Router dieses Pakete nicht fragmentieren darf.
Als Folge wird er das Paket verwerfen und ein ICMP-Paket an den
Abesender zurücksenden, daß er das Paket nicht weiterleiten konnte
da es zu groß war.
In diesem ICMP Paket steht aber auch die MTU des Routers für den
nächsten Hop, also z.B. "max mtu is 1492".
Daraufhin weiß dann die Applikation (bzw. eigentlich der Kernel)
was die optimale MTU ist und verwendet in Zukunft diesen Wert.
(Es sei denn ein weiterer Router meldet eine noch kleinere MTU
aber davon gehen wir einmal nicht aus.)
VPN:
----
VPN, virtual private network, nimmt ein IP-Paket, verschlüsselt
dieses und packt es in ein neues IP-Paket um es an das Ziel zu
senden. Am Ziel wird der zusätzliche IP-Header entfernt, der
Inhalt wieder verschlüsselt und das ursprüngliche Paket wird
ganz normal weitergeleitet.
Für den Anwender sieht es so aus, als ob man transparent mit
der Gegenstelle spricht, das ist auch der Sinn von VPN.
Aufgrund der Problematik mit Path-MTU discovery wurden die
IP-Pakete für das VPN von Haus aus kleiner gewählt, schließlich
kommt noch der VPN-Header und neue IP-Header hinzu die das Paket
wieder größer machen.
Das klassische VPN hatte auch kein DF-Bit gesetzt, wie hätte man
auch darauf reagieren sollen, das ist nicht trivial.
Warum dies nicht trivial ist kommt jetzt:
Die Verschlüsselung erfolgt durch den Kernel, heraus kommt ein
neues IP-Pakete das etwas größer ist. Dieses besteht nun aus
einem IP-Header und (je nach VPN) verschlüsselten Daten. D.h.
ab hier kann man auf den Inhalt keine Rückschlüsse mehr machen.
Dies ist aber notwendig damit das ICMP-Paket an den richtigen
Computer weitergeleitet wird.
Neuere Versionen können das nun richtig, d.h. wenn in dem zu
verschlüsselnden Paket das DF-Bit gesetzt ist, so wird dies
auch im (größeren) verschlüsselten gesetzt.
Muß ein solches Paket nun fragmentiert werden, so wird das
ICMP Paket generiert, daß die geringere MTU beinhaltet.
Da die ersten Bytes des ursprünglichen IP-Paketes mitgesendet
werden kann der Kernel erkennen zu welcher VPN-Verbindung dieses
Paket gehört hat.
Daraufhin generiert der Kernel selber ein solches ICMP Paket
mit der MTU minus den Bytes für das VPN und sendet diese an
den ursprünglichen Computer zurück. Dieser reduziert dann
seine MTU und findet so das optimale Maximum.
Soweit, so gut. Da mittlerweile fast alle Firmen über Ethernet
angeschlossen sind, beträgt die MTU gewöhnlich 1500 Bytes.
Diese Grenze kann und wird nun durch das neue Verfahren auch
erreicht.
Und damit fing das Problem an...
Nach der Umstellung auf das neue Verfahren lief eigentlich alles
normal. Nur mit einer VPN-Außenstelle in der Schweiz gab es ein
Problem bei der Mailsynchronisation.
Da ich die Path-MTU discovery lang und breit erklärt habe brauche
ich wohl nicht mehr lang auflisten wie schwierig es war das Problem
dort zu lokalisieren, schließlich sucht man zuerst den Fehler im
VPN und nicht im Netzwerk.
Aber gut, ich verrate nicht zu viel, daß es ein Problem mit Path-
MTU discovery ist. Bei der Mailsynchronisation ist es nicht unge-
wöhnlich, daß viele Daten übertragen werden, kleine Datenmengen
funktionieren tadellos, Probleme entstehen erst wenn große Daten-
mengen bewegt werden die die MTU ausschöpfen. Wenn dann noch
Path-MTU discovery hinzukommt kann man sich leicht ausrechnen,
daß es aussieht wie eine halb-funktionierende Verbindung...
(Und nicht alle Computer verwenden PMTU)
Nachdem das nun einmal lokalisiert war konnte man endlich das
VPN ein VPN sein lassen und den Fehler irgendwo auf der Leitung
vermuten. D.h. ein Provider hat eine kleinere MTU und aus welchen
Gründen auch immer versendet er keine ICMP Pakete.
Von München in die Schweiz waren es zum Glück nur 6 Router, da
konnte man den schuldigen relativ leicht lokalisieren, es war
green.ch in Schweiz, ein ISP.
Da ich Zugriff auf Systeme an beiden Standorten habe konnte ich
von zwei Seiten testen bis wohin ein ping mit gesetztem DF-Bit
und entsprechender Größe gesendet werden kann. Es blieben nur
zwei Router übrig, einer von diesen beiden (oder beide) sind
die Verursacher des Problems.
Der Rest ist nun eigentlich Aufgabe des Kunden, dieser war
technisch aber nicht firm genug und hatte mich daher gebeten
dort anzurufen und denen zu erklären was das Problem ist.
Nun es ist schon ein paar Tage her - die brauchte ich um mich
wieder zu beruhigen - aber ungefähr ging das Telefonat so:
Ich: "Sie haben da ein Problem mit ihrem Router, der scheint keine ICMP's zu verschicken wenn die MTU zu groß ist"
Green: "Ja sind sie denn Kunde von uns?"
I: "Nein, wozu? Es gibt ein Netzwerkproblem auf einer Route von München in die Schweiz über ihren Router und der scheint fehlerhaft konfiguriert zu sein."
G: "Haben sie einmal die IP-Adresse?"
I: "Klar, das ist vermutlich der Router mit der IP-Adresse 194.42.48.63"
G: "Das ist nicht unser Router. Wir haben nur den Adressbereich beginnend mit 80 und 81, nicht mit 194. Dieser Router gehört dem Telehouse Zurich, da sind wir nicht zuständig."
I: "Aber der Router hat doch den DNS-Namen tix.green.ch"
G: "Das kann ich mir nicht erklären, aber das ist nicht unser Router."
I: "Ok, vielleicht hat der andere Router das Problem, das ist der mit der IP Adresse 80.254.161.52."
G: "Ja, das könnte einer unserer Router sein, wo ist denn das Problem."
I: "Einer dieser beiden Router scheint auf einem Segment eine kleinere MTU als 1500 zu haben und versendet keine ICMPs. Daher gibt es Probleme mit Path-MTU discovery."
G: "Unser Router ist in Ordnung, da gibt es kein Problem ich kann ihn anpingen."
Ok, an dieser Stelle habe ich mir gedacht (und gehofft) das der
andere Router das Problem hat, es war auch naheliegender, dies
war der letzte Router der mit großen Paketen noch anpingbar
war.
Also rufe ich nach einer kurzen "whois" Anfrage beim Systemhaus
an und erfahre was alle schon ahnen werden: Das Systemhaus stellt
einen 100 MBit/s Internetanschluß, Strom und Kühlung bereit, sie
betreiben alles andere nur auf Layer2, d.h. die diversen ISPs
stellen dort ihren Router auf und verwalten den auch selber.
Das liegt doch auch irgendwie nahe wenn der Router tix.green.ch
heißt.
Also geht der nächste Anruf wieder bei green.ch ein (für schlappe
1,40 Euro pro Minute). Dummerweise hatte ich nach demjenigen
gefragt mit dem ich eben schon einmal telefoniert hatte. Nach
kurzer Zeit hatte ich ihn auch wieder an der Strippe:
I: "Das Telehouse Zürich hat mir mitgeteilt, daß das dort sehr wohl ihr Router ist."
G: "Das kann nicht sein, daß ist nicht unser Router, die IP- Adresse fängt weder mit 80 noch mit 81 an."
I: "Es ist im allgemeinen nicht unüblich, daß ein Router mehr als eine IP-Adresse hat, gewöhnlich hat er auch eine in einem anderem Netzsegement."
G: "Das mag sein, daß ist aber nicht unser Router 194 ist nicht unser Adressblock."
I: "Aber der DNS-Name deutet doch schon darauf hin, daß das Ihr Router ist."
G: "Das kann ich mir auch nicht erklären, aber für die DNS-Einträge können wir nichts."
I: "Hae?"
G: "194 ist definitiv nicht unser Adressbereich, das kann kein Router von uns sein!"
I: "Ein Router hat meistens mehr als ein Interface, gewöhnlich auch IP-Adressen aus anderen Bereichen sonst könnte man doch garnicht in andere Netze Routen."
G: "Das ist aber trotzdem nicht unser Router..."
I: "Sagen Sie einmal, haben Sie überhaupt Ahnung von IP????"
G: "Wahrscheinlich sogar mehr als sie denken. Vielleicht routen sie auch garnicht über unseren Router, das DNS bestimmt schließlich wie geroutet wird."
I: "Wie bitte??? Was hat denn DNS mit Routing zu tun???? Können Sie mich bitte einmal mit einem Kollegen verbinden der Ahnung hat und sich auskennt?"
G: "Nein, das werde ich nicht tun. Das geht auch gerade nicht, die sind alle am telefonieren."
Jetzt hat er es geschafft, jetzt verliere sogar ich meine Ruhe:
I: "Ok, wie lautet Ihr Name?"
G: "Wieso wollen Sie den wisse?"
I: "Sagen sie mir doch einfach Ihren Namen."
G: "Den werde ich ihnen nicht sagen!"
I: "Warum wollen Sie mir den Ihren Namen nicht nennen?"
G: "Nein, den sage ich Ihnen nicht. Außerdem hatte ich Ihnen den schon ganz am Anfang genannt."
Als ob sich einer den Namen gleich merkt, ich jedenfalls nicht.
Schließlich rechnet man ja nicht damit, daß einem so ein DAU die
letzten Nerven raubt:
I: "Ok, dann verbinden Sie mich bitte mit Ihrem Chef."
Immerhin hatte ich dann jeman anderem am Ohr und es hätte vielleicht
auch die Chefin sein können. Immerhin sagte sie, daß an diesen Routern
heute Nacht ohnehin die Konfiguration geändert wird. Da ich ohnehin
keine Lust mehr hatte mich aufzuregen habe ich es dabei belassen
in der Hoffnung, daß das Problem dann morgen vielleicht schon behoben
ist.
Unnötig zu erwähnen: Es war nicht behoben.
Also gab ich eine kurze Zusammenfassung an den Kunden in der Schweiz
weiter, der hatte noch einen Consultant griffbereit der früher bei
green gearbeitet hat. Dieser hat mich dann noch kontaktiert, dem
habe ich kurz den Sachverhalt erklärt und er hat es sogar verstanden.
Er wollte dann durch seine alten Beziehungen direkt den IT-Leiter
dort ansprechen. Meinen Hinweis er sollte es besser mit der Hotline
versuchen, die wäre amüsanter, hat er abgelehnt, er kenne die
Qualität der Leute da schon...
Dabei wäre das Problem vermutlich leicht zu klären gewesen wenn der
Greenler ein wenig kooperativer und kompetenter gewesen wäre.
Vermutliche Ursache:
* Sie verwenden eine DSL-Leitung um Kunden anzubinden, d.h. die MTU ist nur 1492
* Zwischen zwei Ihrer Router, z.B 194.42.48.63 und 80.254.161.52
verwenden sie RFC-1918 Adressen, also z.B. 192.168.1.x, das ist
nichts ungewöhnliches, diese Adressen tauchen normalerweise
nirgendwo auf. Unnormal ist aber, wenn diese Router dann ICMPs
generieren, dann ist die Absendeadresse eventuell dies RFC-1918
Adresse die ein Router auf dem Weg gemäß dem RFC verwirft. Daher
kommt das ICMP-Paket nicht an.
Was allerdings der genauer Grund ist werden wir vermutlich nicht
erfahren. Vielleicht ist der Router auch so konfiguriert, daß er
keine ICMP's generieren soll, etc.
Erstellt von Dirk.
