Date: Wed, 21 Sep 2005 11:50:01 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: =?ISO-8859-1?Q?Sten_Daniel_S=F8rsdal?= <lists@wm-access.no> Cc: freebsd-net@freebsd.org, Milscvaer <millueradfa@yahoo.com> Subject: Re: UDP dont fragment bit Message-ID: <20050921114511.D34322@fledge.watson.org> In-Reply-To: <43313924.9050009@wm-access.no> References: <20050918212110.61962.qmail@web54501.mail.yahoo.com> <20050920134408.Y34322@fledge.watson.org> <43313924.9050009@wm-access.no>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1679374524-1127299801=:34322 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 21 Sep 2005, Sten Daniel S=F8rsdal wrote: >> For whatever reason, it turns out that you and only you have requested= =20 >> this feature. For typicaly network debugging applications, a raw=20 >> socket is used, which allows the direct frobbing the the IP DF bit.=20 >> For example, in traceroute(8). >> >> Could you tell us a bit more about the application and proposed use?=20 >> Presumably forcing the DF bit isn't much use unless you can also=20 >> retrieve useful reporting on the ICMP errors associated with needing=20 >> the fragment? > > I have been looking for such a feature too. My Application; Bandwidth=20 > tester (also as a support app for an UDP file transfer utility) The=20 > reason i want DF bit removed? I want to be able to generate my own=20 > fragments or let the routers generate the fragments. I also want to be=20 > able to receive bad UDP packets to gather statistics. This would be=20 > userland applications. By default, we don't generate UDP with the IP DF bit set. If you want to= =20 receive the detailed ICMP responses, you currently need to to use a raw=20 socket, which is what most network exploration tools (such as traceroute)= =20 do. If we want to be able to manage more detailed state information using= =20 unprivileged UDP sockets, then we need to have more complex state=20 management on UDP sockets when ICMPs are received. Hence my asking for=20 requirements: what is it that is really being looked for here? Just being= =20 able to set the DF bit isn't very much use for a casual application, as=20 there's no real reporting of the resulting ICMP MTU messages to UDP=20 sockets. So presumably, what's being looked for is more than just a=20 socket option to say "Set or don't set the DF bit", but a way to query=20 recent ICMP received state on the socket. So if someone could generate some application pseudo-code that suggests=20 what specifically is necessary from the socket layer in order for the=20 application to function, we can talk about socket service extensions that= =20 might support the application. For example, a way to query detailed error= =20 information rather than just the SO_ERROR socket option. Or a longer haul= =20 PMTU data gathering mechanism for UDP sockets. Or ways for UDP=20 applications to more usefully query the kernel for the TCP PMTU data=20 already being recorded. It sounds like for the bandwidth tester, IP raw sockets already provide=20 what you need, since you want to be able to do fairly irregular UDP things= =20 (i.e., receive UDP packets with bad checksums, and see fragments). Robert N M Watson --0-1679374524-1127299801=:34322--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050921114511.D34322>