Date: Thu, 19 Apr 2007 19:51:13 +1000 From: Alan Garfield <alan@fromorbit.com> To: Yar Tikhiy <yar@comp.chem.msu.su> Cc: freebsd-net@freebsd.org Subject: Re: rtentry and rtrequest Message-ID: <1176976273.4177.17.camel@hiro.auspc.com.au> In-Reply-To: <20070419093847.GC60301@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2007-04-19 at 13:38 +0400, Yar Tikhiy wrote:
>
> > ----
> > // Configure the structure for the device
> > ifp->if_softc = sc;
> > if_initname(ifp, device_get_name(dev), device_get_unit(dev));
> >
> > // Function pointers
> > ifp->if_start = jnet_start;
> > ifp->if_ioctl = jnet_ioctl;
> > ifp->if_watchdog = jnet_watchdog;
> > ifp->if_init = jnet_init;
> >
> > // Interface specifics
> > ifp->if_flags = IFF_SIMPLEX;
>
>
> Try setting those flags to
> IFF_SIMPLEX | IFF_BROADCAST | IFF_MULTICAST
>
> I have no direct evidence, but ARP may have trouble operating on
> an interface w/o IFF_BROADCAST, as it utilizes broadcasts. Essentially,
> IFF_BROADCAST just means that the interface has a broadcast address,
> but there may be some indirect consequences via the routing table.
Will do. I only removed them in the hope of finding what was wrong. I'll
put them back.
> Anyway, an Ethernet interface ought to have IFF_BROADCAST set on
> it because it's a broadcast interface.
>
> > IFQ_SET_MAXLEN(&ifp->if_snd, IFQ_MAXLEN);
> > ifp->if_snd.ifq_drv_maxlen = IFQ_MAXLEN;
> > IFQ_SET_READY(&ifp->if_snd);
> > ifp->if_timer = MAX_TIMEOUT;
> >
> > // Set our fake MAC address
> > bcopy(localMac, sc->enaddr, 6);
>
> Just a style note: the 6 should be ETHER_ADDR_LEN. We prefer
> ETHER_ADDR_LEN to sizeof(...) because sizeof returns size_t, while
> an int is sometimes needed. (int and size_t have different width
> on 64-bit architectures.) ETHER_ADDR_LEN expands to the constant
> 6, which gets the correct type provided that the function has been
> prototyped.
Yep no problem. Easily fixed. I'm actually going through and fixing my
style while I compute this problem in my head. :)
> > 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=1b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING>
inet 192.168.1.42 netmask 0xffffff00 broadcast 192.168.1.255
ether 00:09:3d:13:21:6a
media: Ethernet autoselect (1000baseTX <full-duplex>)
status: active
bge1: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
options=1b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING>
ether 00:09:3d:13:21:6b
media: Ethernet autoselect (1000baseTX <full-duplex>)
status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
inet6 ::1 prefixlen 128
inet 127.0.0.1 netmask 0xff000000
jnet0: flags=845<UP,DEBUG,RUNNING,SIMPLEX> mtu 241
inet 169.254.101.3 netmask 0xffff0000
ether 00:09:3d:00:00:03
----
[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
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: <JNet Ethernet System Interface> 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.
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? :)
-A.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1176976273.4177.17.camel>