home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / os / linux / 16794 < prev    next >
Encoding:
Internet Message Format  |  1992-11-15  |  2.9 KB
  1. Path: sparky!uunet!walter!qualcom.qualcomm.com!network.ucsd.edu!swrinde!emory!wupost!darwin.sura.net!paladin.american.edu!news.univie.ac.at!alijku11!k111114
  2. Organization: Johannes Kepler University Linz - Computing Center
  3. Date: Monday, 16 Nov 1992 02:51:09 CET
  4. From: <K111114@ALIJKU11.BITNET>
  5. Message-ID: <92321.025109K111114@ALIJKU11.BITNET>
  6. Newsgroups: comp.os.linux
  7. Subject: ICMP packages lost
  8. Lines: 54
  9.  
  10. Hi all.
  11. I tried to port ping.c from a BSD-System. After doing some adaptive work,
  12. (#if 0'ed all fields concerning time-measurement, etc.), the program seemed
  13. to run, BUT ... I never get an ICMP-Echoreply for a sent ICMP-Message.
  14. I have looked at the hexdump of the outgoing package, and it seems perfectly
  15. right:
  16.  
  17.    8    0    E5   C7   5C   0   1   0
  18.    !    !    !    !    !    !   !   !
  19.    !    !    !    !    !    !   +---+----> Sequence Number
  20.    !    !    !    !    !    !
  21.    !    !    !    !    +----+------------> Identifier (e.g., PID)
  22.    !    !    !    !
  23.    !    !    +----+----------------------> Checksum
  24.    !    !
  25.    !    +--------------------------------> Code (has to be 0)
  26.    !
  27.    +-------------------------------------> Type
  28.  
  29.   (of course this values change for every icmp-msg sent, and for every new
  30.   ping process started: fields seq-number/identifier/checksum)
  31.  
  32.   "Type" can contain many values, for "ping" only 2 are interesting:
  33.   a) type=0 -> Echo Reply
  34.   b) type=8 -> Echo Request.
  35.  
  36.   Therefore, a machine sends out an Echo-request, and the target machine
  37.   sends back an Echo-reply.
  38.  
  39.   My problem was, that this didn't happen, I got 100 % packet loss from
  40.   both devices: a) loopback and b) eth0.
  41.  
  42.   Doing kernel-debugging, I noticed that allthough dev_rint (net/tcp/dev.c)
  43.   was called, an incoming ICMP-packet NEVER was generated. (I have added some
  44.   printk's in net/tcp/icmp.c). As far as I can say, the problem is with the
  45.   packet-type-functions, I noticed that in dev_rint, a function called
  46.   ptype->func(skb2, dev, ptype) is called. The only place where this pointer
  47.   is initialized is in net/tcp/packet.c, saying "p->func = packet_rcv". This
  48.   again is done in a routine called packet_init. Again, I have added printks to
  49.   packet.c (to packet_sendto, rvc, close, init, etc...), and I was very
  50.   surprised that none of this function are called... strange...
  51.  
  52.   On the other hand, doing a ping TO the machine from outside generated the
  53.   right response, i.e. sending a ping to Linux from our SunSparc generated
  54.   an echo-reply, and the SunSparc wrote "xxx is alive".
  55.  
  56.   When reading through the source, I couldn't find the call to packet_init.
  57.   When is it done ? Is ICMP not yet implemented ? "getprotobyname" did give
  58.   me something like it is not implemented ... but there are the sources in
  59.   net/tcp .. !? Is there a pointer to a function that points to another
  60.   devicepointerfunctionentry not set ? Why is it possible to send ICMPs TO
  61.   but not FROM the machine ?
  62.  
  63. Herp, getting confused.
  64.