site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com I had a look at /usr/include/netinit.h for the definition of struct ip, Matt, an interesting test would be to do, newip->ip_hl = 4; /* IP version 4 */ newip->ip_v = 5; /* header length of 5 */ ie. just reverse them. Can anybody spread any light on this? Thanks aid _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... On 18 Sep 2004, at 06:55, Matt Jaffa wrote: despite the fact that some of the other stuff might be wrong, why wouldn't the ip_v be the right version? The output does print out 4 like it should be. struct ip { #ifdef _IP_VHL u_char ip_vhl; /* version << 4 | header length

...

2 */

#else #if BYTE_ORDER == LITTLE_ENDIAN u_int ip_hl:4, /* header length */ ip_v:4; /* version */ #endif #if BYTE_ORDER == BIG_ENDIAN u_int ip_v:4, /* version */ ip_hl:4; /* header length */ #endif I am confused now, as I thought that ENDIANness was the ordering of bytes. I that were the case then there would be no need to change round the nibbles depending upon the ENDIANness of the local machine. I realise that bits can be stored either most significant bit first or least significant bit first. However if the bits in the bytes were flipped when accessing a normal byte (ie. a char) then one could read 97 (1100001) when 67 (1000011) was transmitted - which is obviously not the case. I presume the NIC is swapping the bits in the bytes before the byte hits the CPU / RAM. It feels to me like the above is compensating for something that has already been compensated. This email sent to site_archiver@lists.apple.com