Wer ist noch unzufrieden mit INODE.at

[jutta]

ich sag ja......
von wo anders geht es .... nur ueber mein XDSL eben nicht mehr...

nein - von woanders gehts dann *nicht*, wenn man icmp verwendet.

[Adream]

1 0 0 0 192.168.2.1 RAZOR.com
2 7 7 7 213.191.89.24 Germany C
3 11 11 11 213.191.88.114 Germany C
4 11 12 13 213.191.87.198 Germany C
5 11 11 11 213.191.87.202 Germany C
6 11 12 13 80.81.192.47 ff-m-GB-11-cix.frankfm.germ.inode.de Germany A
7 27 27 29 62.99.170.1 ott1-po-07-001.shuttle.vien.inode.at Austria A
8 27 27 28 62.99.170.214 vie2-po-00-002.shuttle.vien.inode.at Austria A
9 29 29 30 62.99.170.206 voe2-vl-00-020.voesend.vien.inode.at Austria A
10 33 33 34 62.99.170.106 schl-vl-00-981.josemic.klgf.inode.at Austria A
11 33 33 34 62.99.170.38 kela-vl-00-005.villach.krtn.inode.at Austria A
12 33 33 33 81.223.38.101 Austria A
13 49 49 51 85.125.76.177 Austria A
14 * * * * * * *


Geht auch hier nicht weiter

[eisberg]

dann probiert ein ssh...

...login geb ich aber keines...

[max_payne]

na toll....
einmal ssh ohne login
bittesehr:

[eisberg]

ping......icmp ist geblockt !

[roro]

Ob es von uns aus geht oder nicht ist mehr oder weniger irrelevant, da es ja um den Zugang von eisberg geht. Was mich wundert ist, dass bereits der 2. HOP nur mehr * anzeigt. Ich nehme an, dass Du Dein Modem bereits einmal neu gestartet hast.

[eisberg]

a traceroute von meim XDSL aufn DNS von AON

traceroute to 195.3.96.67 (195.3.96.67), 30 hops max, 40 byte packets
1 172.25.46.23 26.256 ms 24.550 ms 27.666 ms
2 kela-fe-00-002.villach.krtn.inode.at (81.223.38.97) 52.403 ms 20.504 ms 23.955 ms
3 schl-vl-00-005.josemic.klgf.inode.at (62.99.170.37) 23.311 ms 39.652 ms 35.455 ms
4 voe2-vl-00-981.voesend.vien.inode.at (62.99.170.105) 38.505 ms 30.923 ms 31.724 ms
5 vie2-vl-00-020.shuttle.vien.inode.at (62.99.170.205) 31.655 ms 31.435 ms 31.689 ms
6 otta-po-00-002.shuttle.vien.inode.at (62.99.170.213) 27.461 ms 31.452 ms 27.040 ms
7 vix2.highway.telekom.at (193.203.0.11) 28.629 ms 27.618 ms 27.780 ms
8 195.3.70.162 28.828 ms 29.006 ms 27.727 ms
9 195.3.70.30 34.356 ms 35.560 ms 31.458 ms
10 WARSL401-pub2.highway.telekom.at (213.33.98.132) 77.744 ms 31.360 ms 35.240 ms

[max_payne]

hast du das modem schon neu gestartet?

[eisberg]

hast du das modem schon neu gestartet?

jetzt grad nicht ...bin ja weit weg...
aber seit dem problem schon zig mal...
war uebrigens der erste (und letzte) vorschlag vom support...

[hmmmm]

Also ich kann hier überhaupt kein Fehlverhalten von Seiten der Inode GmbH feststellen ... immerhin ist Inode ein seriöser Provider - und - auch noch nicht an UPC verkauft. Flatrates sind bei Inode auch Flatrates ... ich habe noch nie von Reklamationen vom Provider gehört.

[roro]

Langsam glaube ich auch juttas Theorie.

Selbes Netzwerk

1. OS-X mit traceroute

