From owner-freebsd-net Tue Jun 1 16:52:19 1999 Delivered-To: freebsd-net@freebsd.org Received: from mullian.ee.mu.OZ.AU (mullian.ee.mu.OZ.AU [128.250.77.2]) by hub.freebsd.org (Postfix) with ESMTP id 30CBA14D20 for ; Tue, 1 Jun 1999 16:52:14 -0700 (PDT) (envelope-from m.summerfield@ee.mu.oz.au) Received: from m-summerfield.ee.mu.oz.au (m-summerfield.ee.mu.OZ.AU [128.250.79.188]) by mullian.ee.mu.OZ.AU (8.9.1a/8.9.1) with SMTP id JAA15035 for ; Wed, 2 Jun 1999 09:52:13 +1000 (EST) Message-Id: <199906012352.JAA15035@mullian.ee.mu.OZ.AU> X-Sender: summer@mullian.ee.mu.oz.au X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Wed, 02 Jun 1999 09:51:55 +1000 To: freebsd-net@freebsd.org From: Mark Summerfield Subject: Interface implementation and ARP under FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi freebsd-net'ers, I'm developing a driver for an experimental network interface. Currently my development system is running FreeBSD 2.2.7. The system has an Ethernet interface (xl0) and the experimental interface (exp0). I'm having real trouble getting address resolution going for my interface. I know that the BSD implementation of ARP is fairly "ethernet-centric", but I also know that it does work for networks that have ethernet-like addressing (e.g. FDDI). Incoming packets are OK -- I can e.g. construct an ICMP packet addressed to a host on the local ethernet, send it into the experimental interface, and, with ipforwarding enabled, "see" (with tcpdump on another host) it emerge from the Ethernet interface. This implies that the packet is correctly received on exp0, passed up the IP stack, and routed out of xl0 intact. Sending IP packets out of the experimental interface is another matter. If I configure exp0 with "inet 10.0.0.1 netmask 255.255.255.0" then "ping 10.0.0.2" my output code calls arpresolve(), and I expect my output function to be called again, by arprequest(), since the address is not yet resolved. Instead I get the message "arpresolve: can't allocate llinfo". I've looked at the source, and consulted the bible (Wright and Stevens), and I believe that what it's really telling me is that it can't infer the route (i.e. interface exp0) to 10.0.0.2, and hence can't work out which interface to send the ARP request on -- it's not an actual allocation failure, nor is it one of the conditions explicitly trapped and reported by arplookup(). I think I must have misconfigured something, either in my interface initialisation, or via "ifconfig". I *can* "ping 10.0.0.255" and generate broadcast echo-requests with a correct source address of 10.0.0.1 on the experimental interface (since arpresolve() automatically resolves packets with the M_BCAST flag set to the ethernet broadcast address). The (duplex) experimental interface then receives an echo-request and passes it up -- and the attempt to generate a (unicast) echo-reply then results in the error above. The relevant output of "netstat -r -n", "ifconfig xl0" and "ifconfig exp0" is (note that tcpdump is running, so the PROMISC flag on xl0 is set): Routing tables Internet: Destination Gateway Flags Refs Use Netif default 128.250.79.129 UGSc 2 0 xl0 10/24 10.0.0.1 Uc 0 0 exp0 127.0.0.1 127.0.0.1 UH 0 0 lo0 128.250.79.128/25 link#3 UC 0 0 xl0: flags=8943 mtu 1500 inet 128.250.79.184 netmask 0xffffff80 broadcast 128.250.79.255 ether 00:60:97:8a:37:b9 exp0: flags=3 mtu 9180 inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255 lladdr 00:60:97:8a:37:b9 Note that my link-level addresses are Ethernet compatible (this was done specifically to try to get ARP to work with a minimum of fuss). I have, in fact, just used the address of the Ethernet interface on each host, since the choice is essentially arbitrary and this makes identifying the source of packets easy. The difference is that ifconfig reports the Ethernet address as "ether" (since it's of type IFT_ETHER), and the experimental LL address as "lladdr", since it's type IFT_OTHER. Any hints as to what it is I'm doing wrong would be greatly appreciated. Thanks, Mark ---- Dr. Mark Summerfield Australian Photonics Cooperative Research Centre Photonics Research Laboratory Dept. of Electrical and Electronic Engineering The University of Melbourne Parkville, 3052 AUSTRALIA Phone: +61 3 9344 7419 Fax: +61 3 9344 6678 Email: m.summerfield@ieee.org WWW: http://www.ee.mu.oz.au/staff/summer/index.htm To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message