UDP dont fragment bit

[Andre Oppermann]

Robert Watson wrote:
> 
> 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.

I can think of a couple of uses to say IP DF on a UDP socket.  Will cook
up a patch to add such a sysctl in a few hours.

-- 
Andre


> 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
> 
>   --------------------------------------------------------------------------------
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"