jamesp@wacsvax.uwa.oz (James Pinakis) (06/07/90)
I'm trying to write programs which communicate via IP datagrams using the raw socket interface in SunOS 4.0.3. I was initially somewhat confused by the difference between sending a receiving a datagram i.e. when I do a 'sendto' on the raw socket I provide it with the data part of the datagram but when I do a 'recvfrom' I am provided the whole datagram including the header. Upon close inspection of the ip(4p) man page I found this to be as it should. Now I find that in received datagrams, the TOTAL LENGTH field contains only the length of the data part and does not include the length of the header as specified in the RFC. Also, it appears the HEADER CHECKSUM contains zero. Obviously the IP layer is changing these fields, but this isn't mentioned in the manual entry (which in fact says "Received datagrams are returned with the IP header and options intact"). Is this normal behaviour or am I experiencing something peculiar? Are there any other pitfalls to be wary of when using raw sockets? There seems to be a dearth of documentation in this area. james jamesp@bison.cs.uwa.oz.au
akhale@chamomile.uucp (Abhijit Khale) (06/08/90)
In article <jamesp.644735317@bison> jamesp@wacsvax.uwa.oz (James Pinakis) writes: >I'm trying to write programs which communicate via IP datagrams using the >raw socket interface in SunOS 4.0.3. . >Now I find that in received datagrams, the TOTAL LENGTH field contains only >the length of the data part and does not include the length of the header >as specified in the RFC. Yes. What happens is : the ipintr() [IP input] routines subtract the header length from the total length field before switching the packet up to the higher layer protocol (normally tcp or udp). In the case of a raw socket it just gets handed to the raw socket processing routines which eventually pass it up to the user process. > Also, it appears the HEADER CHECKSUM contains >zero. In 4.0.3, thats what will happen. In 4.1, you should get the correct header checksum provided the packet hasnt been fragmented and reassembled. Obviously the IP layer is changing these fields, but this isn't >mentioned in the manual entry (which in fact says "Received datagrams are >returned with the IP header and options intact"). Is this normal behaviour or >am I experiencing something peculiar? This is "normal". However, there seems to be no reason why the total length field should be changed for a raw IP socket. That should probably be regarded as a bug. Its less clear whether the checksum should be passed up as is [ There doesnt seem to be any reason why the checksum should be recomputed for a fragmented/reassembled packet]. Now if you really want raw packets, use NIT :-) Abhijit Khale akhale@parc.xerox.com akhale@jerico.usc.edu Computer Science Lab, Xerox PARC University of Southern California