Re: dlil_inject_if_input
Re: dlil_inject_if_input
- Subject: Re: dlil_inject_if_input
- From: Adrian Bool <email@hidden>
- Date: Sun, 19 Sep 2004 01:05:47 +0200
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.
I had a look at /usr/include/netinit.h for the definition of struct ip,
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.
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden