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