From owner-freebsd-net@FreeBSD.ORG Thu Apr 19 11:38:49 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4AEB816A400 for ; Thu, 19 Apr 2007 11:38:49 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id 5C73413C46A for ; Thu, 19 Apr 2007 11:38:48 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l3JBcjOL092941; Thu, 19 Apr 2007 15:38:45 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l3JBchYa092935; Thu, 19 Apr 2007 15:38:43 +0400 (MSD) (envelope-from yar) Date: Thu, 19 Apr 2007 15:38:42 +0400 From: Yar Tikhiy To: Alan Garfield Message-ID: <20070419113842.GE60301@comp.chem.msu.su> References: <1176861009.4426.21.camel@hiro.auspc.com.au> <20070418120622.GF40826@comp.chem.msu.su> <1176947814.4175.39.camel@hiro.auspc.com.au> <20070419073525.GA60301@comp.chem.msu.su> <1176972863.4177.7.camel@hiro.auspc.com.au> <20070419093847.GC60301@comp.chem.msu.su> <1176976273.4177.17.camel@hiro.auspc.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1176976273.4177.17.camel@hiro.auspc.com.au> User-Agent: Mutt/1.5.9i Cc: freebsd-net@freebsd.org Subject: Re: rtentry and rtrequest 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: Thu, 19 Apr 2007 11:38:49 -0000 On Thu, Apr 19, 2007 at 07:51:13PM +1000, Alan Garfield wrote: [...] > > > > I beginning to think the ARP issue is a symptom not the cause. The cause > > > may well be something is wrong with my initialisation of the output > > > queue and my handling of the de-queueing packets. I've looked at many > > > if_* drivers sources and they all seem very similar to what I've already > > > done. > > > > Please try fixing the interface flags. > > > > Could you also show output from "ifconfig jnetX" and "netstat -rn" > > after the interface has been configured (i.e., had IP assigned)? > > ---- > [alan@twofish jnet_pci]$ ifconfig > bge0: flags=8843 mtu 1500 > options=1b > inet 192.168.1.42 netmask 0xffffff00 broadcast 192.168.1.255 > ether 00:09:3d:13:21:6a > media: Ethernet autoselect (1000baseTX ) > status: active > bge1: flags=8802 mtu 1500 > options=1b > ether 00:09:3d:13:21:6b > media: Ethernet autoselect (1000baseTX ) > status: active > lo0: flags=8049 mtu 16384 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff000000 > jnet0: flags=845 mtu 241 > inet 169.254.101.3 netmask 0xffff0000 > ether 00:09:3d:00:00:03 Note that jnet0 has no broadcast address. That should be wrong for an Ethernet interface. (Honestly, I'm still uncertain whether it is legal at all for an interface to have none of the following flags: BROADCAST, POINTOPOINT, LOOPBACK.) > ---- > [alan@twofish jnet_pci]$ netstat -rn > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif > Expire > default 192.168.1.1 UGS 0 192 bge0 > 127.0.0.1 127.0.0.1 UH 0 0 lo0 > 169.254 link#4 UC 0 0 jnet0 ^^^^^^^^^ This record is there. Good... Note the C (cloning) flag. Individual ARP records will be "cloned" from this one via the rtresolve mechanism. > 192.168.1 link#1 UC 0 0 bge0 > 192.168.1.1 00:17:95:ba:b8:a6 UHLW 2 0 bge0 > 37 > 192.168.1.8 00:04:76:3b:0a:57 UHLW 1 45 bge0 > 1199 > 192.168.1.99 00:15:58:2d:85:c7 UHLW 2 12188 bge0 > 1172 > > Internet6: > Destination Gateway Flags > Netif Expire > ::1 ::1 UHL > lo0 > fe80::%lo0/64 fe80::1%lo0 U > lo0 > fe80::1%lo0 link#3 UHL > lo0 > ff01:3::/32 fe80::1%lo0 UC > lo0 > ff02::%lo0/32 fe80::1%lo0 UC > lo0 > ---- > > > I think I've made a little break through! I've removed :- > > ---- > case SIOCSIFADDR: > ifp->if_flags |= IFF_UP; > ifa = (struct ifaddr *)data; > if (ifa != 0) > ifa->ifa_rtrequest = jnet_rtrequest; > break; > ---- > > .... and now it seems like I'm actually getting mbuf's and no more ARP > errors! > > ---- > jnet0: port 0xa8,0xae-0xaf irq 19 on > acpi0 > jnet0: Ethernet address: 00:09:3d:00:00:03 > jnet0: jnet_start_locked() called. > jnet0: m == 0. > jnet0: jnet_start_locked() called. > jnet0: mbuf len: 42. > jnet0: packets buffered, but tx idle. > jnet0: TX called > jnet0: m == 0. > jnet0: jnet_start_locked() called. > jnet0: packets buffered, but tx idle. > jnet0: TX called > jnet0: mbuf len: 42. > jnet0: packets buffered, but tx idle. > jnet0: TX called > jnet0: m == 0. > ---- > > So what did I do?!? Was my rtrequest function stuffing everything up, > all it did was set the rt MTU and return. In fact, you were overriding the normal ARP's arp_rtrequest() handler for the addresses. Grep /sys/netinet/if_ether.c for ifa_rtrequest. See also rtentry(9) (again, search for ifa_rtrequest). That's why nothing worked. > My tx just consumes the packets at the moment, I've not written the > buffer writing code yet. I'll do that now and see if packets move. :) > > > P.S. Was the name "jnet" inherited from the Linux driver? > > Yeah it's what the Linux driver is called. Can be something else, got a > better name? :) Perhaps just "jn"? Some utilities still have trouble with long interface names[1], and they are a drag to type in. :-) So I'd rather keep the name as short as possible. -- Yar