From owner-freebsd-current Tue Dec 24 14:17: 1 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D77A37B401 for ; Tue, 24 Dec 2002 14:16:59 -0800 (PST) Received: from nebula.wanadoo.fr (ca-sqy-1-181.abo.wanadoo.fr [80.8.54.181]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8EBE343E4A for ; Tue, 24 Dec 2002 14:16:57 -0800 (PST) (envelope-from dak@wanadoo.fr) Received: from nebula.wanadoo.fr (localhost [127.0.0.1]) by nebula.wanadoo.fr (8.12.6/8.12.6) with ESMTP id gBOMHacC073579 for ; Tue, 24 Dec 2002 23:17:36 +0100 (CET) (envelope-from dak@nebula.wanadoo.fr) Received: (from dak@localhost) by nebula.wanadoo.fr (8.12.6/8.12.6/Submit) id gBOMHZQg073548 for current@freebsd.org; Tue, 24 Dec 2002 23:17:35 +0100 (CET) Date: Tue, 24 Dec 2002 23:17:34 +0100 From: Aurelien Nephtali To: current@freebsd.org Subject: Re: [PATCH] Wrong behaviour of writes of IP packets through BPF fd Message-ID: <20021224221734.GA69934@nebula.wanadoo.fr> References: <20021224205819.GA2042@nebula.wanadoo.fr> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="C7zPtVaVf+AK4Oqc" Content-Disposition: inline In-Reply-To: <20021224205819.GA2042@nebula.wanadoo.fr> User-Agent: Mutt/1.5.1i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --C7zPtVaVf+AK4Oqc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 24, 2002 at 09:58:19PM +0100, Aurelien Nephtali wrote: > Hi, >=20 > I think I've found a bug in the BPF stack (if I can call it a stack :p). > According to the bpf man, packets can be written directly through a bpf f= ile > descriptor. But writing IP packets using write() doesn't seem to work, the > "ip_len" field of the ip header isn't sent in host byte order so the pack= et is > discarded by the remote host since the len of the packet doesn't match the > length of the data captured... > BSD is known to have a strange behaviour with the "ip_len" field, returni= ng > EINVAL when this field is htons()'ized and passed to functions like write= (), > send(), etc... and of course, writing of a BPF fd using write() doesn't > break this "rule". :/ >=20 > But, strangely, as writing with write() doesn't work, writing with writev= () > seems to work (?!). That's why "dhclient" works fine _EVEN_ if it htons() > "ip_len" field of his IP packets! >=20 > Attached are two patches, one against bpf.c (kernel) and the other against > packet.c (dhclient). > These patches are ugly and you can (at least you are encouraged to :p) mo= dify > them or tell me what is good or not with them. They're only here to try to > illustrate what I'm trying to explain :) >=20 > For the BPF patch, I don't know if the test > if (dst.sa_family =3D=3D AF_UNSPEC) > is correct ... but it seems to work and I wonder why sa_family isn't AF_I= NET... >=20 > BTW, -STABLE/-RELEASE is also *affected* and I think the patch for bpf.c = can > also be applied against -STABLE, I've checked, bpf.c from -STABLE and the= one > from -CURRENT are the same. >=20 > Hope I was clear even if my english isn't as good as it should be :) > I plan to put this into a PR but I want some comments to be sure that's n= ot > a "desired" feature. >=20 > -- Aurelien Hum ... the previous patch against bpf.c was the result of multiple test, t= hus it was _VERY_ ugly with useless lines of code... now the new one is cleaner= :) (it's just aesthetic modifications but ... better for the eyes :p) -- Aurelien --C7zPtVaVf+AK4Oqc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+CNz+DNsbHbt8ok8RAiuaAJ9n0IwPZxw3shTAGi1GH8fQVSJybwCgnZ17 qnJ+OXJt3KEmQ0mr2YLZFZc= =/GWP -----END PGP SIGNATURE----- --C7zPtVaVf+AK4Oqc-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message