Re: [PATCH] warning in SCTP
From: Meelis Roos [EMAIL PROTECTED] Date: Thu, 2 Nov 2006 09:29:16 +0200 (EET) CC [M] net/sctp/sm_make_chunk.o net/sctp/sm_make_chunk.c: In function 'sctp_unpack_cookie': net/sctp/sm_make_chunk.c:1358: warning: initialization discards qualifiers from pointer target type The reason is that sctp_unpack_cookie() takes a const struct sctp_endpoint and modifies the digest in it (digest being embedded in the struct, not a pointer). So sctp_unpack_cookie really does not use the argument as const, mark it as such. Signed-off-by: Meelis Roos [EMAIL PROTECTED] Applied, but like your other patch I had to apply it by hand. Something in your email client adds extra spaces to the patch, for example: diff --git a/include/net/sctp/sm.h b/include/net/sctp/sm.h index de313de..ef80489 100644 --- a/include/net/sctp/sm.h +++ b/include/net/sctp/sm.h @@ -272,7 +272,7 @@ void sctp_generate_heartbeat_event(unsig void sctp_ootb_pkt_free(struct sctp_packet *); There should only be one space before the void in the patch, your email client (or something else) put another space there. Also, your email client likes to turn lines containing only spaces into empty lines, which also corrupts the patch. - 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] warning in SCTP
There should only be one space before the void in the patch, your email client (or something else) put another space there. Also, your email client likes to turn lines containing only spaces into empty lines, which also corrupts the patch. cg-diff file and in pine 4.61 ^R read a file. So I guess it's pine misbehaving... Have not heard complaints before but will try to remember to use mutt next time. -- Meelis Roos ([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] warning in SCTP
On 2006-11-02, Meelis Roos wrote: There should only be one space before the void in the patch, your email client (or something else) put another space there. Also, your email client likes to turn lines containing only spaces into empty lines, which also corrupts the patch. cg-diff file and in pine 4.61 ^R read a file. So I guess it's pine misbehaving... Have not heard complaints before but will try to remember to use mutt next time. (quilt || git) mbox - formail (procmail package), no MUAs, job's done. - 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] warning in SCTP
From: David Miller [EMAIL PROTECTED] Date: Thu, 02 Nov 2006 00:16:43 -0800 (PST) From: Meelis Roos [EMAIL PROTECTED] Date: Thu, 2 Nov 2006 09:29:16 +0200 (EET) CC [M] net/sctp/sm_make_chunk.o net/sctp/sm_make_chunk.c: In function 'sctp_unpack_cookie': net/sctp/sm_make_chunk.c:1358: warning: initialization discards qualifiers from pointer target type The reason is that sctp_unpack_cookie() takes a const struct sctp_endpoint and modifies the digest in it (digest being embedded in the struct, not a pointer). So sctp_unpack_cookie really does not use the argument as const, mark it as such. Signed-off-by: Meelis Roos [EMAIL PROTECTED] Applied, Actually, I'm backing this one out, it creates new warnings because callers of this function pass in a const pointer. net/sctp/sm_statefuns.c: In function $,1rx(Bsctp_sf_do_5_1D_ce$,1ry(B: net/sctp/sm_statefuns.c:630: warning: passing argument 1 of $,1rx(Bsctp_unpack_cookie$,1ry(B discards qualifiers from pointer target type net/sctp/sm_statefuns.c: In function $,1rx(Bsctp_sf_do_5_2_4_dupcook$,1ry(B: net/sctp/sm_statefuns.c:1884: warning: passing argument 1 of $,1rx(Bsctp_unpack_cookie$,1ry(B discards qualifiers from pointer target type Please test the complete build when doing warning fixes like this in the future, 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
cfg80211/nl80211/WE (was: Re: d80211 merge)
On Wed, 2006-11-01 at 21:55 -0500, Jeff Garzik wrote: Speaking specifically, Linus noted recently d80211 should maintain backwards compatibility with the WE userspace ABI, so that existing wireless tools keep working, and I definitely agree. For additional functionality/flexibility, I presume there will be some sort of netlink extensible interface (cfg80211 I think?) that newer wireless tools will use. In time, the WE back-compat ABI could become an optional module that users can disable. I'm pretty sure I've said this like a dozen times but apparently it hasn't sunk in yet: The latest cfg80211/nl80211 code comes with WE compatibility code that users can disable if they want to, which, however, gives them the ability to use WE in userspace while the drivers are happily using cfg80211. My goal is to remove WE from *all* drivers, even from the ancient pre-802.11 and early 802.11 fullmac drivers, and leave WE merely as another userspace interface for cfg80211, albeit with limitations that the netlink interface nl80211 doesn't have. Until all drivers are converted, however, cfg80211-WE and regular WE coexist peacefully, it is even possible to convert one ioctl at a time over to cfg80211 (which is only really useful while working at it, but still). johannes - 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] warning in SCTP
Actually, I'm backing this one out, it creates new warnings because callers of this function pass in a const pointer. OK, fair enough. Will have a look. Please test the complete build when doing warning fixes like this in the future, thanks. Sure. Evenso, I did test full make after the single compile was fine (still have it in my scrollback so here it is). So did I do anything wrong here or do we have some dependencies broken somewhere or what? Now that I read the transript again I can see that despite modifying include/net/sctp/sm.h nothing was really recompiled - should have noticed. [EMAIL PROTECTED]:~/compile/linux-2.6$ vi net/sctp/sm_make_chunk.c [EMAIL PROTECTED]:~/compile/linux-2.6$ !make make net/sctp/sm_make_chunk.o CHK include/linux/version.h CHK include/linux/utsrelease.h CC net/sctp/sm_make_chunk.o net/sctp/sm_make_chunk.c:1353: error: conflicting types for 'sctp_unpack_cookie' include/net/sctp/sm.h:279: error: previous declaration of 'sctp_unpack_cookie' was here make[1]: *** [net/sctp/sm_make_chunk.o] Error 1 make: *** [net/sctp/sm_make_chunk.o] Error 2 [EMAIL PROTECTED]:~/compile/linux-2.6$ vi include/net/sctp/sm.h [EMAIL PROTECTED]:~/compile/linux-2.6$ make net/sctp/sm_make_chunk.o CHK include/linux/version.h CHK include/linux/utsrelease.h CC net/sctp/sm_make_chunk.o [EMAIL PROTECTED]:~/compile/linux-2.6$ make CHK include/linux/version.h CHK include/linux/utsrelease.h CHK include/linux/compile.h MODPOST vmlinux Kernel: arch/i386/boot/bzImage is ready (#274) Building modules, stage 2. MODPOST 511 modules [EMAIL PROTECTED]:~/compile/linux-2.6$ cg-diff ~/sctppatch -- Meelis Roos ([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: cfg80211/nl80211/WE
Johannes Berg wrote: My goal is to remove WE from *all* drivers, even from the ancient pre-802.11 and early 802.11 fullmac drivers, and leave WE merely as another userspace interface for cfg80211, albeit with limitations that the netlink interface nl80211 doesn't have. Sounds good to me... Jeff - 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] warning in SCTP
Sure. Evenso, I did test full make after the single compile was fine (still have it in my scrollback so here it is). So did I do anything wrong here or do we have some dependencies broken somewhere or what? Never mind - I discovered the warning on one box with SCTP enabled in config and tried the fix on a faster machine that unfortunately had SCTP disabled. -- Meelis Roos ([EMAIL PROTECTED]) http://www.cs.ut.ee/~mroos/ - 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] warning in SCTP
Actually, I'm backing this one out, it creates new warnings because callers of this function pass in a const pointer. Yes, it now seems it's not so simple. Marking it non-const there would mark the it non-const in the whole family of sctp_state_fn_t and I'm not sure that's the best thing to do. I guess the maintainer has better bases for deciding what to do about it. -- Meelis Roos ([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: cfg80211/nl80211/WE (was: Re: d80211 merge)
On Thu, Nov 02, 2006 at 09:49:01AM +0100, Johannes Berg wrote: I'm pretty sure I've said this like a dozen times but apparently it hasn't sunk in yet: The latest cfg80211/nl80211 code comes with WE compatibility code that users can disable if they want to, which, however, gives them the ability to use WE in userspace while the drivers are happily using cfg80211. My goal is to remove WE from *all* drivers, even from the ancient pre-802.11 and early 802.11 fullmac drivers, and leave WE merely as another userspace interface for cfg80211, albeit with limitations that the netlink interface nl80211 doesn't have. Yes, that is exatly the right way to go forward. The userspace interface is however more than just the WE ioctls. It's also that for every wireless card one single ethX device appears and not multiple devices with other names. This might sound like nitpicking, but without this all kinds of scripts break. - 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] bcm43xx: Drain TX status before starting IRQs
On Wed, 2006-11-01 at 23:46 -0600, Larry Finger wrote: Has anyone used this patch, particularly with WPA encryption? When I try it, wpa_supplicant immediately uses 90+% of the cpu and never actually authenticates with my AP. I wonder if it is something with my system. Unless wpa supplicant is stupid [1] this cannot cause it any problems. johannes [1] by that, I mean sending out frames, turning off and on the interface, and then hoping to get a transmit status for frames sent before off/on cycle. - 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/6] IPv6: Fix SIOCCHGTUNNEL bug in IPv6 tunnels
From f9812eb0349f44f6374910ce38524f0c6f7ce8f4 Mon Sep 17 00:00:00 2001
From: Ville Nuorvala [EMAIL PROTECTED]
Date: Thu, 2 Nov 2006 12:40:38 +0200
Subject: [PATCH 1/6] IPv6: Fix SIOCCHGTUNNEL bug in IPv6 tunnels
A logic bug in tunnel lookup could result in duplicate tunnels
when changing an existing device.
Signed-off-by: Ville Nuorvala [EMAIL PROTECTED]
---
net/ipv6/ip6_tunnel.c | 111
1 files changed, 46 insertions(+), 65 deletions(-)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 84d7ebd..e61458c 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -215,11 +215,10 @@ ip6ip6_tnl_unlink(struct ip6_tnl *t)
* Create tunnel matching given parameters.
*
* Return:
- * 0 on success
+ * created tunnel or NULL
**/
-static int
-ip6_tnl_create(struct ip6_tnl_parm *p, struct ip6_tnl **pt)
+static struct ip6_tnl *ip6_tnl_create(struct ip6_tnl_parm *p)
{
struct net_device *dev;
struct ip6_tnl *t;
@@ -236,11 +235,11 @@ ip6_tnl_create(struct ip6_tnl_parm *p, s
break;
}
if (i == IP6_TNL_MAX)
- return -ENOBUFS;
+ goto failed;
}
dev = alloc_netdev(sizeof (*t), name, ip6ip6_tnl_dev_setup);
if (dev == NULL)
- return -ENOMEM;
+ goto failed;
t = netdev_priv(dev);
dev-init = ip6ip6_tnl_dev_init;
@@ -248,13 +247,13 @@ ip6_tnl_create(struct ip6_tnl_parm *p, s
if ((err = register_netdevice(dev)) 0) {
free_netdev(dev);
- return err;
+ goto failed;
}
dev_hold(dev);
-
ip6ip6_tnl_link(t);
- *pt = t;
- return 0;
+ return t;
+failed:
+ return NULL;
}
/**
@@ -268,32 +267,23 @@ ip6_tnl_create(struct ip6_tnl_parm *p, s
* tunnel device is created and registered for use.
*
* Return:
- * 0 if tunnel located or created,
- * -EINVAL if parameters incorrect,
- * -ENODEV if no matching tunnel available
+ * matching tunnel or NULL
**/
-static int
-ip6ip6_tnl_locate(struct ip6_tnl_parm *p, struct ip6_tnl **pt, int create)
+static struct ip6_tnl *ip6ip6_tnl_locate(struct ip6_tnl_parm *p, int create)
{
struct in6_addr *remote = p-raddr;
struct in6_addr *local = p-laddr;
struct ip6_tnl *t;
- if (p-proto != IPPROTO_IPV6)
- return -EINVAL;
-
for (t = *ip6ip6_bucket(p); t; t = t-next) {
if (ipv6_addr_equal(local, t-parms.laddr)
- ipv6_addr_equal(remote, t-parms.raddr)) {
- *pt = t;
- return (create ? -EEXIST : 0);
- }
+ ipv6_addr_equal(remote, t-parms.raddr))
+ return t;
}
if (!create)
- return -ENODEV;
-
- return ip6_tnl_create(p, pt);
+ return NULL;
+ return ip6_tnl_create(p);
}
/**
@@ -919,26 +909,20 @@ static int
ip6ip6_tnl_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
{
int err = 0;
- int create;
struct ip6_tnl_parm p;
struct ip6_tnl *t = NULL;
switch (cmd) {
case SIOCGETTUNNEL:
if (dev == ip6ip6_fb_tnl_dev) {
- if (copy_from_user(p,
- ifr-ifr_ifru.ifru_data,
- sizeof (p))) {
+ if (copy_from_user(p, ifr-ifr_ifru.ifru_data, sizeof
(p))) {
err = -EFAULT;
break;
}
- if ((err = ip6ip6_tnl_locate(p, t, 0)) == -ENODEV)
- t = netdev_priv(dev);
- else if (err)
- break;
- } else
+ t = ip6ip6_tnl_locate(p, 0);
+ }
+ if (t == NULL)
t = netdev_priv(dev);
-
memcpy(p, t-parms, sizeof (p));
if (copy_to_user(ifr-ifr_ifru.ifru_data, p, sizeof (p))) {
err = -EFAULT;
@@ -947,35 +931,36 @@ ip6ip6_tnl_ioctl(struct net_device *dev,
case SIOCADDTUNNEL:
case SIOCCHGTUNNEL:
err = -EPERM;
- create = (cmd == SIOCADDTUNNEL);
if (!capable(CAP_NET_ADMIN))
break;
- if (copy_from_user(p, ifr-ifr_ifru.ifru_data, sizeof (p))) {
- err = -EFAULT;
+ err = -EFAULT;
+ if (copy_from_user(p, ifr-ifr_ifru.ifru_data, sizeof (p)))
break;
- }
- if (!create dev != ip6ip6_fb_tnl_dev) {
- t = netdev_priv(dev);
- }
- if (!t (err =
[PATCH 0/6] IPv6: IPv6 tunnel fixes
Hello, the following incremental patches contain several fixes to ip6_tunnel.c. They are in chronological order, so the most critical one is unfortunately last. Many thanks to Tero Kauppinen for reporting that one! The patches are sent as attachments as my mailer has at least previously messed up inlined patches. Regards, Ville - 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/6] IPv6: Do mandatory IPv6 tunnel endpoint checks in realtime
From e60ed41fb11793d16ffcbfd56b889e0bbf04ea88 Mon Sep 17 00:00:00 2001
From: Ville Nuorvala [EMAIL PROTECTED]
Date: Thu, 2 Nov 2006 12:43:50 +0200
Subject: [PATCH 2/6] IPv6: Do mandatory IPv6 tunnel endpoint checks in realtime
Doing the mandatory tunnel endpoint checks when the tunnel is set up
isn't enough as interfaces can go up or down and addresses can be
added or deleted after this. The checks need to be done realtime when
the tunnel is processing a packet.
Signed-off-by: Ville Nuorvala [EMAIL PROTECTED]
---
net/ipv6/ip6_tunnel.c | 96 +++-
1 files changed, 62 insertions(+), 34 deletions(-)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index e61458c..2467b04 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -494,6 +494,27 @@ static inline void ip6ip6_ecn_decapsulat
if (INET_ECN_is_ce(ipv6_get_dsfield(outer_iph)))
IP6_ECN_set_ce(inner_iph);
}
+static inline int ip6_tnl_rcv_ctl(struct ip6_tnl *t)
+{
+ struct ip6_tnl_parm *p = t-parms;
+ int ret = 0;
+
+ if (p-flags IP6_TNL_F_CAP_RCV) {
+ struct net_device *ldev = NULL;
+
+ if (p-link)
+ ldev = dev_get_by_index(p-link);
+
+ if ((ipv6_addr_is_multicast(p-laddr) ||
+likely(ipv6_chk_addr(p-laddr, ldev, 0)))
+ likely(!ipv6_chk_addr(p-raddr, NULL, 0)))
+ ret = 1;
+
+ if (ldev)
+ dev_put(ldev);
+ }
+ return ret;
+}
/**
* ip6ip6_rcv - decapsulate IPv6 packet and retransmit it locally
@@ -518,7 +539,7 @@ ip6ip6_rcv(struct sk_buff *skb)
goto discard;
}
- if (!(t-parms.flags IP6_TNL_F_CAP_RCV)) {
+ if (!ip6_tnl_rcv_ctl(t)) {
t-stat.rx_dropped++;
read_unlock(ip6ip6_lock);
goto discard;
@@ -596,6 +617,34 @@ ip6ip6_tnl_addr_conflict(struct ip6_tnl
return ipv6_addr_equal(t-parms.raddr, hdr-saddr);
}
+static inline int ip6_tnl_xmit_ctl(struct ip6_tnl *t)
+{
+ struct ip6_tnl_parm *p = t-parms;
+ int ret = 0;
+
+ if (p-flags IP6_TNL_F_CAP_XMIT) {
+ struct net_device *ldev = NULL;
+
+ if (p-link)
+ ldev = dev_get_by_index(p-link);
+
+ if (unlikely(!ipv6_chk_addr(p-laddr, ldev, 0)))
+ printk(KERN_WARNING
+ %s xmit: Local address not yet configured!\n,
+ p-name);
+ else if (!ipv6_addr_is_multicast(p-raddr)
+unlikely(ipv6_chk_addr(p-raddr, NULL, 0)))
+ printk(KERN_WARNING
+ %s xmit: Routing loop!
+ Remote address found on this node!\n,
+ p-name);
+ else
+ ret = 1;
+ if (ldev)
+ dev_put(ldev);
+ }
+ return ret;
+}
/**
* ip6ip6_tnl_xmit - encapsulate packet and send
* @skb: the outgoing socket buffer
@@ -633,10 +682,9 @@ ip6ip6_tnl_xmit(struct sk_buff *skb, str
goto tx_err;
}
if (skb-protocol != htons(ETH_P_IPV6) ||
- !(t-parms.flags IP6_TNL_F_CAP_XMIT) ||
- ip6ip6_tnl_addr_conflict(t, ipv6h)) {
+ !ip6_tnl_xmit_ctl(t) || ip6ip6_tnl_addr_conflict(t, ipv6h))
goto tx_err;
- }
+
if ((offset = parse_tlv_tnl_enc_lim(skb, skb-nh.raw)) 0) {
struct ipv6_tlv_tnl_enc_lim *tel;
tel = (struct ipv6_tlv_tnl_enc_lim *) skb-nh.raw[offset];
@@ -767,39 +815,19 @@ tx_err:
static void ip6_tnl_set_cap(struct ip6_tnl *t)
{
struct ip6_tnl_parm *p = t-parms;
- struct in6_addr *laddr = p-laddr;
- struct in6_addr *raddr = p-raddr;
- int ltype = ipv6_addr_type(laddr);
- int rtype = ipv6_addr_type(raddr);
+ int ltype = ipv6_addr_type(p-laddr);
+ int rtype = ipv6_addr_type(p-raddr);
p-flags = ~(IP6_TNL_F_CAP_XMIT|IP6_TNL_F_CAP_RCV);
- if (ltype != IPV6_ADDR_ANY rtype != IPV6_ADDR_ANY
- ((ltype|rtype)
-(IPV6_ADDR_UNICAST|
- IPV6_ADDR_LOOPBACK|IPV6_ADDR_LINKLOCAL|
- IPV6_ADDR_MAPPED|IPV6_ADDR_RESERVED)) == IPV6_ADDR_UNICAST) {
- struct net_device *ldev = NULL;
- int l_ok = 1;
- int r_ok = 1;
-
- if (p-link)
- ldev = dev_get_by_index(p-link);
-
- if (ltypeIPV6_ADDR_UNICAST !ipv6_chk_addr(laddr, ldev, 0))
- l_ok = 0;
-
- if (rtypeIPV6_ADDR_UNICAST ipv6_chk_addr(raddr, NULL, 0))
- r_ok = 0;
-
- if (l_ok r_ok) {
-
[PATCH 3/6] IPv6: Allow link-local tunnel endpoints
From de1ad3df949303a1454ae0cdee0a599c0fc95e45 Mon Sep 17 00:00:00 2001
From: Ville Nuorvala [EMAIL PROTECTED]
Date: Thu, 2 Nov 2006 12:45:08 +0200
Subject: [PATCH 3/6] IPv6: Allow link-local tunnel endpoints
Allow link-local tunnel endpoints if the underlying link is defined.
Signed-off-by: Ville Nuorvala [EMAIL PROTECTED]
---
net/ipv6/ip6_tunnel.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 2467b04..008bd11 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -460,6 +460,7 @@ ip6ip6_err(struct sk_buff *skb, struct i
if (rel_msg pskb_may_pull(skb, offset + sizeof (*ipv6h))) {
struct rt6_info *rt;
struct sk_buff *skb2 = skb_clone(skb, GFP_ATOMIC);
+
if (!skb2)
goto out;
@@ -823,7 +824,7 @@ static void ip6_tnl_set_cap(struct ip6_t
if (ltype (IPV6_ADDR_UNICAST|IPV6_ADDR_MULTICAST)
rtype (IPV6_ADDR_UNICAST|IPV6_ADDR_MULTICAST)
!((ltype|rtype) IPV6_ADDR_LOOPBACK)
- !((ltype|rtype) IPV6_ADDR_LINKLOCAL)) {
+ (!((ltype|rtype) IPV6_ADDR_LINKLOCAL) || p-link)) {
if (ltypeIPV6_ADDR_UNICAST)
p-flags |= IP6_TNL_F_CAP_XMIT;
if (rtypeIPV6_ADDR_UNICAST)
@@ -861,8 +862,11 @@ static void ip6ip6_tnl_link_config(struc
dev-iflink = p-link;
if (p-flags IP6_TNL_F_CAP_XMIT) {
+ int strict = (ipv6_addr_type(p-raddr)
+ (IPV6_ADDR_MULTICAST|IPV6_ADDR_LINKLOCAL));
+
struct rt6_info *rt = rt6_lookup(p-raddr, p-laddr,
-p-link, 0);
+p-link, strict);
if (rt == NULL)
return;
--
1.4.3.2
[PATCH 4/6] IPv6: Don't allocate memory for Tunnel Encapsulation Limit Option
From b278633af228bcc986856f6492b02422c25656c7 Mon Sep 17 00:00:00 2001
From: Ville Nuorvala [EMAIL PROTECTED]
Date: Thu, 2 Nov 2006 12:47:54 +0200
Subject: [PATCH 4/6] IPv6: Don't allocate memory for Tunnel Encapsulation Limit
Option
Signed-off-by: Ville Nuorvala [EMAIL PROTECTED]
---
net/ipv6/ip6_tunnel.c | 58 ++--
1 files changed, 22 insertions(+), 36 deletions(-)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 008bd11..a97eb52 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -571,31 +571,23 @@ discard:
return 0;
}
-static inline struct ipv6_txoptions *create_tel(__u8 encap_limit)
-{
- struct ipv6_tlv_tnl_enc_lim *tel;
- struct ipv6_txoptions *opt;
- __u8 *raw;
-
- int opt_len = sizeof(*opt) + 8;
-
- if (!(opt = kzalloc(opt_len, GFP_ATOMIC))) {
- return NULL;
- }
- opt-tot_len = opt_len;
- opt-dst0opt = (struct ipv6_opt_hdr *) (opt + 1);
- opt-opt_nflen = 8;
+struct ipv6_tel_txoption {
+ struct ipv6_txoptions ops;
+ __u8 dst_opt[8];
+};
- tel = (struct ipv6_tlv_tnl_enc_lim *) (opt-dst0opt + 1);
- tel-type = IPV6_TLV_TNL_ENCAP_LIMIT;
- tel-length = 1;
- tel-encap_limit = encap_limit;
+static void init_tel_txopt(struct ipv6_tel_txoption *opt, __u8 encap_limit)
+{
+ memset(opt, 0, sizeof(struct ipv6_tel_txoption));
- raw = (__u8 *) opt-dst0opt;
- raw[5] = IPV6_TLV_PADN;
- raw[6] = 1;
+ opt-dst_opt[2] = IPV6_TLV_TNL_ENCAP_LIMIT;
+ opt-dst_opt[3] = 1;
+ opt-dst_opt[4] = encap_limit;
+ opt-dst_opt[5] = IPV6_TLV_PADN;
+ opt-dst_opt[6] = 1;
- return opt;
+ opt-ops.dst0opt = (struct ipv6_opt_hdr *) opt-dst_opt;
+ opt-ops.opt_nflen = 8;
}
/**
@@ -665,8 +657,8 @@ ip6ip6_tnl_xmit(struct sk_buff *skb, str
struct ip6_tnl *t = netdev_priv(dev);
struct net_device_stats *stats = t-stat;
struct ipv6hdr *ipv6h = skb-nh.ipv6h;
- struct ipv6_txoptions *opt = NULL;
int encap_limit = -1;
+ struct ipv6_tel_txoption opt;
__u16 offset;
struct flowi fl;
struct dst_entry *dst;
@@ -695,9 +687,9 @@ ip6ip6_tnl_xmit(struct sk_buff *skb, str
goto tx_err;
}
encap_limit = tel-encap_limit - 1;
- } else if (!(t-parms.flags IP6_TNL_F_IGN_ENCAP_LIMIT)) {
+ } else if (!(t-parms.flags IP6_TNL_F_IGN_ENCAP_LIMIT))
encap_limit = t-parms.encap_limit;
- }
+
memcpy(fl, t-fl, sizeof (fl));
proto = fl.proto;
@@ -707,9 +699,6 @@ ip6ip6_tnl_xmit(struct sk_buff *skb, str
if ((t-parms.flags IP6_TNL_F_USE_ORIG_FLOWLABEL))
fl.fl6_flowlabel |= (*(__u32 *) ipv6h IPV6_FLOWLABEL_MASK);
- if (encap_limit = 0 (opt = create_tel(encap_limit)) == NULL)
- goto tx_err;
-
if ((dst = ip6_tnl_dst_check(t)) != NULL)
dst_hold(dst);
else {
@@ -730,7 +719,7 @@ ip6ip6_tnl_xmit(struct sk_buff *skb, str
goto tx_err_dst_release;
}
mtu = dst_mtu(dst) - sizeof (*ipv6h);
- if (opt) {
+ if (encap_limit = 0) {
max_headroom += 8;
mtu -= 8;
}
@@ -768,9 +757,10 @@ ip6ip6_tnl_xmit(struct sk_buff *skb, str
skb-h.raw = skb-nh.raw;
- if (opt)
- ipv6_push_nfrag_opts(skb, opt, proto, NULL);
-
+ if (encap_limit = 0) {
+ init_tel_txopt(opt, encap_limit);
+ ipv6_push_nfrag_opts(skb, opt.ops, proto, NULL);
+ }
skb-nh.raw = skb_push(skb, sizeof(struct ipv6hdr));
ipv6h = skb-nh.ipv6h;
*(u32*)ipv6h = fl.fl6_flowlabel | htonl(0x6000);
@@ -794,9 +784,6 @@ ip6ip6_tnl_xmit(struct sk_buff *skb, str
stats-tx_aborted_errors++;
}
ip6_tnl_dst_store(t, dst);
-
- kfree(opt);
-
t-recursion--;
return 0;
tx_err_link_failure:
@@ -804,7 +791,6 @@ tx_err_link_failure:
dst_link_failure(skb);
tx_err_dst_release:
dst_release(dst);
- kfree(opt);
tx_err:
stats-tx_errors++;
stats-tx_dropped++;
--
1.4.3.2
[PATCH 5/6] IPv6: Improve IPv6 tunnel error reporting
From 6b9b468f1cf3f2897fbcda389e8c2514a69c4943 Mon Sep 17 00:00:00 2001
From: Ville Nuorvala [EMAIL PROTECTED]
Date: Thu, 2 Nov 2006 12:49:47 +0200
Subject: [PATCH 5/6] IPv6: Improve IPv6 tunnel error reporting
Log an error if the remote tunnel endpoint is unable to handle
tunneled packets.
Signed-off-by: Ville Nuorvala [EMAIL PROTECTED]
---
net/ipv6/ip6_tunnel.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index a97eb52..4f64ed7 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -424,12 +424,9 @@ ip6ip6_err(struct sk_buff *skb, struct i
}
break;
case ICMPV6_PARAMPROB:
- /* ignore if parameter problem not caused by a tunnel
- encapsulation limit sub-option */
- if (code != ICMPV6_HDR_FIELD) {
- break;
- }
- teli = parse_tlv_tnl_enc_lim(skb, skb-data);
+ teli = 0;
+ if (code == ICMPV6_HDR_FIELD)
+ teli = parse_tlv_tnl_enc_lim(skb, skb-data);
if (teli teli == ntohl(info) - 2) {
tel = (struct ipv6_tlv_tnl_enc_lim *) skb-data[teli];
@@ -441,6 +438,10 @@ ip6ip6_err(struct sk_buff *skb, struct i
tunnel!\n, t-parms.name);
rel_msg = 1;
}
+ } else if (net_ratelimit()) {
+ printk(KERN_WARNING
+ %s: Recipient unable to parse tunneled
+ packet!\n , t-parms.name);
}
break;
case ICMPV6_PKT_TOOBIG:
--
1.4.3.2
[PATCH 6/6] IPv6: Fix infinite loop if no matching IPv6 tunnel found
From d9ecea2b1d88bc8702f70fbbca7cde2afb8312ee Mon Sep 17 00:00:00 2001
From: Ville Nuorvala [EMAIL PROTECTED]
Date: Thu, 2 Nov 2006 13:07:35 +0200
Subject: [PATCH 6/6] IPv6: Fix infinite loop if no matching IPv6 tunnel found
If no matching IPv6 tunnel was found ip6ip6_rcv() would cause
ip6_input_finish() to resubmit the same skb to ip6ip6_rcv().
Many thanks to Tero Kauppinen at Ericsson for reporting this issue.
Signed-off-by: Ville Nuorvala [EMAIL PROTECTED]
---
net/ipv6/ip6_tunnel.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 4f64ed7..603ed0d 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -565,11 +565,11 @@ ip6ip6_rcv(struct sk_buff *skb)
return 0;
}
read_unlock(ip6ip6_lock);
- return 1;
-
+ icmpv6_send(skb, ICMPV6_DEST_UNREACH,
+ ICMPV6_ADDR_UNREACH, 0, skb-dev);
discard:
kfree_skb(skb);
- return 0;
+ return -1;
}
struct ipv6_tel_txoption {
--
1.4.3.2
Re: cfg80211/nl80211/WE (was: Re: d80211 merge)
On Thu, 2006-11-02 at 10:56 +, Christoph Hellwig wrote: Yes, that is exatly the right way to go forward. The userspace interface is however more than just the WE ioctls. It's also that for every wireless card one single ethX device appears and not multiple devices with other names. This might sound like nitpicking, but without this all kinds of scripts break. cfg80211 doesn't care about that, it only requires you to register one logical wiphy device. Whether it has more than one netdev or not isn't significant. For d80211, however, trying to get rid of the wmasterX interface requires tighter integration in order to run a qdisc on a non-netdev wireless physical device. Which gets us back to how this thread started :) johannes - 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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
On Wed, Nov 01, 2006 at 10:31:19AM -0800, James Ketrenos wrote: The only merge requirement should be that merging d80211 doesn't break existing in-tree wireless drivers. We have that today -- you can have both stacks in the tree and running in parallel. With that, we have the ability to migrate over time. The other 'merge requirements' are functionally irrelevant. We know the d80211 stack is where wireless on Linux is going -- the sooner steps are taken to get that stack out to the masses the faster it can be adopted and improved. We had that discussion offline last week, but let's repeat it here for the general public. The most important merge requirement is to not break userspace. That means proper support of WE (hopefully via cfg80211), and a single ethX network device. The second most important is proper smp support, or good code quality in general. We can't afford to merge buggy code. Third most important is to make sure it's a full replacment for the current ieee80211 code - for the softmac cards that's mostly trivial, but the half-hard mac old intel cards are hard. That's where intel comes into play because you support that hardware _and_ are pushing for d80211. That makes your team pretty much volunteer to fix that up in my eyes. - 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 9/13] [SCTP] Merge IPv4 and IPv6 versions of get_saddr() with their corresponding get_dst().
On 10/27/06 20:47, Sridhar Samudrala wrote:
On Tue, 2006-10-17 at 03:19 +0300, Ville Nuorvala wrote:
As the IPv6 route lookup now also returns the selected source address
there is no need for a separate source address lookup. In fact, the
source address selection needs to be moved to get_dst() because the
selected IPv6 source address isn't always stored in the route.
Sometimes this makes it impossible to guess the correct address later on.
Ville,
Overall the patch looks pretty good. I found only 1 issue in
sctp_v6_get_dst(). See below.
snip
+/* Returns the dst cache entry for the given source and destination ip
+ * addresses.
+ */
+static struct dst_entry *sctp_v6_get_dst(struct sctp_association *asoc,
+ union sctp_addr *daddr,
+ union sctp_addr *saddr)
+{
+struct dst_entry *dst;
+struct flowi fl;
+struct sctp_bind_addr *bp;
+rwlock_t *addr_lock;
+struct sctp_sockaddr_entry *laddr;
+struct list_head *pos;
+struct rt6_info *rt;
+union sctp_addr baddr;
+sctp_scope_t scope;
+__u8 matchlen = 0;
+__u8 bmatchlen;
+
+memset(fl, 0, sizeof(fl));
+ipv6_addr_copy(fl.fl6_dst, daddr-v6.sin6_addr);
+if (ipv6_addr_type(daddr-v6.sin6_addr) IPV6_ADDR_LINKLOCAL)
+fl.oif = daddr-v6.sin6_scope_id;
+
+ipv6_addr_copy(fl.fl6_src, saddr-v6.sin6_addr);
+SCTP_DEBUG_PRINTK(%s: DST= NIP6_FMT SRC= NIP6_FMT ,
+ __FUNCTION__, NIP6(fl.fl6_dst), NIP6(fl.fl6_src));
+
+dst = ip6_route_output(NULL, fl);
+if (dst-error) {
+dst_release(dst);
+dst = NULL;
+}
+if (!ipv6_addr_any(saddr-v6.sin6_addr))
+goto out;
+if (!asoc) {
+if (dst)
+ipv6_addr_copy(saddr-v6.sin6_addr, fl.fl6_src);
+goto out;
+}
+bp = asoc-base.bind_addr;
+addr_lock = asoc-base.addr_lock;
+
+if (dst) {
+/* Walk through the bind address list and look for a bind
+ * address that matches the source address of the returned rt.
+ */
+sctp_v6_fl_saddr(baddr, fl, bp-port);
Here we are checking if the source address returned in the dst matches one of
the address in the bind address list of the association. Not the source
address
that is passed to this routine(it could be INADDRY_ANY).
So this should be changed back to sctp_v6_dst_saddr().
No, see that's the problem. The source address isn't always stored in
the rt6_info. Therefore I copy the address into the flowi, so after
ip6_route_output() fl does indeed contain the selected source address.
Sorry if I didn't cc you all relevant patches from the patch set.
Anyway there are still some unresolved issues with my code, but it's
nice to know I didn't at least mess up SCTP in a big way ;-)
Thanks,
Ville
-
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: (usagi-core 31424) Re: [PATCH 7/13] [RFC] [IPV6] Move source address selection into route lookup.
On 10/19/06 05:27, Mitsuru Chinen wrote: Hello again Mitsuru-san, I haven't yet had time to follow up on this issue and I would in fact need some help to proceed. http://testlab.linux-ipv6.org/tahi-autorun.2/net-2.6_20061018/ The host testlab.linux-ipv6.org doesn't seem to be visible to the outside world so could you post the results somewhere where I could take a closer look at the results? Could you actually also send me the configuration files for the TAHI test, so I could try to set up an identical test environment? Thanks, Ville - 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 6/6] IPv6: Fix infinite loop if no matching IPv6 tunnel found
In article [EMAIL PROTECTED] (at Thu, 02 Nov 2006 13:39:19 +0200), Ville Nuorvala [EMAIL PROTECTED] says: read_unlock(ip6ip6_lock); - return 1; - + icmpv6_send(skb, ICMPV6_DEST_UNREACH, + ICMPV6_ADDR_UNREACH, 0, skb-dev); discard: I'd argue this. We probably should not send back any ICMPv6 packets to the original sender in this case to avoid DoS. --yoshfuji. - 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 0/6] IPv6: IPv6 tunnel fixes
In article [EMAIL PROTECTED] (at Thu, 02 Nov 2006 13:27:05 +0200), Ville Nuorvala [EMAIL PROTECTED] says: the following incremental patches contain several fixes to ip6_tunnel.c. They are in chronological order, so the most critical one is unfortunately last. Many thanks to Tero Kauppinen for reporting that one! I ack all patches except for the last one. Note: they are in the branch of git://git.linux-ipv6.org/gitroot/yoshfuji/linux-2.6-fix/ --yoshfuji - 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/6] IPv6: Fix SIOCCHGTUNNEL bug in IPv6 tunnels
In article [EMAIL PROTECTED] (at Thu, 02 Nov 2006 13:29:31 +0200), Ville Nuorvala [EMAIL PROTECTED] says: From f9812eb0349f44f6374910ce38524f0c6f7ce8f4 Mon Sep 17 00:00:00 2001 From: Ville Nuorvala [EMAIL PROTECTED] Date: Thu, 2 Nov 2006 12:40:38 +0200 Subject: [PATCH 1/6] IPv6: Fix SIOCCHGTUNNEL bug in IPv6 tunnels A logic bug in tunnel lookup could result in duplicate tunnels when changing an existing device. Signed-off-by: Ville Nuorvala [EMAIL PROTECTED] Acked-by: YOSHIFUJI Hideaki [EMAIL PROTECTED] --yoshfuji - 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 2/6] IPv6: Do mandatory IPv6 tunnel endpoint checks in realtime
In article [EMAIL PROTECTED] (at Thu, 02 Nov 2006 13:31:34 +0200), Ville Nuorvala [EMAIL PROTECTED] says: From e60ed41fb11793d16ffcbfd56b889e0bbf04ea88 Mon Sep 17 00:00:00 2001 From: Ville Nuorvala [EMAIL PROTECTED] Date: Thu, 2 Nov 2006 12:43:50 +0200 Subject: [PATCH 2/6] IPv6: Do mandatory IPv6 tunnel endpoint checks in realtime Doing the mandatory tunnel endpoint checks when the tunnel is set up isn't enough as interfaces can go up or down and addresses can be added or deleted after this. The checks need to be done realtime when the tunnel is processing a packet. Signed-off-by: Ville Nuorvala [EMAIL PROTECTED] Acked-by: YOSHIFUJI Hideaki [EMAIL PROTECTED] However, this does not seem efficient and we'd probably better to find better way. --yoshfuji - 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 3/6] IPv6: Allow link-local tunnel endpoints
In article [EMAIL PROTECTED] (at Thu, 02 Nov 2006 13:33:48 +0200), Ville Nuorvala [EMAIL PROTECTED] says: From de1ad3df949303a1454ae0cdee0a599c0fc95e45 Mon Sep 17 00:00:00 2001 From: Ville Nuorvala [EMAIL PROTECTED] Date: Thu, 2 Nov 2006 12:45:08 +0200 Subject: [PATCH 3/6] IPv6: Allow link-local tunnel endpoints Allow link-local tunnel endpoints if the underlying link is defined. Signed-off-by: Ville Nuorvala [EMAIL PROTECTED] Acked-by: YOSHIFUJI Hideaki [EMAIL PROTECTED] --yoshfuji - 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 4/6] IPv6: Don't allocate memory for Tunnel Encapsulation Limit Option
In article [EMAIL PROTECTED] (at Thu, 02 Nov 2006 13:35:10 +0200), Ville Nuorvala [EMAIL PROTECTED] says: From b278633af228bcc986856f6492b02422c25656c7 Mon Sep 17 00:00:00 2001 From: Ville Nuorvala [EMAIL PROTECTED] Date: Thu, 2 Nov 2006 12:47:54 +0200 Subject: [PATCH 4/6] IPv6: Don't allocate memory for Tunnel Encapsulation Limit Option Signed-off-by: Ville Nuorvala [EMAIL PROTECTED] Acked-by: YOSHIFUJI Hideaki [EMAIL PROTECTED] --yoshfuji - 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/6] IPv6: Improve IPv6 tunnel error reporting
In article [EMAIL PROTECTED] (at Thu, 02 Nov 2006 13:37:29 +0200), Ville Nuorvala [EMAIL PROTECTED] says: From 6b9b468f1cf3f2897fbcda389e8c2514a69c4943 Mon Sep 17 00:00:00 2001 From: Ville Nuorvala [EMAIL PROTECTED] Date: Thu, 2 Nov 2006 12:49:47 +0200 Subject: [PATCH 5/6] IPv6: Improve IPv6 tunnel error reporting Log an error if the remote tunnel endpoint is unable to handle tunneled packets. Signed-off-by: Ville Nuorvala [EMAIL PROTECTED] Acked-by: YOSHIFUJI Hideaki [EMAIL PROTECTED] --yoshfuji - 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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
On Thu, 2 Nov 2006 12:16:57 + Christoph Hellwig [EMAIL PROTECTED] wrote: The most important merge requirement is to not break userspace. That means proper support of WE (hopefully via cfg80211), and a single ethX network device. Sounds reasonable. Though: - I don't think ethX is the appropriate name. It's not an ethernet device and many wireless drivers currently use wlanX name. I think the current wlanX name is a better choice here. - Single device is not as easy as it sounds. It would require rather invasive changes in the networking core or ugly hacks in d80211. I'm afraid this is something not achievable in a near future with current number of people working on d80211. But in general, it's doable and desirable, yes. The second most important is proper smp support, or good code quality in general. We can't afford to merge buggy code. I definitely agree here. Third most important is to make sure it's a full replacment for the current ieee80211 code - for the softmac cards that's mostly trivial, but the half-hard mac old intel cards are hard. That's where intel comes into play because you support that hardware _and_ are pushing for d80211. That makes your team pretty much volunteer to fix that up in my eyes. Let's see... Jiri -- Jiri Benc SUSE Labs - 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 6/6] IPv6: Fix infinite loop if no matching IPv6 tunnel found
In article [EMAIL PROTECTED] (at Thu, 02 Nov 2006 15:16:23 +0200), Ville Nuorvala [EMAIL PROTECTED] says: On 11/02/06 14:59, YOSHIFUJI Hideaki wrote: In article [EMAIL PROTECTED] (at Thu, 02 Nov 2006 13:39:19 +0200), Ville Nuorvala [EMAIL PROTECTED] says: read_unlock(ip6ip6_lock); - return 1; - + icmpv6_send(skb, ICMPV6_DEST_UNREACH, + ICMPV6_ADDR_UNREACH, 0, skb-dev); discard: I'd argue this. We probably should not send back any ICMPv6 packets to the original sender in this case to avoid DoS. Sorry, I don't follow you. I don't see the DoS scenario here (after we apply the patch, that is ;-). Well, leaving aside whether sending icmpv6 is good thing (*), the code for sending icmpv6 was moved from ip6_tunnel.c to tunnel6.c by commit-id 50fba2aa7cefa6b0e1768cb350c9e69042320c03 by Herbert. The ip6_tunnel.c change that Herbert made does not seem consistent with ipip.c change. To fix your issue the appropriate change is just fall through to discard section, as we're doing for ipip.c. Please do not re-add sending icmpv6 logic here. If you DO think it is appropriate, please fix other codes such as ipip.c, and your comment. *: As far as I remember, *BSD*s do not send icmpv6 in this case. Anyway, I'd talk to people at ietf next week. --yoshfuji - 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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
On Thu, Nov 02, 2006 at 12:16:57PM +, Christoph Hellwig wrote: The most important merge requirement is to not break userspace. That means proper support of WE (hopefully via cfg80211), and a single ethX network device. The second most important is proper smp support, or good code quality in general. We can't afford to merge buggy code. Third most important is to make sure it's a full replacment for the current ieee80211 code - for the softmac cards that's mostly trivial, but the half-hard mac old intel cards are hard. That's where intel comes into play because you support that hardware _and_ are pushing for d80211. That makes your team pretty much volunteer to fix that up in my eyes. +1 This aligns very well with my position. John -- John W. Linville [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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
On Thu, Nov 02, 2006 at 03:05:50PM +0100, Jiri Benc wrote: On Thu, 2 Nov 2006 12:16:57 + Christoph Hellwig [EMAIL PROTECTED] wrote: The most important merge requirement is to not break userspace. That means proper support of WE (hopefully via cfg80211), and a single ethX network device. Sounds reasonable. Though: - I don't think ethX is the appropriate name. It's not an ethernet device and many wireless drivers currently use wlanX name. I think the current wlanX name is a better choice here. This is not about the name that makes sense. I think using ethX names for wireless devices is utterly stupid, but it's what all current upstream drivers do, and at least for WE compat we'll have to stick to it. - Single device is not as easy as it sounds. It would require rather invasive changes in the networking core or ugly hacks in d80211. I'm afraid this is something not achievable in a near future with current number of people working on d80211. But in general, it's doable and desirable, yes. Again, I'm not sure it's even desirable in the end. We do however need a mode in which you can configure a single ethX device with WE and it'll just work. It's entirely reasonable to only support a subset of the functionality that way (no 802.11n, no AP mode, etc) - 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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
On Thu, 2006-11-02 at 15:05 +0100, Jiri Benc wrote: - Single device is not as easy as it sounds. It would require rather invasive changes in the networking core or ugly hacks in d80211. I'm afraid this is something not achievable in a near future with current number of people working on d80211. But in general, it's doable and desirable, yes. Actually, just as a note to all the others (talked to Jiri about it already), I think it's easier than thought since the code is so convoluted. The only purpose of the wmaster device appears to be to have an outgoing frame queue through the qdisc. Since we require the 802.11 qdisc to be installed at the root for all netdevices anyway, we could just as well hand the frame to it right away. I'll look into that later today. johannes - 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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
On Thu, 2006-11-02 at 14:18 +, Christoph Hellwig wrote: This is not about the name that makes sense. I think using ethX names for wireless devices is utterly stupid, but it's what all current upstream drivers do, and at least for WE compat we'll have to stick to it. No, that's not true, zd1201 doesn't [1] :) Has anyoen ever complained about that? In any case, tools iterate all netdevs and call some wireless ioctl to check if they are wireless, or check /proc/net/wireless (which is actually bad, but ...). Besides, WE never said that names have to have certain names. What makes you think so? johannes [1] http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;h=36b29ff058141a712619e55184566b39ce414efd;hb=aefba081d7b7dfd1c5752f6e6e709d8b5ab80ab7;f=drivers/net/wireless/zd1201.c#l1790 - 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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
Hi Johannes, On Thu, 2006-11-02 at 14:18 +, Christoph Hellwig wrote: This is not about the name that makes sense. I think using ethX names for wireless devices is utterly stupid, but it's what all current upstream drivers do, and at least for WE compat we'll have to stick to it. No, that's not true, zd1201 doesn't [1] :) Neither does hostap [2] :) Thanks, Jochen [2] http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;h=ed00ebb6e7f4bd255d1a1fe8bf05a6f7a5574d6e;hb=aefba081d7b7dfd1c5752f6e6e709d8b5ab80ab7;f=drivers/net/wireless/hostap/hostap_hw.c#l84 - 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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
On Thu, Nov 02, 2006 at 03:32:34PM +0100, Johannes Berg wrote: On Thu, 2006-11-02 at 14:18 +, Christoph Hellwig wrote: This is not about the name that makes sense. I think using ethX names for wireless devices is utterly stupid, but it's what all current upstream drivers do, and at least for WE compat we'll have to stick to it. No, that's not true, zd1201 doesn't [1] :) Has anyoen ever complained about that? In any case, tools iterate all netdevs and call some wireless ioctl to check if they are wireless, or check /proc/net/wireless (which is actually bad, but ...). Besides, WE never said that names have to have certain names. What makes you think so? I never said the name was related to WE - in fact there are tons of out of tree drivers with different names. The important bit is that upgrading a kernel adn changing the wireless stack must not change the device name. All my scripts expect my bcm43xx card to be eth1 and not wifi0 or wlansomething. There's in fact another much worse migration prblem when we want to do wlan support correctly: the advertised frametype still is 802.3 for all wlan devices (which make the current ethX names correct in some obscure very technical way) and we need to make them raw 802.11 long-term. It will probably make sense to do both migrations at the same time and have a CONFIG_ option to force the old behaviour [1]. [1] I really hate config options affecting the abi, but this is a tough problem as we can't have a etdevice with different frametypes for the same piece of hardware. maybewe could at least make it a module option.. - 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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
On Thu, 2006-11-02 at 14:45 +, Christoph Hellwig wrote: I never said the name was related to WE - in fact there are tons of out of tree drivers with different names. The important bit is that upgrading a kernel adn changing the wireless stack must not change the device name. Ah, but if that is your point then you should be arguing that the stack may not dictate the device name at all, in order to keep existing drivers able to keep whatever devicenames they were creating now... All my scripts expect my bcm43xx card to be eth1 and not wifi0 or wlansomething. But, but.. Kernel-assigned device names aren't really stable in practise, and in most distros udev will actually assign a stable name based on the mac address (which will, incidentally, apparently be ethX). Really though, I don't care about having it ethX, I rename it to whatever I want in userspace anyway. There's in fact another much worse migration prblem when we want to do wlan support correctly: the advertised frametype still is 802.3 for all wlan devices (which make the current ethX names correct in some obscure very technical way) and we need to make them raw 802.11 long-term. It will probably make sense to do both migrations at the same time and have a CONFIG_ option to force the old behaviour [1]. Making it 802.11 will probably upset dhcp, I'd think. I have no idea how to handle that, at this time. johannes - 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: [tipc-discussion] [KJ] [patch] net/tipc:sprintf/strcpy conversion
Hi, Florian Westphal wrote: walter harms [EMAIL PROTECTED] wrote: These line + strcpy(bcbearer-media.name, tipc-multicast); i gues that means tipc_bclink_name ? The idea was to change how things are done, not _what_ is being done. an even more secure version could be like this: strncpy(bcbearer-media.name,sizeof(bcbearer-media.name),tipc_bclink_na me); Ugh, please, no. The size of src is known in all cases; there is absoluty no point in using str(n|l)cpy here. (in case someone ever changes the size of cbearer-media.name or tipc_bclink_name and the hope that wchat_t will never reach the kernel) In this case 'someone' should be really hurt, don't you think? hi florian, i am on the side of error, the code increase is marginal and the speed penalty also, so why not ? you make sure that an overflow may never happen, and the rest in name gets zeroed. The problem is that when the error occurs it may be later than the actual changeset. NTL it is an hint, and if you feel ok with it and the maintainer has no objects i have no problems either. re, wh This objection I would have here is that you have would have to use strlcpy or you must explicitly set the last byte to '\0'. strncpy() will not guarnatee a null-terminated string. Also, str(n|l)cpy always writes 'n' bytes whereas strcpy() will only write as many bytes as required stopping at the null. This is inefficient. It would be better to ensure that the sting being copied is correctly sized when first accepted if this is possible. I didn't trace the usage, but it has likely already been checked for size. No? Elmer - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ tipc-discussion mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/tipc-discussion - 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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
On Thu, 2 Nov 2006 14:18:15 +, Christoph Hellwig wrote: This is not about the name that makes sense. I think using ethX names for wireless devices is utterly stupid, but it's what all current upstream drivers do, and at least for WE compat we'll have to stick to it. That's not true. Look at hostap or zd1201, for example. Also, ethX name is not needed for WE compatibility. And because of various names used by various drivers (madwifi uses ath0, for example) config scripts don't depend on ethX name today anyway. Jiri -- Jiri Benc SUSE Labs - 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] warning in SCTP
Meelis Roos wrote:
Actually, I'm backing this one out, it creates new warnings because
callers of this function pass in a const pointer.
Yes, it now seems it's not so simple. Marking it non-const there would
mark the it non-const in the whole family of sctp_state_fn_t and I'm not
sure that's the best thing to do. I guess the maintainer has better
bases for deciding what to do about it.
An alternate solution would be to make the digest a pointer, allocate
it in sctp_endpoint_init() and free it in sctp_endpoint_destroy().
I guess I should have originally done it this way...
CC [M] net/sctp/sm_make_chunk.o
net/sctp/sm_make_chunk.c: In function 'sctp_unpack_cookie':
net/sctp/sm_make_chunk.c:1358: warning: initialization discards qualifiers from
pointer target type
The reason is that sctp_unpack_cookie() takes a const struct sctp_endpoint and
modifies the digest in it
(digest being embedded in the struct, not a pointer). Make digest a pointer to
fix this warning.
Signed-off-by: Vlad Yasevich [EMAIL PROTECTED]
diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
index c6d93bb..5596f5d 100644
--- a/include/net/sctp/structs.h
+++ b/include/net/sctp/structs.h
@@ -1270,7 +1270,7 @@ struct sctp_endpoint {
* this here so we pre-allocate this once and can re-use
* on every receive.
*/
- __u8 digest[SCTP_SIGNATURE_SIZE];
+ __u8 *digest;
/* sendbuf acct. policy. */
__u32 sndbuf_policy;
diff --git a/net/sctp/endpointola.c b/net/sctp/endpointola.c
index 35c49ff..4576933 100644
--- a/net/sctp/endpointola.c
+++ b/net/sctp/endpointola.c
@@ -72,6 +72,10 @@ static struct sctp_endpoint *sctp_endpoi
{
memset(ep, 0, sizeof(struct sctp_endpoint));
+ ep-digest = kzalloc(SCTP_SIGNATURE_SIZE, gfp);
+ if (!ep-digest)
+ return NULL;
+
/* Initialize the base structure. */
/* What type of endpoint are we? */
ep-base.type = SCTP_EP_TYPE_SOCKET;
@@ -175,6 +180,9 @@ static void sctp_endpoint_destroy(struct
/* Free up the HMAC transform. */
crypto_free_hash(sctp_sk(ep-base.sk)-hmac);
+ /* Free the digest buffer */
+ kfree(ep-digest);
+
/* Cleanup. */
sctp_inq_free(ep-base.inqueue);
sctp_bind_addr_free(ep-base.bind_addr);
Re: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
On Thu, 2 Nov 2006, Jiri Benc wrote: On Thu, 2 Nov 2006 14:18:15 +, Christoph Hellwig wrote: This is not about the name that makes sense. I think using ethX names for wireless devices is utterly stupid, but it's what all current upstream drivers do, and at least for WE compat we'll have to stick to it. That's not true. Look at hostap or zd1201, for example. Also, ethX name is not needed for WE compatibility. And because of various names used by various drivers (madwifi uses ath0, for example) config scripts don't depend on ethX name today anyway. At least the ones used on my machines all do. (Debian Sarge, Etch and Unstable) The configfiles can be changed without problems to use any device name, but needing to edit various files just for a kernel update would inhibt me from just trying a new version until I really know I would not need to go back to the old version again. (Switching wireless from eth1 to eth2 after copying the harddisk contents to a new laptop was work enough, but at least expected with a new machine and changed hardware) c'ya sven -- The Internet treats censorship as a routing problem, and routes around it. (John Gilmore on http://www.cygnus.com/~gnu/) - 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
IPv6 and rt6_lookup()
Hello,
Suppose that a host has autoconfiguration enabled. It will take RA to
autoconfigure an IPv6 address. For example,
2001:0db8:3008:c1ca:2d0:b7ff:febb:4aee/64.
This host will create a route entry for this onlink prefix (dst:
2001:0db8:3008:c1ca::/64)
in the MAIN table with the lifetime present in prefix option in RA.
Each time this host will receive a RA, it will update this lifetime. To
do this,
it will call rt6_lookup() (in addrconf_prefix_rcv()) to find the entry.
Now, suppose that our host joins this anycast group:
2001:0db8:3008:c1ca::0. A route
entry will be added in the LOCAL table (see addrconf_join_anycast()).
Problem is that, next time our host will receive a RA and will perform a
rt6_lookup(),
this function will return the local entry (LOCAL table), and not the
dynamic entry
(MAIN table). Consequence is that the lifetime of the dynamic entry will
never been updated,
and so will expire, whereas the host will keep the corresponding address.
Maybe, when strict is set to 1 in rt6_lookup(), kernel must not return
an anycast route.
What about this patch ?
Regards,
Nicolas
[IPv6] Don't return anycast route when strict is enable
Signed-off-by: Nicolas DICHTEL [EMAIL PROTECTED]
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index c953466..51a8c1d 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -248,6 +248,8 @@ static __inline__ struct rt6_info *rt6_d
if (dev-ifindex == oif)
return sprt;
if (dev-flags IFF_LOOPBACK) {
+if (strict sprt-rt6i_flags RTF_ANYCAST)
+ continue;
if (sprt-rt6i_idev == NULL ||
sprt-rt6i_idev-dev-ifindex != oif) {
if (strict oif)
RE: [patch] d80211: use pfifo_qdisc_ops rather thand80211-specific qdisc
There are many reasons to have the master device - and many reasons not to get rid of it. The only excpetion is when using a limited fullmac card. Some fullmac cards only support a single ethernet interface, so for these cards a single device may be OK, if we want to allow multiple different appearences for different types of card (a bad thing in my book). (Note - older prism 54g fullmac cards support WDS, hence need multiple interfaces). The master interface represents the physical networking device that works using native 802.11 frames. The qdisc works on 802.11 frames - not ethernet, and it can change how 802.11 management frames are queued. It can only be got rid of in the case of a fullmac card with only a single interface, where all management frames are processed in the card. In addition as we move to make 802.11 devices native (i.e. create an 802.11 protocol) the 802.11 master interface will be essential. I don't see the problem with 802.11 master devices - they are not ethernet devices, and should not confuse any user space. Any user space that gets confused by netdevices with arp-hdr types that they do not recognise is broken, and needs to be fixed. Simon -Original Message- From: Johannes Berg [mailto:[EMAIL PROTECTED] Sent: Thursday, November 02, 2006 6:23 AM To: Christoph Hellwig Cc: James Ketrenos; John W. Linville; Simon Barber; Jeff Garzik; Patrick McHardy; David Kimdon; netdev@vger.kernel.org Subject: Re: [patch] d80211: use pfifo_qdisc_ops rather thand80211-specific qdisc On Thu, 2006-11-02 at 15:05 +0100, Jiri Benc wrote: - Single device is not as easy as it sounds. It would require rather invasive changes in the networking core or ugly hacks in d80211. I'm afraid this is something not achievable in a near future with current number of people working on d80211. But in general, it's doable and desirable, yes. Actually, just as a note to all the others (talked to Jiri about it already), I think it's easier than thought since the code is so convoluted. The only purpose of the wmaster device appears to be to have an outgoing frame queue through the qdisc. Since we require the 802.11 qdisc to be installed at the root for all netdevices anyway, we could just as well hand the frame to it right away. I'll look into that later today. johannes - 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: [airo.c bug] Couldn't allocate RX FID / Max tries exceeded when issueing command
On Wed, 2006-11-01 at 22:14 -0500, Ivan Matveich wrote: hardware: ibm thinkpad t30 kernel: 2.6.18 problem: airo(): Probing for PCI adapters ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11 ACPI: PCI Interrupt :02:02.0[A] - Link [LNKC] - GSI 11 (level, low) - IRQ 11 airo(eth1): Found an MPI350 card airo(eth1): Max tries exceeded when issueing command airo(eth1): Couldn't allocate RX FID airo(eth1): Could not map memory airo(): Finished probing for PCI adapters It appears that the driver cannot talk to your card; see the max tries exceeded when issueing command. Did this card work previously with a kernel? Can narrow down which kernels have problems and which don't? Any ideas? 1) Firmware upgrade/downgrade? (How?) It's a bit hard to figure out what firmware you have because the driver can't talk to the card; can you boot under Windows and determine that using the Cisco wireless utility? You also need to flash the card under Windows, not Linux, ideally to a version of firmware greater than 5.60.08. 2) Command sequence to better reset the card? Documentation? reloading the driver (rmmod airo; modprobe airo) should reset the card. Dan - 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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
I don't believe it makes sense to change the frame type except for the master interface. The interface to an 802.11 MAC (the MAC-SAP) is very similar to the interface to an 802.3 MAC. It is a 2 address format - not 3 or 4. The master interface is an internal part of the MAC, and here 802.11 frames are essential. Simon -Original Message- From: Christoph Hellwig [mailto:[EMAIL PROTECTED] Sent: Thursday, November 02, 2006 6:46 AM To: Johannes Berg Cc: Christoph Hellwig; Jiri Benc; James Ketrenos; John W. Linville; Simon Barber; Jeff Garzik; Patrick McHardy; David Kimdon; netdev@vger.kernel.org Subject: Re: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc On Thu, Nov 02, 2006 at 03:32:34PM +0100, Johannes Berg wrote: On Thu, 2006-11-02 at 14:18 +, Christoph Hellwig wrote: This is not about the name that makes sense. I think using ethX names for wireless devices is utterly stupid, but it's what all current upstream drivers do, and at least for WE compat we'll have to stick to it. No, that's not true, zd1201 doesn't [1] :) Has anyoen ever complained about that? In any case, tools iterate all netdevs and call some wireless ioctl to check if they are wireless, or check /proc/net/wireless (which is actually bad, but ...). Besides, WE never said that names have to have certain names. What makes you think so? I never said the name was related to WE - in fact there are tons of out of tree drivers with different names. The important bit is that upgrading a kernel adn changing the wireless stack must not change the device name. All my scripts expect my bcm43xx card to be eth1 and not wifi0 or wlansomething. There's in fact another much worse migration prblem when we want to do wlan support correctly: the advertised frametype still is 802.3 for all wlan devices (which make the current ethX names correct in some obscure very technical way) and we need to make them raw 802.11 long-term. It will probably make sense to do both migrations at the same time and have a CONFIG_ option to force the old behaviour [1]. [1] I really hate config options affecting the abi, but this is a tough problem as we can't have a etdevice with different frametypes for the same piece of hardware. maybewe could at least make it a module option.. - 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] d80211: use pfifo_qdisc_ops rather thand80211-specific qdisc
On Thu, 2006-11-02 at 08:33 -0800, Simon Barber wrote: There are many reasons to have the master device - and many reasons not to get rid of it. The only excpetion is when using a limited fullmac card. Some fullmac cards only support a single ethernet interface, so for these cards a single device may be OK, if we want to allow multiple different appearences for different types of card (a bad thing in my book). (Note - older prism 54g fullmac cards support WDS, hence need multiple interfaces). The master interface represents the physical networking device that works using native 802.11 frames. The qdisc works on 802.11 frames - not ethernet, and it can change how 802.11 management frames are queued. It can only be got rid of in the case of a fullmac card with only a single interface, where all management frames are processed in the card. In addition as we move to make 802.11 devices native (i.e. create an 802.11 protocol) the 802.11 master interface will be essential. While these are good points, I don't believe having the master interface as a *netdev* is essential. In fact, it now has no functionality as a netdev, if you try routing packets over it they're simply dropped. Of course we need some notion of the wireless PHY and cfg80211 explicitly represents that by assigning a wiphy index, but there's no need for it to be a netdev. johannes signature.asc Description: This is a digitally signed message part
Re: IPv6 and rt6_lookup()
Nicolas DICHTEL wrote:
Hello,
Suppose that a host has autoconfiguration enabled. It will take RA to
autoconfigure an IPv6 address. For example,
2001:0db8:3008:c1ca:2d0:b7ff:febb:4aee/64.
This host will create a route entry for this onlink prefix (dst:
2001:0db8:3008:c1ca::/64)
in the MAIN table with the lifetime present in prefix option in RA.
Each time this host will receive a RA, it will update this lifetime. To
do this,
it will call rt6_lookup() (in addrconf_prefix_rcv()) to find the entry.
Now, suppose that our host joins this anycast group:
2001:0db8:3008:c1ca::0. A route
Hmm... you are configuring a subnet router anycast address on host and
the implementation lets you do it? That's not good. I don't think
you sould be permitted to configure a subnet router anycast address
on a host that autoconfigures it's interface.
-vlad
entry will be added in the LOCAL table (see addrconf_join_anycast()).
Problem is that, next time our host will receive a RA and will perform a
rt6_lookup(),
this function will return the local entry (LOCAL table), and not the
dynamic entry
(MAIN table). Consequence is that the lifetime of the dynamic entry will
never been updated,
and so will expire, whereas the host will keep the corresponding address.
Maybe, when strict is set to 1 in rt6_lookup(), kernel must not return
an anycast route.
What about this patch ?
Regards,
Nicolas
[IPv6] Don't return anycast route when strict is enable
Signed-off-by: Nicolas DICHTEL [EMAIL PROTECTED]
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index c953466..51a8c1d 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -248,6 +248,8 @@ static __inline__ struct rt6_info *rt6_d
if (dev-ifindex == oif)
return sprt;
if (dev-flags IFF_LOOPBACK) {
+ if (strict sprt-rt6i_flags RTF_ANYCAST)
+ continue;
if (sprt-rt6i_idev == NULL ||
sprt-rt6i_idev-dev-ifindex != oif) {
if (strict oif)
-
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 and rt6_lookup()
Le 02.11.2006 18:02, Vlad Yasevich a écrit : Nicolas DICHTEL wrote: Hello, Suppose that a host has autoconfiguration enabled. It will take RA to autoconfigure an IPv6 address. For example, 2001:0db8:3008:c1ca:2d0:b7ff:febb:4aee/64. This host will create a route entry for this onlink prefix (dst: 2001:0db8:3008:c1ca::/64) in the MAIN table with the lifetime present in prefix option in RA. Each time this host will receive a RA, it will update this lifetime. To do this, it will call rt6_lookup() (in addrconf_prefix_rcv()) to find the entry. Now, suppose that our host joins this anycast group: 2001:0db8:3008:c1ca::0. A route Hmm... you are configuring a subnet router anycast address on host and the implementation lets you do it? That's not good. I don't think you sould be permitted to configure a subnet router anycast address on a host that autoconfigures it's interface. The current implementation allow this and I don't know if we must prohibit this. For example, in case of NEMO (RFC3963), router may autoconfigured its address. Nicolas - 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] Update SNMP basic for full IP address NAT
All,
This patch applies to the netfilter file nat_ip_snmp_basic.c
The algorithm now applies NAT to the complete IP address (and not only
the first byte)
It also recomputes the UDP checksum accordingly.
Please apply this patch to the 2.6.18.1 official release.
Many thanks to Remy Harel for his early contributions on this code.
Gilles Kerdoncuff
---
--- linux-2.6.18.1/net/ipv4/netfilter/ip_nat_snmp_basic.c
2006-10-14 05:34:03.0 +0200
+++ linux/net/ipv4/netfilter/ip_nat_snmp_basic.c2006-11-02
17:02:24.0 +0100
@@ -70,14 +70,12 @@
static DEFINE_SPINLOCK(snmp_lock);
/*
- * Application layer address mapping mimics the NAT mapping, but
- * only for the first octet in this case (a more flexible system
- * can be implemented if needed).
+ * Application layer address mapping (complete IP)
*/
-struct oct1_map
+struct ip_map
{
- u_int8_t from;
- u_int8_t to;
+ u_int32_t from;
+ u_int32_t to;
};
@@ -612,7 +610,7 @@
static inline void mangle_address(unsigned char *begin,
unsigned char *addr,
- const struct oct1_map *map,
+ const struct ip_map *map,
u_int16_t *check);
struct snmp_cnv
{
@@ -907,6 +905,23 @@
csum[1] = x 0xFF;
}
+/* Fast checksum update on 16 bits */
+static void update_csum(u_int16_t *csum,
+u_int16_t *old_addr,
+u_int16_t *new_addr,
+int odd)
+{
+ /* The idea is to call 4 times the fast csum function which
recalculate the new
+* csum according to the new ip address in the payload
+*/
+ int i;
+ for (i=0;i4;i++) {
+ fast_csum((unsigned char*)csum, ((const unsigned
char*)(old_addr))+i, ((const unsigned char*)(new_addr))+i,(odd+i)%2 );
+ }
+}
+
+
+
/*
* Mangle IP address.
* - begin points to the start of the snmp messgae
@@ -914,24 +929,22 @@
*/
static inline void mangle_address(unsigned char *begin,
unsigned char *addr,
- const struct oct1_map *map,
+ const struct ip_map *map,
u_int16_t *check)
{
- if (map-from == NOCT1(*addr)) {
- u_int32_t old;
-
- if (debug)
- memcpy(old, (unsigned char *)addr,
sizeof(old));
-
- *addr = map-to;
-
+ u_int32_t old;
+
+ memcpy(old, (unsigned char *)addr, sizeof(old));
+
+ if (map-from == old) {
+ *((u_int32_t*) addr) = map-to;
+
/* Update UDP checksum if being used */
if (*check) {
unsigned char odd = !((addr - begin) % 2);
- fast_csum((unsigned char *)check,
- map-from, map-to, odd);
-
+ update_csum(check, (u_int16_t*)old,
(u_int16_t*)addr, odd);
+
}
if (debug)
@@ -942,7 +955,7 @@
static unsigned char snmp_trap_decode(struct asn1_ctx *ctx,
struct snmp_v1_trap *trap,
- const struct oct1_map *map,
+ const struct ip_map *map,
u_int16_t *check)
{
unsigned int cls, con, tag, len;
@@ -1036,7 +1049,7 @@
*/
static int snmp_parse_mangle(unsigned char *msg,
u_int16_t len,
- const struct oct1_map *map,
+ const struct ip_map *map,
u_int16_t *check)
{
unsigned char *eoc, *end;
@@ -1215,7 +1228,7 @@
u_int16_t udplen = ntohs(udph-len);
u_int16_t paylen = udplen - sizeof(struct udphdr);
int dir = CTINFO2DIR(ctinfo);
- struct oct1_map map;
+ struct ip_map map;
/*
* Determine mappping for application layer addresses based
@@ -1223,12 +1236,12 @@
*/
if (dir == IP_CT_DIR_ORIGINAL) {
/* SNAT traps */
- map.from =
NOCT1(ct-tuplehash[IP_CT_DIR_ORIGINAL].tuple.src.ip);
- map.to =
NOCT1(ct-tuplehash[IP_CT_DIR_REPLY].tuple.dst.ip);
+ map.from =
ct-tuplehash[IP_CT_DIR_ORIGINAL].tuple.src.ip;
+ map.to = ct-tuplehash[IP_CT_DIR_REPLY].tuple.dst.ip;
} else {
/* DNAT replies */
- map.from =
NOCT1(ct-tuplehash[IP_CT_DIR_REPLY].tuple.src.ip);
- map.to =
NOCT1(ct-tuplehash[IP_CT_DIR_ORIGINAL].tuple.dst.ip);
+ map.from = ct-tuplehash[IP_CT_DIR_REPLY].tuple.src.ip;
+ map.to =
Re: [PATCH 9/13] [SCTP] Merge IPv4 and IPv6 versions of get_saddr() with their corresponding get_dst().
On Thu, 2006-11-02 at 14:32 +0200, Ville Nuorvala wrote:
On 10/27/06 20:47, Sridhar Samudrala wrote:
On Tue, 2006-10-17 at 03:19 +0300, Ville Nuorvala wrote:
As the IPv6 route lookup now also returns the selected source address
there is no need for a separate source address lookup. In fact, the
source address selection needs to be moved to get_dst() because the
selected IPv6 source address isn't always stored in the route.
Sometimes this makes it impossible to guess the correct address later on.
Ville,
Overall the patch looks pretty good. I found only 1 issue in
sctp_v6_get_dst(). See below.
snip
+/* Returns the dst cache entry for the given source and destination ip
+ * addresses.
+ */
+static struct dst_entry *sctp_v6_get_dst(struct sctp_association *asoc,
+ union sctp_addr *daddr,
+ union sctp_addr *saddr)
+{
+ struct dst_entry *dst;
+ struct flowi fl;
+ struct sctp_bind_addr *bp;
+ rwlock_t *addr_lock;
+ struct sctp_sockaddr_entry *laddr;
+ struct list_head *pos;
+ struct rt6_info *rt;
+ union sctp_addr baddr;
+ sctp_scope_t scope;
+ __u8 matchlen = 0;
+ __u8 bmatchlen;
+
+ memset(fl, 0, sizeof(fl));
+ ipv6_addr_copy(fl.fl6_dst, daddr-v6.sin6_addr);
+ if (ipv6_addr_type(daddr-v6.sin6_addr) IPV6_ADDR_LINKLOCAL)
+ fl.oif = daddr-v6.sin6_scope_id;
+
+ ipv6_addr_copy(fl.fl6_src, saddr-v6.sin6_addr);
+ SCTP_DEBUG_PRINTK(%s: DST= NIP6_FMT SRC= NIP6_FMT ,
+__FUNCTION__, NIP6(fl.fl6_dst), NIP6(fl.fl6_src));
+
+ dst = ip6_route_output(NULL, fl);
+ if (dst-error) {
+ dst_release(dst);
+ dst = NULL;
+ }
+ if (!ipv6_addr_any(saddr-v6.sin6_addr))
+ goto out;
+ if (!asoc) {
+ if (dst)
+ ipv6_addr_copy(saddr-v6.sin6_addr, fl.fl6_src);
+ goto out;
+ }
+ bp = asoc-base.bind_addr;
+ addr_lock = asoc-base.addr_lock;
+
+ if (dst) {
+ /* Walk through the bind address list and look for a bind
+ * address that matches the source address of the returned rt.
+ */
+ sctp_v6_fl_saddr(baddr, fl, bp-port);
Here we are checking if the source address returned in the dst matches one
of
the address in the bind address list of the association. Not the source
address
that is passed to this routine(it could be INADDRY_ANY).
So this should be changed back to sctp_v6_dst_saddr().
No, see that's the problem. The source address isn't always stored in
the rt6_info. Therefore I copy the address into the flowi, so after
ip6_route_output() fl does indeed contain the selected source address.
Sorry if I didn't cc you all relevant patches from the patch set.
When you said that IPV6 route lookup returns the selected source
address, i assumed it will be returned via rt6_info-rt6i_src. But
looks like it is returned in fl-fl6_src. If so, there is no problem.
Why is rt6i_src not filled in some cases?
I noticed this problem when i ran SCTP frametests that use a IP
simulator in userspace. We have our own ip6_route_output that i
modified to set source in rt6_info and not fl.
Thanks
Sridhar
Anyway there are still some unresolved issues with my code, but it's
nice to know I didn't at least mess up SCTP in a big way ;-)
Thanks,
Ville
-
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] warning in SCTP
On Thu, 2006-11-02 at 11:09 -0500, Vlad Yasevich wrote: Meelis Roos wrote: Actually, I'm backing this one out, it creates new warnings because callers of this function pass in a const pointer. Yes, it now seems it's not so simple. Marking it non-const there would mark the it non-const in the whole family of sctp_state_fn_t and I'm not sure that's the best thing to do. I guess the maintainer has better bases for deciding what to do about it. An alternate solution would be to make the digest a pointer, allocate it in sctp_endpoint_init() and free it in sctp_endpoint_destroy(). I agree that this is a better solution. Acked-by: Sridhar Samudrala [EMAIL PROTECTED] Thanks Sridhar I guess I should have originally done it this way... CC [M] net/sctp/sm_make_chunk.o net/sctp/sm_make_chunk.c: In function 'sctp_unpack_cookie': net/sctp/sm_make_chunk.c:1358: warning: initialization discards qualifiers from pointer target type The reason is that sctp_unpack_cookie() takes a const struct sctp_endpoint and modifies the digest in it (digest being embedded in the struct, not a pointer). Make digest a pointer to fix this warning. Signed-off-by: Vlad Yasevich [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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
On Thu, 2 Nov 2006 17:09:24 +0100 (CET), Sven-Haegar Koch wrote: At least the ones used on my machines all do. (Debian Sarge, Etch and Unstable) The configfiles can be changed without problems to use any device name, but needing to edit various files just for a kernel update would inhibt me from just trying a new version until I really know I would not need to go back to the old version again. Then your config scripts don't work with Prism and Zydas cards. Something is broken with your setup. (Switching wireless from eth1 to eth2 after copying the harddisk contents to a new laptop was work enough, but at least expected with a new machine and changed hardware) Because nobody can guarantee you even the order of your Ethernet interfaces with newer kernels (e.g. your eth0 Ethernet card may become eth1 at any time) and it will become even worse with the parallel device discovery, your setup is going to explode anyway. Sorry, I can't take this as an argument. Using your argumentation, we must preserve wlan0 name because scripts of zd1201 users will break otherwise. Or - wait a moment - no no, we must preserve ath0 name because of madwifi users - and oh, we must preserve eth1 (not ethX because the scripts cannot deal with it) because of ipw users. And we must definitely ensure that card numbers won't ever change. Even if you uplug them and replug to another slots in a different order. Sorry, that cannot work. Jiri -- Jiri Benc SUSE Labs - 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
Fw: [Bugme-new] [Bug 7450] New: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
Begin forwarded message: Date: Thu, 2 Nov 2006 06:41:04 -0800 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Bugme-new] [Bug 7450] New: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang http://bugzilla.kernel.org/show_bug.cgi?id=7450 Summary: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang Kernel Version: 2.6.19-rc3 Status: NEW Severity: normal Owner: [EMAIL PROTECTED] Submitter: [EMAIL PROTECTED] Most recent kernel where this bug did not occur: not known Distribution: Gentoo Linux x86_64 Hardware Environment: lspci 00:00.0 Host bridge: Intel Corporation E7230/3000/3010 Memory Controller Hub (rev c0) 00:01.0 PCI bridge: Intel Corporation E7230/3000/3010 PCI Express Root Port (rev c0) 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01) 00:1c.4 PCI bridge: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI Express Port 5 (rev 01) 00:1c.5 PCI bridge: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI Express Port 6 (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1) 00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01) 00:1f.2 SATA controller: Intel Corporation 82801GR/GH (ICH7 Family) Serial ATA Storage Controller AHCI (rev 01) 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01) 01:00.0 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge A (rev 09) 01:00.1 PIC: Intel Corporation 6700/6702PXH I/OxAPIC Interrupt Controller A (rev 09) 01:00.2 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge B (rev 09) 01:00.3 PIC: Intel Corporation 6700PXH I/OxAPIC Interrupt Controller B (rev 09) 0d:00.0 Ethernet controller: Intel Corporation 82573E Gigabit Ethernet Controller (Copper) (rev 03) 0e:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller 0f:04.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02) Software Environment: Iptables/Iproute2 Problem Description: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang Tx Queue 0 TDH 31 TDT 31 next_to_use 31 next_to_cleanaf buffer_info[next_to_clean] time_stamp 1014b175c next_to_watchaf jiffies 1014b1875 next_to_watch.status 1 e1000: eth1: e1000_clean_tx_irq: Detected Tx Unit Hang Tx Queue 0 TDH 36 TDT 36 next_to_use 36 next_to_cleanb8 buffer_info[next_to_clean] time_stamp 1014b1922 next_to_watchb9 jiffies 1014b1a7c next_to_watch.status 1 e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang Tx Queue 0 TDH fa TDT fa next_to_use fa next_to_clean7f buffer_info[next_to_clean] time_stamp 1014b194b next_to_watch80 jiffies 1014b1ae0 next_to_watch.status 1 printk: 423 messages suppressed. dst cache overflow e1000: eth1: e1000_clean_tx_irq: Detected Tx Unit Hang Tx Queue 0 TDH cf TDT cf next_to_use cf next_to_clean56 buffer_info[next_to_clean] time_stamp 1014b1bb7 next_to_watch57 jiffies 1014b1cc9 next_to_watch.status 1 e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang Tx Queue 0 TDH 8c TDT 8c next_to_use 8c next_to_cleanfe buffer_info[next_to_clean] time_stamp 1014b1bef next_to_watchfe jiffies 1014b1d86 next_to_watch.status 1 e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang Tx Queue 0 TDH ee TDT ee next_to_use ee next_to_clean59 buffer_info[next_to_clean] time_stamp 1014b1ddd next_to_watch59 jiffies 1014b1fb6 next_to_watch.status 1 0d:00.0 Ethernet controller: Intel Corporation 82573E Gigabit Ethernet Controller (Copper) (rev 03) Subsystem: Super Micro Computer Inc Unknown device 108c Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 0, Cache Line Size 10 Interrupt: pin A routed to IRQ 16 Region 0: Memory at e020 (32-bit, non-prefetchable) [size=128K] Region 2: I/O ports at 4000 [size=32] Capabilities: [c8] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=1 PME- Capabilities: [d0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Address: Data:
Re: [airo.c bug] Couldn't allocate RX FID / Max tries exceeded when issueing command
On 11/2/06, Dan Williams [EMAIL PROTECTED] wrote: It appears that the driver cannot talk to your card; see the max tries exceeded when issueing command. Did this card work previously with a kernel? Can narrow down which kernels have problems and which don't? It spontaneously stopped working about a week after I bought the laptop and installed Linux. I tried kernel 2.6.12 and it had the same problem. (Let me know if you'd like me to try a specific version.) I'm hoping that the card has simply got itself into some kind of invalid state, and not failed altogether. It's a bit hard to figure out what firmware you have because the driver can't talk to the card; can you boot under Windows and determine that using the Cisco wireless utility? You also need to flash the card under Windows, not Linux, ideally to a version of firmware greater than 5.60.08. I haven't run Windows in many years, so that's problematic. What's the most straightforward way to boot into a Windows environment sufficient to run the Cisco wireless utility? reloading the driver (rmmod airo; modprobe airo) should reset the card. Yeah, it unfortunately doesn't help. (Nor does rebooting or resetting the bios.) I noticed a suspiciously relevant commit in the airo.c git log: [wireless airo] reset card in init without this patch after an rmmod, modprobe the card won't work anymore until the next reboot. This patch seem safe to apply for all cards as the bsd driver already do that. I had to add a timeout because strange things happen (issuecommand will fail) if the card is already reseted (after a reboot). PS : it seems there are missing reset when leaving monitor mode... Signed-off-by: Matthieu CASTET [EMAIL PROTECTED] and that makes me wonder if there might be some kind of subtle bug in the card initialization sequence that manifests itself with my particular card/firmware. I think I'll burn a freebsd livecd today and see if their kernel works. - 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: [airo.c bug] Couldn't allocate RX FID / Max tries exceeded when issueing command
On Thu, 2006-11-02 at 13:30 -0500, Ivan Matveich wrote: On 11/2/06, Dan Williams [EMAIL PROTECTED] wrote: It appears that the driver cannot talk to your card; see the max tries exceeded when issueing command. Did this card work previously with a kernel? Can narrow down which kernels have problems and which don't? It spontaneously stopped working about a week after I bought the That does not bode well for the card itself. laptop and installed Linux. I tried kernel 2.6.12 and it had the same problem. (Let me know if you'd like me to try a specific version.) 2.6.12 should be old enough, but maybe if you could try 2.6.9 that would definitely be old enough to rule out recent airo changes. I'm hoping that the card has simply got itself into some kind of invalid state, and not failed altogether. It's a bit hard to figure out what firmware you have because the driver can't talk to the card; can you boot under Windows and determine that using the Cisco wireless utility? You also need to flash the card under Windows, not Linux, ideally to a version of firmware greater than 5.60.08. I haven't run Windows in many years, so that's problematic. What's the most straightforward way to boot into a Windows environment sufficient to run the Cisco wireless utility? You get to either install windows on your laptop, or pull the card (pcmcia or minipci, either way) and put it into a windows computer. reloading the driver (rmmod airo; modprobe airo) should reset the card. Yeah, it unfortunately doesn't help. (Nor does rebooting or resetting the bios.) I noticed a suspiciously relevant commit in the airo.c git log: [wireless airo] reset card in init without this patch after an rmmod, modprobe the card won't work anymore until the next reboot. This patch seem safe to apply for all cards as the bsd driver already do that. I had to add a timeout because strange things happen (issuecommand will fail) if the card is already reseted (after a reboot). PS : it seems there are missing reset when leaving monitor mode... Signed-off-by: Matthieu CASTET [EMAIL PROTECTED] Do you know which kernel version that patch first appeared in? and that makes me wonder if there might be some kind of subtle bug in the card initialization sequence that manifests itself with my particular card/firmware. Could be, it would be quite helpful to get the version of firmware you are using. Versions earlier than 5.30.17 are known not be flaky or even not work with newer Linux kernel drivers since Cisco changed the firmware interface in that version. That said, I've seen cards in the 5.00.xx range work with the latest drivers, but not well. These older firmware versions sometimes lock up sponaneously and require a reboot, updating to later firmware post-5.30.17 fixes that problem. I think I'll burn a freebsd livecd today and see if their kernel works. That would be a great idea, let us know what the results are, especially if you cna figure out which firmware version you have, or if the card itself is really just dead. Thanks, Dan - 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: [take22 0/4] kevent: Generic event handling mechanism.
On 11/1/06, Evgeniy Polyakov [EMAIL PROTECTED] wrote: On Wed, Nov 01, 2006 at 06:12:41PM -0800, Nate Diller ([EMAIL PROTECTED]) wrote: Indesiciveness has certainly been an issue here, but I remember akpm and Ulrich both giving concrete suggestions. I was particularly interested in Andrew's request to explain and justify the differences between kevent and BSD's kqueue interface. Was there a discussion that I missed? I am very interested to see your work on this mechanism merged, because you've clearly emphasized performance and shown impressive results. But it seems like we lose out on a lot by throwing out all the applications that already use kqueue. It looks you missed that discussion - freebsd kqueue has fields in the kevent structure which have diffent sizes in 32 and 64 bit environments. Are you saying that the *only* reason we choose not to be source-compatible with BSD is the 32 bit userland on 64 bit arch problem? I've followed every thread that gmail 'kqueue' search returns, which thread are you referring to? Nicholas Miell, in The Proposed Linux kevent API thread, seems to think that there are no advantages over kqueue to justify the incompatibility, an argument you made no effort to refute. I've also read the Kevent wiki at linux-net.osdl.org, but it too is lacking in any direct comparisons (even theoretical, let alone benchmarks) of the flexibility, performance, etc. between the two. I'm not arguing that you've done a bad design, I'm asking you to brag about the things you improved on vs. kqueue. Your emphasis on unifying all the different event types into one interface is really cool, fill me in on why that can't be effectively done with the kqueue compatability and I also will advocate for kevent inclusion. NATE - 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: TCP congestion graphs (2.6.19-rc4)
On Wed, 01 Nov 2006 21:44:18 -0800 (PST) David Miller [EMAIL PROTECTED] wrote: From: Stephen Hemminger [EMAIL PROTECTED] Date: Tue, 31 Oct 2006 21:58:48 -0800 Some basic stuff is on the parent page http://developer.osdl.org/shemminger/tcp Are you using tcptrace to generate those plots? If so are you using xplot or gnuplot to build those image files? Description now up on linux-net http://linux-net.osdl.org/index.php/TCP_testing I use tcpprobe kernel module because you can't directly see congestion window from packet captures. -- 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
[TG3]: Fix 2nd ifup failure on 5752M.
[TG3]: Fix 2nd ifup failure on 5752M. This fixes a bug reported in: http://bugzilla.kernel.org/show_bug.cgi?id=7438 tg3_close() turns off the PHY if WoL and ASF are both disabled. On the next tg3_open(), some devices such as the 5752M will not be brought up correctly without a PHY reset early in the reset sequence. The PHY clock is needed for some internal MAC blocks to function correctly. This problem is fixed by always resetting the PHY early in tg3_reset_hw() when it is called from tg3_open() or tg3_resume(). tg3_setup_phy() can then be called later in the sequence without the reset_phy parameter set to 1, since the PHY reset is already done. Update version to 3.68. Signed-off-by: Michael Chan [EMAIL PROTECTED] diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c index 8e39849..8f059b7 100644 --- a/drivers/net/tg3.c +++ b/drivers/net/tg3.c @@ -68,8 +68,8 @@ #include tg3.h #define DRV_MODULE_NAMEtg3 #define PFX DRV_MODULE_NAME: -#define DRV_MODULE_VERSION 3.67 -#define DRV_MODULE_RELDATE October 18, 2006 +#define DRV_MODULE_VERSION 3.68 +#define DRV_MODULE_RELDATE November 02, 2006 #define TG3_DEF_MAC_MODE 0 #define TG3_DEF_RX_MODE0 @@ -6014,7 +6014,7 @@ static int tg3_reset_hw(struct tg3 *tp, tg3_abort_hw(tp, 1); } - if ((tp-tg3_flags2 TG3_FLG2_MII_SERDES) reset_phy) + if (reset_phy) tg3_phy_reset(tp); err = tg3_chip_reset(tp); @@ -6574,7 +6574,7 @@ #endif tw32(GRC_LOCAL_CTRL, tp-grc_local_ctrl); } - err = tg3_setup_phy(tp, reset_phy); + err = tg3_setup_phy(tp, 0); if (err) return err; - 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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
On Thu, 2006-11-02 at 19:38 +0100, Jiri Benc wrote: On Thu, 2 Nov 2006 17:09:24 +0100 (CET), Sven-Haegar Koch wrote: At least the ones used on my machines all do. (Debian Sarge, Etch and Unstable) The configfiles can be changed without problems to use any device name, but needing to edit various files just for a kernel update would inhibt me from just trying a new version until I really know I would not need to go back to the old version again. Then your config scripts don't work with Prism and Zydas cards. Something is broken with your setup. (Switching wireless from eth1 to eth2 after copying the harddisk contents to a new laptop was work enough, but at least expected with a new machine and changed hardware) Because nobody can guarantee you even the order of your Ethernet interfaces with newer kernels (e.g. your eth0 Ethernet card may become eth1 at any time) and it will become even worse with the parallel device discovery, your setup is going to explode anyway. Sorry, I can't take this as an argument. Using your argumentation, we must preserve wlan0 name because scripts of zd1201 users will break otherwise. Or - wait a moment - no no, we must preserve ath0 name because of madwifi users - and oh, we must preserve eth1 (not ethX because the scripts cannot deal with it) because of ipw users. And we must definitely ensure that card numbers won't ever change. Even if you uplug them and replug to another slots in a different order. Sorry, that cannot work. Right. Nothing should be relying on the actual device name, they should be relying on the MAC address or some other UID of the actual device. In many distros, the config scripts depend on a set name, but only _AFTER_ they have check the devices MAC address, matched that up with a MAC-devname table, and renamed the device. That's somewhat sane, but scripts cannot just rely on the device name without checking some other unique attribute of the device. Dan Jiri - 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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
Perhaps the solution is to allow the prefix to be a kernel configuration item? Simon -Original Message- From: Jiri Benc [mailto:[EMAIL PROTECTED] Sent: Thursday, November 02, 2006 10:39 AM To: Sven-Haegar Koch Cc: Christoph Hellwig; James Ketrenos; John W. Linville; Simon Barber; Jeff Garzik; Patrick McHardy; David Kimdon; netdev@vger.kernel.org Subject: Re: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc On Thu, 2 Nov 2006 17:09:24 +0100 (CET), Sven-Haegar Koch wrote: At least the ones used on my machines all do. (Debian Sarge, Etch and Unstable) The configfiles can be changed without problems to use any device name, but needing to edit various files just for a kernel update would inhibt me from just trying a new version until I really know I would not need to go back to the old version again. Then your config scripts don't work with Prism and Zydas cards. Something is broken with your setup. (Switching wireless from eth1 to eth2 after copying the harddisk contents to a new laptop was work enough, but at least expected with a new machine and changed hardware) Because nobody can guarantee you even the order of your Ethernet interfaces with newer kernels (e.g. your eth0 Ethernet card may become eth1 at any time) and it will become even worse with the parallel device discovery, your setup is going to explode anyway. Sorry, I can't take this as an argument. Using your argumentation, we must preserve wlan0 name because scripts of zd1201 users will break otherwise. Or - wait a moment - no no, we must preserve ath0 name because of madwifi users - and oh, we must preserve eth1 (not ethX because the scripts cannot deal with it) because of ipw users. And we must definitely ensure that card numbers won't ever change. Even if you uplug them and replug to another slots in a different order. Sorry, that cannot work. Jiri -- Jiri Benc SUSE Labs - 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: Fw: [Bugme-new] [Bug 7450] New: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
Andrew Morton wrote: Begin forwarded message: Date: Thu, 2 Nov 2006 06:41:04 -0800 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Bugme-new] [Bug 7450] New: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang http://bugzilla.kernel.org/show_bug.cgi?id=7450 Summary: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang Kernel Version: 2.6.19-rc3 Status: NEW Severity: normal Owner: [EMAIL PROTECTED] Submitter: [EMAIL PROTECTED] Most recent kernel where this bug did not occur: not known Distribution: Gentoo Linux x86_64 Hardware Environment: lspci 00:00.0 Host bridge: Intel Corporation E7230/3000/3010 Memory Controller Hub (rev c0) 00:01.0 PCI bridge: Intel Corporation E7230/3000/3010 PCI Express Root Port (rev c0) 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01) 00:1c.4 PCI bridge: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI Express Port 5 (rev 01) 00:1c.5 PCI bridge: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI Express Port 6 (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1) 00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01) 00:1f.2 SATA controller: Intel Corporation 82801GR/GH (ICH7 Family) Serial ATA Storage Controller AHCI (rev 01) 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01) 01:00.0 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge A (rev 09) 01:00.1 PIC: Intel Corporation 6700/6702PXH I/OxAPIC Interrupt Controller A (rev 09) 01:00.2 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge B (rev 09) 01:00.3 PIC: Intel Corporation 6700PXH I/OxAPIC Interrupt Controller B (rev 09) 0d:00.0 Ethernet controller: Intel Corporation 82573E Gigabit Ethernet Controller (Copper) (rev 03) 0e:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller 0f:04.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02) Software Environment: Iptables/Iproute2 Problem Description: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang Tx Queue 0 TDH 31 TDT 31 the hang is caused by a bad eeprom bit. A script that fixes it for 82573-series with eeproms that need this bit fixed is attached to the bugreport. It detects the proper chipset and patches if required (uses ethtool). hth, Auke - 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] d80211: use pfifo_qdisc_ops rather thand80211-specific qdisc
On Thu, 02 Nov 2006 17:43:57 +0100 Johannes Berg [EMAIL PROTECTED] wrote: On Thu, 2006-11-02 at 08:33 -0800, Simon Barber wrote: There are many reasons to have the master device - and many reasons not to get rid of it. The only excpetion is when using a limited fullmac card. Some fullmac cards only support a single ethernet interface, so for these cards a single device may be OK, if we want to allow multiple different appearences for different types of card (a bad thing in my book). (Note - older prism 54g fullmac cards support WDS, hence need multiple interfaces). The master interface represents the physical networking device that works using native 802.11 frames. The qdisc works on 802.11 frames - not ethernet, and it can change how 802.11 management frames are queued. It can only be got rid of in the case of a fullmac card with only a single interface, where all management frames are processed in the card. In addition as we move to make 802.11 devices native (i.e. create an 802.11 protocol) the 802.11 master interface will be essential. While these are good points, I don't believe having the master interface as a *netdev* is essential. In fact, it now has no functionality as a netdev, if you try routing packets over it they're simply dropped. It makes 802.11 packet capture easier as well. Please don't invent yet another network access object for the master device. Of course we need some notion of the wireless PHY and cfg80211 explicitly represents that by assigning a wiphy index, but there's no need for it to be a netdev. johannes -- 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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
On Thu, 2 Nov 2006 13:27:59 -0800 Simon Barber [EMAIL PROTECTED] wrote: Perhaps the solution is to allow the prefix to be a kernel configuration item? Simon All modern distro's support device naming stuff through hotplug. Don't put effort into keeping the kernel defaults absolute. Please have Ethernet (and wireless) devices show up as eth%d. For the master device, choose something else (mac%d ?). -- 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] d80211: use pfifo_qdisc_ops rather thand80211-specific qdisc
On Thu, 2006-11-02 at 14:34 -0800, Stephen Hemminger wrote: It makes 802.11 packet capture easier as well. Please don't invent yet another network access object for the master device. Oh, but the master device doesn't get any packets you could capture. For that, you need to add a monitor interface. johannes signature.asc Description: This is a digitally signed message part
Re: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
On 11/2/06, Stephen Hemminger [EMAIL PROTECTED] wrote: Please have Ethernet (and wireless) devices show up as eth%d. For the master device, choose something else (mac%d ?). If ultimately we're going to make wireless devices, as John puts it, 1st class citizens by making 802.11 a full protocol we should just start sticking to a new convention. Before when we didn't have any softmac drivers in the kernel ethX made sense, with softmac this isn't so clear, but with 802.11 as a full protocol perhaps wlanX will finally make perfect sense. For the master device yes, how about mac%d as its there do 802.11 MAC management. - 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 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled
On Wednesday 01 November 2006 11:15 pm, Greg KH wrote:
Argh, there were just too many different versions of these patches
floating around. Can you resend the final versions please?
This should replace BOTH of Randy's patches. It addresses all the
issues I've heard raised, and resolves the regresssion introduced
when adding the mcs7830 minidriver.
- Dave
CUT HERE
Fix mcs7830 patch
The recent mcs7830 update to make the MII support sharable goofed various
pre-existing configurations in two ways:
- it made the usbnet infrastructure reference MII symbols even
when they're not needed in the kernel being built
- it didn't enable MII along with the mcs7830 minidriver
This patch fixes these two problems.
However, there does seem to be a Kconfig reverse dependency bug in that MII
gets wrongly enabled in some cases (like USBNET=y and USBNET_MII=n); I think
I've noticed that same problem in other situations too. So the result can
mean kernels being bloated by stuff that's needlessly enabled ... better
than wrongly being disabled, but contributing to bloat.
Signed-off-by: David Brownell [EMAIL PROTECTED]
Index: at91/drivers/usb/net/Kconfig
===
--- at91.orig/drivers/usb/net/Kconfig 2006-11-02 10:58:49.0 -0800
+++ at91/drivers/usb/net/Kconfig2006-11-02 12:10:13.0 -0800
@@ -92,8 +92,13 @@ config USB_RTL8150
To compile this driver as a module, choose M here: the
module will be called rtl8150.
+config USB_USBNET_MII
+ tristate
+ default n
+
config USB_USBNET
tristate Multi-purpose USB Networking Framework
+ select MII if USBNET_MII != n
---help---
This driver supports several kinds of network links over USB,
with minidrivers built around a common network driver core
@@ -129,7 +134,7 @@ config USB_NET_AX8817X
tristate ASIX AX88xxx Based USB 2.0 Ethernet Adapters
depends on USB_USBNET NET_ETHERNET
select CRC32
- select MII
+ select USB_USBNET_MII
default y
help
This option adds support for ASIX AX88xxx based USB 2.0
@@ -210,6 +215,7 @@ config USB_NET_PLUSB
config USB_NET_MCS7830
tristate MosChip MCS7830 based Ethernet adapters
depends on USB_USBNET
+ select USB_USBNET_MII
help
Choose this option if you're using a 10/100 Ethernet USB2
adapter based on the MosChip 7830 controller. This includes
Index: at91/drivers/usb/net/usbnet.c
===
--- at91.orig/drivers/usb/net/usbnet.c 2006-11-02 10:58:49.0 -0800
+++ at91/drivers/usb/net/usbnet.c 2006-11-02 11:09:29.0 -0800
@@ -669,6 +669,9 @@ done:
* they'll probably want to use this base set.
*/
+#if defined(CONFIG_MII) || defined(CONFIG_MII_MODULE)
+#define HAVE_MII
+
int usbnet_get_settings (struct net_device *net, struct ethtool_cmd *cmd)
{
struct usbnet *dev = netdev_priv(net);
@@ -699,20 +702,6 @@ int usbnet_set_settings (struct net_devi
}
EXPORT_SYMBOL_GPL(usbnet_set_settings);
-
-void usbnet_get_drvinfo (struct net_device *net, struct ethtool_drvinfo *info)
-{
- struct usbnet *dev = netdev_priv(net);
-
- /* REVISIT don't always return usbnet */
- strncpy (info-driver, driver_name, sizeof info-driver);
- strncpy (info-version, DRIVER_VERSION, sizeof info-version);
- strncpy (info-fw_version, dev-driver_info-description,
- sizeof info-fw_version);
- usb_make_path (dev-udev, info-bus_info, sizeof info-bus_info);
-}
-EXPORT_SYMBOL_GPL(usbnet_get_drvinfo);
-
u32 usbnet_get_link (struct net_device *net)
{
struct usbnet *dev = netdev_priv(net);
@@ -730,40 +719,57 @@ u32 usbnet_get_link (struct net_device *
}
EXPORT_SYMBOL_GPL(usbnet_get_link);
-u32 usbnet_get_msglevel (struct net_device *net)
+int usbnet_nway_reset(struct net_device *net)
{
struct usbnet *dev = netdev_priv(net);
- return dev-msg_enable;
+ if (!dev-mii.mdio_write)
+ return -EOPNOTSUPP;
+
+ return mii_nway_restart(dev-mii);
}
-EXPORT_SYMBOL_GPL(usbnet_get_msglevel);
+EXPORT_SYMBOL_GPL(usbnet_nway_reset);
-void usbnet_set_msglevel (struct net_device *net, u32 level)
+#endif /* HAVE_MII */
+
+void usbnet_get_drvinfo (struct net_device *net, struct ethtool_drvinfo *info)
{
struct usbnet *dev = netdev_priv(net);
- dev-msg_enable = level;
+ /* REVISIT don't always return usbnet */
+ strncpy (info-driver, driver_name, sizeof info-driver);
+ strncpy (info-version, DRIVER_VERSION, sizeof info-version);
+ strncpy (info-fw_version, dev-driver_info-description,
+ sizeof info-fw_version);
+ usb_make_path (dev-udev, info-bus_info, sizeof info-bus_info);
}
-EXPORT_SYMBOL_GPL(usbnet_set_msglevel);
+EXPORT_SYMBOL_GPL(usbnet_get_drvinfo);
-int
Re: [linux-usb-devel] [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled
On Tuesday 31 October 2006 5:23 pm, Adrian Bunk wrote: select MII if USB_NET_AX8817X!=n || USB_NET_MCS7830!=n Thing is, I'm seeing that get morphed inside Kconfig to select MII in some cases ... the if x != n gets ignored, MII can't be deselected. That looks to me like a Kconfig dependency engine bug, so I'm just noting it here rather than fixing it. I guess it's not quite enough of a Prolog engine ... ;) - Dave - 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: [airo.c bug] Couldn't allocate RX FID / Max tries exceeded when issueing command
On 11/2/06, Dan Williams [EMAIL PROTECTED] wrote: Do you know which kernel version that patch first appeared in? It was committed on 1 Dec 2005, and 2.6.15 was released on 3 Jan 2006. That would be a great idea, let us know what the results are, especially if you cna figure out which firmware version you have, or if the card itself is really just dead. No luck with freebsd: error resetting card. I'll try my luck with Cisco's Windows utility---probably tomorrow---but I'd now wager that my card has simply croaked. (I've even taken it out and re-seated it in its slot, just in case that helped.) In any case, thanks for the help. - 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: [airo.c bug] Couldn't allocate RX FID / Max tries exceeded when issueing command
On Thu, Nov 02, 2006 at 04:21:16PM -0500, Ivan Matveich wrote: On 11/2/06, Dan Williams [EMAIL PROTECTED] wrote: Do you know which kernel version that patch first appeared in? It was committed on 1 Dec 2005, and 2.6.15 was released on 3 Jan 2006. That would be a great idea, let us know what the results are, especially if you cna figure out which firmware version you have, or if the card itself is really just dead. No luck with freebsd: error resetting card. I'll try my luck with Cisco's Windows utility---probably tomorrow---but I'd now wager that my card has simply croaked. (I've even taken it out and re-seated it in its slot, just in case that helped.) In any case, thanks for the help. Just remembered... Check the IRQ allocation. I remmeber having issues with the BIOS not doing the right stuff. Jean - 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 0/6] rework d80211 cookie pointer
On Thursday 02 November 2006 17:38, Johannes Berg wrote: Now, I tried to update adm8211 and rt2x00 as well, but faced some problems. adm8211 actually accesses the struct net_device and calls it's open() call! This is broken. Good catch. Looks like I never updated the suspend/resume code properly when I ported to d80211. The fix is easy - the code just needs to call the adm8211_open/stop functions directly. I'll send a patch later tonight. -Michael Wu pgpQYkVQJIbQS.pgp Description: PGP signature
Re: [KJ] [patch] net/tipc: sprintf/strcpy conversion
On Wed, Nov 01, 2006 at 03:06:24PM +0100, Florian Westphal wrote:
convert sprintf(a,b) to strcpy(a,b). Make tipc_bclink_name[] const.
Ahhh, I missed the start of threads.
Patch is useless because it changes one unbounded string function into
another unbounded string function.
--- a/net/tipc/bcast.c
+++ b/net/tipc/bcast.c
@@ -790,7 +790,7 @@ int tipc_bclink_init(void)
INIT_LIST_HEAD(bcbearer-bearer.cong_links);
bcbearer-bearer.media = bcbearer-media;
bcbearer-media.send_msg = tipc_bcbearer_send;
- sprintf(bcbearer-media.name, tipc-multicast);
+ strcpy(bcbearer-media.name, tipc-multicast);
bcl = bclink-link;
memset(bclink, 0, sizeof(struct bclink));
@@ -802,7 +802,7 @@ int tipc_bclink_init(void)
tipc_link_set_queue_limits(bcl, BCLINK_WIN_DEFAULT);
bcl-b_ptr = bcbearer-bearer;
bcl-state = WORKING_WORKING;
- sprintf(bcl-name, tipc_bclink_name);
+ strcpy(bcl-name, tipc_bclink_name);
if (BCLINK_LOG_BUF_SIZE) {
char *pb = kmalloc(BCLINK_LOG_BUF_SIZE, GFP_ATOMIC);
--- a/net/tipc/node.c
+++ b/net/tipc/node.c
@@ -667,7 +667,7 @@ struct sk_buff *tipc_node_get_links(cons
link_info.dest = tipc_own_addr 0xf00;
link_info.dest = htonl(link_info.dest);
link_info.up = htonl(1);
-sprintf(link_info.str, tipc_bclink_name);
+strcpy(link_info.str, tipc_bclink_name);
-
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/6] d80211: change the cookie to be opaque
On Fri, 2006-11-03 at 00:09 +0100, Johannes Berg wrote: /* Return a pointer to network statistics data area for the given device. */ -void * ieee80211_dev_stats(struct net_device *dev); +void *ieee80211_dev_stats(struct ieee80211_local *ieee80211_ptr); Ok, that one was wrong. But what is it doing in the public API? We need to remove it from the public API and leave struct net_device *dev as the parameter. adm8211 actually uses it and increases the tx_fifo_error counter, but that's a bit strange. johannes signature.asc Description: This is a digitally signed message part
Re: [PATCH 1/6] d80211: change the cookie to be opaque
Ok, that one was wrong. But what is it doing in the public API? We need to remove it from the public API and leave struct net_device *dev as the parameter. adm8211 actually uses it and increases the tx_fifo_error counter, but that's a bit strange. Fixed, and since, as always, netdev doesn't like my patches, they're here instead: http://johannes.sipsolutions.net/files/d80211-mdev-cleanup/ I also added d80211-reduce-mdev.patch which reduces stupid mdev usage, but see the description in the patch itself. johannes signature.asc Description: This is a digitally signed message part
[PATCH wireless-dev] adm8211: fix suspend code
adm8211: fix suspend code
Apparently, I forgot to port the suspend and resume code in the
d80211 port of adm8211. Thanks to Johannes Berg for finding this.
Signed-off-by: Michael Wu [EMAIL PROTECTED]
---
drivers/net/wireless/d80211/adm8211/adm8211.c | 19 ---
1 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/d80211/adm8211/adm8211.c
b/drivers/net/wireless/d80211/adm8211/adm8211.c
index bc0c8b6..fcfd05a 100644
--- a/drivers/net/wireless/d80211/adm8211/adm8211.c
+++ b/drivers/net/wireless/d80211/adm8211/adm8211.c
@@ -2135,26 +2135,31 @@ #ifdef CONFIG_PM
static int adm8211_suspend(struct pci_dev *pdev, pm_message_t state)
{
struct net_device *dev = pci_get_drvdata(pdev);
- netif_device_detach(dev);
+ struct adm8211_priv *priv = ieee80211_dev_hw_data(dev);
- if (dev-flags IFF_UP)
- dev-stop(dev);
+ if (priv-mode != IEEE80211_IF_TYPE_MGMT) {
+ ieee80211_stop_queues(dev);
+ adm8211_stop(dev);
+ }
pci_save_state(pdev);
- pci_set_power_state(pdev, PCI_D3hot);
+ pci_set_power_state(pdev, pci_choose_state(pdev, state));
return 0;
}
static int adm8211_resume(struct pci_dev *pdev)
{
struct net_device *dev = pci_get_drvdata(pdev);
+ struct adm8211_priv *priv = ieee80211_dev_hw_data(dev);
+
pci_set_power_state(pdev, PCI_D0);
pci_restore_state(pdev);
- if (dev-flags IFF_UP)
- dev-open(dev);
+ if (priv-mode != IEEE80211_IF_TYPE_MGMT) {
+ adm8211_open(dev);
+ ieee80211_start_queues(dev);
+ }
- netif_device_attach(dev);
return 0;
}
#endif /* CONFIG_PM */
pgpocvfmarqtd.pgp
Description: PGP signature
Re: d80211: remove unused variable in ieee80211_rx_irqsafe
On Wed, Oct 25, 2006 at 11:16:21AM -0700, David Kimdon wrote: tmp is unused. Applied to wireless-dev. -- John W. Linville [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: [take1] d80211: switch crypto to use new ciphers API
On Mon, Oct 30, 2006 at 10:08:58AM -0800, David Kimdon wrote: On Thu, Oct 26, 2006 at 10:06:24AM +1000, Herbert Xu wrote: If you're only encrypting/decrypting a single block then you should use the cipher interface. So net/d80211/aes_ccm.c should do that instead. See drivers/net/wirless/airo.c for an example of that. Thanks Herbert. Updated patch, now aes, tkip and wep are all tested. Changes from take0: Use IS_ERR() to evaluate return value of crypto_alloc_cipher(). Use ciper interface rather than blkcipher for aes encryption since we only encrypt a single block at a time. Switch d80211 software crypto to use the new cipher API. Applied to wireless-dev. -- John W. Linville [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] d80211: fix kernel doc for ieee80211_get_buffered_bc
On Wed, Oct 18, 2006 at 03:44:05PM -0700, David Kimdon wrote: ieee80211_beacon_get() was already described. The doc entry in question describes ieee80211_get_buffered_bc(). Signed-off-by: David Kimdon [EMAIL PROTECTED] Applied to wireless-dev. -- John W. Linville [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 1/6] d80211: change the cookie to be opaque
On Thursday 02 November 2006 19:22, Johannes Berg wrote: Ok, that one was wrong. But what is it doing in the public API? We need to remove it from the public API and leave struct net_device *dev as the parameter. adm8211 actually uses it and increases the tx_fifo_error counter, but that's a bit strange. That's because TX might fail for reasons other than not getting an ACK. I can't say I've actually seen this happen, so it might just be something left over from tulip that doesn't need to be there now. (or perhaps it only happens when there's something really bad going on) However, what's so bad about letting drivers update some statistics if it is possible? If you remove ieee80211_dev_stats, please provide some other way for drivers to access struct net_device_stats. -Michael Wu pgpSXbD257dOW.pgp Description: PGP signature
[PATCH 0/4] d80211: Add wireless statistics
This set of patches modifies the d80211 stack and the drivers that use it to support wireless statistics. 1. Adds the necessary data and code to the d80211 routines. 2. Modifies bcm43xx-d80211 to conform. 3. Modifies adm8211-d80211 to conform. 4. Modifies the rt2x00-d80211 drivers to conform. Larry - 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/4] d80211: Add wireless statistics
This patch modifies d80211 to support wireless statistics.
Signed-Off-By: Larry Finger [EMAIL PROTECTED]
---
John,
Please add to wireless-dev.
Larry
Index: wireless-dev/include/net/d80211.h
===
--- wireless-dev.orig/include/net/d80211.h
+++ wireless-dev/include/net/d80211.h
@@ -195,6 +195,8 @@ struct ieee80211_rx_status {
int channel;
int phymode;
int ssi;
+ int signal;
+ int noise;
int antenna;
int rate;
int flag;
@@ -479,6 +481,8 @@ struct ieee80211_hw {
/* This is the time in us to change channels
*/
int channel_change_time;
+ /* This is maximum value for rssi reported by this device */
+ int maxssi;
int num_modes;
struct ieee80211_hw_modes *modes;
Index: wireless-dev/net/d80211/ieee80211.c
===
--- wireless-dev.orig/net/d80211/ieee80211.c
+++ wireless-dev/net/d80211/ieee80211.c
@@ -3152,6 +3152,8 @@ ieee80211_rx_h_sta_process(struct ieee80
sta-rx_fragments++;
sta-rx_bytes += rx-skb-len;
sta-last_rssi = rx-u.rx.status-ssi;
+ sta-last_signal = rx-u.rx.status-signal;
+ sta-last_noise = rx-u.rx.status-noise;
if (!(rx-fc IEEE80211_FCTL_MOREFRAGS)) {
/* Change STA power saving mode only in the end of a frame
Index: wireless-dev/net/d80211/ieee80211_i.h
===
--- wireless-dev.orig/net/d80211/ieee80211_i.h
+++ wireless-dev/net/d80211/ieee80211_i.h
@@ -336,6 +336,7 @@ struct ieee80211_local {
struct net_device *apdev; /* wlan#ap - management frames (hostapd) */
int open_count;
int monitors;
+ struct iw_statistics wstats;
struct ieee80211_conf conf;
int dev_index;
Index: wireless-dev/net/d80211/ieee80211_ioctl.c
===
--- wireless-dev.orig/net/d80211/ieee80211_ioctl.c
+++ wireless-dev/net/d80211/ieee80211_ioctl.c
@@ -1586,6 +1586,16 @@ static int ieee80211_ioctl_giwrange(stru
range-min_frag = 256;
range-max_frag = 2346;
+ range-max_qual.qual = 100;
+ range-max_qual.level = 146; /* set floor at -110 dBm (146 - 256) */
+ range-max_qual.noise = 146;
+ range-max_qual.updated = IW_QUAL_ALL_UPDATED;
+
+ range-avg_qual.qual = 50;
+ range-avg_qual.level = 0;
+ range-avg_qual.noise = 0;
+ range-avg_qual.updated = IW_QUAL_ALL_UPDATED;
+
return 0;
}
@@ -2973,6 +2983,39 @@ static int ieee80211_ioctl_siwauth(struc
return ret;
}
+/* Get wireless statistics. Called by /proc/net/wireless and by SIOCGIWSTATS
*/
+static struct iw_statistics *ieee80211_get_wireless_stats(struct net_device
*net_dev)
+{
+ struct ieee80211_local *local = net_dev-ieee80211_ptr;
+ struct iw_statistics * wstats = local-wstats;
+ struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(net_dev);
+ struct sta_info *sta;
+ static int tmp_level = 0;
+ static int tmp_qual = 0;
+
+ sta = sta_info_get(local, sdata-u.sta.bssid);
+ if (!sta) {
+ wstats-discard.fragment = 0;
+ wstats-discard.misc = 0;
+ wstats-qual.qual = 0;
+ wstats-qual.level = 0;
+ wstats-qual.noise = 0;
+ wstats-qual.updated = IW_QUAL_ALL_INVALID;
+ } else {
+ if (!tmp_level) { /* get initial values */
+ tmp_level = sta-last_signal;
+ tmp_qual = sta-last_rssi;
+ } else {/* smooth results */
+ tmp_level = (15 * tmp_level + sta-last_signal)/16;
+ tmp_qual = (15 * tmp_qual + sta-last_rssi)/16;
+ }
+ wstats-qual.level = tmp_level;
+ wstats-qual.qual = 100*tmp_qual/local-hw-maxssi;
+ wstats-qual.noise = sta-last_noise;
+ wstats-qual.updated = IW_QUAL_ALL_UPDATED | IW_QUAL_DBM;
+ }
+ return wstats;
+}
static int ieee80211_ioctl_giwauth(struct net_device *dev,
struct iw_request_info *info,
@@ -3162,6 +3205,7 @@ const struct iw_handler_def ieee80211_iw
.standard = (iw_handler *) ieee80211_handler,
.private= (iw_handler *) ieee80211_private_handler,
.private_args = (struct iw_priv_args *) ieee80211_ioctl_priv,
+ .get_wireless_stats = ieee80211_get_wireless_stats,
};
/* Wireless handlers for master interface */
Index: wireless-dev/net/d80211/ieee80211_sysfs_sta.c
===
--- wireless-dev.orig/net/d80211/ieee80211_sysfs_sta.c
+++ wireless-dev/net/d80211/ieee80211_sysfs_sta.c
@@ -48,7 +48,7 @@ static ssize_t show_sta_##name(const
[PATCH 3/4] adm8211-d80211: Add wireless statistics (compile tested only)
These patches modify adm8211-d80211 to use the wireless statics added in patch
1.
Signed-Off-By: Larry [EMAIL PROTECTED]
Index: wireless-dev/drivers/net/wireless/d80211/adm8211/adm8211.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/adm8211/adm8211.c
+++ wireless-dev/drivers/net/wireless/d80211/adm8211/adm8211.c
@@ -73,6 +73,8 @@ ADM8211_IER_TDUIE | ADM8211_IER_GPTIE)
#define PLCP_SIGNAL_5M50x37
#define PLCP_SIGNAL_11M0x6e
+#define ADM8211_RX_MAX_SSI 100
+
struct adm8211_tx_hdr {
u8 da[6];
u8 signal; /* PLCP signal / TX rate in 100 Kbps */
@@ -557,6 +559,14 @@ static void adm8211_interrupt_rci(struct
if (dev-flags IFF_PROMISC)
skb_trim(skb, skb-len - FCS_LEN);
+
+/* FIXME: The following set of assignments supply additional data for wireless
statistics. The
+ necessary quantities are (1) the noise value in dBm, and (2) the
signal value in dBm.
+ The present code supplies dummy values for these quantities. */
+
+ rx_status.noise = -85; /* FIXME */
+ rx_status.signal = rx_status.ssi - ADM8211_RX_MAX_SSI;
/* FIXME */
+
ieee80211_rx_irqsafe(dev, skb, rx_status);
}
@@ -2045,6 +2055,7 @@ static int __devinit adm8211_probe(struc
hw-get_tsf = adm8211_get_tsft;
hw-get_tx_stats = adm8211_get_tx_stats;
hw-queues = 1; // ADM8211C supports more, maybe ADM8211B
+ hw-maxssi = ADM8211_RX_MAX_SSI;// FIXME - This is an approximation
priv-retry_limit = 3;
priv-ant_power = 0x40;
-
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/4] bcm43xx-d80211: Add wireless statistics
These patches modify bcm43xx-d80211 to use the wireless statics added in patch
1.
Signed-Off-By: Larry [EMAIL PROTECTED]
---
Please apply to wireless-dev
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h
===
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h
@@ -27,6 +27,8 @@
#define BCM43xx_IO_SIZE8192
+#define BCM43xx_RX_MAX_SSI 60
+
/* MMIO offsets */
#define BCM43xx_MMIO_DMA0_REASON 0x20
#define BCM43xx_MMIO_DMA0_IRQ_MASK 0x24
@@ -610,7 +612,7 @@ struct bcm43xx_noise_calculation {
};
struct bcm43xx_stats {
- u8 link_quality;
+ u8 link_noise;
/* Store the last TX/RX times here for updating the leds. */
unsigned long last_tx;
unsigned long last_rx;
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
@@ -1199,15 +1199,7 @@ static void handle_irq_noise(struct bcm4
else
average -= 48;
- if (average -65)
- bcm-stats.link_quality = 0;
- else if (average -75)
- bcm-stats.link_quality = 1;
- else if (average -85)
- bcm-stats.link_quality = 2;
- else
- bcm-stats.link_quality = 3;
-// dprintk(KERN_INFO PFX Link Quality: %u (avg was %d)\n,
bcm-stats.link_quality, average);
+ bcm-stats.link_noise = average;
drop_calculation:
bcm-noisecalc.calculation_running = 0;
return;
@@ -3981,6 +3973,7 @@ static int __devinit bcm43xx_init_one(st
ieee-host_gen_beacon_template = 1;
ieee-rx_includes_fcs = 0;
ieee-monitor_during_oper = 1;
+ ieee-maxssi = BCM43xx_RX_MAX_SSI;
ieee-tx = bcm43xx_net_hard_start_xmit;
ieee-open = bcm43xx_net_open;
ieee-stop = bcm43xx_net_stop;
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_xmit.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_xmit.c
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_xmit.c
@@ -678,10 +678,12 @@ void bcm43xx_rx(struct bcm43xx_private *
status.flag |= RX_FLAG_DECRYPTED;
}
- status.ssi = bcm43xx_rssi_postprocess(bcm, jssi,
+ status.signal = bcm43xx_rssi_postprocess(bcm, jssi,
(phystat0
BCM43xx_RX_PHYST0_OFDM),
(phystat0
BCM43xx_RX_PHYST0_GAINCTL),
(phystat3
BCM43xx_RX_PHYST3_TRSTATE));
+ status.noise = bcm-stats.link_noise;
+ status.ssi = jssi;
if (phystat0 BCM43xx_RX_PHYST0_OFDM)
status.rate = bcm43xx_plcp_get_bitrate_ofdm(plcp);
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 4/4] rt2x00-d80211: Add wireless statistics (compile tested only)
These patches modify the rt2x00-d80211 family of drivers to use
the wireless statics added in patch 1.
Signed-Off-By: Larry [EMAIL PROTECTED]
Index: wireless-dev/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
+++ wireless-dev/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
@@ -1695,6 +1695,14 @@ static void rt2400pci_rxdone(void *data)
rt2x00dev-rx_params.ssi =
rt2x00_get_field32(rxd-word2, RXD_W2_RSSI);
+/* FIXME: The following set of assignments supply additional data for wireless
statistics. The
+ necessary quantities are (1) the noise value in dBm, and (2) the
signal value in dBm.
+ The present code supplies dummy values for these quantities. */
+
+ rt2x00dev-rx_params.noise = -85; /* FIXME */
+ rt2x00dev-rx_params.signal =
+ rt2x00dev-rx_params.ssi - RT2X00_RX_MAX_SSI;
/* FIXME */
+
__ieee80211_rx(ring-net_dev,
skb, rt2x00dev-rx_params);
}
@@ -2581,6 +2589,7 @@ static int rt2400pci_init_hw(struct rt2x
hw-device_strips_mic = 0;
hw-monitor_during_oper = 1;
hw-fraglist = 0;
+ hw-maxssi = RT2X00_RX_MAX_SSI;
/*
* We have 2 TX queues: TX and PRIO.
Index: wireless-dev/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
+++ wireless-dev/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
@@ -1841,6 +1841,14 @@ static void rt2500pci_rxdone(void *data)
rt2x00dev-rx_params.ssi =
rt2x00_get_field32(rxd-word2, RXD_W2_RSSI);
+/* FIXME: The following set of assignments supply additional data for wireless
statistics. The
+ necessary quantities are (1) the noise value in dBm, and (2) the
signal value in dBm.
+ The present code supplies dummy values for these quantities. */
+
+ rt2x00dev-rx_params.noise = -85; /* FIXME */
+ rt2x00dev-rx_params.signal =
+ rt2x00dev-rx_params.ssi - RT2X00_RX_MAX_SSI;
/* FIXME */
+
__ieee80211_rx(ring-net_dev,
skb, rt2x00dev-rx_params);
@@ -2735,6 +2743,7 @@ static int rt2500pci_init_hw(struct rt2x
hw-device_strips_mic = 0;
hw-monitor_during_oper = 1;
hw-fraglist = 0;
+ hw-maxssi = RT2X00_RX_MAX_SSI;
/*
* We have 2 TX queues: TX and PRIO.
Index: wireless-dev/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
+++ wireless-dev/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
@@ -1627,6 +1627,14 @@ static void rt2500usb_rxdone(void *data)
rt2x00dev-rx_params.ssi =
rt2x00_get_field32(rxd-word1, RXD_W1_RSSI);
+/* FIXME: The following set of assignments supply additional data for wireless
statistics. The
+ necessary quantities are (1) the noise value in dBm, and (2) the
signal value in dBm.
+ The present code supplies dummy values for these quantities. */
+
+ rt2x00dev-rx_params.noise = -85; /* FIXME */
+ rt2x00dev-rx_params.signal =
+ rt2x00dev-rx_params.ssi - RT2X00_RX_MAX_SSI;
/* FIXME */
+
__ieee80211_rx(ring-net_dev,
skb, rt2x00dev-rx_params);
@@ -2423,6 +2431,7 @@ static int rt2500usb_init_hw(struct rt2x
hw-device_strips_mic = 0;
hw-monitor_during_oper = 1;
hw-fraglist = 0;
+ hw-maxssi = RT2X00_RX_MAX_SSI;
/*
* We have 2 TX queues: TX and PRIO.
Index: wireless-dev/drivers/net/wireless/d80211/rt2x00/rt2x00.h
===
--- wireless-dev.orig/drivers/net/wireless/d80211/rt2x00/rt2x00.h
+++ wireless-dev/drivers/net/wireless/d80211/rt2x00/rt2x00.h
@@ -850,6 +850,8 @@ struct rt2x00_dev {
#define CONFIG_DOUBLE_ANTENNA 0x0001
#define CONFIG_DISABLE_BBP_TUNING 0x0002
+#define RT2X00_RX_MAX_SSI 100
+
/*
* Chipset identification.
*/
Index: wireless-dev/drivers/net/wireless/d80211/rt2x00/rt61pci.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/rt2x00/rt61pci.c
+++ wireless-dev/drivers/net/wireless/d80211/rt2x00/rt61pci.c
@@ -2285,6 +2285,14 @@ static void rt61pci_rxdone(void *data)
rt2x00dev-rx_params.ssi =
Re: [PATCH 2/4] bcm43xx-d80211: Add wireless statistics
On Thursday 02 November 2006 19:46, Larry Finger wrote:
These patches modify bcm43xx-d80211 to use the wireless statics added in
patch 1.
Signed-Off-By: Larry [EMAIL PROTECTED]
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
Please apply to wireless-dev
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h
===
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h
@@ -27,6 +27,8 @@
#define BCM43xx_IO_SIZE 8192
+#define BCM43xx_RX_MAX_SSI 60
+
/* MMIO offsets */
#define BCM43xx_MMIO_DMA0_REASON 0x20
#define BCM43xx_MMIO_DMA0_IRQ_MASK 0x24
@@ -610,7 +612,7 @@ struct bcm43xx_noise_calculation {
};
struct bcm43xx_stats {
- u8 link_quality;
+ u8 link_noise;
/* Store the last TX/RX times here for updating the leds. */
unsigned long last_tx;
unsigned long last_rx;
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
@@ -1199,15 +1199,7 @@ static void handle_irq_noise(struct bcm4
else
average -= 48;
- if (average -65)
- bcm-stats.link_quality = 0;
- else if (average -75)
- bcm-stats.link_quality = 1;
- else if (average -85)
- bcm-stats.link_quality = 2;
- else
- bcm-stats.link_quality = 3;
-// dprintk(KERN_INFO PFX Link Quality: %u (avg was %d)\n,
bcm-stats.link_quality, average);
+ bcm-stats.link_noise = average;
drop_calculation:
bcm-noisecalc.calculation_running = 0;
return;
@@ -3981,6 +3973,7 @@ static int __devinit bcm43xx_init_one(st
ieee-host_gen_beacon_template = 1;
ieee-rx_includes_fcs = 0;
ieee-monitor_during_oper = 1;
+ ieee-maxssi = BCM43xx_RX_MAX_SSI;
ieee-tx = bcm43xx_net_hard_start_xmit;
ieee-open = bcm43xx_net_open;
ieee-stop = bcm43xx_net_stop;
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_xmit.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_xmit.c
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_xmit.c
@@ -678,10 +678,12 @@ void bcm43xx_rx(struct bcm43xx_private *
status.flag |= RX_FLAG_DECRYPTED;
}
- status.ssi = bcm43xx_rssi_postprocess(bcm, jssi,
+ status.signal = bcm43xx_rssi_postprocess(bcm, jssi,
(phystat0
BCM43xx_RX_PHYST0_OFDM),
(phystat0
BCM43xx_RX_PHYST0_GAINCTL),
(phystat3
BCM43xx_RX_PHYST3_TRSTATE));
+ status.noise = bcm-stats.link_noise;
+ status.ssi = jssi;
if (phystat0 BCM43xx_RX_PHYST0_OFDM)
status.rate = bcm43xx_plcp_get_bitrate_ofdm(plcp);
else
--
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: [Rt2400-devel] [PATCH 4/4] rt2x00-d80211: Add wireless statistics (compile tested only)
On Thursday 02 November 2006 19:48, Larry Finger wrote:
These patches modify the rt2x00-d80211 family of drivers to use
the wireless statics added in patch 1.
Signed-Off-By: Larry [EMAIL PROTECTED]
I will put the search for the correct values on my TODO list,
but that needs some heavy legacy driver research.
But these values seem sane enough for me. ;)
Signed-Off-By: Ivo van Doorn [EMAIL PROTECTED]
Index: wireless-dev/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
+++ wireless-dev/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
@@ -1695,6 +1695,14 @@ static void rt2400pci_rxdone(void *data)
rt2x00dev-rx_params.ssi =
rt2x00_get_field32(rxd-word2, RXD_W2_RSSI);
+/* FIXME: The following set of assignments supply additional data for
wireless statistics. The
+ necessary quantities are (1) the noise value in dBm, and (2) the
signal value in dBm.
+ The present code supplies dummy values for these quantities. */
+
+ rt2x00dev-rx_params.noise = -85; /* FIXME */
+ rt2x00dev-rx_params.signal =
+ rt2x00dev-rx_params.ssi - RT2X00_RX_MAX_SSI;
/* FIXME */
+
__ieee80211_rx(ring-net_dev,
skb, rt2x00dev-rx_params);
}
@@ -2581,6 +2589,7 @@ static int rt2400pci_init_hw(struct rt2x
hw-device_strips_mic = 0;
hw-monitor_during_oper = 1;
hw-fraglist = 0;
+ hw-maxssi = RT2X00_RX_MAX_SSI;
/*
* We have 2 TX queues: TX and PRIO.
Index: wireless-dev/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
+++ wireless-dev/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
@@ -1841,6 +1841,14 @@ static void rt2500pci_rxdone(void *data)
rt2x00dev-rx_params.ssi =
rt2x00_get_field32(rxd-word2, RXD_W2_RSSI);
+/* FIXME: The following set of assignments supply additional data for
wireless statistics. The
+ necessary quantities are (1) the noise value in dBm, and (2) the
signal value in dBm.
+ The present code supplies dummy values for these quantities. */
+
+ rt2x00dev-rx_params.noise = -85; /* FIXME */
+ rt2x00dev-rx_params.signal =
+ rt2x00dev-rx_params.ssi - RT2X00_RX_MAX_SSI;
/* FIXME */
+
__ieee80211_rx(ring-net_dev,
skb, rt2x00dev-rx_params);
@@ -2735,6 +2743,7 @@ static int rt2500pci_init_hw(struct rt2x
hw-device_strips_mic = 0;
hw-monitor_during_oper = 1;
hw-fraglist = 0;
+ hw-maxssi = RT2X00_RX_MAX_SSI;
/*
* We have 2 TX queues: TX and PRIO.
Index: wireless-dev/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
+++ wireless-dev/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
@@ -1627,6 +1627,14 @@ static void rt2500usb_rxdone(void *data)
rt2x00dev-rx_params.ssi =
rt2x00_get_field32(rxd-word1, RXD_W1_RSSI);
+/* FIXME: The following set of assignments supply additional data for
wireless statistics. The
+ necessary quantities are (1) the noise value in dBm, and (2) the
signal value in dBm.
+ The present code supplies dummy values for these quantities. */
+
+ rt2x00dev-rx_params.noise = -85; /* FIXME */
+ rt2x00dev-rx_params.signal =
+ rt2x00dev-rx_params.ssi - RT2X00_RX_MAX_SSI;
/* FIXME */
+
__ieee80211_rx(ring-net_dev,
skb, rt2x00dev-rx_params);
@@ -2423,6 +2431,7 @@ static int rt2500usb_init_hw(struct rt2x
hw-device_strips_mic = 0;
hw-monitor_during_oper = 1;
hw-fraglist = 0;
+ hw-maxssi = RT2X00_RX_MAX_SSI;
/*
* We have 2 TX queues: TX and PRIO.
Index: wireless-dev/drivers/net/wireless/d80211/rt2x00/rt2x00.h
===
--- wireless-dev.orig/drivers/net/wireless/d80211/rt2x00/rt2x00.h
+++ wireless-dev/drivers/net/wireless/d80211/rt2x00/rt2x00.h
@@ -850,6 +850,8 @@ struct rt2x00_dev {
#define CONFIG_DOUBLE_ANTENNA0x0001
#define CONFIG_DISABLE_BBP_TUNING0x0002
+#define RT2X00_RX_MAX_SSI100
+
/*
* Chipset identification.
*/
Index: wireless-dev/drivers/net/wireless/d80211/rt2x00/rt61pci.c
Re: [PATCH 3/4] adm8211-d80211: Add wireless statistics (compile tested only)
On Thursday 02 November 2006 13:47, Larry Finger wrote: These patches modify adm8211-d80211 to use the wireless statics added in patch 1. Signed-Off-By: Larry [EMAIL PROTECTED] ACK. I can put better values in later. Thanks, -Michael Wu pgpduYKxxEeea.pgp Description: PGP signature
Re: [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled
On Thu, Nov 02, 2006 at 12:29:12PM -0800, David Brownell wrote: On Wednesday 01 November 2006 11:15 pm, Greg KH wrote: Argh, there were just too many different versions of these patches floating around. Can you resend the final versions please? This should replace BOTH of Randy's patches. It addresses all the issues I've heard raised, and resolves the regresssion introduced when adding the mcs7830 minidriver. It seems to lack the select MII at the USB_RTL8150 option that was in Randy's first patch? - Dave ... --- at91.orig/drivers/usb/net/Kconfig 2006-11-02 10:58:49.0 -0800 +++ at91/drivers/usb/net/Kconfig 2006-11-02 12:10:13.0 -0800 @@ -92,8 +92,13 @@ config USB_RTL8150 To compile this driver as a module, choose M here: the module will be called rtl8150. +config USB_USBNET_MII + tristate + default n + config USB_USBNET tristate Multi-purpose USB Networking Framework + select MII if USBNET_MII != n ---help--- This driver supports several kinds of network links over USB, with minidrivers built around a common network driver core @@ -129,7 +134,7 @@ config USB_NET_AX8817X tristate ASIX AX88xxx Based USB 2.0 Ethernet Adapters depends on USB_USBNET NET_ETHERNET select CRC32 - select MII + select USB_USBNET_MII default y help This option adds support for ASIX AX88xxx based USB 2.0 @@ -210,6 +215,7 @@ config USB_NET_PLUSB config USB_NET_MCS7830 tristate MosChip MCS7830 based Ethernet adapters depends on USB_USBNET + select USB_USBNET_MII help Choose this option if you're using a 10/100 Ethernet USB2 adapter based on the MosChip 7830 controller. This includes Index: at91/drivers/usb/net/usbnet.c === --- at91.orig/drivers/usb/net/usbnet.c2006-11-02 10:58:49.0 -0800 +++ at91/drivers/usb/net/usbnet.c 2006-11-02 11:09:29.0 -0800 ... 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: [take22 0/4] kevent: Generic event handling mechanism.
2006/11/2, Eric Dumazet [EMAIL PROTECTED]:
zhou drangon a écrit :
performance is great, and we are exciting at the result.
I want to know why there can be so much improvement, can we improve
epoll too ?
Why did you remove most of CC addresses but lkml ?
Dont do that please...
I seldom reply to the mailing list, Sorry for this.
Good question :)
Hum, I think I can look into epoll and see how it can be improved (if necessary)
I have an other question.
As for the VFS system, when we introduce the AIO machinism, we add aio_read,
aio_write, etc... to file ops, and then we make the read, write op to
call aio_read,
aio_write, so that we only remain one implement in kernel.
Can we do event machinism the same way?
when kevent is robust enough, can we implement epoll/select/io_submit etc...
base on kevent ??
In this way, we can simplified the kernel, and epoll can gain
improvement from kevent.
This is not to say we dont need kevent ! Please Evgeniy continue your work !
Yes! We are expecting for you greate work.
I create an userland event-driven framework for my application.
but I have to use multiple thread to receive event, epoll to wait most event,
and io_getevent to wait disk AIO event, I hope we can get a universal
event machinism
to make the code elegance.
Just to remind you that according to
http://www.xmailserver.org/linux-patches/nio-improve.html David Libenzi had to
wait 18 months before epoll being officialy added into kernel.
At that time, many applications were using epoll, and we were patching our
kernels for that.
I cooked a very simple program (attached in this mail), using pipes and epoll,
and got 250.000 events received per second on an otherwise lightly loaded
machine (dual opteron 246 , 2GHz, 1MB cache per cpu) with 10.000 pipes (20.000
handles)
It could be nice to add support for other event providers in this program
(AF_INET AF_UNIX sockets for example), and also add support for kevent, so
that we really can compare epoll/kevent without a complex setup.
I should extend the program to also add/remove sources during lifetime, not
only insert at setup time.
# gcc -O2 -o epoll_pipe_bench epoll_pipe_bench.c -lpthread
# ulimit -n 100
# epoll_pipe_bench -n 1
^C after a while...
oprofile results say that ep_poll_callback() and sys_epoll_wait() use 20% of
cpu time.
Even if we gain a two factor in cpu time or cache usage, we wont eliminate
other costs...
oprofile results gave :
Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit
mask of 0x00 (No unit mask) count 5
samples %symbol name
2015420 11.1309 ep_poll_callback
1867431 10.3136 pipe_writev
1791872 9.8963 sys_epoll_wait
1357297 7.4962 fget_light
1277515 7.0556 pipe_readv
9984475.5143 current_fs_time
8015974.4271 __mark_inode_dirty
7552684.1713 __wake_up
5870653.2423 __write_lock_failed
5829313.2195 system_call
2971321.6410 iov_fault_in_pages_read
2961361.6355 sys_write
2901061.6022 __wake_up_common
2706921.4950 bad_pipe_w
2615161.4443 do_pipe
2572081.4205 tg3_start_xmit_dma_bug
2549171.4079 pipe_poll
2529251.3969 copy_user_generic_c
2342121.2935 generic_pipe_buf_map
2286591.2629 ret_from_sys_call
2125411.1738 sysret_check
1665290.9197 sys_read
1600380.8839 vfs_write
1510910.8345 pipe_ioctl
1363010.7528 file_update_time
1071730.5919 tg3_poll
77846 0.4299 ipt_do_table
75081 0.4147 schedule
73059 0.4035 vfs_read
69787 0.3854 get_task_comm
63923 0.3530 memcpy
60019 0.3315 touch_atime
57490 0.3175 eventpoll_release_file
56152 0.3101 tg3_write_flush_reg32
54468 0.3008 rw_verify_area
47833 0.2642 generic_pipe_buf_unmap
4 0.2639 __switch_to
44106 0.2436 bad_pipe_r
41824 0.2310 proc_nr_files
41319 0.2282 pipe_iov_copy_from_user
Eric
/*
* How to stress epoll
*
* This program uses many pipes and two threads.
* First we open as many pipes we can. (see ulimit -n)
* Then we create a worker thread.
* The worker thread will send bytes to random pipes.
* The main thread uses epoll to collect ready pipes and read them.
* Each second, a number of collected bytes is printed on stderr
*
* Usage : epoll_bench [-n X]
*/
#include pthread.h
#include stdlib.h
#include errno.h
#include stdio.h
#include string.h
#include sys/epoll.h
#include signal.h
#include unistd.h
#include sys/time.h
int nbpipes = 1024;
struct pipefd {
int fd[2];
} *tab;
int epoll_fd;
static int alloc_pipes()
{
int i;
epoll_fd = epoll_create(nbpipes);
if (epoll_fd == -1) {
perror(epoll_create);
return -1;
}
tab = malloc(sizeof(struct pipefd) * nbpipes);
if (tab ==NULL) {
perror(malloc);
return -1;
}
for (i = 0 ; i nbpipes ; i++) {
struct epoll_event ev;
Re: [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled
On Thursday 02 November 2006 6:27 pm, Adrian Bunk wrote: It seems to lack the select MII at the USB_RTL8150 option that was in Randy's first patch? I was just addressing the usbnet issues ... that driver doesn't use the usbnet framework. - Dave - 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 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled
On Thu, 2 Nov 2006, David Brownell wrote: On Thursday 02 November 2006 6:27 pm, Adrian Bunk wrote: It seems to lack the select MII at the USB_RTL8150 option that was in Randy's first patch? I was just addressing the usbnet issues ... that driver doesn't use the usbnet framework. and Randy is away for a few days with very limited net access. -- ~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: [take3 0/5] d80211: remove bitfields from include/net/d80211.h
On Wed, Oct 25, 2006 at 03:28:03PM -0400, Jeff Garzik wrote: On Wed, Oct 25, 2006 at 12:17:02PM -0700, David Kimdon wrote: That is how I originally had the patch, but then had a question about increasing structure size so I dropped flags to u16 or u8 for structures that were made larger by the bitfield removal. On non-x86 platforms, u16 and u8 generate shitty code too. Not as shitty as bitfields, but still shitty. David, may I presume there will be a take4? John -- John W. Linville [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
[patch] d80211: fix key access race
It seems we don't have any protection when accessing the key.
The RX/TX path may acquire a key which can be freed by the
ioctl cmd.
I put a key_lock spinlock to protect all the accesses to the key
(whether the sta_info-key or ieee80211_sub_if_data-keys[]).
Don't find a good way to handle it :(
Thanks,
Hong
Signed-off-by: Hong Liu [EMAIL PROTECTED]
diff --git a/net/d80211/ieee80211.c b/net/d80211/ieee80211.c
index 751bc76..1a1f6fb 100644
--- a/net/d80211/ieee80211.c
+++ b/net/d80211/ieee80211.c
@@ -99,12 +99,38 @@ struct ieee80211_key *ieee80211_key_allo
return key;
}
-void ieee80211_key_free(struct ieee80211_key *key)
+void ieee80211_key_put(struct ieee80211_key *key)
{
if (key)
kobject_put(key-kobj);
}
+void ieee80211_key_get(struct ieee80211_key *key)
+{
+ if (key)
+ kobject_get(key-kobj);
+}
+
+void ieee80211_key_free(struct ieee80211_local *local,
+ struct ieee80211_key **key,
+ struct ieee80211_sub_if_data *sdata)
+{
+ int remove_def = 0;
+
+ if (*key sdata sdata-default_key == *key) {
+ ieee80211_key_sysfs_remove_default(sdata);
+ remove_def = 1;
+ }
+ ieee80211_key_sysfs_remove(*key);
+
+ spin_lock_bh(local-key_lock);
+ if (remove_def)
+ sdata-default_key = NULL;
+ *key = NULL;
+ ieee80211_key_put(*key);
+ spin_unlock_bh(local-key_lock);
+}
+
void ieee80211_key_release(struct kobject *kobj)
{
struct ieee80211_key *key;
@@ -402,6 +428,7 @@ ieee80211_tx_h_select_key(struct ieee802
else
tx-u.tx.control-key_idx = HW_KEY_IDX_INVALID;
+ spin_lock_bh(tx-local-key_lock);
if (unlikely(tx-u.tx.control-flags IEEE80211_TXCTL_DO_NOT_ENCRYPT))
tx-key = NULL;
else if (tx-sta tx-sta-key)
@@ -410,11 +437,16 @@ ieee80211_tx_h_select_key(struct ieee802
tx-key = tx-sdata-default_key;
else if (tx-sdata-drop_unencrypted
!(tx-sdata-eapol ieee80211_is_eapol(tx-skb))) {
+ spin_unlock_bh(tx-local-key_lock);
I802_DEBUG_INC(tx-local-tx_handlers_drop_unencrypted);
return TXRX_DROP;
} else
tx-key = NULL;
+ if (tx-key)
+ ieee80211_key_get(tx-key);
+ spin_unlock_bh(tx-local-key_lock);
+
if (tx-key) {
tx-key-tx_rx_count++;
if (unlikely(tx-local-key_tx_rx_threshold
@@ -1216,6 +1248,9 @@ static int ieee80211_tx(struct net_devic
skb = tx.skb; /* handlers are allowed to change skb */
+ if (tx.key)
+ ieee80211_key_put(tx.key);
+
if (sta)
sta_info_put(sta);
@@ -3092,6 +3127,7 @@ ieee80211_rx_h_check(struct ieee80211_tx
else
always_sta_key = 1;
+ spin_lock(rx-local-key_lock);
if (rx-sta rx-sta-key always_sta_key) {
rx-key = rx-sta-key;
} else {
@@ -3109,6 +3145,7 @@ ieee80211_rx_h_check(struct ieee80211_tx
rx-key = rx-sdata-keys[keyidx];
if (!rx-key) {
+ spin_unlock(rx-local-key_lock);
if (!rx-u.rx.ra_match)
return TXRX_DROP;
printk(KERN_DEBUG %s: RX WEP frame with
@@ -3126,6 +3163,10 @@ ieee80211_rx_h_check(struct ieee80211_tx
}
}
+ if (rx-key)
+ ieee80211_key_get(rx-key);
+ spin_unlock(rx-local-key_lock);
+
if (rx-fc IEEE80211_FCTL_PROTECTED rx-key rx-u.rx.ra_match) {
rx-key-tx_rx_count++;
if (unlikely(rx-local-key_tx_rx_threshold
@@ -3705,6 +3746,8 @@ void __ieee80211_rx(struct net_device *d
}
end:
+ if (rx.key)
+ ieee80211_key_put(rx.key);
if (sta)
sta_info_put(sta);
}
@@ -4411,6 +4454,7 @@ struct net_device *ieee80211_alloc_hw(si
init_timer(local-scan.timer); /* clear it out */
spin_lock_init(local-generic_lock);
+ spin_lock_init(local-key_lock);
init_timer(local-stat_timer);
local-stat_timer.function = ieee80211_stat_refresh;
local-stat_timer.data = (unsigned long) local;
diff --git a/net/d80211/ieee80211_i.h b/net/d80211/ieee80211_i.h
index 89666ec..8e2a4a3 100644
--- a/net/d80211/ieee80211_i.h
+++ b/net/d80211/ieee80211_i.h
@@ -361,6 +361,7 @@ #define IEEE80211_IRQSAFE_QUEUE_LIMIT 12
} ieee80211_msg_enum;
spinlock_t generic_lock;
+ spinlock_t key_lock;
/* Station data structures */
struct kset sta_kset;
spinlock_t sta_lock; /* mutex for STA data structures */
@@ -568,7 +569,11 @@ ieee80211_key_data2conf(struct ieee80211
struct ieee80211_key *data);
struct ieee80211_key
Re: [PATCH 1/6] d80211: change the cookie to be opaque
On Fri, Nov 03, 2006 at 01:46:31AM +0100, Johannes Berg wrote: Ok, that one was wrong. But what is it doing in the public API? We need to remove it from the public API and leave struct net_device *dev as the parameter. adm8211 actually uses it and increases the tx_fifo_error counter, but that's a bit strange. Fixed, and since, as always, netdev doesn't like my patches, they're here instead: http://johannes.sipsolutions.net/files/d80211-mdev-cleanup/ I also added d80211-reduce-mdev.patch which reduces stupid mdev usage, but see the description in the patch itself. 403 Forbidden (shouldn't that be Verboten? :-) FWIW, I have the other 6 patches on the 'pending' branch of wireless-dev. Driver authors, please proceed accordingly. Thanks, John -- John W. Linville [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
New stuff in wireless-dev, wireless developers please pull...
I'm basically caught-up on merging for wireless-dev. Here is the URL, just in case you forgot... :-) git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git This includes a pull from Michael Buesch for bcm43xx stuff, a fresh pull from Jiri for stack stuff, the addition of the p54 driver from Michael Wu, Larry's wireless stats patches, and some misc patches from (or through) David Kimdon and others. I apologize if I've left anyone out. You'll still be in the changelogs... :-) I've also added a 'pending' branch, with similar policies to the 'pending' branch in wireless-2.6 (i.e it means I've got the patch, but I'm waiting on some feedback or changes, etc). One big addition is the cfg80211/nl80211 stuff from Johannes. I'm not quite confident that the Kconfig stuff is right, but the code is there. This is our WE successor, so driver authors please take notice and plan for your driver's migration to the new configuration regime. Please pull the tree and check things out. If you sent a patch more than a few days ago and it isn't in there, I've probably missed it or discarded it for some reason. Please feel free to resubmit any missing patches. Thanks for your support, and for all the great patches! Keep 'em coming! :-) John -- John W. Linville [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: New stuff in wireless-dev, wireless developers please pull...
On Thursday 02 November 2006 23:30, John W. Linville wrote: One big addition is the cfg80211/nl80211 stuff from Johannes. I'm not quite confident that the Kconfig stuff is right, but the code is there. It doesn't seem to compile on my system: net/built-in.o: In function `iw_send_thrspy_event': wext-old.c:(.text+0x67672): undefined reference to `wireless_send_event' net/built-in.o: In function `ioctl_standard_call': wext-old.c:(.text+0x677bf): undefined reference to `standard_ioctl_num' wext-old.c:(.text+0x677ea): undefined reference to `standard_ioctl' wext-old.c:(.text+0x677f1): undefined reference to `standard_ioctl' wext-old.c:(.text+0x679b9): undefined reference to `wireless_send_event' wext-old.c:(.text+0x679f0): undefined reference to `wireless_send_event' wext-old.c:(.text+0x67abf): undefined reference to `wireless_send_event' net/built-in.o: In function `iw_handler_get_iwstats': wext-old.c:(.text+0x67f67): undefined reference to `get_wireless_stats' net/built-in.o: In function `net_dev_init': dev.c:(.init.text+0x28e): undefined reference to `wireless_proc_init' net/built-in.o:(__ksymtab+0x1248): undefined reference to `wireless_send_event' make: *** [.tmp_vmlinux1] Error 1 This is with cfg80211 turned off. Thanks, -Michael Wu pgpDYhLuuGOBL.pgp Description: PGP signature
[PATCH] bcm43xx: Remove useless core enable/disable messages
In the softmac version of bcm43xx, the core scan logs whether each core is
enabled or disabled. This information is useless as one of the next steps
is to enable all cores. This patch removes this output from the log.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
John,
These are more janitorial changes for wireless-2.6 and 2.6.20.
Larry
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -2667,14 +2667,10 @@ static int bcm43xx_probe_cores(struct bc
bcm-chip_id, bcm-chip_rev);
dprintk(KERN_INFO PFX Number of cores: %d\n, core_count);
if (bcm-core_chipcommon.available) {
- dprintk(KERN_INFO PFX Core 0: ID 0x%x, rev 0x%x, vendor 0x%x,
%s\n,
- core_id, core_rev, core_vendor,
- bcm43xx_core_enabled(bcm) ? enabled : disabled);
- }
-
- if (bcm-core_chipcommon.available)
+ dprintk(KERN_INFO PFX Core 0: ID 0x%x, rev 0x%x, vendor
0x%x\n,
+ core_id, core_rev, core_vendor);
current_core = 1;
- else
+ } else
current_core = 0;
for ( ; current_core core_count; current_core++) {
struct bcm43xx_coreinfo *core;
@@ -2692,9 +2688,8 @@ static int bcm43xx_probe_cores(struct bc
core_rev = (sb_id_hi 0xF);
core_vendor = (sb_id_hi 0x) 16;
- dprintk(KERN_INFO PFX Core %d: ID 0x%x, rev 0x%x, vendor 0x%x,
%s\n,
- current_core, core_id, core_rev, core_vendor,
- bcm43xx_core_enabled(bcm) ? enabled : disabled );
+ dprintk(KERN_INFO PFX Core %d: ID 0x%x, rev 0x%x, vendor
0x%x\n,
+ current_core, core_id, core_rev, core_vendor);
core = NULL;
switch (core_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: [Bugme-new] [Bug 7450] New: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
From: Auke Kok [EMAIL PROTECTED] Date: Thu, 02 Nov 2006 13:48:48 -0800 the hang is caused by a bad eeprom bit. A script that fixes it for 82573-series with eeproms that need this bit fixed is attached to the bugreport. It detects the proper chipset and patches if required (uses ethtool). Those third party card makers, they always mess up the eeprom making things hard to support. :-) - 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
