Re: arp -s

Condor <condor@vcable.net> writes:
> Hello,

Probably your host has no interface with the same subnet as IP address 192.168.11.15. This is not a great error message, but you must have correctly understood that it's inviting you to try "pub", since that is what you tried next. At the least it would be good if the man page described this behavior. (It would be nice if arp were smart enough to not suggest this when it's not going to work, but probably not worth the extra code. This does have to fit on boot disks.)

	[ interesting feature: you can also say permanent.aol.com
		in place of permanent and get the identical behavior.
		Fascinating what you can learn by reading the code. ]

>
> # arp -s 192.168.11.15 00:60:97:92:58:1e pub
> arp: writing to routing socket: No buffer space available

Again, perhaps your host probably has no interface on the subnet belonging to 192.168.11.15. This is a really lousy error message. Perhaps EADDRNOTAVAIL or even better ENETUNREACH. There's some pretty hairy code in the kernel that does the guts (/usr/src/sys/net/rtsock.c and friends) - I'm not confident that I understand exactly which return results in this error let alone that changing it won't break something. In fact, I get a different error:

        cannot intuit interface index and type for 192.168.1.2 which is not a great error message either but certainly more accurate than no buffer space. It's possible that something else is happening for you; perhaps your arp didn't write enough data to the socket, due to kernel/userland skew or other oddness?

	[ Here the abbreviation feature allows you to say "pubescent"
		in place of "pub". ]

More generally, there is an interesting unobvious design change in 4.4bsd over previous versions, which is not obvious by the man page or the error message. I believe older arp implementations had a single system-wide arp cache and would allow you to associate any arbitrary IP address with any arbitrary ethernet address. The current code integrates IP routing with ARP routing - so "netstat -r -n" is actually showing you a superset of what "arp -a" shows you - and what "arp -a" shows you is actually a very incomplete picture of what's really happening. Apparently, however, arp entries are now associated with an interface, and cannot exist separately. If I understand what's happening here, by separating out the arp logic per-interface, it's also possible to advertise the same ethernet address on more than one interface with a different IP address -- which is useful but creates some interesting behavior with hardware like certain models of sun which has a notion of a "machine" ethernet address (for instance, if more than one interface belonging to the same machine is on the same wire.)

Note that you failed to post the results of a "netstat -i -n" with your results, which would have confirmed whether my theory of what you did is right. Possibly "dmesg" output would also have been appropriate, or at least the first 4 lines of that with the kernel build info. "netstat -r -n" would also have been good.

bugs@ is not a good place to start with problems like this. misc@ is actually the right place (I think) - there are more people, and they are likely to be less grumpy too. I believe you will find most people on bugs@ expect you to be at least capable of performing something like the above analysis yourself before sending in a bug report (so that you aren't, in effect, asking people to debug the user instead of the code) or better yet capable of trying small patches and experiments to result in improved behavior, and sending those in with the bug report.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related openbsd.org Links advocacy announce bugs ipv6 misc ports ports-changes security-announce smp source-changes tech Request more information about Pantek

                                        -Marcus Watts Received on Thu Dec 12 05:58:15 2002