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