rtentry and rtrequest

[Alan Garfield]

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 at 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 at 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.