tracerouten & tweaked alcatel

[ErwinvA]

ik weet dat er aardig wat posts over alcatel modems gaan etc.. maar er stond niet direct iets in wat het antwoord geeft op de volgende vraag:

waarom werkt traceroute via een gehackte modem wel in FreeBSD & Debian maar niet in Win32 (2k/xp)

ze maken beide gebruik van ICMP en die worden niet 'herkend' door een getweaked modem

[supakeen]

Lijkt meer op een fout van Win32 Al eens geprobeerd met een ander programma dan de cmd

[ErwinvA]

hmm.. ik heb me er nooit echt heel erg in verdiept, maar het vreemde is dat een gehackt/ed alcatel modem niet om kan gaan met ICMP packages .. en als het goed is gebruiken traceroute's die wel.. tres strange

[QBiT]

Voor zo ver ik weet kan het helemaal niet achter een gehackte modem met NAT. zie ook de FAQ van bruning.

[Verwijderd]

ErwinvA schreef op 06 juli 2002 @ 23:46:
ik weet dat er aardig wat posts over alcatel modems gaan etc.. maar er stond niet direct iets in wat het antwoord geeft op de volgende vraag:

waarom werkt traceroute via een gehackte modem wel in FreeBSD & Debian maar niet in Win32 (2k/xp)

ze maken beide gebruik van ICMP en die worden niet 'herkend' door een getweaked modem

traceroute op unix werkt op een andere manier, ik dacht via hogere poorten. Hier kan nat wel mee omgaan ... de implementatie van M$'s traceroute is dus niet helemaal volgens de standaard

Zover was ik dus in het oplossen van dit probleem... nu de werkelijke oplossing nog scoren en dan heb ik weer een blije klant.

Het probleem wat ik heb is trouwens op een CheckPoint Firewall -1 NG. Het ligt dus niet perse aan de Alcatel lijkt me.

[ripexx]

Dit is weer eens zo'n microsoft stunt, het progje voor window sheet ook nite voor niets tracert ipv traceroute. Ik had hetzelfde probleem, dus gebruik nu gewoon standaard linux

Wat betreft ICMP, zouden deze gewoon doorgelaten moeten worden, want een ping werkt wel, nog zelfs ff bij ms zelf gezocht maar kan dara niet een twee drie wat vinden.

[Verwijderd]

ripexx schreef op 23 augustus 2002 @ 16:21:
Wat betreft ICMP, zouden deze gewoon doorgelaten moeten worden, want een ping werkt wel, nog zelfs ff bij ms zelf gezocht maar kan dara niet een twee drie wat vinden.

Dit nog wel gevonden hierover:

That's because tracert uses PING to gather the info shown.

The problem is that NAT works needs a connection to be established so it can
map the host+port from the outside network to an internal host+port. Since
ping does not establishes a connection it can be mapped. Even if ping would
establish a connection, tracert won´t work because it uses a ping with a
very short TTL setting to purposedely obtain the ICMP info upon failure of
the TTL.

[ Voor 0% gewijzigd door Verwijderd op 23-08-2002 16:26 . Reden: rare paste ]

[Verwijderd]

traceroute (linux) werkt op een andere manier dan die van windows.

traceroute stuurt udp pakketjes naar een ongeldige poort met verschillende TTL terwijl tracert icmp echo requests verstuurt met verschillende TTL

Het is dan ook bekend dat die van linux meer kans maakt dan de windows variant om betere resultaten te geven.

ik heb juist gereageerd op een *boohoo*

[QBiT]

TTL van tracert kan je verhogen volgensmij. maar dan houd je nog het probleem dat het connectionless is Maarja, als het onder unix werkend te krijgen is, is er vast ook wel een progje dat het onder windows kan op een NORMALE manier

[PowerFlower]

code:

C:\>tracert www.xs4all.nl -w 1000

Tracing route to 0.0.3.232 over a maximum of 30 hops

  1   <10 ms   <10 ms   <10 ms  SpeedTouch.lan [10.0.0.138]
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.

Vreemd dat hij dat lokale (NAT?) IP gebruikt, maar ook met direct gebruik van IP niente. Maar hogere timeouts helpen iig niet en de ttl kun je niet aanpassen.

[QBiT]

ttl = timetolife = timeout ?

[Verwijderd]

dit gaat inderdaat niet, omdat je geen IP meer hebt, niks aan te doen..