Re: UDP sockets and IPv4 header fields

Rick Jones wrote:

> Spoon wrote:
>
>> Rick Jones wrote:
>>
>>> Spoon wrote:
>>>
>>>> My OS is Linux 2.6.
>>>
>>> That leaves a great deal of ambiguity :)
>>
>> I've been experimenting with the latest 2.6.20 kernel.
>> 2.6.0 behaves the same way. Why do you say ambiguity?
>
> Because the Linux 2.6 kernel, while perhaps maintaining this
> particular behavior, is not "static" wrt all of its behaviour. It
> continues to evolve.

Point taken. However, since I have the source, I may be able to keep the
behavior I want, even if it is changed in later kernels :-)

>>> It is also not a behaviour you can count on to be present in other
>>> stacks.
>>
>> I can always write my own IP header.
>
> Which may need to have a different IP address than the host stack, so
> you may have to run your very own little UDP/IP stack and run it
> either over an interface in promiscuous mode, or an interface of its
> very own where you can bind the IP and ARP SAPs directly.

I don't understand this statement.

>>> Today. Given the behaviour is not required, or even suggested, by
>>> the RFC's governing IP, there is a certain element of risk counting
>>> on it to continue to behave that way in the future. And you
>>> definitely cannot count on it to behave that way on other
>>> platforms. Caveat programmor as it were.
>>
>> Thanks for pointing that out. As I've stated above, I can always write
>> my own IP header.
>
> I thought you had a legacy side with which you had to communicate?

The receiver may be either a legacy system which does not expect any
extra information, or a new system which needs the extra information for
diagnostics.

If the sender provides the extra information in the IP header (e.g. in
the ID field, or within IP options) then the legacy system is happy (its
IP stack ignores the information) and the new system is happy (it can
find the extra information with a little more work).

I think I can add an IP_RECVID socket option. New systems would then be
able to call getsockopt(IP_RECVID, ...) to retrieve the ID field of the
last datagram. What do you think?

Regards.

Spoon wrote:

> I think I can add an IP_RECVID socket option. New systems would then be
> able to call getsockopt(IP_RECVID, ...) to retrieve the ID field of the
> last datagram. What do you think?

I think I meant an ioctl call (e.g. SIOCGSTAMP).

>> Which may need to have a different IP address than the host stack,
>> so you may have to run your very own little UDP/IP stack and run it
>> either over an interface in promiscuous mode, or an interface of
>> its very own where you can bind the IP and ARP SAPs directly.

> I don't understand this statement.

When traffic arrives at the host, if it is for an IP address known to
the "real" stack then likely as not it will be consumed by the "real"
stack rather than arrive at your (raw?) socket.

> I think I can add an IP_RECVID socket option. New systems would then
> be able to call getsockopt(IP_RECVID, ...) to retrieve the ID field
> of the last datagram. What do you think?

With source, almost anything is possible.

rick jones
--
oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...