[ moved from current-users ]

On Mon, 16 Mar 1998, Geir Inge Jensen wrote:

> >> How is IPPROTO_RAW supposed to work? I thought that I could send raw ip
> >> packets unchanged to the network. [ ... ]
> >
> >   int state = 1;
> >   setsockopt(sockfd, 0, IP_HDRINCL, &state, sizeof(state))
> 
> Thanks, both to you and the other who responded to me. It works, but
> not as expected. I thought I could feed the socket with a raw IP
> header, but that is not the case. If you, for instance, use network
> byte order on the ip-length field, NetBSD will return with EINVAL
> because the length of the packet does not match the length-field I fed
> the socket with. If I use native byte order on the field, everything
> goes well. But then I thought, this should not work at all, because now
> my ip-checksum field would be wrong. However, after examining the code,
> it seems that NetBSD changes the byte order of the relevant fields, and
> computes its own checksum of the packet before it is sent. That is not
> my perception of a _raw_ packet. Maybe this is how it is supposed to
> work :)

Addressing your first point [network vs. host ordering], the kernel does
indeed need the header to be provided in host byte order.  The conversion
from host to network order occurs at the very end of IP output processing,
of which, IPPROTO_RAW processing is before.  That's the way life is.

> I have yet another problem. How am I supposed to read raw tcp packets
> through a socket? I tried with 
> 
>   socket(AF_INET, SOCK_RAW, IPPROTO_ICMP)
> 
> and I got all ICMP packets delivered to my address. However, with
> IPPROTO_TCP, my code does not receive anything. I thought it
> would receive all IP packets with the protocol set to tcp. Is this
> possible to achieve?

I'm begining to see that your needs are straining the capacity of
SOCK_RAW sockets.  If you want to really generate and receive raw packets,
you should consider using BPF.  SOCK_RAW isn't completely intuitive, and
wasn't made for this kind of behavior.

-J