on 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 <[EMAIL PROTECTED]>
on 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 <[EMAIL PROTECTED]>
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 it
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.
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
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 co
Chase Venters wrote:
As an aside to this whole thing, I know we're talking about *kernel* wireless
but it's worthless to most people without good userland support as well.
Anyone have any thoughts and feelings on what things look like on the
desktop? I think if we work closely with some deskto
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
http://www.hpl.hp.com/personal/Jean_Tou