traceroute to 85.125.76.178 (85.125.76.178), 64 hops max, 40 byte packets
1 192.168.1.1 (192.168.1.1) 5.297 ms 1.105 ms 0.524 ms
2 10.255.29.1 (10.255.29.1) 8.773 ms 6.409 ms 4.779 ms
3 schl-vl-00-988.josemic.klgf.inode.at (62.99.171.194) 11.072 ms 10.782 ms 16.607 ms
4 kela-vl-00-005.villach.krtn.inode.at (62.99.170.38 ) 11.882 ms 7.896 ms 11.483 ms
5 81.223.38.101 (81.223.38.101) 9.272 ms 9.738 ms 8.385 ms
6 85.125.76.177 (85.125.76.177) 25.359 ms 23.969 ms 25.481 ms
7 85.125.76.178 (85.125.76.178) 25.683 ms 24.850 ms 24.525 ms

2. Windows 2000 mit tracert

Routenverfolgung zu 85.125.76.178 Ã…ber maximal 30 Abschnitte
1 1 ms <10 ms <10 ms 192.168.1.1
2 4 ms 4 ms 4 ms 10.255.29.1
3 10 ms 7 ms 12 ms schl-vl-00-988.josemic.klgf.inode.at [62.99.171.194]
4 8 ms 8 ms 16 ms kela-vl-00-005.villach.krtn.inode.at [62.99.170.38]
5 8 ms 8 ms 8 ms 81.223.38.101
6 24 ms 24 ms 24 ms 85.125.76.177
7 * * * ZeitÃ…berschreitung der Anforderung.
8 * * * ZeitÃ…berschreitung der Anforderung.
9

[eisberg]

...das heisst ...es ist eh alles OK...
und ich bild mir nur ein dass es über meinem XDSL nicht geht...
dann hab ich mir wohl nur vorgemacht in den letzten monaten
die server gewartet zu haben...

mal sehen...vielleicht hat noch wer solche hallunzinationen...

[jutta]

...das heisst ...es ist eh alles OK...

nein, die einstellung der firewall auf dem einen server ist zb nicht ok.
die anderen server kennen wir nicht.

[superracer]

du hängst offenbar am selben einwahlknoten wie dein server, und anscheinend ist hier die wurzel des übels begraben. kannst du bitte mal:

1) deine eigene aktuelle ip notieren und danach posten
2) ethereal anstarten und auf der netzwerkkarte mitsniffen
3) ein traceroute auf deinen server machen
4) das dumpfile abspeichern und zusammen mit deiner ip hier posten (oder mir als PM schicken)

das ganze hat garantiert nichts mit verbrauchtem traffic oder gesperrten ips zu tun, das sieht eher nach einem routingproblem (auf welcher seite auch immer) aus.

[Neptunus]

Der Server antwortet nicht auf IP-Pakete

C:\>hping 85.125.76.178 --rawip
HPING 85.125.76.178 (IEEE 802.11b WLAN network adaptor PCI Card 85.125.76.178):
raw IP mode set, 20 headers + 0 data bytes

--- 85.125.76.178 hping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

nicht auf ICMP-Pakete

C:\>hping 85.125.76.178 --icmp
HPING 85.125.76.178 (IEEE 802.11b WLAN network adaptor PCI Card 85.125.76.178):
icmp mode set, 28 headers + 0 data bytes

--- 85.125.76.178 hping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

nicht auf TCP-Pakete

C:\>hping 85.125.76.178
HPING 85.125.76.178 (IEEE 802.11b WLAN network adaptor PCI Card 85.125.76.178):
NO FLAGS are set, 40 headers + 0 data bytes

--- 85.125.76.178 hping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

und nicht auf UDP-Pakete

C:\>hping 85.125.76.178 --udp
HPING 85.125.76.178 (IEEE 802.11b WLAN network adaptor PCI Card 85.125.76.178):
udp mode set, 28 headers + 0 data bytes

--- 85.125.76.178 hping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

