Re: rtentry and rtrequest

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

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

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
_______________________________________________
freebsd-net@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: rtentry and rtrequest
    ... an interface w/o IFF_BROADCAST, as it utilizes broadcasts. ... IFF_BROADCAST just means that the interface has a broadcast address, ... jnet0: jnet_start_lockedcalled. ...
    (freebsd-net)
  • Re: rtentry and rtrequest
    ... jnet0: jnet_start_lockedcalled. ... arplookup 169.254.101.2 failed: could not allocate llinfo ... an interface w/o IFF_BROADCAST, as it utilizes broadcasts. ... IFF_BROADCAST just means that the interface has a broadcast address, ...
    (freebsd-net)