Newsgroup: it.comp.os.linux.sys
Titolo: ping sì, traceroute no?

Scusate l'ignoranza... mi hanno segnalato un problema di connessione tra 
un server con Suse SLES 8 e un altro server remoto Unix HP (nel mezzo ci 
sono un paio di router gestiti da Telecom). Mi sono messo ad indagare ed 
ho fatto i controlli di base: ping, traceroute, ecc. ecc...
ebbene: la cosa veramente bizzarra è che da linux a HP i ping vanno 
tranquillamente, il traceroute non parte neanche. In senso inverso non 
va una mazza, o meglio il trace parte ma si ferma all'interfaccia del 
router. Servizi più "elevati" (telnet, ftp) vanno in un senso, ma non 
nell'altro.
Sto cercando di far resettare i router che ci sono nel mezzo perchè 
sospetto che risentano ancora dello spumante di fine anno ;-)... ma nel 
frattempo, la cosa che mi lascia veramente basito è quella in subject. 
Ero convinto che ping e traceroute usassero entrambi degli ICMP echo 
request per funzionare... com'e' possibile che uno vada e l'altro no??
bye bye!
-- 
Fabrizio "Hermooz" Ermini

 tranquillamente, il traceroute non parte neanche.
Evidentemente uno dei router in mezzo non fa' passare i
corrispondenti pacchetti ICMP.
Davide
-- 
| When you say 'I wrote a program that crashed Windows', people just
| stare at  you blankly and say 'Hey, I got those with the system, for
| free' --Linus Torvalds 

> tranquillamente, il traceroute non parte neanche.
DB> Evidentemente uno dei router in mezzo non fa' passare i
DB> corrispondenti pacchetti ICMP.
Mi sa che Davide ha ragione:
Dal man di traceroute sulla mia Debian: 
       -I     Use ICMP ECHO instead of UDP datagrams.
Prova ad usarlo sulla macchina GNU/Linux (traceroute -I host).
Il perche'  della non bidirezionalita`  puo` essere dovuto o  al fatto
che il traceroute di HP spara delle echo request (ICMP ECHO) invece di
datagram  UDP oppure  che in  una  direzione i  pacchetti UDP  vengono
filtrati e nell'altra no. Le risposte sono sempre ICMP TIME_EXCEEDED.
/* 
 * Per la cronaca, anche io pensavo che traceroute sparasse ICMP ECHO
 * come Ping. Mi sa che la cosa dipende dall'implementazione in quanto
 * quello che conta e` la generazione dell pacchetto ICMP
 * TIME_EXCEEDED  
 */
 /\            ___
/___/\__|_|\_|__|___Gian Uberto Lauri_____________________
  //--\ | | \|  |   Integralista GNUslamico e fancazzista 
\/

  */
Pensavi male.
Ping fa un banale echo request, e aspetta un echo reply. Traceroute a
seconda dell'implementazione, manda pacchetti udp con ttl in scadenza.
Leggi rfc1393, per capire come funziona traceroute, e come potrebbe
funzionare piu` avanti.
Consiglio anche l'uso di tcptraceroute, o tool furbi come hping per
questo genere di cose.
Ps:
Per cultura, e` interessante anche questo:
http://www.faqs.org/faqs/internet/tcp-ip/applications-FAQ/index.html
HTH,
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
God is real, unless declared integer

> TIME_EXCEEDED */
M> Pensavi male.
Non  cosi` male. 
Purtroppo  era "male"  il  sistema dove  per  la prima  volta mi  sono
interessato a guardare la  documentazione (l'implementazione di M$ usa
sempre gli ICMP ECHO)
M> Ping fa un banale echo request, e aspetta un echo reply. Traceroute
M> a seconda dell'implementazione, manda pacchetti udp con ttl in
M> scadenza.
Manca "dopo un prefissato numero di hops" per completare la frase :).
M> Leggi rfc1393, per capire come funziona traceroute, e come potrebbe
M> funzionare piu` avanti.
Parla principalmente di un protocollo che probabilmente nessuno usera`
se non con IPV6 (quando questo arrivera`).
M> Consiglio anche l'uso di tcptraceroute, o tool furbi come hping per
M> questo genere di cose.
Carucci. Carucci forte! Grazie.
Conta  pero`  che solo  ping  aveva  una  vecchia manpage  che  faceva
riferimento al  test dei rami  della rete sopravvissuti ad  un attacco
nucleare (sovietico)... :)
M> Ps: Per cultura, e` interessante anche questo:
M> 
http://www.faqs.org/faqs/internet/tcp-ip/applications-FAQ/index.html
Ha una  cosa che  manca nella  parte del talk,  dimentica di  dire che
l'implementazione  BSD   era  strettamente  legata   ad  hardware  con
allineamento ai 2 byte...


 allineamento ai 2 byte...
Di nuovo: quindi? Si parlava di ping e traceroute. Il riferimento, se
utile, e` per quella parte di discorso.
A me rimane la sensazione.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sb20293A2058554E494Csnlbxq'|dc

> allineamento ai 2 byte...
M> Di nuovo: quindi? Si parlava di ping e traceroute. Il riferimento,
M> se utile, e` per quella parte di discorso.
Effettivamente. Ma  talk e` un  programma che ha un  posto particolare
nella  mia memoria  e quindi  trovarlo nella  faq ha  attirato  la mia
attenzione, e  devo dire  che purtroppo l'entry  mi ha un  po' deluso,
tutto qua.


 non erro era un Sys V R3.
Vabbe`, se cerchi sulla docu della DARPA... :)
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Lottery: a tax on people who are bad at math.

> writes:
M> A quel tempo, era troppo impegnato a biasimare "gli hacker" che gli
M> avevano copiato il basic (eh). Ma e` una storia _luuungaaa_ :)
BTW, riguardo la cosa hai visto le differenti espressioni che ha nelle
foto che appaiono in Revolution OS ? :)
M> Vabbe`, se cerchi sulla docu della DARPA... :)
Mi basterebbe riavere quella manpage paranoide! :) :) :)


 foto che appaiono in Revolution OS ? :)
Non ho ancora avuto occasione di vedere il film. E visto che non e`
esattamente "spoiler", non ne ho una gran fretta. Ho sentito cmq,
commenti diversi, in merito.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
There's going to be no serious problem after this.  --Ken Thompson