Hallo Liste.
Ich würde gerne in einem Skript prüfen, ob eine Netzwerkverbindung besteht oder nicht, und je nachdem abbrechen oder weitermachen.
Wie macht man denn sowas am elegantesten? Ich hab mir gedacht, ich könnte ja einen Ping absetzen und schauen, ob eine Antwort kommt. Aber erstens schlägt ein erster Ping oft fehl (wg. Dialup), und zweitens prüft diese Vorgehensweise genaugenommen ja die Verfügbarkeit des Zielrechners. Was ist, wenn der down ist, obwohl das Netz ansonsten verfügbar wäre? Oder wenn er neuerdings nicht mehr auf Ping reagiert?
Da ich ganz unterschiedlich ins Netz gehe, mal über LAN/Dialup, mal über LAN/Standleitung, mal direkt über Dialup, kann ich nicht einfach die lokalen Netzwerkeinstellungen überprüfen (ifstatus ippp0 oder sowas).
Was gäbe es denn noch für Möglichkeiten?
On Tue, Sep 20, 2005 at 09:44:25AM +0200, Andre Tann wrote:
Hallo Liste.
Ich würde gerne in einem Skript prüfen, ob eine Netzwerkverbindung besteht oder nicht, und je nachdem abbrechen oder weitermachen.
Wie macht man denn sowas am elegantesten? Ich hab mir gedacht, ich könnte ja einen Ping absetzen und schauen, ob eine Antwort kommt. Aber erstens schlägt ein erster Ping oft fehl (wg. Dialup), und zweitens prüft diese Vorgehensweise genaugenommen ja die Verfügbarkeit des Zielrechners. Was ist, wenn der down ist, obwohl das Netz ansonsten verfügbar wäre? Oder wenn er neuerdings nicht mehr auf Ping reagiert?
Da ich ganz unterschiedlich ins Netz gehe, mal über LAN/Dialup, mal über LAN/Standleitung, mal direkt über Dialup, kann ich nicht einfach die lokalen Netzwerkeinstellungen überprüfen (ifstatus ippp0 oder sowas).
Was gäbe es denn noch für Möglichkeiten?
Ein traceroute oder ein DNS lookup (wenn kein lokaler Nameserver läuft).
Gruß, Jürgen
Hallo Andre Tann, hallo auch an alle anderen
Am Dienstag, 20. September 2005 09:44 schrieb Andre Tann:
Hallo Liste.
Ich würde gerne in einem Skript prüfen, ob eine Netzwerkverbindung besteht oder nicht, und je nachdem abbrechen oder weitermachen.
Wie macht man denn sowas am elegantesten? Ich hab mir gedacht, ich könnte ja einen Ping absetzen und schauen, ob eine Antwort kommt. Aber erstens schlägt ein erster Ping oft fehl (wg. Dialup), und zweitens prüft diese Vorgehensweise genaugenommen ja die Verfügbarkeit des Zielrechners. Was ist, wenn der down ist, obwohl das Netz ansonsten verfügbar wäre? Oder wenn er neuerdings nicht mehr auf Ping reagiert?
Schau dir mal arping an.
Das Programm erfragt für die angegebeen IP die MAC der Netzwerkkarte. Die ist nötig für die direkte Adressierung (OSI-Schicht 1), weshalb der Zielrechner darauf immer antwortet (so er erreichbar ist).
Tag.
On 21.09.2005 18:23, Matthias Houdek wrote:
Hallo Andre Tann, hallo auch an alle anderen
Am Dienstag, 20. September 2005 09:44 schrieb Andre Tann:
Hallo Liste.
Ich würde gerne in einem Skript prüfen, ob eine Netzwerkverbindung besteht oder nicht, und je nachdem abbrechen oder weitermachen.
Wie macht man denn sowas am elegantesten? Ich hab mir gedacht, ich könnte ja einen Ping absetzen und schauen, ob eine Antwort kommt. Aber erstens schlägt ein erster Ping oft fehl (wg. Dialup), und zweitens prüft diese Vorgehensweise genaugenommen ja die Verfügbarkeit des Zielrechners. Was ist, wenn der down ist, obwohl das Netz ansonsten verfügbar wäre? Oder wenn er neuerdings nicht mehr auf Ping reagiert?
Das erste Problem liesse sich lösen indem Du entweder einmal pingst, etwas wartest, und dann richtig loslegst, oder ein längeres Timeout und mehrere Retries einplanst, oder erstmal die Internetverbindung aufbaust.
Das zweite Problem lässt sich lösen indem Du z.B. mehrere Rechner pingst die Du sinnvoll wählst - z.B. dürfte es unwahrscheinlich sein dass www.goole.com und www.microsoft.com und www.ibm.de gleichzeitig nicht erreichbar sind (allerdings würde ich etwas sorgfältiger auswählen, zum einen lieber IP-Adressen nutzen falls mein DNS ausgefallen ist, zum anderen die Zieladressen etwas zurückhaltend wählen - immerhin ist es unhöflich anderer Leute Resourcen unbedacht zu nutzen).
Die eleganteste Möglichkeit ist nach meiner Meinung ein traceroute auf irgendeine IP-Adresse die (quasi) immer verfügbar ist, wobei mich nicht der ganze trace interessiert, sondern nur ob Pakete aus meinem Netz rausgehen, d.h. z.B. ob ein zweiter Router sich meldet - das wäre dann hier irgendein Router beim POP meines Providers, oder der Access point der Telekomiker.
Schau dir mal arping an.
Das Programm erfragt für die angegebeen IP die MAC der Netzwerkkarte. Die ist nötig für die direkte Adressierung (OSI-Schicht 1), weshalb der Zielrechner darauf immer antwortet (so er erreichbar ist).
Auch nicht unfehlbar... vor allem geht das nur im lokalen Subnetz.
Grundsätzlich ist das Originalproblem nicht ohne. Bei den Leuten die sich damit beschäftigen gibt es eigentlich nur einen Konsens: Es gibt keine Möglichkeit einen Rechner "aufzuspüren" der nicht aufgespürt werden will. Daher hält man sich besser an Dienste als an Rechner - z.B. wird www.google.de u.U. pings ignorieren, aber auf http-Anfragen werden die schon antworten...
Ansonsten: www.nagios.org bietet eine "grosse" Lösung. Die Plugins lassen sich auch einzeln zum Prüfen von Diensten einspannen (z.B. check_http). Und die Mailinglistenarchive enthalten leider zu 80% Fragen auf die man nur RTFM antworten kann, aber im Rest finden sich auch Perlen wenn man sich mit den Grundsätzen des Monitoring beschäftigen will oder muss.
Arno
Hallo,
Am Tue, 27 Sep 2005, Arno Lehmann schrieb:
Die eleganteste Möglichkeit ist nach meiner Meinung ein traceroute auf irgendeine IP-Adresse die (quasi) immer verfügbar ist, wobei mich nicht der ganze trace interessiert, sondern nur ob Pakete aus meinem Netz rausgehen, d.h. z.B. ob ein zweiter Router sich meldet
Dafuer reicht ein Ping auf eine gueltige IP, z.B. die des DNS:
ping -n -c 1 -t 3 -w 20 194.25.2.129 ^^^^ IP bitte anpassen. Ein traceroute macht ja auch nix anderes als PINGs mit steigender ttl ab 1 auszusenden.
-dnh
Guten Morgen (na ja, gleich...),
On 27.09.2005 19:15, David Haller wrote:
Hallo,
Am Tue, 27 Sep 2005, Arno Lehmann schrieb:
Die eleganteste Möglichkeit ist nach meiner Meinung ein traceroute auf irgendeine IP-Adresse die (quasi) immer verfügbar ist, wobei mich nicht der ganze trace interessiert, sondern nur ob Pakete aus meinem Netz rausgehen, d.h. z.B. ob ein zweiter Router sich meldet
Dafuer reicht ein Ping auf eine gueltige IP, z.B. die des DNS:
ping -n -c 1 -t 3 -w 20 194.25.2.129 ^^^^IP bitte anpassen. Ein traceroute macht ja auch nix anderes als PINGs mit steigender ttl ab 1 auszusenden.
Na ja. Im Prinzip hast Du recht, aber zunächst mal glaube ich ja dass ich nicht wissen kann welche IPs extern gültig sind. Und die IP-Adressen der nächsten Router können sich nun mal ändern. Und ein traceroute -m 3 134.76.123.34 | head -n 3 | tail -n 1 z.B. sollte dann imer eine Zeile liefern die (hier) auf /2 *[0-9]+.[0-9]+.[0-9]+.[0-9]+ */ passt. Oder so. Mit ping krieg' ich dann normalerweise ein ttl exceeded, und das sagt mir eben nicht ob der erste Upstream-Router geantwortet hat oder nur 'ne andere IP hat als ich erwartete.
Arno
-dnh
Hallo,
Am Tue, 27 Sep 2005, Arno Lehmann schrieb:
On 27.09.2005 19:15, David Haller wrote:
Dafuer reicht ein Ping auf eine gueltige IP, z.B. die des DNS:
ping -n -c 1 -t 3 -w 20 194.25.2.129 ^^^^ IP bitte anpassen. Ein traceroute macht ja auch nix anderes als PINGs mit steigender ttl ab 1 auszusenden.
Na ja. Im Prinzip hast Du recht, aber zunächst mal glaube ich ja dass ich nicht wissen kann welche IPs extern gültig sind.
Naja, die des (externen) DNS-Servers sollte wohl gueltig sein... ;)
Und die IP-Adressen der nächsten Router können sich nun mal ändern. Und ein traceroute -m 3 134.76.123.34 | head -n 3 | tail -n 1 z.B. sollte dann imer eine Zeile
^^^^^^^^^^^ ueberfluessig, zumindest bei meinem traceroute
liefern die (hier) auf /2 *[0-9]+.[0-9]+.[0-9]+.[0-9]+ */ passt. Oder so.
Jep. Die Option -m von traceroute kannte ich noch gar nicht, das macht ja im Prinzip das, was gemeint war (s.u.).
Mit ping krieg' ich dann normalerweise ein ttl exceeded, und das sagt mir eben nicht ob der erste Upstream-Router geantwortet hat oder nur 'ne andere IP hat als ich erwartete.
Der Witz ist, dass du normalerweise (musst eben einmal mit traceroute schauen, wie du im Netz haengst) > 5 hops zu praktisch allen Servern hast. Bsp:
$ traceroute ftp.de.kernel.org traceroute to ftp.de.kernel.org (62.112.154.204), 30 hops max, 40 byte packets 1 fritz.fonwlan.box (192.168.178.1) 1 ms 1 ms 1 ms 2 217.0.116.64 (217.0.116.64) 48 ms 43 ms 50 ms 3 217.0.68.146 (217.0.68.146) 45 ms 44 ms 44 ms 4 l-eb1.L.DE.net.DTAG.DE (62.154.89.102) 54 ms 54 ms 54 ms 5 62.156.139.98 (62.156.139.98) 60 ms 60 ms 59 ms 6 kpn.netdiscounter.de (134.222.107.254) 61 ms 60 ms 60 ms 7 gw.1st-housing.gbit1.netdiscounter.de (62.112.129.174) 61 ms 61 ms 62 ms 8 spiderman.gw-ext.fue.kgt.org (62.112.152.29) 63 ms 59 ms 62 ms 9 kgt.lkams.kernel.org (62.112.154.204) 65 ms 61 ms 60 ms
Wenn man ein paar traceroutes in verschiedene Netze (in DE, EU, US) vergleicht sieht man, dass die ersten X hops immer gleich sind bzw. dass immer mindestens Y hops bis zu einem CIX sind. Bzw. man sieht, dass diese ersten hops immer aus dem gleichen Netz sind (z.B. 217.0.x.y bei der rosa Puschel Infrastuktur von hier aus)...
Und die IPs, die noch im eigenen Netz liegen sollte man ja kennen (hier also 192.168.178.0/24 der fritzbox).
Meine Idee war nun: per Ping mit begrenzter TTL auf eine bekanntermassen gueltige IP (eben z.B. den DNS des Providers o.ae) pingen. Kommt dann von ausserhalb des eigenen Netzes die Meldung:
==== $ ping -n -c 1 -t 4 -v -w 3 194.25.2.129 ### = dns00.btx.dtag.de PING 194.25.2.129 (194.25.2.129): 56 data bytes 36 bytes from 62.154.58.166: Time to live exceeded Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data 4 5 00 5400 7950 0 0000 01 01 e231 192.168.178.11 194.25.2.129
--- 194.25.2.129 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss ====
XXX bytes from 62.154.58.166 (was auch ne dtag-IP ist), dann weiss man, dass das Netz bis zu diesem Host eben "steht".
Die Loesung mit 'traceroute -m 4' ist aber wohl huebscher. Bequemer aber nicht unbedingt.
EXTIP=`ping -n -c 1 -t 4 -v -w 3 194.25.2.129 \ | sed -n '/Time to live exceeded/s/.* ([0-9.]+):.*/\1/p'`
Jetzt kann man noch pruefen, ob $EXTIP nicht aus dem eigenen Netz stammt oder ob $EXTIP aus einem der Netzbloecke des Providers stammt. Und schwuppdiwupp weiss man, dass das Netz da draussen laeuft ;)
Nochmal: intern verwendet traceroute genau diesen Mechanismus: es sendet zur angeforderten IP (ggfs. nach Aufloesung eines Hostnamens) PING Pakete mit einer TTL von 1, 2, 3 ... bis der Zielhost erreicht ist oder ein Fehler (ausser TTL exceeded) auftritt... Die bei jedem Schritt gefundenen Hosts (die eben die Fehlermeldung TTL exceeded) zurueckschicken gibt traceroute eben aus (ggfs. wieder nach reverse-lookup des Hostnamens)... Simpelst:
==== poor-mans-traceroute UNGETESTET! ==== #!/bin/sh MAXHOPS=30 ## ist IIRC traceroute default TIMEOUT=2
test -n "$1" || { echo "Usage: $0 IP"; exit 1; } eingabeip="$1"
hops=1 while test $hops -lt $MAXHOPS; do pingout="`ping -c 1 -t $hops -v -w $TIMEOUT $eingabeip`" # | tee /dev/stderr
extip=`echo "$pingout" | sed -n "/Time to live exceeded|bytes from $eingabeip/s/.* ([0-9.]+):.*/\1/p"`
if test "x$extip" = "x$eingabeip"; then printf "% 2i %s\n" $hops $extip exit 0 elif test -n "$extip"; then printf "% 2i %s\n" $hops $extip else printf "% 2i * * *\n" $hops fi hops=$(( hops + 1 )) done ====
$ sh ~/bin/poor-mans-traceroute 194.25.2.129 1 * * * 2 217.0.116.64 3 217.0.68.150 4 62.154.58.166 5 62.156.139.102 6 194.25.2.129
Ich hoffe, es ist jetzt klarer, was ich gemeint habe ;)
-dnh
Am Wed, 28 Sep 2005, David Haller schrieb:
==== poor-mans-traceroute UNGETESTET! ====
[..]
====
Nachtrag: Da fehlt allerdings noch die Fehlerbehandlung, DNS, reverse-DNS usw., aber das script sollte ja nur demonstrieren, wie traceroute funktioniert.
Jetzt aber noch zum eigentlichen Punkt: Wie man am script sieht, und wie man z.B. mittels eine tcpdump feststellen kann wird beim traceroute (auch mit -m X) fuer jeden Hop ein ICMP ECHO_REQUEST -Paket weggeschickt und (mindestens) ein ICMP ECHO_REPLY bzw. TTL-EXCEEDED zurueck.
Ein einzelnes 'ping -c 1 -t 4 -v -w 3 IPADRESSE' wie von mir vorgeschlagen hingegen verursacht genau ein ICMP ECHO_REQUEST und genau ein TTL-EXCEEDED.
Vor allem also, wenn man ueber viele Hops testen will verursacht ein traceroute deutlich mehr Verkehr auf den beteiligten Rechnern.
Bei mir mit 4 hops verursacht 'traceroute -m 4' 14 ICMP-Pakete, ein einzelnes 'ping -t 4' nur zwei(!).
Weil ich von diesen Hintergrund (wie traceroute arbeitet) wusste kam mir eben die Idee, nur _ein_ 'ping' mit beschraenkter TTL loszuschicken und eben NICHT traceroute zu verwenden. Dass das Ping bei der Ziel-IP nicht ankommt ist beide Male irrelevant, das passiert beim traceroute ja auch nicht (bzw. erst beim letzten Hop, sofern die TTL ausreicht)...
Das 'ping -t X' ist also vergleichbar mit _dem letzten Schritt_ eines 'traceroute -m X'. Und die Schritte davor beim traceroute sind ueberfluessig, will man nur schauen, ob man bis eben zum Xten "hop" durchkommt.
HTH & HAND, -dnh
Tag,
On 28.09.2005 03:22, David Haller wrote:
...
Na ja. Im Prinzip hast Du recht, aber zunächst mal glaube ich ja dass ich nicht wissen kann welche IPs extern gültig sind.
Naja, die des (externen) DNS-Servers sollte wohl gueltig sein... ;)
Also gut, bei den root-Servern lass' ich ja mit mir reden. :-)
Und die IP-Adressen der nächsten Router können sich nun mal ändern. Und ein traceroute -m 3 134.76.123.34 | head -n 3 | tail -n 1 z.B. sollte dann imer eine Zeile
^^^^^^^^^^^ ueberfluessig, zumindest bei meinem traceroute
Normalerweise ja, aber damit kann ich zumindest auch unerwartete Ausgaben von traceroute als Fehler erkennen. Wenn's eben aus was für Gründen auch immer mehr Text gibt... allerdings hab' ich im Normalbetrieb dann auch noch ein >>&2 eingestreut...
liefern die (hier) auf /2 *[0-9]+.[0-9]+.[0-9]+.[0-9]+ */ passt. Oder so.
Jep. Die Option -m von traceroute kannte ich noch gar nicht, das macht ja im Prinzip das, was gemeint war (s.u.).
Mit ping krieg' ich dann normalerweise ein ttl exceeded, und das sagt mir eben nicht ob der erste Upstream-Router geantwortet hat oder nur 'ne andere IP hat als ich erwartete.
Der Witz ist, dass du normalerweise (musst eben einmal mit traceroute schauen, wie du im Netz haengst) > 5 hops zu praktisch allen Servern hast. Bsp:
Äh, ja. Das ist mir klar. Aber irgendwie ist mir grade nicht klar wie das mein Problem löst (zugegeben, ursprünglich nicht meins): Ich will ja wissen ob eine Internetverbindung besteht. Ich kann die IP-Adresse des Upstream-Routers nicht wissen. Ich kann aber, ausgehend von der Kenntnis meines Netzwerks, wissen nach welchem Hop ich "Das Internet" am Draht habe, nämlich nach einem mehr als ich Router intern passiere.
Aber unabhängig davon - das häufigere Problem das ich sehe ist ein anderes, und damit kommt in der Tat Dein ping-Vorschlag besser zurecht als mein traceroute - sind router die gar keine ICMP ttl exceeded, timeouts oder echo replies verschicken. Ich muss da erst auf 'ne IP filtern, ping liefert dann schon das (brauchbare) timeout.
...
Die Loesung mit 'traceroute -m 4' ist aber wohl huebscher. Bequemer aber nicht unbedingt.
;-)
Stimmt. Das script drumrum hat mich damals etwas Zeit gekostet...
EXTIP=`ping -n -c 1 -t 4 -v -w 3 194.25.2.129 \ | sed -n '/Time to live exceeded/s/.* ([0-9.]+):.*/\1/p'`
Jaja, ich geb' ja zu das das den einen oder anderen Prozess spart...
Jetzt kann man noch pruefen, ob $EXTIP nicht aus dem eigenen Netz stammt oder ob $EXTIP aus einem der Netzbloecke des Providers stammt. Und schwuppdiwupp weiss man, dass das Netz da draussen laeuft ;)
Wobei das dann wieder das unbequeme Drumherum ergibt :-P
... Danke für das schöne Beispiel. Wie gross ist eigentlich inzwischen Deine Sammlung solcher ad-hoc-Demontrationen?
Ich hoffe, es ist jetzt klarer, was ich gemeint habe ;)
Ooch, mir schon, nur bin ich bei meiner Lösung von dem - zugegebenermassen nicht besonders häufig zutreffenden - Fall ausgegangen dass ich eben keine garantiert vorhandene externe IP-Adresse kenne und dass ich nicht wissen kann aus welchem IP-Subnetz mein Provider seine Router versorgt.
Das ist allerdings bei genau einer Internetanbindung mit festem Vertragspartner bzw. Kabelvermieter eher kein Problem :-)
Arno
-dnh
Hallo,
Am Thu, 29 Sep 2005, Arno Lehmann schrieb:
On 28.09.2005 03:22, David Haller wrote: ...
Na ja. Im Prinzip hast Du recht, aber zunächst mal glaube ich ja dass ich nicht wissen kann welche IPs extern gültig sind.
Naja, die des (externen) DNS-Servers sollte wohl gueltig sein... ;)
Also gut, bei den root-Servern lass' ich ja mit mir reden. :-)
*g* Oder die deines Providers... Ggfs. kann man die ja direkt aus der /etc/resolv.conf auslesen oder bei nem extra Router kommt man u.U. auch ran (wenn der Router ein telnet IF hat und man darueber die IP auslesen kann -- Theoretisch koennte man auch eine WUI[1] parsen). Oder man sucht sich ne Liste von IPs zusammen (z.B. die Nameserver von mehreren grossen Providern) und iteriert ueber diese bis man durchkommt oder sowas... Ich hab hier noch z.B. einige IPs von T-Online (dns, mail und news server)... Und die IPs der Root-Server kann man ja auch noch ans Ende der Liste stellen ;)
#/bin/bash ... IPLIST=( 194.25.2.129 194.25.2.130 194.25.2.131 ) for ip in ${IPLIST[*]}; do ... done
Dabei hilft ein 'dig ns provider.domain' ;)
[..]
Äh, ja. Das ist mir klar. Aber irgendwie ist mir grade nicht klar wie das mein Problem löst (zugegeben, ursprünglich nicht meins): Ich will ja wissen ob eine Internetverbindung besteht. Ich kann die IP-Adresse des Upstream-Routers nicht wissen. Ich kann aber, ausgehend von der Kenntnis meines Netzwerks, wissen nach welchem Hop ich "Das Internet" am Draht habe, nämlich nach einem mehr als ich Router intern passiere.
Jep. Oder zur Sicherheit noch ein hop mehr, denn ich kenne das von Modem und DSL, dass zwar der PtP erreichbar und pingbar war, aber alles dahinter nicht. Andererseits weisst du, dass wenn der erste externe Host erreichbar ist, dass dann die Minuten/Volumenzaehler wohl mitlaufen... Da muss man eben aussuchen, was genau man testen will ;) Jedenfalls: die Anzahl internen Hops sollte man i.d.R. kennen, ich kann mir was anderes nur bei wirklich grossen "internen" Netzen vorstellen, dass man mal ueber mehr und mal ueber weniger Hops nach "draussen" geroutet wird. Bsp. wenn man als T-* das T-* Netz als "intern" ansehen kann und auf verschiedenen Wegen zum DE-CIX oder ins DFN-Netz kommen kann ;)
Aber unabhängig davon - das häufigere Problem das ich sehe ist ein anderes, und damit kommt in der Tat Dein ping-Vorschlag besser zurecht als mein traceroute - sind router die gar keine ICMP ttl exceeded, timeouts oder echo replies verschicken. Ich muss da erst auf 'ne IP filtern, ping liefert dann schon das (brauchbare) timeout.
Dann kann man aber nicht unterscheiden ob "ausgefallen"... Naja, dann koennte man ausprobieren ein paar Hops weiter zu einem Host zu pingen der eine TTL-Exceeded Fehlermeldung liefert, so dass man diese von einem Ausfall unterscheiden kann.
[..]
... Danke für das schöne Beispiel.
Siehe bitte den Nachtrag!
Wie gross ist eigentlich inzwischen Deine Sammlung solcher ad-hoc-Demontrationen?
Keine Ahnung *g* Sind sicherlich inzwischen deutlich ueber 100... Und ich hebe auch nicht alles auf bzw. habe die teils nur und direkt in eine Mail geschrieben...
Ich hoffe, es ist jetzt klarer, was ich gemeint habe ;)
Ooch, mir schon, nur bin ich bei meiner Lösung von dem - zugegebenermassen nicht besonders häufig zutreffenden - Fall ausgegangen dass ich eben keine garantiert vorhandene externe IP-Adresse kenne
Siehe oben. Das kann man umgehen und IMHO hinreichend zuverlaessig machen. Es muesste dann reichen, so vielleicht alle 3 Monate oder so mal zu schauen, ob die IPs noch bekannt sind[2]. Der Witz ist ja, dass man ja gar nicht bis zur Ziel-IP durchpingen braucht und will :) Das einzige was man braucht ist, dass die Ziel-IP als "routebar" angesehen wird :)
und dass ich nicht wissen kann aus welchem IP-Subnetz mein Provider seine Router versorgt.
Siehe oben, das muss man auch garnicht wenn man das oder die interenen Netze kennt -- dann testet man eben "$extip \not\in $int_networks".
Das ist allerdings bei genau einer Internetanbindung mit festem Vertragspartner bzw. Kabelvermieter eher kein Problem :-)
Dann noch weniger, jep :)
-dnh
[1] Web User Interface ;)
[2] koennte man mittels eines weiteren scripts und cron auch automatisieren ;)
-
Andre Tann -
Arno Lehmann -
David Haller -
Jürgen Knelangen -
Matthias Houdek