From owner-freebsd-net@FreeBSD.ORG Wed Sep 21 10:50:03 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 095EA16A41F for ; Wed, 21 Sep 2005 10:50:03 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 953C843D45 for ; Wed, 21 Sep 2005 10:50:02 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 176C846B86; Wed, 21 Sep 2005 06:50:02 -0400 (EDT) Date: Wed, 21 Sep 2005 11:50:01 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: =?ISO-8859-1?Q?Sten_Daniel_S=F8rsdal?= In-Reply-To: <43313924.9050009@wm-access.no> Message-ID: <20050921114511.D34322@fledge.watson.org> References: <20050918212110.61962.qmail@web54501.mail.yahoo.com> <20050920134408.Y34322@fledge.watson.org> <43313924.9050009@wm-access.no> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1679374524-1127299801=:34322" Cc: freebsd-net@freebsd.org, Milscvaer Subject: Re: UDP dont fragment bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2005 10:50:03 -0000 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--