es sei denn, sie werden zu einem Port > 1023 gesendet. In dem Fall kommt schön brav ein ICMP-Paket als Antwort, wies eigentlich immer der Fall sein sollte.

C:\>hping 85.125.76.178 --udp --destport 1024
HPING 85.125.76.178 (IEEE 802.11b WLAN network adaptor PCI Card 85.125.76.178):
udp mode set, 28 headers + 0 data bytes
ICMP Port Unreachable from ip=85.125.76.178 name=UNKNOWN
ICMP Port Unreachable from ip=85.125.76.178 name=UNKNOWN
ICMP Port Unreachable from ip=85.125.76.178 name=UNKNOWN
ICMP Port Unreachable from ip=85.125.76.178 name=UNKNOWN
ICMP Port Unreachable from ip=85.125.76.178 name=UNKNOWN

--- 85.125.76.178 hping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

Der Server scheint sich also immer tot zu stellen, wenn ihn Pakete erreichen - bis eben auf die hier genannte Ausnahme.

Zusätzlich tut er noch was, wenn er ein TCP-Paket auf Port 21, 22 oder 80 erhält und das SYN-Flag gesetzt ist. (hab Ports > 443 nicht getestet, es könnte da also auch noch was sein)
Heißt also, der Server ist auf diesen 3 Ports für Verbindungen von der Außenwelt erreichbar. Und da ich diese Test selber von einem Inode xDSL-Flatrate-Anschluss durchgeführt habe, heißt dies, dass Inode wahrscheinlich nicht willkürlich und vorsätzlich Pakete blockt, bei Kunden mit einer Flatrate.

C:\>hping 85.125.76.178 --scan 1-443 --syn
Scanning 85.125.76.178 (85.125.76.178), port 1-443
443 ports to scan, use -V to see all the replies
+----+-----------+---------+---+-----+-----+
|port| serv name | flags |ttl| id | win |
+----+-----------+---------+---+-----+-----+
21 ftp : .S..A... 55 24561 5840
22 : .S..A... 55 24817 5840
80 http : .S..A... 55 25073 5840
All replies received. Done.

Und hier noch der Weg, wie mich die von diesem Server versandten ICMP-Pakete erreichen:

C:\>hping 85.125.76.178 --udp --destport 1024 --rroute
HPING 85.125.76.178 (IEEE 802.11b WLAN network adaptor PCI Card 85.125.76.178):
udp mode set, 28 headers + 0 data bytes
ICMP Port Unreachable from ip=85.125.76.178 name=UNKNOWN
RR: 1.2.3.4
85.125.225.55
81.223.100.190
62.99.170.69
62.99.170.205
62.99.170.105
62.99.170.37
81.223.38.97
172.25.46.23
ICMP Port Unreachable from ip=85.125.76.178 name=UNKNOWN
(same route)
ICMP Port Unreachable from ip=85.125.76.178 name=UNKNOWN
(same route)
ICMP Port Unreachable from ip=85.125.76.178 name=UNKNOWN
(same route)
ICMP Port Unreachable from ip=85.125.76.178 name=UNKNOWN
(same route)
ICMP Port Unreachable from ip=85.125.76.178 name=UNKNOWN
(same route)
ICMP Port Unreachable from ip=85.125.76.178 name=UNKNOWN
(same route)
ICMP Port Unreachable from ip=85.125.76.178 name=UNKNOWN
(same route)

--- 85.125.76.178 hping statistics ---
9 packets transmitted, 8 packets received, 12% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

Verwundern tut mich aber, dass dein geposteter Traceroute bei einer Adresse 172.* endet. Steht der betroffene Server vielleicht in der Nähe (netzwerkmäßig) von deinem Zugang?

Wenn ja, könnte es sich um ein Routing-Problem von Inode handeln.
Seltsam, dass das der Support nicht bemerkt hat ... Da verstehe anscheined ja selbst ich besser, was im Inode-Netz los ist, als Inode selbst ...