Raw sockets and zero-source IP packets

[David Byers <davby@ida.liu.se>]

I apologise if this is something that has already been discussed. I
haven't been keeping track of linux-kernel for very long.

For testing purposes I need to be able to send IP packets with the
source address set to zero (at the moment for testing ICMP address
mask request/reply, but I've seen that others who want to test DHCP
and BOOTP implementations also think they need this).

Since I do not want to deal with the link layer, I would prefer to use
raw IP sockets with IP_HDRINCL. As far as I can tell all such pakets
get sent through raw_getrawfrag in net/ipv4/raw.c. This function will
always overwrite a zero source address. Short of using packet sockets
I can't see a way around this feature (unless using the control
message to set the source address would work -- I haven't tried that
in combination with IP_HDRINCL).

The questions then:

* Is there a reason for never allowing source address zero on outgoing
  IP packets? I appreciate that it is convenient not to have to set
  the source address, but I fail to see why it should be impossible to
  set it to zero if you really, really want to.

* Is there a reason for never allowing packet ID zero on outgoing IP
  packets? 

* Is there a reason for not allowing the user to specify the total
  length and checksum of IP packets? Again, I appreciate the
  convenience of this feature, but sometimes it is convenient to be
  able to construct invalid packets (again, for testing purposes)
  without having to deal with link layer details.


It seems to be fairly straightforward to add a socket option (I added
one just to make sure) that would allow the user to specify which of
the source address, total length, packet ID and checksum are not to be
touched on raw sockets, regardless of their values. 

* Can invalid values in these fields cause problems elsewhere in the
  kernel?

* If not, would a patch adding a socket option to specify fields not
  to touch stand any chance whatsoever of being included in the kernel
  (provided it's well written, doesn't break other things etc.)? 

-- 
David Byers.