[lkml]   [2001]   [Jul]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRaw sockets and zero-source IP packets
    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

    * 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

    * 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.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:57    [W:0.020 / U:14.432 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site