Re: git patches against which tree?
Kumar Gala wrote: Jeff, Do you prefer patches against the netdev tree of Linus's ? Linus's tree, _unless_ there are already patches queued in netdev-2.6.git#upstream for driver. 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: git patches against which tree?
Kumar Gala wrote: Jeff, Do you prefer patches against the netdev tree of Linus's ? Linus's tree, _unless_ there are already patches queued in netdev-2.6.git#upstream for your driver. 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] hostap: allow flashing firmware
On Fri, Dec 30, 2005 at 06:22:26PM -0500, Pavel Roskin wrote: > Host AP driver has code to support writing firmware to non-volatile > memory, a.k.a. flash. This code has been extensively tested when Host > AP was a standalone driver. > > Add a configuration option to the kernel to allow enabling this > functionality. Improve the description of the RAM download option. > Mention cards that require it. Remove obsolete scary comment. I'm not completely against this change, but that scary comment is there on purpose and it is not fully obsolete. It is still possible to get HFA3841 cards into state which require hardware modifications to recover from (i.e., they are as good as dead for most users). Taken into this account, I would prefer that the help text for HOSTAP_FIRMWARE_NVRAM would include a warning about the potential issues of using incorrect firmware images. In most cases, RAM (volatile) download can be used to upgrade the firmware without having to modify the flash contents. This is also what the current Windows drivers are doing. -- Jouni MalinenPGP id EFC895FA - 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] Change 1500 to ETH_DATA_LEN in some files
These patches add the header linux/if_ether.h and change 1500 to ETH_DATA_LEN in
some files.
Signed-off-by: Kris Katterjohn <[EMAIL PROTECTED]>
At first I wasn't going to change anything under net/ipv[46], but I then saw
that
ipv6/ip6_tunnel.c used ETH_DATA_LEN, so I went ahead and changed them, too.
A "grep -R 1500 /usr/src/linux/net" yields a few results, but these files that I
patched seem to be the ones that "fit" best with ETH_DATA_LEN.
Let me know what you think. Thanks!
--- x/net/bridge/br_if.c2006-01-02 21:21:10.0 -0600
+++ y/net/bridge/br_if.c2006-01-04 21:25:10.0 -0600
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include "br_private.h"
@@ -295,7 +296,7 @@ int br_del_bridge(const char *name)
return ret;
}
-/* Mtu of the bridge pseudo-device 1500 or the minimum of the ports */
+/* MTU of the bridge pseudo-device: ETH_DATA_LEN or the minimum of the ports */
int br_min_mtu(const struct net_bridge *br)
{
const struct net_bridge_port *p;
@@ -304,7 +305,7 @@ int br_min_mtu(const struct net_bridge *
ASSERT_RTNL();
if (list_empty(&br->port_list))
- mtu = 1500;
+ mtu = ETH_DATA_LEN;
else {
list_for_each_entry(p, &br->port_list, list) {
if (!mtu || p->dev->mtu < mtu)
--- x/net/ethernet/eth.c2006-01-02 21:21:10.0 -0600
+++ y/net/ethernet/eth.c2006-01-04 21:25:29.0 -0600
@@ -53,6 +53,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -251,7 +252,7 @@ static int eth_mac_addr(struct net_devic
static int eth_change_mtu(struct net_device *dev, int new_mtu)
{
- if ((new_mtu < 68) || (new_mtu > 1500))
+ if (new_mtu < 68 || new_mtu > ETH_DATA_LEN)
return -EINVAL;
dev->mtu = new_mtu;
return 0;
@@ -272,7 +273,7 @@ void ether_setup(struct net_device *dev)
dev->type = ARPHRD_ETHER;
dev->hard_header_len= ETH_HLEN;
- dev->mtu= 1500; /* eth_mtu */
+ dev->mtu= ETH_DATA_LEN;
dev->addr_len = ETH_ALEN;
dev->tx_queue_len = 1000; /* Ethernet wants good queues */
dev->flags = IFF_BROADCAST|IFF_MULTICAST;
--- x/net/ipv4/ip_gre.c 2006-01-02 21:21:10.0 -0600
+++ y/net/ipv4/ip_gre.c 2006-01-04 21:26:03.0 -0600
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1140,7 +1141,7 @@ static void ipgre_tunnel_setup(struct ne
dev->type = ARPHRD_IPGRE;
dev->hard_header_len= LL_MAX_HEADER + sizeof(struct iphdr) + 4;
- dev->mtu= 1500 - sizeof(struct iphdr) - 4;
+ dev->mtu= ETH_DATA_LEN - sizeof(struct iphdr) - 4;
dev->flags = IFF_NOARP;
dev->iflink = 0;
dev->addr_len = 4;
@@ -1152,7 +1153,7 @@ static int ipgre_tunnel_init(struct net_
struct ip_tunnel *tunnel;
struct iphdr *iph;
int hlen = LL_MAX_HEADER;
- int mtu = 1500;
+ int mtu = ETH_DATA_LEN;
int addend = sizeof(struct iphdr) + 4;
tunnel = (struct ip_tunnel*)dev->priv;
--- x/net/ipv4/ipip.c 2006-01-02 21:21:10.0 -0600
+++ y/net/ipv4/ipip.c 2006-01-04 21:26:18.0 -0600
@@ -108,6 +108,7 @@
#include
#include
#include
+#include
#include
#include
@@ -786,7 +787,7 @@ static void ipip_tunnel_setup(struct net
dev->type = ARPHRD_TUNNEL;
dev->hard_header_len= LL_MAX_HEADER + sizeof(struct iphdr);
- dev->mtu= 1500 - sizeof(struct iphdr);
+ dev->mtu= ETH_DATA_LEN - sizeof(struct iphdr);
dev->flags = IFF_NOARP;
dev->iflink = 0;
dev->addr_len = 4;
--- x/net/ipv4/ipmr.c 2006-01-02 21:21:10.0 -0600
+++ y/net/ipv4/ipmr.c 2006-01-04 21:26:32.0 -0600
@@ -49,6 +49,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -192,7 +193,7 @@ static struct net_device_stats *reg_vif_
static void reg_vif_setup(struct net_device *dev)
{
dev->type = ARPHRD_PIMREG;
- dev->mtu= 1500 - sizeof(struct iphdr) - 8;
+ dev->mtu= ETH_DATA_LEN - sizeof(struct iphdr) - 8;
dev->flags = IFF_NOARP;
dev->hard_start_xmit= reg_vif_xmit;
dev->get_stats = reg_vif_get_stats;
--- x/net/ipv6/sit.c2006-01-02 21:21:10.0 -0600
+++ y/net/ipv6/sit.c2006-01-04 21:45:33.0 -0600
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#include
@@ -720,7 +721,7 @@ static void ipip6_tunnel_setup(struct ne
dev->type = ARPHRD_SIT;
dev->hard_header_len= LL_MAX_HEADE
Re: PCI DEVICE ID PROBLEM and Intel Intergrated eth card - a bios bug (?)
On 1/4/06, Krzysztof Baranowski <[EMAIL PROTECTED]> wrote: > After the upgrade my network card disappeared from both Linux and Win. > > After short investigation I noticed one strange incosistency. Under > the new BIOS the PCI device is reported as PCI VENDOR ID 1459 ( > which is gigabyte) DEV_ID 1019. However Windows driver for this > card (the lates from both intel and gigabyte) is looking for > VENDOR_ID 8086 (intel). IMO, gigabyte should not have changed the vendor id. Effectively they've said they will be the only ones supporting this hardware (not intel). Generally subvendor and subdevice ids should be the only thing changed by OEMs. Since it was changed by a bios upgrade i bet its a bios bug and should be reported to gigabyte. Until then you can hack your local kernel to get around it, but the e1000 driver probably shouldn't change to support this device ID. also, this is LKML and mentioning windows is just flame bait. :-) jesse - 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: gcc -Os causes: Re: ip route add default: network unreachable? 2.6.15
On Wed, Jan 04, 2006 at 03:46:21PM -0800, David S. Miller wrote: > > Now verifying if this is fixed in gcc 4.0.2. Plain, non-Ubuntu prerelease, gcc 4.0.2 does not exhibit this problem, even with -Os. Problem solved. -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services - 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
[RFC] bridge + netfilter + vlan + hw checksum = bug?
It looks like the bridge netfilter code does not correctly update
the hardware checksum after popping off the VLAN header.
This is by inspection, I have *not* tested this.
To test you would need to set up a filtering bridge with vlans
and a device the does hardware receive checksum (skge, or sungem)
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- net-2.6.16.orig/net/bridge/br_netfilter.c
+++ net-2.6.16/net/bridge/br_netfilter.c
@@ -394,8 +394,9 @@ inhdr_error:
* target in particular. Save the original destination IP
* address to be able to detect DNAT afterwards. */
static unsigned int br_nf_pre_routing(unsigned int hook, struct sk_buff **pskb,
- const struct net_device *in, const struct net_device *out,
- int (*okfn)(struct sk_buff *))
+ const struct net_device *in,
+ const struct net_device *out,
+ int (*okfn)(struct sk_buff *))
{
struct iphdr *iph;
__u32 len;
@@ -412,8 +413,10 @@ static unsigned int br_nf_pre_routing(un
goto out;
if (skb->protocol == __constant_htons(ETH_P_8021Q)) {
+ u8 *vhdr = skb->data;
skb_pull(skb, VLAN_HLEN);
- (skb)->nh.raw += VLAN_HLEN;
+ skb_postpull_rcsum(skb, vhdr, VLAN_HLEN);
+ skb->nh.raw += VLAN_HLEN;
}
return br_nf_pre_routing_ipv6(hook, skb, in, out, okfn);
}
@@ -429,8 +432,10 @@ static unsigned int br_nf_pre_routing(un
goto out;
if (skb->protocol == __constant_htons(ETH_P_8021Q)) {
+ u8 *vhdr = skb->data;
skb_pull(skb, VLAN_HLEN);
- (skb)->nh.raw += VLAN_HLEN;
+ skb_postpull_rcsum(skb, vhdr, VLAN_HLEN);
+ skb->nh.raw += VLAN_HLEN;
}
if (!pskb_may_pull(skb, sizeof(struct iphdr)))
-
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] Remove unneeded variable in net/packet/af_packet.c
This removes an unneeded "ret" variable and returns directly.
Signed-off-by: Kris Katterjohn <[EMAIL PROTECTED]>
I am now subscribed to the list, so there's no need to CC me anymore.
Thanks!
--- x/net/packet/af_packet.c2006-01-02 21:21:10.0 -0600
+++ y/net/packet/af_packet.c2006-01-04 17:44:17.0 -0600
@@ -1324,7 +1324,6 @@ static int
packet_setsockopt(struct socket *sock, int level, int optname, char __user
*optval, int optlen)
{
struct sock *sk = sock->sk;
- int ret;
if (level != SOL_PACKET)
return -ENOPROTOOPT;
@@ -1346,10 +1345,9 @@ packet_setsockopt(struct socket *sock, i
if (len < (mreq.mr_alen + offsetof(struct packet_mreq,
mr_address)))
return -EINVAL;
if (optname == PACKET_ADD_MEMBERSHIP)
- ret = packet_mc_add(sk, &mreq);
+ return packet_mc_add(sk, &mreq);
else
- ret = packet_mc_drop(sk, &mreq);
- return ret;
+ return packet_mc_drop(sk, &mreq);
}
#endif
#ifdef CONFIG_PACKET_MMAP
-
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] ipw2200: Fix NETDEV_TX_BUSY erroneous returned
Zhu Yi <[EMAIL PROTECTED]> :
>
> This patch fixes the warning below warning for the ipw2200 driver.
>
> NETDEV_TX_BUSY returned; driver should report queue full via
> ieee_device->is_queue_full.
Beyond what was said by Stephen Hemminger, the driver reports a
NETDEV_TX_BUSY when !STATUS_ASSOCIATED: neither this patch nor mine
fix it.
Btw the patch that I posted earlier forgets to protect against
every undue wake-up through:
ipw_rx
-> ipw_rx_notification
-> priv->link_up (work_queue)
-> ipw_bg_link_up
-> ipw_link_up
It will need some extra care to correctly play the
netif_{stop/wake}_queue dance.
--
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gcc -Os causes: Re: ip route add default: network unreachable? 2.6.15
From: bert hubert <[EMAIL PROTECTED]> Date: Thu, 5 Jan 2006 00:37:37 +0100 > This all goes away on removing CONFIG_CC_OPTIMIZE_FOR_SIZE in the kernel > .config with the gcc prerelease Ubunty Breezy ships. > > Now verifying if this is fixed in gcc 4.0.2. > > See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=322723 for more > details. > > I hope to pin down a culprit. Thanks for doing the legwork. This is likely the gcc-4.x bug that Fedora ran into as well and has been fixed there for a while. I've asked DaveJ to look at this and add a comment to the bug entry if he thinks it's the same thing. - 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: [ANNOUNCE] RT2x00 ieee80211 stack switch
On 1/4/06, Jiri Benc <[EMAIL PROTECTED]> wrote: > On Wed, 04 Jan 2006 13:41:43 +0100, Johannes Berg wrote: > > > The list wasn't complete, it was the things that need (from my POV) to > > > be resolved first only. There are more issues - some of them are known > > > to me, including this one, but I have them stored mostly as comments at > > > corresponding places in my development tree. I will try to extract them > > > into some nice todo list accessible to others. > > > > That'd be great :) > > http://kernel.org/pub/linux/kernel/people/jbenc/TODO-ieee80211 May I suggest we use the netdev wiki at http://linux-net.osdl.org? The more information about the work the netdev team is doing the more likely the site gets more value and helps newcomers understand the "big picture", where work is happening, where help is needed, etc. Thanks. - Arnaldo - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
gcc -Os causes: Re: ip route add default: network unreachable? 2.6.15
On Wed, Jan 04, 2006 at 11:36:33PM +0100, bert hubert wrote: > $ sudo ip route re default via 10.0.0.12 > RTNETLINK answers: Network is unreachable This all goes away on removing CONFIG_CC_OPTIMIZE_FOR_SIZE in the kernel .config with the gcc prerelease Ubunty Breezy ships. Now verifying if this is fixed in gcc 4.0.2. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=322723 for more details. I hope to pin down a culprit. -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] TCP_Vegas: Fix slow start
From: Tom Young <[EMAIL PROTECTED]> Date: Wed, 04 Jan 2006 16:14:23 +1100 > That it has. I'm really sorry about that. In this case it was my fault > rather than the client (copying from an xterm). I guess I'm just coming > out of slow start myself after the holiday lull. Please find the > non-abomination version of the patch below. > > Sorry for the noise. No problem, patch applied, thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH (should be ready to apply)] More instruction checks fornet/core/filter.c
From: "Kris Katterjohn" <[EMAIL PROTECTED]> Date: Wed, 4 Jan 2006 06:24:45 -0800 > Really? Have my other patches been screwed up, too? My email client > has "upgraded" recently (although I'm not sure what it was supposed > to be updating), so I'm sending this one from the old web-based > version. It should work because I sent my other patches through this > one. Much better, patch applied, thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fw: [Bugme-new] [Bug 5827] New: pppd with MPPE fails
This is expected, and similar output has been seen before. Jan Dubiec's pppd works with Jan Dubiec's PPP MPPE/MPPC kernel module, and does not always work with the PPP MPPE module maintained by the PPP team. In upgrading to 2.6.15, one should also convert to the upstream pppd from ppp.samba.org. Please do that and tell us the outcome. -- James Cameron - 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/3] [NETFILTER]: Use macro for spinlock_t/rwlock_t initializations/definition.
From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> Date: Wed, 04 Jan 2006 09:36:59 -0600 (CST) > Use macro for spinlock_t/rwlock_t initializations/definition. > > Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> All 3 patches applied, thanks a lot. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Fw: [Bugme-new] [Bug 5827] New: pppd with MPPE fails
Begin forwarded message: Date: Wed, 4 Jan 2006 12:53:40 -0800 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Bugme-new] [Bug 5827] New: pppd with MPPE fails http://bugzilla.kernel.org/show_bug.cgi?id=5827 Summary: pppd with MPPE fails Kernel Version: 2.6.15 Status: NEW Severity: high Owner: [EMAIL PROTECTED] Submitter: [EMAIL PROTECTED] Most recent kernel where this bug did not occur: none Distribution: Gentoo Hardware Environment: ASUS A3E-5018 Software Environment: Gentoo Problem Description: pppd with MPPE doesn't work properly, logs such messages: Jan 4 17:13:53 nelchael pppd[7651]: pppd 2.4.3 started by root, uid 0 Jan 4 17:13:53 nelchael pppd[7651]: Using interface ppp0 Jan 4 17:13:53 nelchael pppd[7651]: Connect: ppp0 <--> /dev/pts/2 Jan 4 17:13:55 nelchael pppd[7651]: CHAP authentication succeeded Jan 4 17:13:55 nelchael pppd[7651]: MPPE 128-bit stateful compression enabled Jan 4 17:13:58 nelchael pppd[7651]: local IP address x.x.x.8 Jan 4 17:13:58 nelchael pppd[7651]: remote IP address x.x.x.13 Jan 4 17:14:15 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 0xf3 Jan 4 17:14:16 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 'Encryption' (0x53) Jan 4 17:14:17 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 0x5afc Jan 4 17:14:18 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 0xc25a Jan 4 17:14:19 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 'NETBIOS Framing' (0x3f) Jan 4 17:14:20 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 0xe3 Jan 4 17:14:21 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 'MP+' (0x73) Jan 4 17:14:23 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 'SNA over 802.2' (0x4b) Jan 4 17:14:24 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 0xa8b6 Jan 4 17:14:25 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 0x50dc Jan 4 17:14:26 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 0x2c52 Jan 4 17:14:27 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 0x1d Jan 4 17:14:28 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 0x8432 Jan 4 17:14:29 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 0x40e4 Jan 4 17:14:30 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 0xe2f3 Jan 4 17:14:32 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 0x347d Jan 4 17:14:33 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 0x1e35 Jan 4 17:14:34 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 0x1842 Jan 4 17:14:35 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 0x641e Jan 4 17:14:36 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 0x44f1 Jan 4 17:14:37 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 0xcd Jan 4 17:14:38 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 0xf07a Jan 4 17:14:39 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 'MPLS Unicast' (0x281) Jan 4 17:14:40 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 0x3012 Jan 4 17:14:41 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 0xf8e4 Jan 4 17:14:42 nelchael pppd[7651]: Protocol-Reject for unsupported protocol 'AppleTalk SmartBuffered' (0x3b) Everything was ok with 2.6.14(.*) with this ( http://mppe-mppc.alphacron.de/ ) patch applied, but MPPE and above situation happens with the in-kernel version of MPPE. --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. - 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: Dummy as IMQ replacement
Andy Furniss wrote: I'll get everything upto date and try the new device tomorrow. Just tried the example script with ifb on 2.6.15 and it works OK, will try more complicated tests & iptables soon. Andy. - 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: RFC: Building a special bridge behaviour/module for wireless.
On Wed, 04 Jan 2006 10:26:16 -0800, Ben Greear wrote: > These devices usually have fairly weak processors...definately not > enough to run a bunch of VOIP calls, for instance. And, it means you > cannot use whatever real applications you might already have installed > on your wired devices (database servers, heavy-weight network testing > logic, etc). Ok, makes sense. > I have a vested interest as I make such network testing logic, but > if the wifi bridge logic is transparent, then anyone should be able to > make use of it I'm not sure that this should be included in the kernel. Anyway, send your patches to netdev, as they may be interesting for other people (including me). Thanks, -- 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: RFC: Building a special bridge behaviour/module for wireless.
Jiri Benc wrote: The end result is a wireless station emulator that can easily be made to pass interesting traffic generated on common hardware/platforms. It should be useful for testing APs and AP deployments, including things like VOIP over wifi. Ok, I can see the benefit from this for testing purposes. But then you don't need those wired machines, packets can be generated locally at your "virtual station emulator" and you need no hacks. These devices usually have fairly weak processors...definately not enough to run a bunch of VOIP calls, for instance. And, it means you cannot use whatever real applications you might already have installed on your wired devices (database servers, heavy-weight network testing logic, etc). I have a vested interest as I make such network testing logic, but if the wifi bridge logic is transparent, then anyone should be able to make use of it Thanks, Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com - 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: [ANNOUNCE] RT2x00 ieee80211 stack switch
On Wed, 04 Jan 2006 13:41:43 +0100, Johannes Berg wrote: > > The list wasn't complete, it was the things that need (from my POV) to > > be resolved first only. There are more issues - some of them are known > > to me, including this one, but I have them stored mostly as comments at > > corresponding places in my development tree. I will try to extract them > > into some nice todo list accessible to others. > > That'd be great :) http://kernel.org/pub/linux/kernel/people/jbenc/TODO-ieee80211 -- 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: RFC: Building a special bridge behaviour/module for wireless.
On Wed, 04 Jan 2006 09:39:31 -0800, Ben Greear wrote:
> WDS appears to work between APs..but I want to bridge wifi clients to wired
> clients.
>
> The network would be something like:
>
> wired-server -- AP {{{wireless}}} virtual-station-emulator -- { multiple
> wired machines }
wired-server -- AP {{{WDS}}} AP -- { multiple wired machines }
No problem at all :-)
> The idea is to have the wired machines talk wired ethernet through the AP
> without
> knowing or caring that wifi is being used. The AP will also be ignorant,
> thinking
> that multiple wireless devices are talking to it (ie, the
> virtual-station-emulator
> has multiple different wireless client interfaces configured in it.)
Only if you don't mind that you are limited by maximal number of APs your
device is capable to connect to.
> The end result is a wireless station emulator that can easily be made to pass
> interesting traffic generated on common hardware/platforms. It should be
> useful
> for testing APs and AP deployments, including things like VOIP over wifi.
Ok, I can see the benefit from this for testing purposes. But then you
don't need those wired machines, packets can be generated locally at
your "virtual station emulator" and you need no hacks.
--
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] ipw2200: Fix NETDEV_TX_BUSY erroneous returned
On Wed, 4 Jan 2006 12:09:54 +0800
Zhu Yi <[EMAIL PROTECTED]> wrote:
>
> This patch fixes the warning below warning for the ipw2200 driver.
>
> NETDEV_TX_BUSY returned; driver should report queue full via
> ieee_device->is_queue_full.
>
> Signed-off-by: Hong Liu <[EMAIL PROTECTED]>
> Signed-off-by: Zhu Yi <[EMAIL PROTECTED]>
> --
>
> diff -urp linux.orig/drivers/net/wireless/ipw2200.c
> linux/drivers/net/wireless/ipw2200.c
> --- linux.orig/drivers/net/wireless/ipw2200.c 2005-10-21 05:35:24.0
> +0800
> +++ linux/drivers/net/wireless/ipw2200.c 2005-10-25 13:22:38.0
> +0800
> @@ -9649,11 +9649,6 @@ static inline int ipw_tx_skb(struct ipw_
> u16 remaining_bytes;
> int fc;
>
> - /* If there isn't room in the queue, we return busy and let the
> - * network stack requeue the packet for us */
> - if (ipw_queue_space(q) < q->high_mark)
> - return NETDEV_TX_BUSY;
> -
> switch (priv->ieee->iw_mode) {
> case IW_MODE_ADHOC:
> hdr_len = IEEE80211_3ADDR_LEN;
> @@ -9871,7 +9866,7 @@ static int ipw_net_hard_start_xmit(struc
>
>fail_unlock:
> spin_unlock_irqrestore(&priv->lock, flags);
> - return 1;
> + return -1;
That's not right... -1 is NETDEV_TX_LOCKED, which is not what you want.
Also, please use NETDEV_TX_ values for return values from transmit routine.
You should post this to netdev@vger.kernel.org and [EMAIL PROTECTED]
for discussion there.
--
Stephen Hemminger <[EMAIL PROTECTED]>
OSDL http://developer.osdl.org/~shemminger
-
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: RFC: Building a special bridge behaviour/module for wireless.
Jiri Benc wrote:
On Wed, 04 Jan 2006 08:51:05 -0800, Ben Greear wrote:
This bridge module would not be used on an AP acting as an AP, but rather
a piece of access-point hardware running virtual client interfaces which are
associated with a real AP. If my understanding is correct (and that could
always be a false hope!), there should be no problem with having different
virtual stations talking to each other.
I misunderstood you, sorry.
Although I think I understand now what are you trying to achieve, I
don't understand why. Why do you not use WDS?
WDS appears to work between APs..but I want to bridge wifi clients to wired
clients.
The network would be something like:
wired-server -- AP {{{wireless}}} virtual-station-emulator -- { multiple wired
machines }
The idea is to have the wired machines talk wired ethernet through the AP
without
knowing or caring that wifi is being used. The AP will also be ignorant,
thinking
that multiple wireless devices are talking to it (ie, the
virtual-station-emulator
has multiple different wireless client interfaces configured in it.)
The end result is a wireless station emulator that can easily be made to pass
interesting traffic generated on common hardware/platforms. It should be useful
for testing APs and AP deployments, including things like VOIP over wifi.
This is a commercial product that mostly does what I want..but it's
quite expensive and definately not open source:
http://www.ixiacom.com/products/performance_applications/pa_display.php?skey=pa_ixwlan&gen=cmc
Thanks,
Ben
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc http://www.candelatech.com
-
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: RFC: Building a special bridge behaviour/module for wireless.
On Wed, 04 Jan 2006 08:51:05 -0800, Ben Greear wrote: > This bridge module would not be used on an AP acting as an AP, but rather > a piece of access-point hardware running virtual client interfaces which are > associated with a real AP. If my understanding is correct (and that could > always be a false hope!), there should be no problem with having different > virtual stations talking to each other. I misunderstood you, sorry. Although I think I understand now what are you trying to achieve, I don't understand why. Why do you not use WDS? -- 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: RFC: Building a special bridge behaviour/module for wireless.
Jiri Benc wrote: On Tue, 03 Jan 2006 19:09:13 -0800, Ben Greear wrote: The AP will act like a bridge/switch according to these rules: If a packet enters the wifi device, it will be sent down the wired ethernet interface un-changed. If a packet enters the wired device, the wifi device with the same MAC as the source-MAC in the ethernet frame will be used to transmit the packet wirelessly. If I understand it correctly, you will remove 802.11 header and build new Ethernet header in the first case and vice versa in the second case. One of the results will be that the communication between two stations associated to the AP is not possible. I was hoping that I could get a 'regular' ethernet frame from the wifi virtual station interfaces, and also send them a regular ethernet frame and have it do the right thing. I was thinking that the main problem with bridging wifi interfaces is that they have hard requirements about their MAC address, so I was going to work around this by just making the wired clients have the same MAC address as the wifi device. This bridge module would not be used on an AP acting as an AP, but rather a piece of access-point hardware running virtual client interfaces which are associated with a real AP. If my understanding is correct (and that could always be a false hope!), there should be no problem with having different virtual stations talking to each other. Thanks, Ben Well, I don't understand what it is good for (or maybe I haven't understood you at all?) but if you plan to implement 802.11<->Ethernet conversion in the bridging code, I'm definitely interested as this may solve some problems with the generic 802.11 stack. -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] [ECONET]: Use macro for spinlock_t definition.
Use macro for spinlock_t definition. Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> diff --git a/net/econet/af_econet.c b/net/econet/af_econet.c index 34fdac5..cefc26d 100644 --- a/net/econet/af_econet.c +++ b/net/econet/af_econet.c @@ -56,7 +56,7 @@ static struct net_device *net2dev_map[25 #define EC_PORT_IP 0xd2 #ifdef CONFIG_ECONET_AUNUDP -static spinlock_t aun_queue_lock; +static DEFINE_SPINLOCK(aun_queue_lock); static struct socket *udpsock; #define AUN_PORT 0x8000 -- YOSHIFUJI Hideaki @ USAGI Project <[EMAIL PROTECTED]> GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] [IPV6]: Use macro for rwlock_t initialization.
Use macro for rwlock_t initialization. Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c index f829a4a..1cf305a 100644 --- a/net/ipv6/mcast.c +++ b/net/ipv6/mcast.c @@ -224,7 +224,7 @@ int ipv6_sock_mc_join(struct sock *sk, i mc_lst->ifindex = dev->ifindex; mc_lst->sfmode = MCAST_EXCLUDE; - mc_lst->sflock = RW_LOCK_UNLOCKED; + rwlock_init(&mc_lst->sflock); mc_lst->sflist = NULL; /* -- YOSHIFUJI Hideaki @ USAGI Project <[EMAIL PROTECTED]> GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA - 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 3/3] [NETFILTER]: Use macro for spinlock_t/rwlock_t initializations/definition.
Use macro for spinlock_t/rwlock_t initializations/definition. Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> diff --git a/net/ipv6/netfilter/nf_conntrack_reasm.c b/net/ipv6/netfilter/nf_conntrack_reasm.c index c2c52af..f3e5ffb 100644 --- a/net/ipv6/netfilter/nf_conntrack_reasm.c +++ b/net/ipv6/netfilter/nf_conntrack_reasm.c @@ -98,7 +98,7 @@ struct nf_ct_frag6_queue #define FRAG6Q_HASHSZ 64 static struct nf_ct_frag6_queue *nf_ct_frag6_hash[FRAG6Q_HASHSZ]; -static rwlock_t nf_ct_frag6_lock = RW_LOCK_UNLOCKED; +static DEFINE_RWLOCK(nf_ct_frag6_lock); static u32 nf_ct_frag6_hash_rnd; static LIST_HEAD(nf_ct_frag6_lru_list); int nf_ct_frag6_nqueues = 0; @@ -371,7 +371,7 @@ nf_ct_frag6_create(unsigned int hash, u3 init_timer(&fq->timer); fq->timer.function = nf_ct_frag6_expire; fq->timer.data = (long) fq; - fq->lock = SPIN_LOCK_UNLOCKED; + spin_lock_init(&fq->lock); atomic_set(&fq->refcnt, 1); return nf_ct_frag6_intern(hash, fq); diff --git a/net/netfilter/nfnetlink_log.c b/net/netfilter/nfnetlink_log.c index cba6372..e10512e 100644 --- a/net/netfilter/nfnetlink_log.c +++ b/net/netfilter/nfnetlink_log.c @@ -151,7 +151,7 @@ instance_create(u_int16_t group_num, int goto out_unlock; INIT_HLIST_NODE(&inst->hlist); - inst->lock = SPIN_LOCK_UNLOCKED; + spin_lock_init(&inst->lock); /* needs to be two, since we _put() after creation */ atomic_set(&inst->use, 2); diff --git a/net/netfilter/nfnetlink_queue.c b/net/netfilter/nfnetlink_queue.c index f28460b..55afdda 100644 --- a/net/netfilter/nfnetlink_queue.c +++ b/net/netfilter/nfnetlink_queue.c @@ -148,7 +148,7 @@ instance_create(u_int16_t queue_num, int atomic_set(&inst->id_sequence, 0); /* needs to be two, since we _put() after creation */ atomic_set(&inst->use, 2); - inst->lock = SPIN_LOCK_UNLOCKED; + spin_lock_init(&inst->lock); INIT_LIST_HEAD(&inst->queue_list); if (!try_module_get(THIS_MODULE)) -- YOSHIFUJI Hideaki @ USAGI Project <[EMAIL PROTECTED]> GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA - 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 (should be ready to apply)] More instruction checks fornet/core/filter.c
From: David S. Miller
> From: "Kris Katterjohn" <[EMAIL PROTECTED]>
> Your email client has corrupted the patch spacing and tabbing.
> Please fix this.
Really? Have my other patches been screwed up, too? My email client has
"upgraded" recently (although I'm not sure what it was supposed to be updating),
so I'm sending this one from the old web-based version. It should work because I
sent my other patches through this one.
It won't be a problem for me to send the patch as an attachment if this one
screws up, will it?
Sorry about this.
Signed-off-by: Kris Katterjohn <[EMAIL PROTECTED]>
--- x/net/core/filter.c 2006-01-03 11:09:07.0 -0600
+++ y/net/core/filter.c 2006-01-03 21:42:02.0 -0600
@@ -13,6 +13,7 @@
* 2 of the License, or (at your option) any later version.
*
* Andi Kleen - Fix a few bad bugs and races.
+ * Kris Katterjohn - Added many additional checks in sk_chk_filter()
*/
#include
@@ -250,7 +251,7 @@ load_b:
mem[fentry->k] = X;
continue;
default:
- /* Invalid instruction counts as RET */
+ WARN_ON(1);
return 0;
}
@@ -283,8 +284,8 @@ load_b:
*
* Check the user's filter code. If we let some ugly
* filter code slip through kaboom! The filter must contain
- * no references or jumps that are out of range, no illegal instructions
- * and no backward jumps. It must end with a RET instruction
+ * no references or jumps that are out of range, no illegal
+ * instructions, and must end with a RET instruction.
*
* Returns 0 if the rule set is legal or a negative errno code if not.
*/
@@ -300,38 +301,85 @@ int sk_chk_filter(struct sock_filter *fi
for (pc = 0; pc < flen; pc++) {
/* all jumps are forward as they are not signed */
ftest = &filter[pc];
- if (BPF_CLASS(ftest->code) == BPF_JMP) {
- /* but they mustn't jump off the end */
- if (BPF_OP(ftest->code) == BPF_JA) {
- /*
-* Note, the large ftest->k might cause loops.
-* Compare this with conditional jumps below,
-* where offsets are limited. --ANK (981016)
-*/
- if (ftest->k >= (unsigned)(flen-pc-1))
- return -EINVAL;
- } else {
- /* for conditionals both must be safe */
- if (pc + ftest->jt +1 >= flen ||
- pc + ftest->jf +1 >= flen)
- return -EINVAL;
- }
- }
- /* check for division by zero -Kris Katterjohn 2005-10-30 */
- if (ftest->code == (BPF_ALU|BPF_DIV|BPF_K) && ftest->k == 0)
- return -EINVAL;
+ /* Only allow valid instructions */
+ switch (ftest->code) {
+ case BPF_ALU|BPF_ADD|BPF_K:
+ case BPF_ALU|BPF_ADD|BPF_X:
+ case BPF_ALU|BPF_SUB|BPF_K:
+ case BPF_ALU|BPF_SUB|BPF_X:
+ case BPF_ALU|BPF_MUL|BPF_K:
+ case BPF_ALU|BPF_MUL|BPF_X:
+ case BPF_ALU|BPF_DIV|BPF_X:
+ case BPF_ALU|BPF_AND|BPF_K:
+ case BPF_ALU|BPF_AND|BPF_X:
+ case BPF_ALU|BPF_OR|BPF_K:
+ case BPF_ALU|BPF_OR|BPF_X:
+ case BPF_ALU|BPF_LSH|BPF_K:
+ case BPF_ALU|BPF_LSH|BPF_X:
+ case BPF_ALU|BPF_RSH|BPF_K:
+ case BPF_ALU|BPF_RSH|BPF_X:
+ case BPF_ALU|BPF_NEG:
+ case BPF_LD|BPF_W|BPF_ABS:
+ case BPF_LD|BPF_H|BPF_ABS:
+ case BPF_LD|BPF_B|BPF_ABS:
+ case BPF_LD|BPF_W|BPF_LEN:
+ case BPF_LD|BPF_W|BPF_IND:
+ case BPF_LD|BPF_H|BPF_IND:
+ case BPF_LD|BPF_B|BPF_IND:
+ case BPF_LD|BPF_IMM:
+ case BPF_LDX|BPF_W|BPF_LEN:
+ case BPF_LDX|BPF_B|BPF_MSH:
+ case BPF_LDX|BPF_IMM:
+ case BPF_MISC|BPF_TAX:
+ case BPF_MISC|BPF_TXA:
+ case BPF_RET|BPF_K:
+ case BPF_RET|BPF_A:
+ break;
+
+ /* Some instructions need special checks */
- /* check that memory operations use valid addresses. */
- if (ftest->k >= BPF_MEMWORDS) {
- /* but it might not be a memory operation... */
- switch (ftest->code) {
- case BPF_ST:
- case BPF_STX:
- case BPF_LD|BPF_MEM:
- case BPF_LDX|BPF_MEM:
+ case BPF_ALU|BPF
Re: Integrating IXP4xx NPE support in kernel (with IXP4xx accesslibrary)
On Tue, Dec 27, 2005 at 09:22:31AM -0500, jamal wrote: > On Tue, 2005-27-12 at 15:05 +0100, Lennert Buytenhek wrote: > > On Tue, Dec 27, 2005 at 08:49:50AM -0500, jamal wrote: > > > > > A question for you: Does the 4XX allow you to rewrite the microcode? > > > > As far as I know, there are no docs for this, at least not any publicly > > available ones. > > > > Chapter 4 in the IXP42X Developer's Manual is titled "Network Processor > > Engines (NPE)", but that's just a 2-page marketing blurb on how great > > their stuff is. If you ask Intel for docs, they just tell you to go > > look at the available (evil-licensed) source code. > > They probably will never open it up. which is quite surprising, given the fact that you get full documentation (even as printed books) for the ixp2xxx microengines. Yes, all the actual example microcode is evil-licensed, but as lennert has shown it is possible to develop gpl licensed microengine code using their docs. why can't they just do the same for ixp4xx? -- - Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) pgpmx85Sbq20y.pgp Description: PGP signature
compiling information on 80211 stacks
Hi, I'm trying to compile information on the advantages and disadvantages of the various 802.11 stacks as so far I haven't found a good overview document. The current draft is at http://johannes.sipsolutions.net/802.11_stacks I'd appreciate if anyone who has information to add to the list would mail it to me *privately*. (Privately so we don't end up with another flamewar again, I'll try to filter it against what others say) If you write a note, please mention how you came to that conclusion (having worked with the stack by writing a driver, having written the stack, having reviewed the code, ) johannes signature.asc Description: This is a digitally signed message part
Re: Resubmit: [PATCH] natsemi: NAPI support
On Wed, Jan 04, 2006 at 07:32:49AM +, Mark Brown wrote: > This patch against 2.6.14 converts the natsemi driver to use NAPI. It > was originally based on one written by Harald Welte, though it has since > been modified quite a bit, most extensively in order to remove the > ability to disable NAPI since none of the other drivers seem to provide > that functionality any more. Mark, sorry for not responding earlier to your emails with regard to your natsemi patch. Thanks for pushing this persistently. From reviewing your patch, I personally thin it's fine to be merged. I will test it on my natsemi based boxes later today. -- - Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) pgpXjBH2ZtIut.pgp Description: PGP signature
Re: RFC: Building a special bridge behaviour/module for wireless.
On Tue, 03 Jan 2006 19:09:13 -0800, Ben Greear wrote: > The AP will act like a bridge/switch according to these rules: > > If a packet enters the wifi device, it will be sent down the wired > ethernet interface un-changed. > > If a packet enters the wired device, the wifi device with the same > MAC as the source-MAC in the ethernet frame will be used to transmit > the packet wirelessly. If I understand it correctly, you will remove 802.11 header and build new Ethernet header in the first case and vice versa in the second case. One of the results will be that the communication between two stations associated to the AP is not possible. Well, I don't understand what it is good for (or maybe I haven't understood you at all?) but if you plan to implement 802.11<->Ethernet conversion in the bridging code, I'm definitely interested as this may solve some problems with the generic 802.11 stack. -- 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: [ANNOUNCE] RT2x00 ieee80211 stack switch
On Wed, 04 Jan 2006 13:41:43 +0100, Johannes Berg wrote: > Oh another question: is the stack capable of having a raw device > associated with the actual hardware device that sees all incoming and > outgoing frames including 802.11 headers? I'd love to have that for > debugging... Sure, wlan0ap. It has also Prism header attached. -- 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: [ANNOUNCE] RT2x00 ieee80211 stack switch
On Wed, 2006-01-04 at 13:35 +0100, Jiri Benc wrote: > The list wasn't complete, it was the things that need (from my POV) to > be resolved first only. There are more issues - some of them are known > to me, including this one, but I have them stored mostly as comments at > corresponding places in my development tree. I will try to extract them > into some nice todo list accessible to others. That'd be great :) > /* TODO: implement register/unregister functions for adding TX/RX handlers > * into ordered list */ Yeah, I've seen that, though couldn't really make sense of it. > The frames really goes through all of decryption functions but they are > not tried to decrypt, the functions return at they beginning. This > probably can be optimized. And many other parts of the code need > optimization too. Ok. > > What's with CONFIG_OAP_LEDS_WLAN? Shouldn't that LED handling function > > be a pointer that can be assigned to whatever one wants, and you could > > then get rid of IEEE80211_LEDS etc? > > LED handling seems strange. It probably depends on some other stuff not > released by Devicescape, I would suspect something responsible for > handling LEDs on their AP boxes or so. Makes sense. With the broadcom cards that have LEDs this could be interesting, but in the current form the code seems just useless. > It's not vlan. Some devices are capable to associate to multiple APs and > you need to present this to userspace by more interfaces. The same with > WDS links. Ah. That makes sense. Didn't know that was supported. Oh another question: is the stack capable of having a raw device associated with the actual hardware device that sees all incoming and outgoing frames including 802.11 headers? I'd love to have that for debugging... Thanks for your quick reply. johannes signature.asc Description: This is a digitally signed message part
Re: [ANNOUNCE] RT2x00 ieee80211 stack switch
On Tue, 03 Jan 2006 18:06:30 +0100, Johannes Berg wrote: > How about > - get rid of all the embedded algorithms (AES, Michael, RC4, >CRC) and use the crypto layer from the kernel Definitely. The list wasn't complete, it was the things that need (from my POV) to be resolved first only. There are more issues - some of them are known to me, including this one, but I have them stored mostly as comments at corresponding places in my development tree. I will try to extract them into some nice todo list accessible to others. > - port IPW drivers instead of just moving everything around, >get rid of old code completely :-) > - split out frame crypto stuff into modules like ieee80211 does >(or maybe even use those?) Would be nice. See also a comment in ieee80211.c: /* TODO: implement register/unregister functions for adding TX/RX handlers * into ordered list */ > and finally > - fix tabs vs spaces all over the place ;) > > I also have a couple of questions: > > It seems that all packets are tried to decrypt with all possible > algorithms, or is that just my misunderstanding of the code? Wouldn't it > be possible to know what to expect and only pass it through those > functions that are needed? The frames really goes through all of decryption functions but they are not tried to decrypt, the functions return at they beginning. This probably can be optimized. And many other parts of the code need optimization too. > What's with CONFIG_OAP_LEDS_WLAN? Shouldn't that LED handling function > be a pointer that can be assigned to whatever one wants, and you could > then get rid of IEEE80211_LEDS etc? LED handling seems strange. It probably depends on some other stuff not released by Devicescape, I would suspect something responsible for handling LEDs on their AP boxes or so. > This may be related to your item about reducing the number of > interfaces, but why do you have vlan interfaces explicitly? Shouldn't > the generic vlan code be able to handle this? It's not vlan. Some devices are capable to associate to multiple APs and you need to present this to userspace by more interfaces. The same with WDS links. Thanks for your comments, -- 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: 2.6.12.6 to 2.6.14.3 Major 10-GigE TCP Network Performance Degradation
On Tue, 3 Jan 2006, Stephen Hemminger wrote: > On Wed, 28 Dec 2005 22:35:50 -0500 > Bill Fink <[EMAIL PROTECTED]> wrote: > > > Would the following patch be at all useful for the 2.6.14.x stable > > series, since enabling TSO there causes a 40% or greater TCP performance > > penalty, or is 2.6.15 final so imminenent that it wouldn't be > > considered useful? > > > > Signed-off-by: Bill Fink <[EMAIL PROTECTED]> > > > > --- linux-2.6.14.3.orig/drivers/net/ixgb/ixgb_main.c2005-11-24 > > 17:10:21.0 -0500 > > +++ linux-2.6.14.3/drivers/net/ixgb/ixgb_main.c 2005-12-28 > > 01:06:05.0 -0500 > > @@ -445,7 +445,8 @@ > >NETIF_F_HW_VLAN_RX | > >NETIF_F_HW_VLAN_FILTER; > > #ifdef NETIF_F_TSO > > - netdev->features |= NETIF_F_TSO; > > + /* TSO not performant at present - disable by default */ > > + netdev->features &= ~NETIF_F_TSO; > > #endif > > > > if(pci_using_dac) > > doesn't make sense to patch just one driver. It would make more sense > to backport the TSO cwnd patch from 2.6.15 I agree but I don't currently have the knowledge or time to do that, and it's probably moot since I believe 2.6.15 final is now out. Also, I suspect it's really only an issue for 10-GigE NICs. Testing with an Intel quad-GigE NIC didn't show any problem: [EMAIL PROTECTED] ifconfig eth5 eth5 Link encap:Ethernet HWaddr 00:04:23:08:8A:46 inet addr:192.168.5.75 Bcast:192.168.5.255 Mask:255.255.255.0 inet6 addr: fe80::204:23ff:fe08:8a46/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1 ... [EMAIL PROTECTED] ethtool -k eth5 Offload parameters for eth5: rx-checksumming: on tx-checksumming: on scatter-gather: on tcp segmentation offload: on (and likewise on chance4 (192.168.5.78)) TSO enabled: chance% nuttcp -w1m 192.168.5.78 1183.7128 MB / 10.03 sec = 989.7925 Mbps 11 %TX 8 %RX chance% nuttcp -r -w1m 192.168.5.78 1183.7982 MB / 10.03 sec = 989.7653 Mbps 11 %TX 8 %RX [EMAIL PROTECTED] ethtool -K eth5 tso off [EMAIL PROTECTED] ethtool -k eth5 Offload parameters for eth5: rx-checksumming: on tx-checksumming: on scatter-gather: on tcp segmentation offload: off (and likewise on chance4 (192.168.5.78)) TSO disabled: chance% nuttcp -w1m 192.168.5.78 1182.5833 MB / 10.02 sec = 989.7864 Mbps 13 %TX 8 %RX chance% nuttcp -r -w1m 192.168.5.78 1182.1543 MB / 10.02 sec = 989.5802 Mbps 12 %TX 8 %RX -Bill P.S. I can't currently get to www.kernel.org, getting the following error: Forbidden You don't have permission to access / on this server. Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request. - 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
