UDP dont fragment bit
Robert Watson
rwatson at FreeBSD.org
Wed Sep 21 03:50:03 PDT 2005
On Wed, 21 Sep 2005, Sten Daniel Sørsdal wrote:
>> For whatever reason, it turns out that you and only you have requested
>> this feature. For typicaly network debugging applications, a raw
>> socket is used, which allows the direct frobbing the the IP DF bit.
>> For example, in traceroute(8).
>>
>> Could you tell us a bit more about the application and proposed use?
>> Presumably forcing the DF bit isn't much use unless you can also
>> retrieve useful reporting on the ICMP errors associated with needing
>> the fragment?
>
> I have been looking for such a feature too. My Application; Bandwidth
> tester (also as a support app for an UDP file transfer utility) The
> reason i want DF bit removed? I want to be able to generate my own
> fragments or let the routers generate the fragments. I also want to be
> able to receive bad UDP packets to gather statistics. This would be
> userland applications.
By default, we don't generate UDP with the IP DF bit set. If you want to
receive the detailed ICMP responses, you currently need to to use a raw
socket, which is what most network exploration tools (such as traceroute)
do. If we want to be able to manage more detailed state information using
unprivileged UDP sockets, then we need to have more complex state
management on UDP sockets when ICMPs are received. Hence my asking for
requirements: what is it that is really being looked for here? Just being
able to set the DF bit isn't very much use for a casual application, as
there's no real reporting of the resulting ICMP MTU messages to UDP
sockets. So presumably, what's being looked for is more than just a
socket option to say "Set or don't set the DF bit", but a way to query
recent ICMP received state on the socket.
So if someone could generate some application pseudo-code that suggests
what specifically is necessary from the socket layer in order for the
application to function, we can talk about socket service extensions that
might support the application. For example, a way to query detailed error
information rather than just the SO_ERROR socket option. Or a longer haul
PMTU data gathering mechanism for UDP sockets. Or ways for UDP
applications to more usefully query the kernel for the TCP PMTU data
already being recorded.
It sounds like for the bandwidth tester, IP raw sockets already provide
what you need, since you want to be able to do fairly irregular UDP things
(i.e., receive UDP packets with bad checksums, and see fragments).
Robert N M Watson
More information about the freebsd-net
mailing list