, and non-ATM ARP manipulation via
netlink is rescued. A more complete solution would involve a rtattr for
ATM ARP entries and some way for the netlink code to give neigh_add
and friends more information than just address family with which to find
the correct ARP table.
Signed-off-by: Simon Kelley
, and non-ATM ARP manipulation via
netlink is rescued. A more complete solution would involve a rtattr for
ATM ARP entries and some way for the netlink code to give neigh_add
and friends more information than just address family with which to find
the correct ARP table.
Signed-off-by: Simon Kelley
Both net/ipv4/arp.c and net/arm/clip.c create neighbour tables with
family == AF_INET. For most purposes this is fine, since the two modules
each hold a pointer to their table and pass it into the neigh_* functions.
A problem arises in neigh_add, which is called by the rtnetlink code and
which
Two machines, many configuration differences, I need to find which one
is causing this difference in behaviour:
Machine 1: (eth1 is on the correct 192.168.3.x network)
# ip neighbour add to 192.168.2.15 lladdr 00:0F:20:98:F8:86 nud \
reachable dev eth1
# cat /proc/net/arp
IP address
It looks like netlink_recvmsg() has recvfrom return sematics - when
userspace buffer is too small the return value is the number of octets
actually copied, not the number which _would_ be copied, if there was
enough space.
This makes using MSG_PEEK to ensure that the buffer is large enough buggy.
Olivier Blin wrote:
The main problems we got in the past year is the lack of a standard
and reliable signal level report, but it will probably get solved when
all drivers are unified to use the same wireless stack.
That may be rather over-optimistic: the Atmel hardware dosen't even
produce
David S. Miller wrote:
Known problem, fixed by Yoshifuji in current GIT. /proc/net/if_net6's
output format got mistakedly changed, and this confused named and
ifconfig, among other things.
For reference, add dnsmasq to the list of confused userspace: the
signature error is:
failed to find
Phil Dibowitz wrote:
Thanks for stepping up John.
I'm really new to the netdev area, but I thought I'd throw this out as
I've been watching this thread with interest...
The GPL Realtek driver Andrea Merello:
http://rtl8180-sa2400.sourceforge.net/
and
