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

Reply via email to