Re: bcm43xx-d80211 broadcast reception with WPA
Hi, I've been backporting the bcm43xx-d80211 driver to whatever the released 2.6 kernel was using the rt2x00 project's d80211 stack (equivalent to current wireless-dev but with a workaround for not having a ieee80211_dev pointer and still using the _tfm interface instead of the _cypher interface.) Just a note about that stack, it should only be used on kernel 2.6.17 and higher. Previous kernels had a bug that caused the stack to crash. The _tfm cipher interface will soon change, since I haven't had time to update the stack to the latest version yet, I'll do that this weekend. Ivo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] dccp: remove module exit functions
The dccp ipv4 ipv6 modules cannot be unloaded, as their control sockets
each maintain a couple of module references. So, it seems like a good
idea to just remove the module exit functions completely.
Please review.
Signed-off-by: James Morris [EMAIL PROTECTED]
---
net/dccp/ipv4.c |8
net/dccp/ipv6.c |8
2 files changed, 16 deletions(-)
diff -purN -X dontdiff linux-2.6.o/net/dccp/ipv4.c linux-2.6.w/net/dccp/ipv4.c
--- linux-2.6.o/net/dccp/ipv4.c 2006-10-27 01:52:53.0 -0400
+++ linux-2.6.w/net/dccp/ipv4.c 2006-11-10 03:10:34.0 -0500
@@ -1135,15 +1135,7 @@ out_proto_unregister:
goto out;
}
-static void __exit dccp_v4_exit(void)
-{
- inet_unregister_protosw(dccp_v4_protosw);
- inet_del_protocol(dccp_v4_protocol, IPPROTO_DCCP);
- proto_unregister(dccp_v4_prot);
-}
-
module_init(dccp_v4_init);
-module_exit(dccp_v4_exit);
/*
* __stringify doesn't likes enums, so use SOCK_DCCP (6) and IPPROTO_DCCP (33)
diff -purN -X dontdiff linux-2.6.o/net/dccp/ipv6.c linux-2.6.w/net/dccp/ipv6.c
--- linux-2.6.o/net/dccp/ipv6.c 2006-10-27 01:52:53.0 -0400
+++ linux-2.6.w/net/dccp/ipv6.c 2006-11-10 03:10:42.0 -0500
@@ -1276,15 +1276,7 @@ out_unregister_proto:
goto out;
}
-static void __exit dccp_v6_exit(void)
-{
- inet6_del_protocol(dccp_v6_protocol, IPPROTO_DCCP);
- inet6_unregister_protosw(dccp_v6_protosw);
- proto_unregister(dccp_v6_prot);
-}
-
module_init(dccp_v6_init);
-module_exit(dccp_v6_exit);
/*
* __stringify doesn't likes enums, so use SOCK_DCCP (6) and IPPROTO_DCCP (33)
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 7483] New: Unable to handle kernel paging request for data at address 0x5a5a5a5a5a5a5a5a
(switching to email - please follow up via reply-to-all and not via bugzilla)
On Fri, 10 Nov 2006 00:48:31 -0800
[EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=7483
Summary: Unable to handle kernel paging request for data at
address 0x5a5a5a5a5a5a5a5a
Kernel Version: 2.6.19-rc5
Status: NEW
Severity: normal
Owner: [EMAIL PROTECTED]
This could be a networking bug.
Submitter: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED],[EMAIL PROTECTED]
Most recent kernel where this bug did not occur: 2.6.19-rc5
You misunderstand. We're asking what is the most recent version of the
kernel which *did not* have this bug.
Distribution: SLES10 GA
Hardware Environment: IBM p-series server (POWER5+)
Software Environment: SLES10 GA + 2.6.19-rc5
Problem Description:
I mount a local samba directory and run fsstress in it. Several minutes
later,
the machine is no response and entered xmon(a debug mode in Power arch).
Dmesg as following:
CIFS VFS: close with pending writes
CIFS VFS: No task to wake, unknown frame rcvd! NumMids 8
Received Data is: : dump of 37 bytes of data at 0xc0003a6d9300
003a ff534d42 3200 008041c0 . . . : _ S M B 2 . . . . . A _
0100cf08 . . . . . . . . . . . . . . _ .
6400422f 0a02 d . B / .
CIFS VFS: No task to wake, unknown frame rcvd! NumMids
..
CIFS VFS: close with pending writes.
..
Unable to handle kernel paging request for data at address 0x5a5a5a5a5a5a5a5a.
Faulting instruction address: 0xc00a2e04..
xmon output:
5:mon e
cpu 0x5: Vector: 300 (Data Access) at [c75b7470]
pc: c00a2e04: .put_page+0x2c/0x16c
lr: c042f238: .skb_release_data+0x84/0xe4
sp: c75b76f0
msr: 80009032
dar: 5a5a5a5a5a5a5a5a
dsisr: 4000
current = 0xc3000ad0
paca= 0xc062ce00
pid = 4419, comm = syslog-ng
5:mon t
[c75b7790] c042f238 .skb_release_data+0x84/0xe4
[c75b7820] c042ef04 .kfree_skbmem+0x20/0xd4
[c75b78a0] c0431c48 .skb_free_datagram+0x14/0x28
[c75b7920] c04a7018 .unix_dgram_recvmsg+0x238/0x294
[c75b7a10] c0427b4c .sock_recvmsg+0xd0/0x110
[c75b7c10] c0428e18 .sys_recvfrom+0xcc/0x14c
[c75b7d90] c044784c .compat_sys_socketcall+0x194/0x214
[c75b7e30] c0008724 syscall_exit+0x0/0x40
--- Exception: c01 (System Call) at 07edffdc
SP (fa4df720) is in userspace
5:mon r
R00 = c042f238 R16 = 1002
R01 = c75b76f0 R17 = 1002
R02 = c0848180 R18 = 1001
R03 = 5a5a5a5a5a5a5a5a R19 = 0003
R04 = 0002 R20 = fbe5fe96
R05 = 00020002 R21 = 1002
R06 = R22 = c3f184b0
R07 = R23 = c3de96e8
R08 = 3520336320633000 R24 = 0050
R09 = c00021f18e20 R25 = c3f181c8
R10 = c75bb8e8 R26 = 0040
R11 = c00021f18e20 R27 = c0007b165e60
R12 = fa4df78cfa4df788 R28 = c75b7a80
R13 = c062ce00 R29 = c0007b165e60
R14 = R30 = c0662d10
R15 = 1002 R31 = 5a5a5a5a5a5a5a5a
pc = c00a2e04 .put_page+0x2c/0x16c
lr = c042f238 .skb_release_data+0x84/0xe4
msr = 80009032 cr = 24044884
ctr = c04a7cb4 xer = 2001 trap = 300
dar = 5a5a5a5a5a5a5a5a dsisr = 4000
Steps to reproduce:
1.mkfs.ext3 /dev/sdb1
2.mount /dev/sdb1 /home
3.mkdir /home/public
4.add entry public (export directory /home/public) to /etc/samba/smb.conf,
then restart samba service
5.mount //localhost/public /mnt/test -o username=xxx,password=xxx
6.fsstress -l 500 -p 1000 -n 1000 -d /mnt/test
I guess skb_release_data() ran off the end of the -frags array and passed
uninitialised, kmalloced data to put_page().
It's a pity that you're running both samba and the CIFS client on the same
machine. If you were to run them on two separate machines across the
network then we might be able to eliminate CIFS.
But it does look like CIFS is involved.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bcm43xx-d80211 broadcast reception with WPA
Ivo Van Doorn ivdoorn at gmail.com writes: I've been backporting the bcm43xx-d80211 driver to whatever the released using the rt2x00 project's d80211 stack Just a note about that stack, it should only be used on kernel 2.6.17 and higher. Thanks, I've noted that at the berlios wiki. -- Paul TBBle Hampson [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Generic Netlink HOW-TO based on Jamal's original doc
* Paul Moore [EMAIL PROTECTED] 2006-11-10 01:08 Excellent! - u32 snd_pid This is the PID of the client which issued the request. In order to avoid confusion it might be better to call it netlink PID as it is not equal to the process ID. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Questions regarding network drivers
On Thu, Nov 09, 2006 at 07:06:00PM -0800, Jonathan Day ([EMAIL PROTECTED]) wrote: Hi, I've got an interesting problem to contend with and need some advice from the great wise ones here. First of all, is it possible (and/or reasonable practice) when developing a network driver to do zero-copy transfers between main memory and the network device? What do you mean? DMA from NIC memory into CPU memory? Secondly, the network device is only designed to work with short packets and I really want to keep the throughput up. My thought was that if I fired off an interrupt then transfer a page of data into an area I know is safe, the kernel will have enough time to find a new safe area and post the address before the next page is ready to send. Can anyone suggest why this wouldn't work or, assuming it can work, why this would be a Bad Idea? There should not be any kind of 'kernel will have enough time to do something', instead you must guarantee that there will not be any kind of races. You can either prealocate several buffers or allocate them on demand in interrupts. Lastly, assuming my sanity lasts that long, would I be correct in assuming that the first step in the process of getting the driver peer-reviewed and accepted would be to post the patches here? Actually not, the first step in that process is learning jig dance and of course providing enough beer and other goodies to network maintainers. Thanks for any help, No problem, but to answer at least on of your question more information should be provided. Jonathan Day -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[IPROUTE2] Add rule notification support to ip monitor
Index: iproute2.git/ip/ip_common.h
===
--- iproute2.git.orig/ip/ip_common.h2006-11-10 12:22:46.0 +0100
+++ iproute2.git/ip/ip_common.h 2006-11-10 12:23:06.0 +0100
@@ -20,6 +20,8 @@
struct nlmsghdr *n, void *arg);
extern int print_prefix(const struct sockaddr_nl *who,
struct nlmsghdr *n, void *arg);
+extern int print_rule(const struct sockaddr_nl *who,
+ struct nlmsghdr *n, void *arg);
extern int do_ipaddr(int argc, char **argv);
extern int do_iproute(int argc, char **argv);
extern int do_iprule(int argc, char **argv);
Index: iproute2.git/ip/ipmonitor.c
===
--- iproute2.git.orig/ip/ipmonitor.c2006-11-10 12:21:00.0 +0100
+++ iproute2.git/ip/ipmonitor.c 2006-11-10 12:23:47.0 +0100
@@ -62,6 +62,10 @@
print_prefix(who, n, arg);
return 0;
}
+ if (n-nlmsg_type == RTM_NEWRULE || n-nlmsg_type == RTM_DELRULE) {
+ print_rule(who, n, arg);
+ return 0;
+ }
if (n-nlmsg_type == 15) {
char *tstr;
time_t secs = ((__u32*)NLMSG_DATA(n))[0];
Index: iproute2.git/ip/iprule.c
===
--- iproute2.git.orig/ip/iprule.c 2006-11-10 12:21:55.0 +0100
+++ iproute2.git/ip/iprule.c2006-11-10 12:24:46.0 +0100
@@ -46,8 +46,7 @@
exit(-1);
}
-static int print_rule(const struct sockaddr_nl *who, struct nlmsghdr *n,
- void *arg)
+int print_rule(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
{
FILE *fp = (FILE*)arg;
struct rtmsg *r = NLMSG_DATA(n);
@@ -58,7 +57,7 @@
char abuf[256];
SPRINT_BUF(b1);
- if (n-nlmsg_type != RTM_NEWRULE)
+ if (n-nlmsg_type != RTM_NEWRULE n-nlmsg_type != RTM_DELRULE)
return 0;
len -= NLMSG_LENGTH(sizeof(*r));
@@ -76,6 +75,9 @@
else if (r-rtm_family == AF_IPX)
host_len = 80;
+ if (n-nlmsg_type == RTM_DELRULE)
+ fprintf(fp, Deleted );
+
if (tb[RTA_PRIORITY])
fprintf(fp, %u:\t, *(unsigned*)RTA_DATA(tb[RTA_PRIORITY]));
else
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [TCP]: remove dead code in init_sequence
This removes two redundancies:
1) The test (skb-protocol == htons(ETH_P_IPV6) in tcp_v6_init_sequence()
is always true, due to
* tcp_v6_conn_request() is the only function calling this one
* tcp_v6_conn_request() redirects all skb's with ETH_P_IP protocol to
tcp_v4_conn_request() [ cf. top of tcp_v6_conn_request()]
2) The first argument, `struct sock *sk' of tcp_v{4,6}_init_sequence() is
never used.
Patch has been tested.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
--
net/ipv4/tcp_ipv4.c |4 ++--
net/ipv6/tcp_ipv6.c | 19 ++-
2 files changed, 8 insertions(+), 15 deletions(-)
--
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 5fbf965..2eb5884 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -111,7 +111,7 @@ void tcp_unhash(struct sock *sk)
inet_unhash(tcp_hashinfo, sk);
}
-static inline __u32 tcp_v4_init_sequence(struct sock *sk, struct sk_buff *skb)
+static inline __u32 tcp_v4_init_sequence(struct sk_buff *skb)
{
return secure_tcp_sequence_number(skb-nh.iph-daddr,
skb-nh.iph-saddr,
@@ -859,7 +859,7 @@ #endif
goto drop_and_free;
}
- isn = tcp_v4_init_sequence(sk, skb);
+ isn = tcp_v4_init_sequence(skb);
}
tcp_rsk(req)-snt_isn = isn;
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index 06b536b..9a8e690 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -106,19 +106,12 @@ static __inline__ u16 tcp_v6_check(struc
return csum_ipv6_magic(saddr, daddr, len, IPPROTO_TCP, base);
}
-static __u32 tcp_v6_init_sequence(struct sock *sk, struct sk_buff *skb)
+static __u32 tcp_v6_init_sequence(struct sk_buff *skb)
{
- if (skb-protocol == htons(ETH_P_IPV6)) {
- return
secure_tcpv6_sequence_number(skb-nh.ipv6h-daddr.s6_addr32,
-
skb-nh.ipv6h-saddr.s6_addr32,
- skb-h.th-dest,
- skb-h.th-source);
- } else {
- return secure_tcp_sequence_number(skb-nh.iph-daddr,
- skb-nh.iph-saddr,
- skb-h.th-dest,
- skb-h.th-source);
- }
+ return secure_tcpv6_sequence_number(skb-nh.ipv6h-daddr.s6_addr32,
+ skb-nh.ipv6h-saddr.s6_addr32,
+ skb-h.th-dest,
+ skb-h.th-source);
}
static int tcp_v6_connect(struct sock *sk, struct sockaddr *uaddr,
@@ -822,7 +815,7 @@ static int tcp_v6_conn_request(struct so
treq-iif = inet6_iif(skb);
if (isn == 0)
- isn = tcp_v6_init_sequence(sk,skb);
+ isn = tcp_v6_init_sequence(skb);
tcp_rsk(req)-snt_isn = isn;
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[NETLINK]: Do precise netlink message allocations where possible
Account for the netlink message header size directly in nlmsg_new()
instead of relying on the caller calculate it correctly.
Replaces error handling of message construction functions when
constructing notifications with bug traps since a failure implies
a bug in calculating the size of the skb.
Signed-off-by: Thomas Graf [EMAIL PROTECTED]
Index: net-2.6.20/include/net/netlink.h
===
--- net-2.6.20.orig/include/net/netlink.h 2006-11-08 15:29:26.0
+0100
+++ net-2.6.20/include/net/netlink.h2006-11-10 11:18:34.0 +0100
@@ -500,14 +500,15 @@
/**
* nlmsg_new - Allocate a new netlink message
- * @size: maximum size of message
+ * @payload: size of the message payload
* @flags: the type of memory to allocate.
*
- * Use NLMSG_GOODSIZE if size isn't know and you need a good default size.
+ * Use NLMSG_DEFAULT_SIZE if the size of the payload isn't known
+ * and a good default is needed.
*/
-static inline struct sk_buff *nlmsg_new(int size, gfp_t flags)
+static inline struct sk_buff *nlmsg_new(size_t payload, gfp_t flags)
{
- return alloc_skb(size, flags);
+ return alloc_skb(nlmsg_total_size(payload), flags);
}
/**
Index: net-2.6.20/include/linux/netlink.h
===
--- net-2.6.20.orig/include/linux/netlink.h 2006-11-08 15:29:26.0
+0100
+++ net-2.6.20/include/linux/netlink.h 2006-11-10 11:18:34.0 +0100
@@ -174,6 +174,7 @@
*/
#define NLMSG_GOODORDER 0
#define NLMSG_GOODSIZE (SKB_MAX_ORDER(0, NLMSG_GOODORDER))
+#define NLMSG_DEFAULT_SIZE (NLMSG_GOODSIZE - NLMSG_HDRLEN)
struct netlink_callback
Index: net-2.6.20/net/ipv4/fib_semantics.c
===
--- net-2.6.20.orig/net/ipv4/fib_semantics.c2006-11-08 15:29:26.0
+0100
+++ net-2.6.20/net/ipv4/fib_semantics.c 2006-11-10 13:06:19.0 +0100
@@ -273,25 +273,49 @@
return -1;
}
+static inline size_t fib_nlmsg_size(struct fib_info *fi)
+{
+ size_t payload = NLMSG_ALIGN(sizeof(struct rtmsg))
++ nla_total_size(4) /* RTA_TABLE */
++ nla_total_size(4) /* RTA_DST */
++ nla_total_size(4) /* RTA_PRIORITY */
++ nla_total_size(4); /* RTA_PREFSRC */
+
+ /* space for nested metrics */
+ payload += nla_total_size((RTAX_MAX * nla_total_size(4)));
+
+ if (fi-fib_nhs) {
+ /* Also handles the special case fib_nhs == 1 */
+
+ /* each nexthop is packed in an attribute */
+ size_t nhsize = nla_total_size(sizeof(struct rtnexthop));
+
+ /* may contain flow and gateway attribute */
+ nhsize += 2 * nla_total_size(4);
+
+ /* all nexthops are packed in a nested attribute */
+ payload += nla_total_size(fi-fib_nhs * nhsize);
+ }
+
+ return payload;
+}
+
void rtmsg_fib(int event, __be32 key, struct fib_alias *fa,
int dst_len, u32 tb_id, struct nl_info *info)
{
struct sk_buff *skb;
- int payload = sizeof(struct rtmsg) + 256;
u32 seq = info-nlh ? info-nlh-nlmsg_seq : 0;
int err = -ENOBUFS;
- skb = nlmsg_new(nlmsg_total_size(payload), GFP_KERNEL);
+ skb = nlmsg_new(fib_nlmsg_size(fa-fa_info), GFP_KERNEL);
if (skb == NULL)
goto errout;
err = fib_dump_info(skb, info-pid, seq, event, tb_id,
fa-fa_type, fa-fa_scope, key, dst_len,
fa-fa_tos, fa-fa_info, 0);
- if (err 0) {
- kfree_skb(skb);
- goto errout;
- }
+ /* failure implies BUG in fib_nlmsg_size() */
+ BUG_ON(err 0);
err = rtnl_notify(skb, info-pid, RTNLGRP_IPV4_ROUTE,
info-nlh, GFP_KERNEL);
Index: net-2.6.20/kernel/taskstats.c
===
--- net-2.6.20.orig/kernel/taskstats.c 2006-11-08 15:29:26.0 +0100
+++ net-2.6.20/kernel/taskstats.c 2006-11-10 11:18:34.0 +0100
@@ -77,8 +77,7 @@
/*
* If new attributes are added, please revisit this allocation
*/
- size = nlmsg_total_size(genlmsg_total_size(size));
- skb = nlmsg_new(size, GFP_KERNEL);
+ skb = nlmsg_new(genlmsg_total_size(size), GFP_KERNEL);
if (!skb)
return -ENOMEM;
Index: net-2.6.20/net/bridge/br_netlink.c
===
--- net-2.6.20.orig/net/bridge/br_netlink.c 2006-11-08 15:29:26.0
+0100
+++ net-2.6.20/net/bridge/br_netlink.c 2006-11-10 13:00:46.0 +0100
@@ -15,6 +15,18 @@
#include net/netlink.h
#include br_private.h
+static inline size_t br_nlmsg_size(void)
+{
+ return NLMSG_ALIGN(sizeof(struct ifinfomsg))
+
[IPv6] rules: Remove bogus tos validation check
Noticed by Al Viro:
(frh-tos ~IPV6_FLOWINFO_MASK))
where IPV6_FLOWINFO_MASK is htonl(0xfff) and frh-tos
is u8, which makes no sense here...
Signed-off-by: Thomas Graf [EMAIL PROTECTED]
Index: net-2.6.20/net/ipv6/fib6_rules.c
===
--- net-2.6.20.orig/net/ipv6/fib6_rules.c 2006-11-10 13:17:40.0
+0100
+++ net-2.6.20/net/ipv6/fib6_rules.c2006-11-10 13:18:16.0 +0100
@@ -142,8 +142,7 @@
int err = -EINVAL;
struct fib6_rule *rule6 = (struct fib6_rule *) rule;
- if (frh-src_len 128 || frh-dst_len 128 ||
- (frh-tos ~IPV6_FLOWINFO_MASK))
+ if (frh-src_len 128 || frh-dst_len 128)
goto errout;
if (rule-action == FR_ACT_TO_TBL) {
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Generic Netlink HOW-TO based on Jamal's original doc
On 10-11-2006 07:08, Paul Moore wrote:
...
An Introduction To Using Generic Netlink
===
...
Here is a proposal of small adjustments.
Maybe some of them will be useful.
Best regards,
Jarek P.
---
--- netlink.txt-2006-11-10 10:53:50.0 +0100
+++ netlink.txt 2006-11-10 14:08:25.0 +0100
@@ -32,7 +32,7 @@
1.1. Document Overview
--
-This document gives is a brief introduction to Generic Netlink, some simple
+This document gives a brief introduction to Generic Netlink, some simple
examples on how to use it, and some recommendations on how to make the most of
the Generic Netlink communications interface. While this document does not
require that the reader have a detailed understanding of what Netlink is
@@ -55,21 +55,21 @@
channels are associated with families or busses, where each bus deals with a
specific service; for example, different Netlink busses exist for routing,
XFRM, netfilter, and several other kernel subsystems. More information about
-Netlink can be found in RFC 3549[1].
+Netlink can be found in RFC 3549[2].
Over the years, Netlink has become very popular which has brought about a very
real concern that the number of Netlink family numbers may be exhausted in the
near future. In response to this the Generic Netlink family was created which
-acts as a Netlink multiplexer, allowing multiple service to use a single
+acts as a Netlink multiplexer, allowing multiple services to use a single
Netlink bus.
-[1] ftp://ftp.rfc-editor.org/in-notes/rfc3549.txt
+[2] ftp://ftp.rfc-editor.org/in-notes/rfc3549.txt
2. Architectural Overview
--
-Figure #1 illustrates how the basic Generic Netlink architecture which is
-composed of five different types of components.
+Figure #1 illustrates the basic Generic Netlink architecture which is
+composed of five different types of components:
1) The Netlink subsystem which serves as the underlying transport layer for
all of the Generic Netlink communications.
@@ -99,7 +99,7 @@
||
+---++---+
|: : | user-space
- =+: (5) Kernel socket API : +
+ =+: (5) kernel socket API : +
|: : | kernel-space
++---+---+
| |
@@ -112,7 +112,7 @@
+--+--+---++
| | |
+---+-+| |
- | (4) Controller | / \
+ | (4) controller | / \
+-+ / \
| |
+--+--+ +--+--+
@@ -149,7 +149,7 @@
3.1. Family Overview
--
-Generic Netlink family service registrations are defined by two structures,
+Generic Netlink family service registrations are defined by two structures:
genl_family and genl_ops. The genl_family structure defines the family and
it's associated communication channel. The genl_ops structure defines
an individual service or operation which the family provides to other Generic
@@ -161,7 +161,7 @@
[1] http://people.suug.ch/~tgr/libnl
-3.1.2. The genl_family Structure
+3.1.1. The genl_family Structure
Generic Netlink services are defined by the genl_family structure, which is
shown below:
@@ -241,7 +241,7 @@
* unsigned int flags
This field is used to specify any special attributes of the operation. The
- following flags may be used, multiple flags can be OR'd together:
+ following flags may be used (multiple flags can be OR'd together):
- GENL_ADMIN_PERM
@@ -251,11 +251,12 @@
This field defines the Netlink attribute policy for the operation request
message. If specified, the Generic Netlink mechanism uses this policy to
- verify all of the attributes in a operation request message before calling
+ verify all of the attributes in an operation request message before calling
the operation handler.
The attribute policy is defined as an array of nla_policy structures indexed
- by the attribute number. The nla_policy structure is defined in figure #4.
+ by the attribute number. The nla_policy structure is defined as shown in
+ figure #4.
struct nla_policy
{
@@ -269,7 +270,7 @@
- u16 type
- This specifies the type of the attribute, presently the following
Re: [patch sungem] improved locking
On 11/10/06, David Miller [EMAIL PROTECTED] wrote:
Please use GREG_STAT_* instead of magic constants for the
interrupt mask and ACK register writes. In fact, there are
some questionable values you use, in particular this one:
+static inline void gem_ack_int(struct gem *gp)
+{
+ writel(0x3f, gp-regs + GREG_IACK);
+}
This code clears bits 0 through 6, which GREG_IACK is for.
There is no bit defined in GREG_STAT_* for 0x08, but you
set it in this magic bitmask. It is another reason not
to use magic constants like this :-)
Yes, the bit 4 isn't used, but I assumed clearing it shouldn't be prolem.
Would you prefer that:
#define GREG_STAT_IACK 0x3f
static inline void gem_ack_int(struct gem *gp)
{
writel(GREG_STAT_IACK, gp-regs + GREG_IACK);
}
or that:
#define GREG_STAT_IACK (GREG_STAT_TXINTME | GREG_STAT_TXALL | \
GREG_STAT_RXDONE | GREG_STAT_RXNOBUF)
to avoid bit 4, and bit 3 (TX_DONE) which is masked.
Personnaly, I like the first way best.
Also, if you need to use an attachment to get the tabbing
right, that's fine, but please also provide a copy inline
so that it is easy to quote the patch for review purposes.
It's a truly a pain in the rear to quote things when you use
a binary attachment.
I will.
I'd like these very simple and straightforward issues to
be worked out before I even begin to review the actual
locking change itself.
Ok.
I'll wait for you regarding gem_ack_int() and send out another patch.
Thanks,
--
Eric
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHSET] packet mark fib rules work
* Steven Whitehouse [EMAIL PROTECTED] 2006-11-09 14:55 So here is roughly what I was thinking... this comes from having spent a little while thinking about the best way to integrate MPLS into the network stack. An MPLS label is 32 bits in size which conviently matches the size of the packet mark. So one thought was this (for MPLS edge routers). Add the ability to set a mark to the IP routing table. Something along the lines of: /sbin/ip route add 10.1.0.0/16 via 10.2.1.1 dev eth0 setmark 6 and then use the mark as the FEC (forwarding equivalence class) for MPLS (which is just an index, but in simple cases could contain a whole MPLS label). I was hoping that it might be possible to use the xfrm infrastructure to deal with the actual application of MPLS labels, but I'm not yet 100% certain that its a good fit. Either way, MPLS will require some kind of way to indicate the FEC for each route, so using the generic mark like this seems to me a reasonable solution on the basis that other uses might then be found for it as well. Using tc_index might work as well. Anyways, having a route metric which influences the mark and tc_index for packets being routed via said route is certainly a good thing. Since MPLS labels are only a subset of the full 32 bits, being able to use a mask in conjunction with setting the mark might also be a useful feature, so that the logic (pseudo code) after route lookup might look something like: skb-mark = ~nh-nh_setmask; skb-mark |= nh-nh_setmark; /* Assume mark only sets bits allowed by mask */ The big question being, is this going to be a problem bearing in mind it would appear in the routing fast path? We probably don't know until we try it. IMHO fast path thoughts should never be a reason to not try and implement something in a clean fashion. There is always ways to optimize things. On the MPLS input side, packet marks would be set according to the incoming MPLS label and then work in just the same way that you propose using the marks to create separate routing for different VLANs for example. An ingress action which can both translate MPLS labels into a mark or tc_index value should suit us fine. This could be a simple 1:1 mapping or a more complex translation table which can be managed by userspace via netlink. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Generic Netlink HOW-TO based on Jamal's original doc
On Fri, 2006-10-11 at 01:45 -0500, Paul Moore wrote: James Morris wrote: An Introduction To Using Generic Netlink === Wow, this is great! Thanks. I consider it an act of penance for all of the evil things I did with Netlink on my first few iterations of NetLabel ;) Hey, theres more than one way to pay for your sins ;- For example: Do you wanna take over maintainance of the doc? ;- i.e it would make a lot of sense to finally submit it for inclusion. Thanks for the effort. I havent read it - dont have the time till this weekend. I would like to have input as well from the other folks who have opined in the past (on CC list - they seemed to have strong opinions of what should be in the doc). This is also timely because this weekend i was going to work on a presentation on this stuff for a conference ;- So i will actually have to read what you put together. I will have more comments later when i am done reading. cheers, jamal - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH wireless-2.6-git] prism54: WPA/RSN support for fullmac cards
On Thu, 2006-11-09 at 18:16 -0500, Luis R. Rodriguez wrote: On 11/9/06, Luis R. Rodriguez [EMAIL PROTECTED] wrote: On 11/9/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Am Mittwoch, 8. November 2006 01:39 schrieben Sie: On Fri, Nov 03, 2006 at 01:41:46PM -0500, Luis R. Rodriguez wrote: On 11/3/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: yes, especially mgt_commit_list caused alot headaches, until I removed DOT11_OID_PSM from the cache list. Now, I can hammer it with ping -f for hours. nice, perhaps that's been the culprit all along... going to dig to see if I find a fullmac prism card. Will like to get this merged in. Any resolution on this? no replies. Seems like it works for just fine for everybody. ;) I found a card, I just need time to test it. Dan didn't you say you ran into issues with the patch on your card? No, more that my card doesn't successfully associate at all even _without_ the patch on unencrypted or WEP APs; I just can't test it, since my card seems to be broken... Dan Luis CC'ing Dan to make sure he gets it ;) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Intel 82559 NIC corrupted EEPROM
Jesse Brandeburg wrote: Can you send output of cat /proc/iomem -0009 : System RAM 000a-000b : Video RAM area 000f-000f : System ROM 0010-0ffe : System RAM 0010-00296a1a : Kernel code 00296a1b-0031bbe7 : Kernel data 0fff-0fff2fff : ACPI Non-volatile Storage 0fff3000-0fff : ACPI Tables 2000-200f : :00:08.0 2010-201f : :00:09.0 2020-202f : :00:0a.0 e000-e3ff : :00:00.0 e500-e50f : :00:08.0 e510-e51f : :00:09.0 e520-e52f : :00:0a.0 e530-e5300fff : :00:08.0 e5301000-e5301fff : :00:0a.0 e5302000-e5302fff : :00:09.0 - : reserved I've also attached: o config-2.6.18.1-adlink used to compile this kernel o dmesg output after the machine boots try something like the attached patch Loading e100-debug.ko reports: e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI e100: Copyright(c) 1999-2005 Intel Corporation ***e100 debug: unable to set power state (error 0) ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 12 PCI: setting IRQ 12 as level-triggered ACPI: PCI Interrupt :00:08.0[A] - Link [LNKA] - GSI 12 (level, low) - IRQ 12 ***e100 debug: read 0100/ from the same register e100: eth0: e100_probe: addr 0xe530, irq 12, MAC addr 00:30:64:04:E6:E4 ***e100 debug: unable to set power state (error 0) ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10 PCI: setting IRQ 10 as level-triggered ACPI: PCI Interrupt :00:09.0[A] - Link [LNKB] - GSI 10 (level, low) - IRQ 10 ***e100 debug: read 0100/ from the same register e100: :00:09.0: e100_eeprom_load: EEPROM corrupted ACPI: PCI interrupt for device :00:09.0 disabled e100: probe of :00:09.0 failed with error -11 ***e100 debug: unable to set power state (error 0) ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11 PCI: setting IRQ 11 as level-triggered ACPI: PCI Interrupt :00:0a.0[A] - Link [LNKC] - GSI 11 (level, low) - IRQ 11 ***e100 debug: read 0100/ from the same register e100: eth1: e100_probe: addr 0xe5301000, irq 11, MAC addr 00:30:64:04:E6:E6 In other words, the behavior is the same for all three NICs. pci_set_power_state(pdev, PCI_D0) returns 0 pci_iomap returns something != NULL Can I provide more information to help locate the problem? # # Automatically generated make config: don't edit # Linux kernel version: 2.6.18.1-hrt # Tue Nov 7 17:52:26 2006 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_RELAY is not set CONFIG_INITRAMFS_SOURCE= # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set # CONFIG_KMOD is not set # # Block layer # # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # # Processor type and features # # CONFIG_HIGH_RES_TIMERS is not set # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set CONFIG_MPENTIUMIII=y # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not
hostap_cs_{resume,suspend}(): inconsequent NULL checking
The Coverity checker spotted the following in
drivers/net/wireless/hostap/hostap_cs.c:
-- snip --
...
static int hostap_cs_suspend(struct pcmcia_device *link)
{
struct net_device *dev = (struct net_device *) link-priv;
int dev_open = 0;
struct hostap_interface *iface = NULL;
if (dev)
iface = netdev_priv(dev);
PDEBUG(DEBUG_EXTRA, %s: CS_EVENT_PM_SUSPEND\n, dev_info);
if (iface iface-local)
dev_open = iface-local-num_dev_open 0;
if (dev_open) {
netif_stop_queue(dev);
netif_device_detach(dev);
}
prism2_suspend(dev);
return 0;
}
static int hostap_cs_resume(struct pcmcia_device *link)
{
struct net_device *dev = (struct net_device *) link-priv;
int dev_open = 0;
struct hostap_interface *iface = NULL;
if (dev)
iface = netdev_priv(dev);
PDEBUG(DEBUG_EXTRA, %s: CS_EVENT_PM_RESUME\n, dev_info);
if (iface iface-local)
dev_open = iface-local-num_dev_open 0;
prism2_hw_shutdown(dev, 1);
prism2_hw_config(dev, dev_open ? 0 : 1);
if (dev_open) {
netif_device_attach(dev);
netif_start_queue(dev);
}
return 0;
}
...
-- snip --
The problem is that if the if (dev) is false, there's a guaranteed
NULL dereference later in the prism2_suspend(dev) resp.
prism2_hw_config(dev, dev_open ? 0 : 1).
cu
Adrian
--
Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
Only a promise, Lao Er said.
Pearl S. Buck - Dragon Seed
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Generic Netlink HOW-TO based on Jamal's original doc
Paul Moore wrote: A couple of months ago I promised Jamal and Thomas I would post some comments to Jamal's original genetlink how-to. However, as I started to work on the document the diff from the original started to get a little ridiculous so instead of posting a patch against Jamal's original how-to I'm just posting the revised document in it's entirety. In the document below I tried to summarize all of the things I learned while developing NetLabel. Some of it came from Jamal's document, some the kernel code, and some from discussions with Thomas. Hopefully this document will make it much easier for others to use genetlink in the future. If this text below is acceptable to everyone, should this be added to the Documentation directory? Mind if we put a wikified version on http://linux-net.osdl.org? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NETLINK]: Do precise netlink message allocations where possible
Thomas Graf wrote:
Account for the netlink message header size directly in nlmsg_new()
instead of relying on the caller calculate it correctly.
Replaces error handling of message construction functions when
constructing notifications with bug traps since a failure implies
a bug in calculating the size of the skb.
Signed-off-by: Thomas Graf [EMAIL PROTECTED]
Index: net-2.6.20/include/net/netlink.h
===
--- net-2.6.20.orig/include/net/netlink.h 2006-11-08 15:29:26.0
+0100
+++ net-2.6.20/include/net/netlink.h 2006-11-10 11:18:34.0 +0100
@@ -500,14 +500,15 @@
/**
* nlmsg_new - Allocate a new netlink message
- * @size: maximum size of message
+ * @payload: size of the message payload
* @flags: the type of memory to allocate.
*
- * Use NLMSG_GOODSIZE if size isn't know and you need a good default size.
+ * Use NLMSG_DEFAULT_SIZE if the size of the payload isn't known
+ * and a good default is needed.
*/
-static inline struct sk_buff *nlmsg_new(int size, gfp_t flags)
+static inline struct sk_buff *nlmsg_new(size_t payload, gfp_t flags)
{
- return alloc_skb(size, flags);
+ return alloc_skb(nlmsg_total_size(payload), flags);
}
I like this approach, it makes much more sense to me then the previous
implementation which was a simple alias to alloc_skb(). Also, the NetLabel
relevant sections look fine to me.
Acked-by: Paul Moore [EMAIL PROTECTED]
--
paul moore
linux security @ hp
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Generic Netlink HOW-TO based on Jamal's original doc
Thomas Graf wrote: * Paul Moore [EMAIL PROTECTED] 2006-11-10 01:08 Excellent! Thanks. - u32 snd_pid This is the PID of the client which issued the request. In order to avoid confusion it might be better to call it netlink PID as it is not equal to the process ID. Good point, I just made the change. I'll push out another rev of the document once the rest of the group has had a chance to review the doc. -- paul moore linux security @ hp - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] [NET/IPv6]: UDP-Litev6 support
[NET/IPv6]: Extension for UDP-Lite over IPv6
This extends the existing UDPv6 code base with support for UDP-Lite
in the same manner as per UDPv4. In particular,
* UDPv6 generic and shared code is in net/ipv6/udp.c
* UDP-Litev6 specific extensions are in net/ipv6/udplite.c
* MIB/statistics support in /proc/net/snmp6 and /proc/net/udplite6
* support for IPV6_ADDRFORM
* aligned the coding style of protocol initialisation with af_inet6.c
* made the error handling in udpv6_queue_rcv_skb consistent;
to return `-1' on error on all error cases
* consolidation of shared code
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
--
include/net/ipv6.h | 12 +
include/net/transp_v6.h |2
net/ipv6/af_inet6.c | 21 ++
net/ipv6/ipv6_sockglue.c | 11 +
net/ipv6/proc.c | 11 +
net/ipv6/udp.c | 330 ++-
net/ipv6/udplite.c | 103 ++
7 files changed, 343 insertions(+), 147 deletions(-)
--
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index 0b8c9b9..aebbd2d 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -143,9 +143,13 @@ #define ICMP6_INC_STATS_OFFSET_BH(idev,
SNMP_INC_STATS_OFFSET_BH(icmpv6_statistics, field, _offset);
\
})
DECLARE_SNMP_STAT(struct udp_mib, udp_stats_in6);
-#define UDP6_INC_STATS(field) SNMP_INC_STATS(udp_stats_in6, field)
-#define UDP6_INC_STATS_BH(field) SNMP_INC_STATS_BH(udp_stats_in6, field)
-#define UDP6_INC_STATS_USER(field) SNMP_INC_STATS_USER(udp_stats_in6,
field)
+DECLARE_SNMP_STAT(struct udp_mib, udplite_stats_in6);
+#define UDP6_INC_STATS_BH(field, is_udplite) do { \
+ if (is_udplite) SNMP_INC_STATS_BH(udplite_stats_in6, field); \
+ elseSNMP_INC_STATS_BH(udp_stats_in6, field);} while(0)
+#define UDP6_INC_STATS_USER(field, is_udplite)do {\
+ if (is_udplite) SNMP_INC_STATS_USER(udplite_stats_in6, field); \
+ elseSNMP_INC_STATS_USER(udp_stats_in6, field);} while(0)
int snmp6_register_dev(struct inet6_dev *idev);
int snmp6_unregister_dev(struct inet6_dev *idev);
@@ -589,6 +593,8 @@ extern int tcp6_proc_init(void);
extern void tcp6_proc_exit(void);
extern int udp6_proc_init(void);
extern void udp6_proc_exit(void);
+extern int udplite6_proc_init(void);
+extern void udplite6_proc_exit(void);
extern int ipv6_misc_proc_init(void);
extern void ipv6_misc_proc_exit(void);
diff --git a/include/net/transp_v6.h b/include/net/transp_v6.h
index 61f724c..409da3a 100644
--- a/include/net/transp_v6.h
+++ b/include/net/transp_v6.h
@@ -11,6 +11,7 @@ #ifdef __KERNEL__
extern struct proto rawv6_prot;
extern struct proto udpv6_prot;
+extern struct proto udplitev6_prot;
extern struct proto tcpv6_prot;
struct flowi;
@@ -24,6 +25,7 @@ extern void ipv6_destopt_init(void);
/* transport protocols */
extern voidrawv6_init(void);
extern voidudpv6_init(void);
+extern voidudplitev6_init(void);
extern voidtcpv6_init(void);
extern int udpv6_connect(struct sock *sk,
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 43fe064..80c0342 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -49,6 +49,7 @@ #include net/ip6_route.h
#include net/addrconf.h
#include net/ip.h
#include net/udp.h
+#include net/udplite.h
#include net/raw.h
#include net/inet_common.h
#include net/tcp_states.h
@@ -66,23 +67,9 @@ static inline int udp_v6_get_port(struct
return udp_get_port(sk, snum, ipv6_rcv_saddr_equal);
}
-static void udp_v6_hash(struct sock *sk)
-{
- BUG();
-}
-
-static void udp_v6_unhash(struct sock *sk)
-{
- write_lock_bh(udp_hash_lock);
- if (sk_del_node_init(sk)) {
- inet_sk(sk)-num = 0;
- sock_prot_dec_use(sk-sk_prot);
- }
- write_unlock_bh(udp_hash_lock);
-}
-
-static struct sock *udp_v6_lookup(struct in6_addr *saddr, u16 sport,
- struct in6_addr *daddr, u16 dport, int dif)
+static struct sock *__udp6_lib_lookup(struct in6_addr *saddr, __be16 sport,
+ struct in6_addr *daddr, __be16 dport,
+ int dif, struct hlist_head udptable[])
{
struct sock *sk, *result = NULL;
struct hlist_node *node;
@@ -90,7 +77,7 @@ static struct sock *udp_v6_lookup(struct
int badness = -1;
read_lock(udp_hash_lock);
- sk_for_each(sk, node, udp_hash[hnum (UDP_HTABLE_SIZE - 1)]) {
+ sk_for_each(sk, node, udptable[hnum (UDP_HTABLE_SIZE - 1)]) {
[PATCH 3/3] [NET]: UDP-Lite misc files
[NET]: UDP-Lite Documentation and basic XFRM/Netfilter support This provides * API documentation for UDP-Lite * basic xfrm support * basic netfilter support for IPv4 and IPv6 (LOG target) Signed-off-by: Gerrit Renker [EMAIL PROTECTED] -- Documentation/networking/udplite.txt | 281 +++ include/net/xfrm.h |2 net/ipv4/netfilter/ipt_LOG.c | 11 - net/ipv4/xfrm4_policy.c |1 net/ipv6/netfilter/ip6t_LOG.c| 10 - net/ipv6/xfrm6_policy.c |1 net/netfilter/xt_multiport.c |5 net/netfilter/xt_tcpudp.c| 20 ++ 8 files changed, 322 insertions(+), 9 deletions(-) -- diff --git a/Documentation/networking/udplite.txt b/Documentation/networking/udplite.txt new file mode 100644 index 000..dd6f46b --- /dev/null +++ b/Documentation/networking/udplite.txt @@ -0,0 +1,281 @@ + === + The UDP-Lite protocol (RFC 3828) + === + + + UDP-Lite is a Standards-Track IETF transport protocol whose characteristic + is a variable-length checksum. This has advantages for transport of multimedia + (video, VoIP) over wireless networks, as partly damaged packets can still be + fed into the codec instead of being discarded due to a failed checksum test. + + This file briefly describes the existing kernel support and the socket API. + For in-depth information, you can consult: + + o The UDP-Lite Homepage: http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/ + Fom here you can also download some example application source code. + + o The UDP-Lite HOWTO on + http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/files/UDP-Lite-HOWTO.txt + + o The Wireshark UDP-Lite WiKi (with capture files): + http://wiki.wireshark.org/Lightweight_User_Datagram_Protocol + + o The Protocol Spec, RFC 3828, http://www.ietf.org/rfc/rfc3828.txt + + + I) APPLICATIONS + + Several applications have been ported successfully to UDP-Lite. Ethereal + (now called wireshark) has UDP-Litev4/v6 support by default. The tarball on + + http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/files/udplite_linux.tar.gz + + has source code for several v4/v6 client-server and network testing examples. + + Porting applications to UDP-Lite is straightforward: only socket level and + IPPROTO need to be changed; senders additionally set the checksum coverage + length (default = header length = 8). Details are in the next section. + + + II) PROGRAMMING API + + UDP-Lite provides a connectionless, unreliable datagram service and hence + uses the same socket type as UDP. In fact, porting from UDP to UDP-Lite is + very easy: simply add `IPPROTO_UDPLITE' as the last argument of the socket(2) + call so that the statement looks like: + + s = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDPLITE); + + or, respectively, + + s = socket(PF_INET6, SOCK_DGRAM, IPPROTO_UDPLITE); + + With just the above change you are able to run UDP-Lite services or connect + to UDP-Lite servers. The kernel will assume that you are not interested in + using partial checksum coverage and so emulate UDP mode (full coverage). + + To make use of the partial checksum coverage facilities requires setting a + single socket option, which takes an integer specifying the coverage length: + +* Sender checksum coverage: UDPLITE_SEND_CSCOV + + For example, + +int val = 20; +setsockopt(s, SOL_UDPLITE, UDPLITE_SEND_CSCOV, val, sizeof(int)); + + sets the checksum coverage length to 20 bytes (12b data + 8b header). + Of each packet only the first 20 bytes (plus the pseudo-header) will be + checksummed. This is useful for RTP applications which have a 12-byte + base header. + + +* Receiver checksum coverage: UDPLITE_RECV_CSCOV + + This option is the receiver-side analogue. It is truly optional, i.e. not + required to enable traffic with partial checksum coverage. Its function is + that of a traffic filter: when enabled, it instructs the kernel to drop + all packets which have a coverage _less_ than this value. For example, if + RTP and UDP headers are to be protected, a receiver can enforce that only + packets with a minimum coverage of 20 are admitted: + +int min = 20; +setsockopt(s, SOL_UDPLITE, UDPLITE_RECV_CSCOV, min, sizeof(int)); + + The calls to getsockopt(2) are analogous. Being an extension and not a stand- + alone protocol, all socket options known from UDP can be used in exactly the + same manner as before, e.g. UDP_CORK or UDP_ENCAP. + + A detailed discussion of UDP-Lite checksum coverage
Re: [patch 1/9] bonding: lockdep annotation
[EMAIL PROTECTED] wrote: From: Peter Zijlstra [EMAIL PROTECTED] = [ INFO: possible recursive locking detected ] 2.6.17-1.2600.fc6 #1 - applied; please CC me on this drivers/net stuff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 5/5] drivers cris: return on NULL dev_alloc_skb()
[EMAIL PROTECTED] wrote: From: David Rientjes [EMAIL PROTECTED] If the next descriptor array entry cannot be allocated by dev_alloc_skb(), return immediately so it is not dereferenced later. We cannot register the device with a partial descriptor list. Cc: Mikael Starvik [EMAIL PROTECTED] Signed-off-by: David Rientjes [EMAIL PROTECTED] Cc: Jeff Garzik [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] applied - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Generic Netlink HOW-TO based on Jamal's original doc
Jarek Poplawski wrote: On 10-11-2006 07:08, Paul Moore wrote: ... An Introduction To Using Generic Netlink === ... Here is a proposal of small adjustments. Maybe some of them will be useful. They all look very useful to me, thank you very much. I'm going to merge your patch and I'll put out an updated rev of the document once Jamal and some others have had a chance to review the document. -- paul moore linux security @ hp - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] [NET]: Supporting UDP-Lite (RFC 3828) in Linux
[NET/IPv4]: Support for the UDP-Lite protocol (RFC 3828)
This adds support for UDP-Lite to the IPv4 stack, provided as an extension
to the existing UDPv4 code:
* generic routines are all located in net/ipv4/udp.c
* UDP-Lite specific routines are in net/ipv4/udplite.c
* MIB/statistics support in /proc/net/snmp and /proc/net/udplite
* shared API with extensions for partial checksum coverage
* consolidation of shared code
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
--
include/linux/in.h |1
include/linux/socket.h |1
include/linux/udp.h| 12 +
include/net/udp.h | 91 -
include/net/udplite.h | 149 +++
net/ipv4/af_inet.c |8
net/ipv4/proc.c| 13 +
net/ipv4/udp.c | 481 +
net/ipv4/udplite.c | 118
9 files changed, 673 insertions(+), 201 deletions(-)
--
diff --git a/include/linux/udp.h b/include/linux/udp.h
index 014b41d..564f3b0 100644
--- a/include/linux/udp.h
+++ b/include/linux/udp.h
@@ -38,6 +38,7 @@ #ifdef __KERNEL__
#include linux/types.h
#include net/inet_sock.h
+#define UDP_HTABLE_SIZE128
struct udp_sock {
/* inet_sock has to be the first member */
@@ -50,12 +51,23 @@ struct udp_sock {
* when the socket is uncorked.
*/
__u16len; /* total length of pending frames */
+ /*
+* Fields specific to UDP-Lite.
+*/
+ __u16pcslen;
+ __u16pcrlen;
+/* indicator bits used by pcflag: */
+#define UDPLITE_BIT 0x1 /* set by udplite proto init function */
+#define UDPLITE_SEND_CC 0x2 /* set via udplite setsockopt */
+#define UDPLITE_RECV_CC 0x4 /* set via udplite setsocktopt*/
+ __u8 pcflag;/* marks socket as UDP-Lite if 0*/
};
static inline struct udp_sock *udp_sk(const struct sock *sk)
{
return (struct udp_sock *)sk;
}
+#define IS_UDPLITE(__sk) (udp_sk(__sk)-pcflag)
#endif
diff --git a/include/net/udp.h b/include/net/udp.h
index db0c05f..4f06267 100644
--- a/include/net/udp.h
+++ b/include/net/udp.h
@@ -26,9 +26,28 @@ #include linux/list.h
#include net/inet_sock.h
#include net/sock.h
#include net/snmp.h
+#include net/ip.h
+#include linux/ipv6.h
#include linux/seq_file.h
-#define UDP_HTABLE_SIZE128
+/**
+ * struct udp_skb_cb - UDP(-Lite) private variables
+ *
+ * @header: private variables used by IPv4/IPv6
+ * @cscov: checksum coverage length (UDP-Lite only)
+ * @partial_cov: if set indicates partial csum coverage
+ */
+struct udp_skb_cb {
+ union {
+ struct inet_skb_parmh4;
+#if defined(CONFIG_IPV6) || defined (CONFIG_IPV6_MODULE)
+ struct inet6_skb_parm h6;
+#endif
+ } header;
+ __u16 cscov;
+ __u8partial_cov;
+};
+#define UDP_SKB_CB(__skb) ((struct udp_skb_cb *)((__skb)-cb))
extern struct hlist_head udp_hash[UDP_HTABLE_SIZE];
extern rwlock_t udp_hash_lock;
@@ -47,6 +66,62 @@ extern struct proto udp_prot;
struct sk_buff;
+/*
+ * Generic checksumming routines for UDP(-Lite) v4 and v6
+ */
+static inline u16 __udp_lib_checksum_complete(struct sk_buff *skb)
+{
+ if (! UDP_SKB_CB(skb)-partial_cov)
+ return __skb_checksum_complete(skb);
+ return csum_fold(skb_checksum(skb, 0, UDP_SKB_CB(skb)-cscov,
+ skb-csum));
+}
+
+static __inline__ int udp_lib_checksum_complete(struct sk_buff *skb)
+{
+ return skb-ip_summed != CHECKSUM_UNNECESSARY
+ __udp_lib_checksum_complete(skb);
+}
+
+/**
+ * udp_csum_outgoing - compute UDPv4/v6 checksum over fragments
+ * @sk:socket we are writing to
+ * @skb: sk_buff containing the filled-in UDP header
+ * (checksum field must be zeroed out)
+ */
+static inline u32 udp_csum_outgoing(struct sock *sk, struct sk_buff *skb)
+{
+ u32 csum = csum_partial(skb-h.raw, sizeof(struct udphdr), 0);
+
+ skb_queue_walk(sk-sk_write_queue, skb) {
+ csum = csum_add(csum, skb-csum);
+ }
+ return csum;
+}
+
+/* hash routines shared between UDPv4/6 and UDP-Litev4/6 */
+static inline void udp_lib_hash(struct sock *sk)
+{
+ BUG();
+}
+
+static inline void udp_lib_unhash(struct sock *sk)
+{
+ write_lock_bh(udp_hash_lock);
+ if (sk_del_node_init(sk)) {
+ inet_sk(sk)-num = 0;
+ sock_prot_dec_use(sk-sk_prot);
+ }
+ write_unlock_bh(udp_hash_lock);
+}
+
+static inline void udp_lib_close(struct sock *sk, long timeout)
+{
+ sk_common_release(sk);
+}
+
+
+/* net/ipv4/udp.c */
extern int
Re: Please pull 'upstream-fixes' branch of wireless-2.6
John W. Linville wrote: The following changes since commit edd106fc8ac1826dbe231b70ce0762db24133e5c: Auke Kok: e1000: Fix regression: garbled stats and irq allocation during swsusp are found in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git upstream-fixes Adrian Bunk: bcm43xx: Add error checking in bcm43xx_sprom_write() Michael Buesch: bcm43xx: Drain TX status before starting IRQs drivers/net/wireless/bcm43xx/bcm43xx_main.c | 22 -- 1 files changed, 20 insertions(+), 2 deletions(-) pulled - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Generic Netlink HOW-TO based on Jamal's original doc
jamal wrote: On Fri, 2006-10-11 at 01:45 -0500, Paul Moore wrote: James Morris wrote: An Introduction To Using Generic Netlink === Wow, this is great! Thanks. I consider it an act of penance for all of the evil things I did with Netlink on my first few iterations of NetLabel ;) Hey, theres more than one way to pay for your sins ;- For example: Do you wanna take over maintainance of the doc? ;- There is a sucker born every minute. right? :) I'll make you a deal: I'll take over maintainance of the document as long as you promise to send me your feedback by Monday. i.e it would make a lot of sense to finally submit it for inclusion. Thanks for the effort. I think so too, I'm glad I was able to help out. I havent read it - dont have the time till this weekend. I would like to have input as well from the other folks who have opined in the past (on CC list - they seemed to have strong opinions of what should be in the doc). This is also timely because this weekend i was going to work on a presentation on this stuff for a conference ;- So i will actually have to read what you put together. I will have more comments later when i am done reading. Okay, I've already made some changes based on other comments in this thread but I'll refrain from pushing out an updated version until early next week. I'll also make the next version of the document a patch against net-2.6.20. Thanks. -- paul moore linux security @ hp - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] IPv6: only modify checksum for UDP
Only change upper-layer checksum from 0 to 0x for UDP (as RFC 768
states), not for others as RFC 4443 doesn't require it.
Signed-off-by: Brian Haley [EMAIL PROTECTED]
diff --git a/net/ipv6/icmp.c b/net/ipv6/icmp.c
index 81bd45b..dbb9b1f 100644
--- a/net/ipv6/icmp.c
+++ b/net/ipv6/icmp.c
@@ -246,8 +246,6 @@ static int icmpv6_push_pending_frames(st
len, fl-proto, tmp_csum);
icmp6h-icmp6_cksum = tmp_csum;
}
- if (icmp6h-icmp6_cksum == 0)
- icmp6h-icmp6_cksum = -1;
ip6_push_pending_frames(sk);
out:
return err;
diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c
index 6bc6655..baf7b82 100644
--- a/net/ipv6/raw.c
+++ b/net/ipv6/raw.c
@@ -536,7 +536,7 @@ static int rawv6_push_pending_frames(str
fl-fl6_dst,
total_len, fl-proto, tmp_csum);
- if (tmp_csum == 0)
+ if (tmp_csum == 0 fl-proto == IPPROTO_UDP)
tmp_csum = -1;
csum = tmp_csum;
Re: Generic Netlink HOW-TO based on Jamal's original doc
Stephen Hemminger wrote: Paul Moore wrote: A couple of months ago I promised Jamal and Thomas I would post some comments to Jamal's original genetlink how-to. However, as I started to work on the document the diff from the original started to get a little ridiculous so instead of posting a patch against Jamal's original how-to I'm just posting the revised document in it's entirety. In the document below I tried to summarize all of the things I learned while developing NetLabel. Some of it came from Jamal's document, some the kernel code, and some from discussions with Thomas. Hopefully this document will make it much easier for others to use genetlink in the future. If this text below is acceptable to everyone, should this be added to the Documentation directory? Mind if we put a wikified version on http://linux-net.osdl.org? That sounds fine to me, although can we hold off for a little bit so I can collect some more comments? Is the wiki open to anyone, i.e. can I add the document directly, or am I better off just letting you do it? -- paul moore linux security @ hp - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] IPv6: optimize echo reply checksum calculation
Since the only difference between echo requests and echo replies is the
ICMPv6 type value (which is a difference of 1), just subtracting one
from the request checksum will result in the correct checksum for the reply.
Signed-off-by: Brian Haley [EMAIL PROTECTED]
diff --git a/net/ipv6/icmp.c b/net/ipv6/icmp.c
index dbb9b1f..ee04610 100644
--- a/net/ipv6/icmp.c
+++ b/net/ipv6/icmp.c
@@ -212,7 +212,7 @@ static __inline__ int opt_unrec(struct s
return (*op 0xC0) == 0x80;
}
-static int icmpv6_push_pending_frames(struct sock *sk, struct flowi *fl, struct icmp6hdr *thdr, int len)
+static int icmpv6_push_pending_frames(struct sock *sk, struct flowi *fl, struct icmp6hdr *thdr, int len, int cksum_needed)
{
struct sk_buff *skb;
struct icmp6hdr *icmp6h;
@@ -223,7 +223,9 @@ static int icmpv6_push_pending_frames(st
icmp6h = (struct icmp6hdr*) skb-h.raw;
memcpy(icmp6h, thdr, sizeof(struct icmp6hdr));
- icmp6h-icmp6_cksum = 0;
+
+ if (!cksum_needed)
+ goto sendit;
if (skb_queue_len(sk-sk_write_queue) == 1) {
skb-csum = csum_partial((char *)icmp6h,
@@ -246,6 +248,7 @@ static int icmpv6_push_pending_frames(st
len, fl-proto, tmp_csum);
icmp6h-icmp6_cksum = tmp_csum;
}
+sendit:
ip6_push_pending_frames(sk);
out:
return err;
@@ -451,7 +454,7 @@ void icmpv6_send(struct sk_buff *skb, in
ip6_flush_pending_frames(sk);
goto out_put;
}
- err = icmpv6_push_pending_frames(sk, fl, tmp_hdr, len + sizeof(struct icmp6hdr));
+ err = icmpv6_push_pending_frames(sk, fl, tmp_hdr, len + sizeof(struct icmp6hdr), 1);
if (type = ICMPV6_DEST_UNREACH type = ICMPV6_PARAMPROB)
ICMP6_INC_STATS_OFFSET_BH(idev, ICMP6_MIB_OUTDESTUNREACHS, type - ICMPV6_DEST_UNREACH);
@@ -489,6 +492,14 @@ static void icmpv6_echo_reply(struct sk_
memcpy(tmp_hdr, icmph, sizeof(tmp_hdr));
tmp_hdr.icmp6_type = ICMPV6_ECHO_REPLY;
+ /*
+ * The only difference between echo requests and echo replies is the
+ * ICMPv6 type value (which is a difference of 1). So if we subtract
+ * one from the request checksum, it will result in the correct
+ * checksum for the reply.
+ */
+ tmp_hdr.icmp6_cksum--;
+
memset(fl, 0, sizeof(fl));
fl.proto = IPPROTO_ICMPV6;
ipv6_addr_copy(fl.fl6_dst, skb-nh.ipv6h-saddr);
@@ -540,7 +551,7 @@ static void icmpv6_echo_reply(struct sk_
ip6_flush_pending_frames(sk);
goto out_put;
}
- err = icmpv6_push_pending_frames(sk, fl, tmp_hdr, skb-len + sizeof(struct icmp6hdr));
+ err = icmpv6_push_pending_frames(sk, fl, tmp_hdr, skb-len + sizeof(struct icmp6hdr), 0);
ICMP6_INC_STATS_BH(idev, ICMP6_MIB_OUTECHOREPLIES);
ICMP6_INC_STATS_BH(idev, ICMP6_MIB_OUTMSGS);
Re: Generic Netlink HOW-TO based on Jamal's original doc
On Fri, 10 Nov 2006 11:17:11 -0500 Paul Moore wrote: jamal wrote: On Fri, 2006-10-11 at 01:45 -0500, Paul Moore wrote: James Morris wrote: An Introduction To Using Generic Netlink === Wow, this is great! Thanks. I consider it an act of penance for all of the evil things I did with Netlink on my first few iterations of NetLabel ;) Hey, theres more than one way to pay for your sins ;- For example: Do you wanna take over maintainance of the doc? ;- There is a sucker born every minute. right? :) I'll make you a deal: I'll take over maintainance of the document as long as you promise to send me your feedback by Monday. Jamal, Were my patches ever merged into your document? i.e it would make a lot of sense to finally submit it for inclusion. Thanks for the effort. I think so too, I'm glad I was able to help out. I havent read it - dont have the time till this weekend. I would like to have input as well from the other folks who have opined in the past (on CC list - they seemed to have strong opinions of what should be in the doc). This is also timely because this weekend i was going to work on a presentation on this stuff for a conference ;- So i will actually have to read what you put together. I will have more comments later when i am done reading. Okay, I've already made some changes based on other comments in this thread but I'll refrain from pushing out an updated version until early next week. I'll also make the next version of the document a patch against net-2.6.20. --- ~Randy - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Questions regarding network drivers
--- Evgeniy Polyakov [EMAIL PROTECTED] wrote: On Thu, Nov 09, 2006 at 07:06:00PM -0800, Jonathan Day ([EMAIL PROTECTED]) wrote: Hi, I've got an interesting problem to contend with and need some advice from the great wise ones here. First of all, is it possible (and/or reasonable practice) when developing a network driver to do zero-copy transfers between main memory and the network device? What do you mean? DMA from NIC memory into CPU memory? Yes. I want to bypass the kernel altogether and think there may be a way to do this, but want to make very certain that I'm not going down the wrong track. The underlying problem is this. The group I'm working with is messing about with building their own networking device that will run at an equal speed to the bus leading to the host (2.5 gigabits/second). The device has its own DMA controller and can operate as bus master. It's my task to figure out how to get the data into the host at near-100% bandwidth without dropping anything, with minimal latency and real-time characteristics. (I talked them out of making me do this blindfolded, but on further consideration, I'm not sure if this was a good idea.) Secondly, the network device is only designed to work with short packets and I really want to keep the throughput up. My thought was that if I fired off an interrupt then transfer a page of data into an area I know is safe, the kernel will have enough time to find a new safe area and post the address before the next page is ready to send. Can anyone suggest why this wouldn't work or, assuming it can work, why this would be a Bad Idea? There should not be any kind of 'kernel will have enough time to do something', instead you must guarantee that there will not be any kind of races. You can either prealocate several buffers or allocate them on demand in interrupts. The exact process I was thinking of is as follows: 1. Driver sets up a full page and pins it. 2. Driver obtains the physical address and places that address into a known, fixed location. 3. Driver sends interrupt to network device to say that everything is ready. 4. On obtaining the interrupt, a bit is set to true on the network device, to say that the host is ready to receive. 5. The network device has a counter for the number of packets that can be put in one page. If this number is zero and the bit is set, then: 5.1 The counter is set to the maximum number of packets storeable in the page. 5.2 The page address is DMAed out of the known location in host memory and placed in network device memory. 5.3 The bit is cleared. 5.4 The driver is given an interrupt to tell it to prepare the next page. 5.5 If the sender had previously been told to stop transmitting, it is now told to continue. 6. Every received packet is placed in a ring buffer on the network device. 7. The counter is reduced by 1. 8. If the counter reaches zero, OR the packet is followed by an end-of-transmission notification: 8.1. The ring buffer is DMAed en-masse into host memory at the location given in the previously cached page address. 8.2. If the new page bit has not been set to true, the network device notifies the sender to pause. The idea is that we're DMAing to a page that we know is safe, because the driver has ensured that before telling the network device where it is. (ie: the driver ensures that the page actually does exist, has been fuly set up in the VMM, and isn't going to move in physical memory or into swap.) The above description could be enhanced by having two or more available pages, so that it could rapidly switch. The only requirement for a sustainable system would be that I could allocate and make safe pages at an average rate equal to or faster than they would be consumed. The xon/xoff-type control would then be simply a way of guaranteeing that the network device didn't run out of places to put things. The people working on the hardware have said that they can handle the hardware side of my description, but I want to make sure that (a) this will actually work the way I expect, and (b) there isn't something staring me in the face that's a billion times easier and a trillion times more efficient. What I'm looking for is every argument that can possibly be thrown against this method - latency, throughput, accepted standards for Linux drivers, excessive weirdness, whatever. Lastly, assuming my sanity lasts that long, would I be correct in assuming that the first step in the process of getting the driver peer-reviewed and accepted would be to post the patches here? Actually not, the first step in that process is learning jig dance and of course providing enough beer and other goodies to network maintainers. I tried doing a jig dance once, but the saw cut my shoes in half. I can try getting beer. Oregon has some acceptable microbreweries, but I miss having a pint of Hatters in England. Mead is easier. I brew mead.
Re: Generic Netlink HOW-TO based on Jamal's original doc
* Jarek Poplawski [EMAIL PROTECTED] 2006-11-10 14:24
@@ -449,7 +449,7 @@
The second step is to define the operations for the family, which we do by
creating at least one instance of the genl_ops structure which we explained
in
-section 3.1.2.. In this example we are only going to define one operation
but
+section 3.1.2. In this example we are only going to define one operation but
you can define up to 255 unique operations for each family.
/* handler */
@@ -465,7 +465,7 @@
DOC_EXMPL_C_ECHO,
__DOC_EXMPL_C_ECHO,
Careful, the typo is here, not below.
};
- #define DOC_EXMPL_C_MAX (__DOC_EXMPL_C_MAX - 1)
+ #define DOC_EXMPL_C_MAX (__DOC_EXMPL_C_ECHO - 1)
/* operation definition */
struct genl_ops doc_exmpl_gnl_ops_echo = {
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] [NET]: Supporting UDP-Lite (RFC 3828) in Linux
On Fri, 10 Nov 2006 16:09:20 + Gerrit Renker [EMAIL PROTECTED] wrote: [NET/IPv4]: Support for the UDP-Lite protocol (RFC 3828) This adds support for UDP-Lite to the IPv4 stack, provided as an extension to the existing UDPv4 code: * generic routines are all located in net/ipv4/udp.c * UDP-Lite specific routines are in net/ipv4/udplite.c * MIB/statistics support in /proc/net/snmp and /proc/net/udplite * shared API with extensions for partial checksum coverage * consolidation of shared code This code is does too much inlining (like existing network code). Should it be made configurable? -- Stephen Hemminger [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [IPROUTE2] Add rule notification support to ip monitor
applied thanks - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Spidernet - remove ETH_ZLEN check in earlier patch
Subject: Spidernet - remove ETH_ZLEN check in earlier patch
From: James K Lewis [EMAIL PROTECTED]
In an earlier patch, code was added to pad packets that were less that
ETH_ZLEN (60) bytes using the skb_pad function. This has caused hangs
when accessing certain NFS mounted file systems. This patch removes the
check and solves the NFS problem. The driver, with this patch, has been
tested extensively. Please apply.
Signed-off-by: James K Lewis [EMAIL PROTECTED]
---
drivers/net/spider_net.c | 17 -
drivers/net/spider_net.h |2 +-
2 files changed, 5 insertions(+), 14 deletions(-)
Index: linux-2.6.18/drivers/net/spider_net.c
===
--- linux-2.6.18.orig/drivers/net/spider_net.c 2006-11-04
13:04:32.0 -0600
+++ linux-2.6.18/drivers/net/spider_net.c 2006-11-04 13:10:00.0
-0600
@@ -610,20 +610,12 @@ spider_net_prepare_tx_descr(struct spide
struct spider_net_descr *descr;
dma_addr_t buf;
unsigned long flags;
- int length;
- length = skb-len;
- if (length ETH_ZLEN) {
- if (skb_pad(skb, ETH_ZLEN-length))
- return 0;
- length = ETH_ZLEN;
- }
-
- buf = pci_map_single(card-pdev, skb-data, length, PCI_DMA_TODEVICE);
+ buf = pci_map_single(card-pdev, skb-data, skb-len,
PCI_DMA_TODEVICE);
if (pci_dma_mapping_error(buf)) {
if (netif_msg_tx_err(card) net_ratelimit())
pr_err(could not iommu-map packet (%p, %i).
- Dropping packet\n, skb-data, length);
+ Dropping packet\n, skb-data, skb-len);
card-spider_stats.tx_iommu_map_error++;
return -ENOMEM;
}
@@ -633,7 +625,7 @@ spider_net_prepare_tx_descr(struct spide
card-tx_chain.head = descr-next;
descr-buf_addr = buf;
- descr-buf_size = length;
+ descr-buf_size = skb-len;
descr-next_descr_addr = 0;
descr-skb = skb;
descr-data_status = 0;
@@ -768,8 +760,7 @@ spider_net_release_tx_chain(struct spide
/* unmap the skb */
if (skb) {
- int len = skb-len ETH_ZLEN ? ETH_ZLEN : skb-len;
- pci_unmap_single(card-pdev, buf_addr, len,
PCI_DMA_TODEVICE);
+ pci_unmap_single(card-pdev, buf_addr, skb-len,
PCI_DMA_TODEVICE);
dev_kfree_skb(skb);
}
}
Index: linux-2.6.18/drivers/net/spider_net.h
===
--- linux-2.6.18.orig/drivers/net/spider_net.h 2006-11-04
13:03:58.0 -0600
+++ linux-2.6.18/drivers/net/spider_net.h 2006-11-04 13:06:11.0
-0600
@@ -24,7 +24,7 @@
#ifndef _SPIDER_NET_H
#define _SPIDER_NET_H
-#define VERSION 1.1 A
+#define VERSION 1.5 A
#include sungem_phy.h
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IPv6: optimize echo reply checksum calculation
Al Viro wrote: On Fri, Nov 10, 2006 at 11:25:53AM -0500, Brian Haley wrote: Since the only difference between echo requests and echo replies is the ICMPv6 type value (which is a difference of 1), just subtracting one from the request checksum will result in the correct checksum for the reply. Um, no. That will *not* result in correct checksum. Please, RTFRFC 1071. I verified this works for echo request/reply on my IA64 box, double-checked with ethereal/wireshark. Is there something specific in RFC 1071 that I should be looking for? -Brian - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IPv6: only modify checksum for UDP
Sorry, I saw this discussion a little late... The Internet checksum is defined as a 1's-complement sum, so if the alternate 0 does not have a special meaning in a protocol, then by 1's-complement arithmetic, 0 == ~0. So, it looks to me without the remapping that a valid checksum may also fail, if it is simply computed in a different way (or on a different architecture) such that one gets 0 and one gets ~0 as un-modified answers. Since we're checking for equality on 2's-complement machines, I think the easiest thing is to still re-map it. Otherwise, instead of testing for 0, we have to test for both 0 and ~0 in the validity checks, right? Disclaimer: I've just glanced through the discussion, so maybe I've misunderstood the point or effect of the patch... +-DLS - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Questions regarding network drivers
On Fri, 10 Nov 2006 09:34:33 -0800 (PST) Jonathan Day [EMAIL PROTECTED] wrote: --- Evgeniy Polyakov [EMAIL PROTECTED] wrote: On Thu, Nov 09, 2006 at 07:06:00PM -0800, Jonathan Day ([EMAIL PROTECTED]) wrote: Hi, I've got an interesting problem to contend with and need some advice from the great wise ones here. First of all, is it possible (and/or reasonable practice) when developing a network driver to do zero-copy transfers between main memory and the network device? What do you mean? DMA from NIC memory into CPU memory? Yes. I want to bypass the kernel altogether and think there may be a way to do this, but want to make very certain that I'm not going down the wrong track. This is not normally possible because network data could be intended for multiple sockets. It is not possible to know where to DMA the data to until you have done all the necessary protocol demultiplexing and filtering. There has been talk of having really smart hardware to help. The underlying problem is this. The group I'm working with is messing about with building their own networking device that will run at an equal speed to the bus leading to the host (2.5 gigabits/second). The device has its own DMA controller and can operate as bus master. It's my task to figure out how to get the data into the host at near-100% bandwidth without dropping anything, with minimal latency and real-time characteristics. You might want to look at RDMA Infiniband model. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IPv6: optimize echo reply checksum calculation
On Fri, Nov 10, 2006 at 12:51:19PM -0500, Brian Haley wrote: Al Viro wrote: On Fri, Nov 10, 2006 at 11:25:53AM -0500, Brian Haley wrote: Since the only difference between echo requests and echo replies is the ICMPv6 type value (which is a difference of 1), just subtracting one from the request checksum will result in the correct checksum for the reply. Um, no. That will *not* result in correct checksum. Please, RTFRFC 1071. I verified this works for echo request/reply on my IA64 box, double-checked with ethereal/wireshark. Is there something specific in RFC 1071 that I should be looking for? Definition of checksum. See also include/net/ip.h::ip_decrease_ttl() for similar situation. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Spidernet - remove ETH_ZLEN check in earlier patch
On Fri, 10 Nov 2006 11:50:46 -0600 Jim Lewis [EMAIL PROTECTED] wrote: Subject: Spidernet - remove ETH_ZLEN check in earlier patch From: James K Lewis [EMAIL PROTECTED] In an earlier patch, code was added to pad packets that were less that ETH_ZLEN (60) bytes using the skb_pad function. This has caused hangs when accessing certain NFS mounted file systems. This patch removes the check and solves the NFS problem. The driver, with this patch, has been tested extensively. Please apply. Signed-off-by: James K Lewis [EMAIL PROTECTED] Does the hardware do padding for you? The padding is important for the Ethernet spec, and for security reasons (random memory leakage). -- Stephen Hemminger [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IPv6: optimize echo reply checksum calculation
On Fri, Nov 10, 2006 at 06:05:34PM +, Al Viro wrote: On Fri, Nov 10, 2006 at 12:51:19PM -0500, Brian Haley wrote: Al Viro wrote: On Fri, Nov 10, 2006 at 11:25:53AM -0500, Brian Haley wrote: Since the only difference between echo requests and echo replies is the ICMPv6 type value (which is a difference of 1), just subtracting one from the request checksum will result in the correct checksum for the reply. Um, no. That will *not* result in correct checksum. Please, RTFRFC 1071. I verified this works for echo request/reply on my IA64 box, double-checked with ethereal/wireshark. Is there something specific in RFC 1071 that I should be looking for? Definition of checksum. See also include/net/ip.h::ip_decrease_ttl() for similar situation. Note that even on little-endian you want 3 - 2 2 - 1 1 - 0x 0 - 0xfffe On big-endian you get 0x102 - 2 0x101 - 1 0x100 - 0x 0xff - 0xfffe ... 0 - 0xfeff so -= 1 is broken even on ia64 and it's *always* broken on big-endian boxen. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Generic Netlink HOW-TO based on Jamal's original doc
On Fri, 10 Nov 2006 01:08:23 -0500 Paul Moore wrote:
An Introduction To Using Generic Netlink
===
3.1.2. The genl_family Structure
Generic Netlink services are defined by the genl_family structure, which is
shown below:
struct genl_family
{
unsigned intid;
unsigned inthdrsize;
charname[GENL_NAMSIZ];
unsigned intversion;
unsigned intmaxattr;
struct nlattr **attrbuf;
struct list_headops_list;
struct list_headfamily_list;
};
Any alignment/packing concerns here? or that is already
handled, just not presented here?
and same questions for other structs below (deleted).
Typo patch attached.
---
~Randy
--- generic-netlink-howto.txt.~1~ 2006-11-10 09:35:03.0 -0800
+++ generic-netlink-howto.txt 2006-11-10 10:21:10.0 -0800
@@ -40,7 +40,7 @@
kernel source code is your best friend here.
While this document talks briefly about Generic Netlink from a userspace point
-of view it's primary focus is on the kernel's Generic Netlink API. It is
+of view, its primary focus is on the kernel's Generic Netlink API. It is
recommended that application developers who are interested in using Generic
Netlink make use of the libnl library[1].
@@ -141,17 +141,17 @@
--
The Generic Netlink mechanism is based on a client-server model. The Generic
-Netlink servers register families, which are a collection of well defined
+Netlink servers register families, which are a collection of well-defined
services, with the controller and the clients communicate with the server
through these service registrations. This section explains how Generic Netlink
-families are defined, created and registered.
+families are defined, created, and registered.
3.1. Family Overview
--
Generic Netlink family service registrations are defined by two structures,
genl_family and genl_ops. The genl_family structure defines the family and
-it's associated communication channel. The genl_ops structure defines
+its associated communication channel. The genl_ops structure defines
an individual service or operation which the family provides to other Generic
Netlink users.
@@ -191,7 +191,7 @@
* unsigned int hdrsize
- If the family makes use of a family specific header, it's size is stored
+ If the family makes use of a family specific header, its size is stored
here. If there is no family specific header this value should be zero.
* char name[GENL_NAMSIZ]
@@ -278,19 +278,19 @@
o NLA_U8
- A 8 bit unsigned integer
+ A 8-bit unsigned integer
o NLA_U16
- A 16 bit unsigned integer
+ A 16-bit unsigned integer
o NLA_U32
- A 32 bit unsigned integer
+ A 32-bit unsigned integer
o NLA_U64
- A 64 bit unsigned integer
+ A 64-bit unsigned integer
o NLA_FLAG
@@ -298,7 +298,7 @@
o NLA_MSECS
- A 64 bit time value in msecs
+ A 64-bit time value in msecs
o NLA_STRING
@@ -319,7 +319,7 @@
NULL byte. If the attribute type is unknown or NLA_UNSPEC then this field
should be set to the exact length of the attribute's payload.
- Unless the attribute type is one of the fixed length types above, a value
+ Unless the attribute type is one of the fixed-length types above, a value
of zero indicates that no validation of the attribute should be performed.
* int (*doit)(struct skbuff *skb, struct genl_info *info)
@@ -331,7 +331,7 @@
which triggered the handler and the second is a Generic Netlink genl_info
structure which is defined in figure #5.
- struct genl_ops
+ struct genl_info
{
u32 snd_seq;
u32 snd_pid;
@@ -449,7 +449,7 @@
The second step is to define the operations for the family, which we do by
creating at least one instance of the genl_ops structure which we explained in
-section 3.1.2.. In this example we are only going to define one operation but
+section 3.1.2. In this example we are only going to define one operation but
you can define up to 255 unique operations for each family.
/* handler */
@@ -659,19 +659,19 @@
* scalar values
- Most scalar values already have well defined attribute types, see section 3
- for details
+ Most scalar values already have well-defined attribute types; see section 3
+ for details.
* structures
Structures can be represented using a nested attribute with the structure
- fields represented as attributes in the payload of the container attribute
+ fields represented as attributes in the payload of the container
[PATCH] spidernet: fix transmit routine.
Try this patch instead (I don't have the hardware to even build).
Fix spider_net transmit routine:
1. use skb_padto properly
2. don't return -ENOMEM. Only valid returns from device transmit
routine are NETDEV_TX_OK, BUSY, LOCKED
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
drivers/net/spider_net.c | 20
1 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/net/spider_net.c b/drivers/net/spider_net.c
index 418138d..cd7f13c 100644
--- a/drivers/net/spider_net.c
+++ b/drivers/net/spider_net.c
@@ -644,22 +644,18 @@ spider_net_prepare_tx_descr(struct spide
struct spider_net_descr *descr;
dma_addr_t buf;
unsigned long flags;
- int length;
- length = skb-len;
- if (length ETH_ZLEN) {
- if (skb_pad(skb, ETH_ZLEN-length))
- return 0;
- length = ETH_ZLEN;
- }
+ if (skb_padto(skb, ETH_ZLEN))
+ return NETDEV_TX_OK;
- buf = pci_map_single(card-pdev, skb-data, length, PCI_DMA_TODEVICE);
+ buf = pci_map_single(card-pdev, skb-data, skb-len, PCI_DMA_TODEVICE);
if (pci_dma_mapping_error(buf)) {
if (netif_msg_tx_err(card) net_ratelimit())
pr_err(could not iommu-map packet (%p, %i).
- Dropping packet\n, skb-data, length);
+ Dropping packet\n, skb-data, skb-len);
card-spider_stats.tx_iommu_map_error++;
- return -ENOMEM;
+ dev_kfree_skb(skb);
+ return NETDEV_TX_OK;
}
spin_lock_irqsave(card-tx_chain.lock, flags);
@@ -667,7 +663,7 @@ spider_net_prepare_tx_descr(struct spide
card-tx_chain.head = descr-next;
descr-buf_addr = buf;
- descr-buf_size = length;
+ descr-buf_size = skb-len;
descr-next_descr_addr = 0;
descr-skb = skb;
descr-data_status = 0;
@@ -690,7 +686,7 @@ spider_net_prepare_tx_descr(struct spide
descr-prev-next_descr_addr = descr-bus_addr;
card-netdev-trans_start = jiffies; /* set netdev watchdog timer */
- return 0;
+ return NETDEV_TX_OK;
}
static int
--
1.4.1
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IPv6: optimize echo reply checksum calculation
Al Viro wrote: so -= 1 is broken even on ia64 and it's *always* broken on big-endian boxen. It's not broken in ia64, I've tested that, just don't have an x86 for testing right now. Can you please apply these changes and prove it's broken? This little trick has been done in other UNIXes for years without any problems. -Brian - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IPv6: optimize echo reply checksum calculation
On Fri, Nov 10, 2006 at 02:04:32PM -0500, Brian Haley wrote: Al Viro wrote: so -= 1 is broken even on ia64 and it's *always* broken on big-endian boxen. It's not broken in ia64, I've tested that, just don't have an x86 for testing right now. Can you please apply these changes and prove it's broken? This little trick has been done in other UNIXes for years without any problems. Could you fscking read what you've replied to? Your -=1 will turn 0 into 0x instead of correct 0xfffe. IOW, it's broken in 1:65536 cases. On big-endian boxen (which x86 is not, BTW), it will *always* give the wrong result. -= htons(0x100) is better, but still fscks up in 1:256. You _can_ adjust the checksum; however it's not that trivial. One working variant is if (sum htons(0x100) sum -= htons(0x100); else sum += 0x - htons(0x100); In little-endian case it turns into if (sum 1) sum--; else sum += 0xfffe; which is why your variant breaks rarely on itanic (or x86 - they are not different in that respect). You still need to handle that corner case, though. As for the various Unices doing the same trick, I suggest you to check what they _really_ do and report bugs for those that have pure -- and nothing else. Again, the checksum is sum modulo 0x, *not* 0x1. And endianness matters, of course, since the packet type is either LSB or MSB, depending on it. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] spidernet: fix transmit routine.
On Fri, 10 Nov 2006 13:10:25 -0600 James K Lewis [EMAIL PROTECTED] wrote: Stephen, I had already tried that previously, the fail still occurred. Note that the skb_pad (or skb_padto) never actually fails. There is just something about calling it that causes the hang. Note too that I believe your patch is incorrect, you would still have to pci_unmap_single the correct length (skb_pad does not actually change skb-len which just seems plain wrong to me). Yeah, that was a bad choice not to set skb-len to start with. Too late now given how it might affect other drivers. I checked, and none of our mainstream PPC ethernet drivers (e100, e1000, pcnet32, tg3) have this check in them. When I have time I may add the pad to pcnet32 (for example) to see if it fails. The hardware for all these drivers does padding. Jim Lewis Advisory Software Engineer IBM Linux Technology Center 512-838-7754 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[git patches] net driver fixes
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
drivers/net/arcnet/com20020.c |7 +--
drivers/net/bonding/bond_main.c |5 +
drivers/net/cris/eth_v10.c |2 ++
drivers/net/wireless/bcm43xx/bcm43xx_main.c | 22 --
4 files changed, 32 insertions(+), 4 deletions(-)
Adrian Bunk:
bcm43xx: Add error checking in bcm43xx_sprom_write()
David Rientjes:
drivers cris: return on NULL dev_alloc_skb()
Michael Buesch:
bcm43xx: Drain TX status before starting IRQs
Peter Zijlstra:
bonding: lockdep annotation
Randy Dunlap:
com20020 build fix
diff --git a/drivers/net/arcnet/com20020.c b/drivers/net/arcnet/com20020.c
index 0dc70c7..aa9dd8f 100644
--- a/drivers/net/arcnet/com20020.c
+++ b/drivers/net/arcnet/com20020.c
@@ -337,13 +337,16 @@ static void com20020_set_mc_list(struct
}
}
-#ifdef MODULE
-
+#if defined(CONFIG_ARCNET_COM20020_PCI_MODULE) || \
+defined(CONFIG_ARCNET_COM20020_ISA_MODULE)
EXPORT_SYMBOL(com20020_check);
EXPORT_SYMBOL(com20020_found);
+#endif
MODULE_LICENSE(GPL);
+#ifdef MODULE
+
int init_module(void)
{
BUGLVL(D_NORMAL) printk(VERSION);
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index c0bbdda..17a4611 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -4692,6 +4692,8 @@ static int bond_check_params(struct bond
return 0;
}
+static struct lock_class_key bonding_netdev_xmit_lock_key;
+
/* Create a new bond based on the specified name and bonding parameters.
* Caller must NOT hold rtnl_lock; we need to release it here before we
* set up our sysfs entries.
@@ -4727,6 +4729,9 @@ int bond_create(char *name, struct bond_
if (res 0) {
goto out_bond;
}
+
+ lockdep_set_class(bond_dev-_xmit_lock, bonding_netdev_xmit_lock_key);
+
if (newbond)
*newbond = bond_dev-priv;
diff --git a/drivers/net/cris/eth_v10.c b/drivers/net/cris/eth_v10.c
index 966b563..a03d781 100644
--- a/drivers/net/cris/eth_v10.c
+++ b/drivers/net/cris/eth_v10.c
@@ -509,6 +509,8 @@ etrax_ethernet_init(void)
* does not share cacheline with any other data (to avoid cache
bug)
*/
RxDescList[i].skb = dev_alloc_skb(MAX_MEDIA_DATA_SIZE + 2 *
L1_CACHE_BYTES);
+ if (!RxDescList[i].skb)
+ return -ENOMEM;
RxDescList[i].descr.ctrl = 0;
RxDescList[i].descr.sw_len = MAX_MEDIA_DATA_SIZE;
RxDescList[i].descr.next = virt_to_phys(RxDescList[i + 1]);
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
index 65edb56..a1b7838 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -746,7 +746,7 @@ int bcm43xx_sprom_write(struct bcm43xx_p
if (err)
goto err_ctlreg;
spromctl |= 0x10; /* SPROM WRITE enable. */
- bcm43xx_pci_write_config32(bcm, BCM43xx_PCICFG_SPROMCTL, spromctl);
+ err = bcm43xx_pci_write_config32(bcm, BCM43xx_PCICFG_SPROMCTL,
spromctl);
if (err)
goto err_ctlreg;
/* We must burn lots of CPU cycles here, but that does not
@@ -768,7 +768,7 @@ int bcm43xx_sprom_write(struct bcm43xx_p
mdelay(20);
}
spromctl = ~0x10; /* SPROM WRITE enable. */
- bcm43xx_pci_write_config32(bcm, BCM43xx_PCICFG_SPROMCTL, spromctl);
+ err = bcm43xx_pci_write_config32(bcm, BCM43xx_PCICFG_SPROMCTL,
spromctl);
if (err)
goto err_ctlreg;
mdelay(500);
@@ -1463,6 +1463,23 @@ static void handle_irq_transmit_status(s
}
}
+static void drain_txstatus_queue(struct bcm43xx_private *bcm)
+{
+ u32 dummy;
+
+ if (bcm-current_core-rev 5)
+ return;
+ /* Read all entries from the microcode TXstatus FIFO
+* and throw them away.
+*/
+ while (1) {
+ dummy = bcm43xx_read32(bcm, BCM43xx_MMIO_XMITSTAT_0);
+ if (!dummy)
+ break;
+ dummy = bcm43xx_read32(bcm, BCM43xx_MMIO_XMITSTAT_1);
+ }
+}
+
static void bcm43xx_generate_noise_sample(struct bcm43xx_private *bcm)
{
bcm43xx_shm_write16(bcm, BCM43xx_SHM_SHARED, 0x408, 0x7F7F);
@@ -3532,6 +3549,7 @@ int bcm43xx_select_wireless_core(struct
bcm43xx_macfilter_clear(bcm, BCM43xx_MACFILTER_ASSOC);
bcm43xx_macfilter_set(bcm, BCM43xx_MACFILTER_SELF, (u8
*)(bcm-net_dev-dev_addr));
bcm43xx_security_init(bcm);
+ drain_txstatus_queue(bcm);
ieee80211softmac_start(bcm-net_dev);
/* Let's go! Be careful after enabling the IRQs.
-
To unsubscribe from this list: send the line
Re: [PATCH] dccp: remove module exit functions
On 11/10/06, James Morris [EMAIL PROTECTED] wrote: The dccp ipv4 ipv6 modules cannot be unloaded, as their control sockets each maintain a couple of module references. So, it seems like a good idea to just remove the module exit functions completely. Please review. Well, I have a patch in the DCCP backlog that uses it, ressurecting the unload hack, for development purposes being able to destroy the control sockets allowing module removal is something the DCCP developers want :) - Arnaldo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dccp: remove module exit functions
On Fri, 10 Nov 2006, Arnaldo Carvalho de Melo wrote: On 11/10/06, James Morris [EMAIL PROTECTED] wrote: The dccp ipv4 ipv6 modules cannot be unloaded, as their control sockets each maintain a couple of module references. So, it seems like a good idea to just remove the module exit functions completely. Please review. Well, I have a patch in the DCCP backlog that uses it, ressurecting the unload hack, for development purposes being able to destroy the control sockets allowing module removal is something the DCCP developers want :) I wonder if this facility can be integrated more generally into the kernel protocol which people are developing. Where is the patch you use? - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dccp: remove module exit functions
On Fri, 10 Nov 2006, James Morris wrote: I wonder if this facility can be integrated more generally into the kernel protocol which people are developing. Ugh, editor screwup. That was meant to be I wonder if this facility can be integrated more generally into the kernel as a kernel hacking option, as this is not the only protocol which people are developing. Where is the patch you use? - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dccp: remove module exit functions
On 11/10/06, James Morris [EMAIL PROTECTED] wrote: On Fri, 10 Nov 2006, James Morris wrote: I wonder if this facility can be integrated more generally into the kernel protocol which people are developing. Ugh, editor screwup. That was meant to be I wonder if this facility can be integrated more generally into the kernel as a kernel hacking option, as this is not the only protocol which people are developing. See: http://www.erg.abdn.ac.uk/users/gerrit/dccp/patch-backlog/09a_release_ctl_socket_at_exit.diff This one requires a bit more thinking, so I'm postponing it for now to get the simple bits in Gerrit's patch queue cherrypicked and sent for Dave. - Arnaldo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Generic Netlink HOW-TO based on Jamal's original doc
Randy Dunlap wrote:
On Fri, 10 Nov 2006 01:08:23 -0500 Paul Moore wrote:
An Introduction To Using Generic Netlink
===
3.1.2. The genl_family Structure
Generic Netlink services are defined by the genl_family structure, which is
shown below:
struct genl_family
{
unsigned intid;
unsigned inthdrsize;
charname[GENL_NAMSIZ];
unsigned intversion;
unsigned intmaxattr;
struct nlattr **attrbuf;
struct list_headops_list;
struct list_headfamily_list;
};
Any alignment/packing concerns here? or that is already
handled, just not presented here?
and same questions for other structs below (deleted).
These structure contents/layout were taken straight from the code.
Typo patch attached.
Applied, thanks.
--
paul moore
linux security @ hp
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bcm43xx-d80211 broadcast reception with WPA
On Thursday 09 November 2006 23:23, Paul Hampson wrote: Hi, Long time lurker, first time poster. ^_^ I've been backporting the bcm43xx-d80211 driver to whatever the released 2.6 kernel was using the rt2x00 project's d80211 stack (equivalent to current wireless-dev but with a workaround for not having a ieee80211_dev pointer and still using the _tfm interface instead of the _cypher interface.) As of last night's wireless-dev tree bcm43xx, everything seems to be operating fine except incoming broadcast traffic is coming in 14 bytes too long and scrambled. I presume this means it's not decrypting properly... It sounds like a bug in the hardware decryption setup. Are you using TKIP or not? Incoming mcast frames are handled in a special way in hardware. The keyidx field of the packet is used to lookup the key, as far as I know. (Otherwise the MAC address is used). Can I see a full dmesg log and a capture log on the broken machine, please? -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFT] mv643xxx_eth_start_xmit oops
Stephen Hemminger [EMAIL PROTECTED] :
[...]
diff --git a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c
index 9997081..4052bfe 100644
--- a/drivers/net/mv643xx_eth.c
+++ b/drivers/net/mv643xx_eth.c
@@ -1191,25 +1191,23 @@ static int mv643xx_eth_start_xmit(struct
struct net_device_stats *stats = mp-stats;
unsigned long flags;
- BUG_ON(netif_queue_stopped(dev));
- BUG_ON(skb == NULL);
-
- if (mp-tx_ring_size - mp-tx_desc_count MAX_DESCS_PER_SKB) {
- printk(KERN_ERR %s: transmit with queue full\n, dev-name);
- netif_stop_queue(dev);
- return 1;
- }
-
- if (has_tiny_unaligned_frags(skb)) {
- if (__skb_linearize(skb)) {
- stats-tx_dropped++;
+ if (has_tiny_unaligned_frags(skb) __skb_linearize(skb)) {
+ stats-tx_dropped++;
+ if (net_ratelimit())
printk(KERN_DEBUG %s: failed to linearize tiny
- unaligned fragment\n, dev-name);
- return 1;
- }
+unaligned fragment\n, dev-name);
+ return NETDEV_TX_OK;
}
It seems to propagate a leak from the initial codebase.
--
Ueimor
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch sungem] improved locking
Yes, the bit 4 isn't used, but I assumed clearing it shouldn't be prolem. Always leave reserved bits alone ... I agree it's very unlikely in this case that it could cause a problem but I've seen stranger things Ben. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch sungem] improved locking
From: Eric Lemoine [EMAIL PROTECTED]
Date: Fri, 10 Nov 2006 14:28:41 +0100
On 11/10/06, David Miller [EMAIL PROTECTED] wrote:
Please use GREG_STAT_* instead of magic constants for the
interrupt mask and ACK register writes. In fact, there are
some questionable values you use, in particular this one:
+static inline void gem_ack_int(struct gem *gp)
+{
+ writel(0x3f, gp-regs + GREG_IACK);
+}
This code clears bits 0 through 6, which GREG_IACK is for.
There is no bit defined in GREG_STAT_* for 0x08, but you
set it in this magic bitmask. It is another reason not
to use magic constants like this :-)
Yes, the bit 4 isn't used, but I assumed clearing it shouldn't be prolem.
Would you prefer that:
#define GREG_STAT_IACK 0x3f
static inline void gem_ack_int(struct gem *gp)
{
writel(GREG_STAT_IACK, gp-regs + GREG_IACK);
}
or that:
#define GREG_STAT_IACK (GREG_STAT_TXINTME | GREG_STAT_TXALL | \
GREG_STAT_RXDONE | GREG_STAT_RXNOBUF)
to avoid bit 4, and bit 3 (TX_DONE) which is masked.
Personnaly, I like the first way best.
I think the second way is better because it clearly states
your intentions. The GREG_STAT_IACK 0x3f macro is still
magic because it doesn't say what the bits actually mean.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 1/9] bonding: lockdep annotation
From: Jeff Garzik [EMAIL PROTECTED] Date: Fri, 10 Nov 2006 11:09:25 -0500 [EMAIL PROTECTED] wrote: From: Peter Zijlstra [EMAIL PROTECTED] = [ INFO: possible recursive locking detected ] 2.6.17-1.2600.fc6 #1 - applied; please CC me on this drivers/net stuff Jeff, I put this one in my net-2.6.20 tree already. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFT] mv643xxx_eth_start_xmit oops
In article [EMAIL PROTECTED] you write: Ueimor [EMAIL PROTECTED] wrote: Stephen Hemminger [EMAIL PROTECTED] : [...] diff --git a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c [...] It seems to propagate a leak from the initial codebase. Can you provide more detail about the leak? -Dale - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFT] mv643xxx_eth_start_xmit oops
Dale Farnsworth [EMAIL PROTECTED] :
[...]
Can you provide more detail about the leak?
+ if (has_tiny_unaligned_frags(skb) __skb_linearize(skb)) {
+ stats-tx_dropped++;
+ if (net_ratelimit())
+ printk(KERN_DEBUG %s: failed to linearize tiny
+ unaligned fragment\n, dev-name);
+ return NETDEV_TX_OK;
Missing kfree_skb(skb) before returning NETDEV_TX_OK ?
--
Ueimor
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFT] mv643xxx_eth_start_xmit oops
On Fri, 10 Nov 2006 22:03:43 +0100
Francois Romieu [EMAIL PROTECTED] wrote:
Dale Farnsworth [EMAIL PROTECTED] :
[...]
Can you provide more detail about the leak?
+ if (has_tiny_unaligned_frags(skb) __skb_linearize(skb)) {
+ stats-tx_dropped++;
+ if (net_ratelimit())
+ printk(KERN_DEBUG %s: failed to linearize tiny
+ unaligned fragment\n, dev-name);
+ return NETDEV_TX_OK;
Missing kfree_skb(skb) before returning NETDEV_TX_OK ?
skb_linearize is documented to free skb on failure.
--
Stephen Hemminger [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFT] mv643xxx_eth_start_xmit oops
Stephen Hemminger [EMAIL PROTECTED] : [...] skb_linearize is documented to free skb on failure. __skb_linearize - __pskb_pull_tail - pskb_expand_head [...] data = kmalloc(size + sizeof(struct skb_shared_info), gfp_mask); if (!data) goto nodata; [...] nodata: return -ENOMEM; I don't see where the skb is freed on this path. Btw, the same __skb_linearize() is followed by a kfree_skb() in drivers/net/via-velocity.c since 364c6badde0dd62a0a38e5ed67f85d87d6665780 I may be wrong but the source code does not seem completely right either. -- Ueimor - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFT] mv643xxx_eth_start_xmit oops
On Fri, 10 Nov 2006 22:30:43 +0100 Francois Romieu [EMAIL PROTECTED] wrote: Stephen Hemminger [EMAIL PROTECTED] : [...] skb_linearize is documented to free skb on failure. __skb_linearize - __pskb_pull_tail - pskb_expand_head [...] data = kmalloc(size + sizeof(struct skb_shared_info), gfp_mask); if (!data) goto nodata; [...] nodata: return -ENOMEM; I don't see where the skb is freed on this path. Btw, the same __skb_linearize() is followed by a kfree_skb() in drivers/net/via-velocity.c since 364c6badde0dd62a0a38e5ed67f85d87d6665780 I may be wrong but the source code does not seem completely right either. Your correct, it does leave the skb alone. so it would be a leak. Better documentation in skb_linearize would help. -- Stephen Hemminger [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IPv6: optimize echo reply checksum calculation
Al Viro wrote: On Fri, Nov 10, 2006 at 02:04:32PM -0500, Brian Haley wrote: Al Viro wrote: so -= 1 is broken even on ia64 and it's *always* broken on big-endian boxen. It's not broken in ia64, I've tested that, just don't have an x86 for testing right now. Can you please apply these changes and prove it's broken? This little trick has been done in other UNIXes for years without any problems. Could you fscking read what you've replied to? Your -=1 will turn 0 into 0x instead of correct 0xfffe. IOW, it's broken in 1:65536 cases. I looked again at your previous email: Note that even on little-endian you want 3 - 2 2 - 1 1 - 0x 0 - 0xfffe That doesn't look right to me, but I'll take your word that there's one edge case out there I don't see (even though this worked on Alpha). Forget about the patch then. -Brian - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[NET] Update documentation of skb_linearize
The data is not released.
drivers/net/mv643xx_eth.c apart, each current caller issues
kfree_skb() when required.
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 85577a4..380e344 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1235,7 +1235,7 @@ static inline int __skb_linearize(struct
* @skb: buffer to linarize
*
* If there is no free memory -ENOMEM is returned, otherwise zero
- * is returned and the old skb data released.
+ * is returned.
*/
static inline int skb_linearize(struct sk_buff *skb)
{
@@ -1247,7 +1247,7 @@ static inline int skb_linearize(struct s
* @skb: buffer to process
*
* If there is no free memory -ENOMEM is returned, otherwise zero
- * is returned and the old skb data released.
+ * is returned.
*/
static inline int skb_linearize_cow(struct sk_buff *skb)
{
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [TCP]: remove dead code in init_sequence
From: Gerrit Renker [EMAIL PROTECTED]
Date: Fri, 10 Nov 2006 12:04:31 +
This removes two redundancies:
1) The test (skb-protocol == htons(ETH_P_IPV6) in tcp_v6_init_sequence()
is always true, due to
* tcp_v6_conn_request() is the only function calling this one
* tcp_v6_conn_request() redirects all skb's with ETH_P_IP protocol to
tcp_v4_conn_request() [ cf. top of tcp_v6_conn_request()]
2) The first argument, `struct sock *sk' of tcp_v{4,6}_init_sequence() is
never used.
Patch has been tested.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
Looks good, patch applied, thanks Gerrit.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NETLINK]: Do precise netlink message allocations where possible
From: Paul Moore [EMAIL PROTECTED] Date: Fri, 10 Nov 2006 11:04:14 -0500 Thomas Graf wrote: Account for the netlink message header size directly in nlmsg_new() instead of relying on the caller calculate it correctly. Replaces error handling of message construction functions when constructing notifications with bug traps since a failure implies a bug in calculating the size of the skb. Signed-off-by: Thomas Graf [EMAIL PROTECTED] ... I like this approach, it makes much more sense to me then the previous implementation which was a simple alias to alloc_skb(). Also, the NetLabel relevant sections look fine to me. Acked-by: Paul Moore [EMAIL PROTECTED] I like it a lot too. Applied, thanks Thomas. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [IPv6] rules: Remove bogus tos validation check
From: Thomas Graf [EMAIL PROTECTED] Date: Fri, 10 Nov 2006 13:28:38 +0100 Noticed by Al Viro: (frh-tos ~IPV6_FLOWINFO_MASK)) where IPV6_FLOWINFO_MASK is htonl(0xfff) and frh-tos is u8, which makes no sense here... Signed-off-by: Thomas Graf [EMAIL PROTECTED] Applied, thanks a lot. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Generic Netlink HOW-TO based on Jamal's original doc
* Randy Dunlap [EMAIL PROTECTED] 2006-11-10 10:23
On Fri, 10 Nov 2006 01:08:23 -0500 Paul Moore wrote:
An Introduction To Using Generic Netlink
===
3.1.2. The genl_family Structure
Generic Netlink services are defined by the genl_family structure, which is
shown below:
struct genl_family
{
unsigned intid;
unsigned inthdrsize;
charname[GENL_NAMSIZ];
unsigned intversion;
unsigned intmaxattr;
struct nlattr **attrbuf;
struct list_headops_list;
struct list_headfamily_list;
};
Any alignment/packing concerns here? or that is already
handled, just not presented here?
I thought I chose GENL_NAMESIZ wisely but to be sure I checked
with Mr. Alignment himself, Arnaldo:
struct genl_family {
unsigned int id; /* 0(0) 4 */
unsigned int hdrsize; /* 4(0) 4 */
char name[16]; /* 8(0)16 */
unsigned int version; /* 24(0) 4 */
unsigned int maxattr; /* 28(0) 4 */
/* -- cacheline 1 boundary -- */
struct nlattr * * attrbuf; /* 32(0) 4 */
struct list_head ops_list; /* 36(0) 8 */
struct list_head family_list; /* 44(0) 8 */
}; /* size: 52 */
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NETLINK]: Do precise netlink message allocations where possible
* Paul Moore [EMAIL PROTECTED] 2006-11-10 11:04 I like this approach, it makes much more sense to me then the previous implementation which was a simple alias to alloc_skb(). Also, the NetLabel relevant sections look fine to me. Question is wheter to do the same for genetlink and add genlmsg_new(). I'm currently thinking about this and also about some _reply() function which takes a struct genl_info so a genetlink module doesn't have to know about how to address the client by pid anymore. Ideas or even patches very welcome. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re : Source address selection + multicast
Excuse me if I am bothering you again, but is there something so wrong
with what I point out, or is multicasting so boring, that it doesn't
even deserve an answer? :)
Please consider.
- Message d'origine
Preferred source address selection in the routing table (src field)
currently does not work properly with multicast destination adresses:
it leads packets to be routed through the wrong network device (see
http://bugzilla.kernel.org/show_bug.cgi?id=7398).
It seems to me that the main reason for this is compatibility with
old multicast applications, and I can see no fundamental reason
preventing the use of this two features together.
Why not finding a way to let them coexist?
What about a sysctl option, letting users who really want to disable
the compatibility hack, and restore normal behavior? I am thinking
about something like the patch below. Or does another simple way to
do it come to your mind?
What do you think about it?
diff -urNp linux-2.6.18/Documentation/filesystems/proc.txt
linux-2.6.18/Documentation/filesystems/proc.txt
--- linux-2.6.18/Documentation/filesystems/proc.txt 2006-09-19
20:42:06.0 -0700
+++ linux-2.6.18/Documentation/filesystems/proc.txt 2006-10-26
05:13:15.0 -0700
@@ -1758,6 +1758,15 @@ max_delay, min_delay
Delays for flushing the routing cache.
+mc_src_strict
+-
+
+There is a hack in the kernel router which provides compatibility for old
+multicast applications such as vic, vat and friends. Unfortunately, this
+hack also breaks normal behavior of preferred source address selection
+(iproute2 src field) with multicast and limited broadcast. Enabling this
+option disables this hack and restores normal (strict) behavior.
+
redirect_load, redirect_number
--
diff -urNp linux-2.6.18/include/linux/sysctl.h
linux-2.6.18/include/linux/sysctl.h
--- linux-2.6.18/include/linux/sysctl.h 2006-09-19 20:42:06.0 -0700
+++ linux-2.6.18/include/linux/sysctl.h 2006-10-26 04:25:00.0 -0700
@@ -433,6 +433,7 @@ enum {
NET_IPV4_ROUTE_MIN_ADVMSS=17,
NET_IPV4_ROUTE_SECRET_INTERVAL=18,
NET_IPV4_ROUTE_GC_MIN_INTERVAL_MS=19,
+ NET_IPV4_ROUTE_MC_SRC_STRICT=20,
};
enum
diff -urNp linux-2.6.18/net/ipv4/route.c linux-2.6.18/net/ipv4/route.c
--- linux-2.6.18/net/ipv4/route.c 2006-09-19 20:42:06.0 -0700
+++ linux-2.6.18/net/ipv4/route.c 2006-10-26 05:11:00.0 -0700
@@ -132,6 +132,7 @@ static int ip_rt_mtu_expires= 10 * 60
static int ip_rt_min_pmtu = 512 + 20 + 20;
static int ip_rt_min_advmss= 256;
static int ip_rt_secret_interval = 10 * 60 * HZ;
+static int ip_rt_mc_src_strict = 0;
static unsigned long rt_deadline;
#define RTprint(a...) printk(KERN_DEBUG a)
@@ -2416,7 +2417,7 @@ static int ip_route_output_slow(struct r
of another iface. --ANK
*/
- if (oldflp-oif == 0
+ if (!ip_rt_mc_src_strict oldflp-oif == 0
(MULTICAST(oldflp-fl4_dst) || oldflp-fl4_dst ==
0x)) {
/* Special hack: user can direct multicasts
and limited broadcast via necessary interface
@@ -2431,6 +2432,12 @@ static int ip_route_output_slow(struct r
cannot know, that ttl is zero, so that packet
will not leave this host and route is valid).
Luckily, this hack is good workaround.
+
+ Unfortunately, it also breaks normal behavior of
+ source address preference, so I added a sysctl option
+ to let the user disable this hack and restore normal
+ behavior. By default, the hack is still enabled (old
+ compatibility behavior). -- PY
*/
fl.oif = dev_out-ifindex;
@@ -3057,6 +3064,15 @@ ctl_table ipv4_route_table[] = {
.proc_handler = proc_dointvec_jiffies,
.strategy = sysctl_jiffies,
},
+ {
+ .ctl_name = NET_IPV4_ROUTE_MC_SRC_STRICT,
+ .procname = mc_src_strict,
+ .data = ip_rt_mc_src_strict,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = ipv4_doint_and_flush,
+ .strategy = ipv4_doint_and_flush_strategy,
+ },
{ .ctl_name = 0 }
};
#endif
--
Pierre Ynard
___
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions !
Profitez des connaissances, des opinions et des expériences des internautes sur
Yahoo! Questions/Réponses
http://fr.answers.yahoo.com
-
To unsubscribe
Re: [PATCH 1/3] [NET]: Supporting UDP-Lite (RFC 3828) in Linux
I can't apply any of this Gerrit. What makes net/ipv4/udplite.c get built at all? I see no changes to net/ipv4/Makefile, so you must have stuffed up the generation of your patches. Please resubmit all 3 patches once you've corrected this and actually _tested_ the patch you submitted. You know, because I might actually try to build what you send me :-) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] [NET]: Supporting UDP-Lite (RFC 3828) in Linux
From: Stephen Hemminger [EMAIL PROTECTED] Date: Fri, 10 Nov 2006 09:37:15 -0800 On Fri, 10 Nov 2006 16:09:20 + Gerrit Renker [EMAIL PROTECTED] wrote: [NET/IPv4]: Support for the UDP-Lite protocol (RFC 3828) This adds support for UDP-Lite to the IPv4 stack, provided as an extension to the existing UDPv4 code: * generic routines are all located in net/ipv4/udp.c * UDP-Lite specific routines are in net/ipv4/udplite.c * MIB/statistics support in /proc/net/snmp and /proc/net/udplite * shared API with extensions for partial checksum coverage * consolidation of shared code This code is does too much inlining (like existing network code). Should it be made configurable? It doesn't get built at all if you check his patches :-) But once that's fixed up, I think we can fix that with a followon patch. We've put Gerrit through the ringer enough on this stuff. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] [NET]: Supporting UDP-Lite (RFC 3828) in Linux
On Fri, 10 Nov 2006 14:38:46 -0800 (PST) David Miller [EMAIL PROTECTED] wrote: From: Stephen Hemminger [EMAIL PROTECTED] Date: Fri, 10 Nov 2006 09:37:15 -0800 On Fri, 10 Nov 2006 16:09:20 + Gerrit Renker [EMAIL PROTECTED] wrote: [NET/IPv4]: Support for the UDP-Lite protocol (RFC 3828) This adds support for UDP-Lite to the IPv4 stack, provided as an extension to the existing UDPv4 code: * generic routines are all located in net/ipv4/udp.c * UDP-Lite specific routines are in net/ipv4/udplite.c * MIB/statistics support in /proc/net/snmp and /proc/net/udplite * shared API with extensions for partial checksum coverage * consolidation of shared code This code is does too much inlining (like existing network code). Should it be made configurable? It doesn't get built at all if you check his patches :-) But once that's fixed up, I think we can fix that with a followon patch. We've put Gerrit through the ringer enough on this stuff. Agreed. But we can do some code rearranging/deinlining early in 2.6.20 -- Stephen Hemminger [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Generic Netlink HOW-TO based on Jamal's original doc
Thomas Graf wrote:
* Randy Dunlap [EMAIL PROTECTED] 2006-11-10 10:23
On Fri, 10 Nov 2006 01:08:23 -0500 Paul Moore wrote:
An Introduction To Using Generic Netlink
===
3.1.2. The genl_family Structure
Generic Netlink services are defined by the genl_family structure, which is
shown below:
struct genl_family
{
unsigned intid;
unsigned inthdrsize;
charname[GENL_NAMSIZ];
unsigned intversion;
unsigned intmaxattr;
struct nlattr **attrbuf;
struct list_headops_list;
struct list_headfamily_list;
};
Any alignment/packing concerns here? or that is already
handled, just not presented here?
I thought I chose GENL_NAMESIZ wisely but to be sure I checked
with Mr. Alignment himself, Arnaldo:
Hm, looks OK to me. Am I missing something?
struct genl_family {
unsigned int id; /* 0(0) 4 */
unsigned int hdrsize; /* 4(0) 4 */
char name[16]; /* 8(0)16 */
unsigned int version; /* 24(0) 4 */
unsigned int maxattr; /* 28(0) 4 */
/* -- cacheline 1 boundary -- */
struct nlattr * * attrbuf; /* 32(0) 4 */
struct list_head ops_list; /* 36(0) 8 */
struct list_head family_list; /* 44(0) 8 */
}; /* size: 52 */
How about field size issues? Usually for int's etc. that are in
userspace interfaces, we use __u32 etc.
--
~Randy
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NET] Update documentation of skb_linearize
From: Francois Romieu [EMAIL PROTECTED] Date: Fri, 10 Nov 2006 23:03:55 +0100 The data is not released. Yes it is. If the non-linear SKB has data in pages, we copy that data from the pages into the new linear skb-data area and release the paged data. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Generic Netlink HOW-TO based on Jamal's original doc
* Randy Dunlap [EMAIL PROTECTED] 2006-11-10 14:49
I thought I chose GENL_NAMESIZ wisely but to be sure I checked
with Mr. Alignment himself, Arnaldo:
Hm, looks OK to me. Am I missing something?
It is OK, I was merely trying to prove it :-)
struct genl_family {
unsigned int id; /* 0(0) 4 */
unsigned int hdrsize; /* 4(0) 4 */
char name[16]; /* 8(0)16 */
unsigned int version; /* 24(0) 4 */
unsigned int maxattr; /* 28(0) 4 */
/* -- cacheline 1 boundary -- */
struct nlattr * * attrbuf; /* 32(0) 4 */
struct list_head ops_list; /* 36(0) 8 */
struct list_head family_list; /* 44(0) 8 */
}; /* size: 52 */
How about field size issues? Usually for int's etc. that are in
userspace interfaces, we use __u32 etc.
This is kernel side only, struct genl_family lives in net/genetlink.h
and is not exported to userspace.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IPv6: only modify checksum for UDP
From: Brian Haley [EMAIL PROTECTED] Date: Fri, 10 Nov 2006 11:24:45 -0500 Only change upper-layer checksum from 0 to 0x for UDP (as RFC 768 states), not for others as RFC 4443 doesn't require it. Signed-off-by: Brian Haley [EMAIL PROTECTED] Applied, thanks Brian. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IPv6: only modify checksum for UDP
David Miller wrote: From: Brian Haley [EMAIL PROTECTED] Date: Fri, 10 Nov 2006 11:24:45 -0500 Only change upper-layer checksum from 0 to 0x for UDP (as RFC 768 states), not for others as RFC 4443 doesn't require it. Signed-off-by: Brian Haley [EMAIL PROTECTED] Applied, thanks Brian. Brian Haley wrote: Al Viro wrote: Could you fscking read what you've replied to? Your -=1 will turn 0 into 0x instead of correct 0xfffe. IOW, it's broken in 1:65536 cases. I looked again at your previous email: Note that even on little-endian you want 3 - 2 2 - 1 1 - 0x 0 - 0xfffe That doesn't look right to me, but I'll take your word that there's one edge case out there I don't see (even though this worked on Alpha). Forget about the patch then. Er, given all of the above, Brian, could you share your test cases and/or other/any information on testing this? thanks, Nivedita - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Generic Netlink HOW-TO based on Jamal's original doc
Thomas Graf wrote:
* Randy Dunlap [EMAIL PROTECTED] 2006-11-10 14:49
I thought I chose GENL_NAMESIZ wisely but to be sure I checked
with Mr. Alignment himself, Arnaldo:
Hm, looks OK to me. Am I missing something?
It is OK, I was merely trying to prove it :-)
struct genl_family {
unsigned int id; /* 0(0) 4 */
unsigned int hdrsize; /* 4(0) 4 */
char name[16]; /* 8(0)16 */
unsigned int version; /* 24(0) 4 */
unsigned int maxattr; /* 28(0) 4 */
/* -- cacheline 1 boundary -- */
struct nlattr * * attrbuf; /* 32(0) 4 */
struct list_head ops_list; /* 36(0) 8 */
struct list_head family_list; /* 44(0) 8 */
}; /* size: 52 */
How about field size issues? Usually for int's etc. that are in
userspace interfaces, we use __u32 etc.
This is kernel side only, struct genl_family lives in net/genetlink.h
and is not exported to userspace.
OK, thanks for the clarifications.
--
~Randy
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IPv6: only modify checksum for UDP
From: Nivedita Singhvi [EMAIL PROTECTED] Date: Fri, 10 Nov 2006 15:17:06 -0800 WATCH YOUR QUOTING! David Miller wrote: From: Brian Haley [EMAIL PROTECTED] Date: Fri, 10 Nov 2006 11:24:45 -0500 Only change upper-layer checksum from 0 to 0x for UDP (as RFC 768 states), not for others as RFC 4443 doesn't require it. Signed-off-by: Brian Haley [EMAIL PROTECTED] Applied, thanks Brian. I applied Brian's FIRST PATCH, which is fine. Brian Haley wrote: Al Viro wrote: Could you fscking read what you've replied to? Your -=1 will turn 0 into 0x instead of correct 0xfffe. IOW, it's broken in 1:65536 cases. I looked again at your previous email: Note that even on little-endian you want 3 - 2 2 - 1 1 - 0x 0 - 0xfffe That doesn't look right to me, but I'll take your word that there's one edge case out there I don't see (even though this worked on Alpha). Forget about the patch then. Er, given all of the above, Brian, could you share your test cases and/or other/any information on testing this? This is a discussion about Brian's SECOND PATCH which needs fixups. Please don't quote things out of context like this! - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NET] Update documentation of skb_linearize
David Miller [EMAIL PROTECTED] : [...] Yes it is. If the non-linear SKB has data in pages, we copy that data from the pages into the new linear skb-data area and release the paged data. Right. The documentation talks about the skb _data_ so there is no reason to imagine that the function could freed the skb on failure. I'll leave Stephen reformulate the documentation if he feels the need to. -- Ueimor - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IPv6: only modify checksum for UDP
David Miller wrote: From: Nivedita Singhvi [EMAIL PROTECTED] Date: Fri, 10 Nov 2006 15:17:06 -0800 WATCH YOUR QUOTING! That explains it! Arg! Sorry, DaveM, a bit on autopilot trying to put some tests together.. thanks, Nivedita - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL 2.6.20] IPv6 Updates
Hello.
Please consider pulling following changesets from
2.6.19-rc5-net-2.6.20-20061110-to-davem branch at:
git://git.linux-ipv6.org/gitroot/yoshfuji/linux-2.6-dev.git
Regards,
HEADLINES
-
[IPV6] ROUTE: Use macros to format /proc/net/ipv6_route.
[IPV6] ROUTE: Use rt-u.dst instead of cast.
[IPV6]: Introduce ip6_dst_idev() to get inet6_dev{} stored in dst_entry{}.
[IPV6]: Per-interface statistics support.
DIFFSTAT
include/net/if_inet6.h |1 +
include/net/ip6_fib.h |5 +++
include/net/ipv6.h | 21 --
net/ipv6/addrconf.c|2 +
net/ipv6/exthdrs.c | 57 ++-
net/ipv6/fib6_rules.c |2 +
net/ipv6/icmp.c|3 +-
net/ipv6/ip6_input.c | 42 +++-
net/ipv6/ip6_output.c | 71
net/ipv6/mcast.c | 20 +-
net/ipv6/ndisc.c |8 +++--
net/ipv6/netfilter.c |2 +
net/ipv6/proc.c|7 +
net/ipv6/raw.c |4 +--
net/ipv6/reassembly.c | 65 ++--
net/ipv6/route.c | 47
16 files changed, 219 insertions(+), 138 deletions(-)
CHANGESETS
--
commit 465b80b2a10ac1fb395f73d41c7578a12ed70267
Author: YOSHIFUJI Hideaki [EMAIL PROTECTED]
Date: Sat Oct 14 02:00:56 2006 +0900
[IPV6] ROUTE: Use macros to format /proc/net/ipv6_route.
Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED]
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index cb31d00..92c948c 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -2245,7 +2245,6 @@ struct rt6_proc_arg
static int rt6_info_route(struct rt6_info *rt, void *p_arg)
{
struct rt6_proc_arg *arg = (struct rt6_proc_arg *) p_arg;
- int i;
if (arg-skip arg-offset / RT6_INFO_LEN) {
arg-skip++;
@@ -2255,38 +2254,28 @@ static int rt6_info_route(struct rt6_inf
if (arg-len = arg-length)
return 0;
- for (i=0; i16; i++) {
- sprintf(arg-buffer + arg-len, %02x,
- rt-rt6i_dst.addr.s6_addr[i]);
- arg-len += 2;
- }
- arg-len += sprintf(arg-buffer + arg-len, %02x ,
+ arg-len += sprintf(arg-buffer + arg-len,
+ NIP6_SEQFMT %02x ,
+ NIP6(rt-rt6i_dst.addr),
rt-rt6i_dst.plen);
#ifdef CONFIG_IPV6_SUBTREES
- for (i=0; i16; i++) {
- sprintf(arg-buffer + arg-len, %02x,
- rt-rt6i_src.addr.s6_addr[i]);
- arg-len += 2;
- }
- arg-len += sprintf(arg-buffer + arg-len, %02x ,
+ arg-len += sprintf(arg-buffer + arg-len,
+ NIP6_SEQFMT %02x ,
+ NIP6(rt-rt6i_src.addr),
rt-rt6i_src.plen);
#else
- sprintf(arg-buffer + arg-len,
- 00 );
- arg-len += 36;
+ arg-len += sprintf(arg-buffer + arg-len,
+ 00 );
#endif
if (rt-rt6i_nexthop) {
- for (i=0; i16; i++) {
- sprintf(arg-buffer + arg-len, %02x,
- rt-rt6i_nexthop-primary_key[i]);
- arg-len += 2;
- }
+ arg-len += sprintf(arg-buffer + arg-len,
+ NIP6_SEQFMT,
+ NIP6(*((struct in6_addr
*)rt-rt6i_nexthop-primary_key)));
} else {
- sprintf(arg-buffer + arg-len,
- );
- arg-len += 32;
+ arg-len += sprintf(arg-buffer + arg-len,
+ );
}
arg-len += sprintf(arg-buffer + arg-len,
%08x %08x %08x %08x %8s\n,
---
commit 9f19e129e7acc28c64cc139f7f65e755d3f51fc9
Author: YOSHIFUJI Hideaki [EMAIL PROTECTED]
Date: Thu Oct 19 13:50:09 2006 +0900
[IPV6] ROUTE: Use rt-u.dst instead of cast.
Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED]
diff --git a/net/ipv6/fib6_rules.c b/net/ipv6/fib6_rules.c
index 8377477..25804cb 100644
--- a/net/ipv6/fib6_rules.c
+++ b/net/ipv6/fib6_rules.c
@@ -63,7 +63,7 @@ struct dst_entry *fib6_rule_lookup(struc
fib_rule_put(arg.rule);
if (arg.result)
- return (struct dst_entry *) arg.result;
+ return arg.result;
dst_hold(ip6_null_entry.u.dst);
return ip6_null_entry.u.dst;
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 92c948c..07d8dbc 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -939,7 +939,7 @@ struct dst_entry *ndisc_dst_alloc(struct
fib6_force_start_gc();
out:
- return (struct dst_entry
Re: [NETLINK]: Do precise netlink message allocations where possible
Thomas Graf wrote:
* Paul Moore [EMAIL PROTECTED] 2006-11-10 11:04
I like this approach, it makes much more sense to me then the previous
implementation which was a simple alias to alloc_skb(). Also, the NetLabel
relevant sections look fine to me.
Question is wheter to do the same for genetlink and add genlmsg_new().
If it makes sense to modify nlmsg_new() I think it makes sense modify
genlmsg_new(). My vote is for yes.
I'm currently thinking about this and also about some _reply() function
which takes a struct genl_info so a genetlink module doesn't have to
know about how to address the client by pid anymore.
Hmm, interesting idea. I've only thought about it for a few minutes now but it
might be nice to do something like the following:
* genlmsg_put_reply()
- write the message headers using genlmsg_put()
+ take the snd_pid and snd_seq from the genl_info struct
+ ?lookup the hdrlen based on the genl family info in the message
headers in the genl_info struct?
* genlmsg_new_reply()
- allocate a buffer using genlmsg_new()
- call genlmsg_put_reply()
* genlmsg_{unicast,multicast}_reply()
- take the pid from the genl_info struct
I think this would simply the genetlink handlers job a little bit.
Ideas or even patches very welcome.
If that sounds reasonable I can put together a patch sometime next week,
although it will probably be later in the week as I have some NetLabel stuff I
want to get done for 2.6.20.
--
paul moore
linux security @ hp
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bcm43xx-d80211 broadcast reception with WPA
Michael Buesch mb at bu3sch.de writes: On Thursday 09 November 2006 23:23, Paul Hampson wrote: I've been backporting the bcm43xx-d80211 driver to whatever the released 2.6 kernel was using the rt2x00 project's d80211 stack (equivalent to current wireless-dev but with a workaround for not having a ieee80211_dev pointer and still using the _tfm interface instead of the _cypher interface.) As of last night's wireless-dev tree bcm43xx, everything seems to be operating fine except incoming broadcast traffic is coming in 14 bytes too long and scrambled. I presume this means it's not decrypting properly... It sounds like a bug in the hardware decryption setup. Are you using TKIP or not? Yes, it's using TKIP. The router docs and the loading of the tkip module when I use the softmac driver agree on this. Incoming mcast frames are handled in a special way in hardware. The keyidx field of the packet is used to lookup the key, as far as I know. (Otherwise the MAC address is used). Can I see a full dmesg log and a capture log on the broken machine, please? Sending first some ipv6 broadcast pings and then some ipv4 broadcast pings: (Commands ping -b 192.168.192.255 -c 1 and ping6 -I intel0 -c 1 ip6-allnodes) 17:04:08.794400 00:02:a5:40:8d:61 (oui Unknown) Unknown SSAP 0x26 33:33:00:00:00:01 (oui Unknown) Unknown DSAP 0x9c Unnumbered, eb, Flags [Poll], length 116 0x: 9d26 fbda 7284 bd60 6cdf 58c4 d064 71c6 0x0010: 2a09 adab 4a19 a691 5640 9216 eae8 df70 0x0020: b94e 9ee9 fd75 6c25 ab16 36fb cdac c231 0x0030: 0f17 f965 4d20 4a11 ab50 c77f 66ca 54e4 0x0040: e469 e458 5d6c c13d cc78 48fd da5c 7f71 0x0050: 2f06 0728 c8da 689b b790 ec22 4d62 5a92 0x0060: 221b b3cb 65e5 dc8a 8e57 3486 2a1e a2c2 0x0070: faf6 ae71 17:04:10.104111 00:02:a5:40:8d:61 (oui Unknown) Unknown SSAP 0xa8 33:33:00:00:00:01 (oui Unknown) Unknown DSAP 0xb8 Supervisory, Reject, rcv seq 78, Flags [Final], length 116 0x: b8a9 099d 0afb f9f3 8ef6 1c31 81c0 f1eb 0x0010: 3869 1952 9762 f4f0 c743 7613 fd9c 99cd 0x0020: 1644 a454 df14 5481 a35a 8c96 59b3 9391 0x0030: 8579 a165 3da2 58ad a6a8 d499 e40c 4c4c 0x0040: 3b33 a4ce 2b2e 439b 77f6 da5d 1d18 1685 0x0050: 1e64 39cb 3565 5596 30eb fa1c 1cbd cec8 0x0060: 395b a38c f7a4 a754 7c19 d694 a94b a4f9 0x0070: 5785 64aa 17:04:10.938418 00:02:a5:40:8d:61 (oui Unknown) Unknown SSAP 0x1c 33:33:00:00:00:01 (oui Unknown) Unknown DSAP 0x64 Unnumbered, 23, Flags [Poll], length 116 0x: 641c 338d 7f62 2bcd 4fff c7dd 4a6e efa1 0x0010: 07ed f39b 5b88 c68e 27dd f35b 70cf df3c 0x0020: 0cb8 f3ba 0b97 9069 43f9 e74f 1cb2 e4d7 0x0030: bf97 fbd8 94d8 efc5 284d 5393 604b 13ef 0x0040: 1cd7 46e1 7b35 008b 8247 89bb 0a6a 4dac 0x0050: 45e3 49af 853d 13fa e263 dea8 26ca 7076 0x0060: bec6 938f bd75 19bd a3ea 9f79 ea65 2c2d 0x0070: a45c b3d1 17:04:14.491735 00:02:a5:40:8d:61 (oui Unknown) Unknown SSAP 0x8a Broadcast Unknown DSAP 0xe4 Information, send seq 49, rcv seq 14, Flags [Final], length 96 0x: e58b 621d 383b 5114 c37d 54de da9e dd8b 0x0010: 7d28 87d2 7d53 cd57 f0b4 c079 54a5 0bbe 0x0020: 3eb2 f0b9 e1e6 e82b e52b ffaf f833 217c 0x0030: dbe7 c9f1 db0f 592e b432 5f7d 8041 f73f 0x0040: 7267 662b d64e 170d c619 a447 b2c0 bd17 0x0050: b97b b032 dd1b d8f5 c007 eae9 0aee ea9f 17:04:16.489911 00:02:a5:40:8d:61 (oui Unknown) Unknown SSAP 0xa4 Broadcast ProWay NM Information, send seq 122, rcv seq 28, Flags [Final], length 96 0x: 0fa5 f439 af38 57a6 564c 0c25 e2c0 7a09 0x0010: 61fb a1f1 adb0 3718 cb39 3a03 6ecf ad42 0x0020: 6e9c 75d7 cd06 0566 30c9 0238 4cf8 61a9 0x0030: 0928 9414 f48b 2a07 3eca 05de a8a9 9787 0x0040: 1ed5 2643 f82a b9a8 8e5a 5410 6858 b5c0 0x0050: ecb2 72a3 2dfb 66ac 0ce8 c4f8 ea87 ab14 17:04:18.449142 00:02:a5:40:8d:61 (oui Unknown) Unknown SSAP 0xb4 Broadcast Unknown DSAP 0x6a Supervisory, Receiver not Ready, rcv seq 23, Flags [Command], length 96 0x: 6bb4 252e 2888 d3b1 68bc 6129 9087 4170 0x0010: f4e2 4a47 adc9 9bce 7bf2 51b3 ac20 bd10 0x0020: 7d67 3e00 6b6f 41ff 3e0c 2940 d31c 6143 0x0030: f7e4 caa6 879f 4663 e04b 0f6d 37eb 1db5 0x0040: fffd 0dfa 9b78 80e1 a30a 799e 9b1a 9d4a 0x0050: 61c8 f041 e564 d566 b697 aaf6 8336 a6f3 And the dmesg output: bcm43xx_d80211: no version for ssb_init found: kernel tainted. PCI: Enabling device 0001:10:12.0 (0004 - 0006) ssb: Core 0 found: cc 0800, rev 04, vendor 4243 ssb: Core 1 found: cc 0812, rev 05, vendor 4243 ssb: Core 2 found: cc 080D, rev 02, vendor 4243 ssb: Core 3 found: cc 0807, rev 02, vendor 4243 ssb: Core 4 found: cc 0804, rev 09, vendor 4243 bcm43xx_d80211: Broadcom 4306 WLAN found ssb: Switching to core 4 ssb: Switching to core 1
