* Re: [PATCH] powerpc: ibmveth: Harden driver initilisation for kexec
From: Michael Ellerman @ 2006-04-26 10:37 UTC (permalink / raw)
To: jgarzik; +Cc: anton, linuxppc64-dev, netdev, Santiago Leon
In-Reply-To: <1143421876.7795.2.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1081 bytes --]
On Mon, 2006-03-27 at 12:11 +1100, Michael Ellerman wrote:
> On Thu, 2006-03-02 at 13:40 -0600, Santiago Leon wrote:
> > From: Michael Ellerman <michael@ellerman.id.au>
> >
> > After a kexec the veth driver will fail when trying to register with the
> > Hypervisor because the previous kernel has not unregistered.
> >
> > So if the registration fails, we unregister and then try again.
> >
> > Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> > Acked-by: Anton Blanchard <anton@samba.org>
> > Signed-off-by: Santiago Leon <santil@us.ibm.com>
> > ---
> >
> > drivers/net/ibmveth.c | 32 ++++++++++++++++++++++++++------
> > 1 files changed, 26 insertions(+), 6 deletions(-)
>
> Looks like this hit the floor. Any chance of getting it into to 2.6.17
> Jeff? AFAICT it should still apply cleanly.
/me knocks politely
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: ipsec tunnel asymmetrical mtu
From: Herbert Xu @ 2006-04-26 10:55 UTC (permalink / raw)
To: Marco Berizzi; +Cc: netdev
In-Reply-To: <BAY103-F290B963EE35123CC2E6DB8B2BE0@phx.gbl>
On Mon, Apr 24, 2006 at 09:23:00AM +0000, Marco Berizzi wrote:
>
> What should I do? Mangling MSS with iptables --set-mss ?
> Altering MSS to 1440 did the trick. See:
> http://marc.theaimsgroup.com/?l=linux-netdev&m=114373067423528&w=2
--clamp-mss-to-pmtu should be the best option.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Please explain this ARP behaviour.
From: Simon Kelley @ 2006-04-26 11:58 UTC (permalink / raw)
To: netdev
Two machines, many configuration differences, I need to find which one
is causing this difference in behaviour:
Machine 1: (eth1 is on the correct 192.168.3.x network)
# ip neighbour add to 192.168.2.15 lladdr 00:0F:20:98:F8:86 nud \
reachable dev eth1
# cat /proc/net/arp
IP address HW type Flags HW address Mask
Device
192.168.0.4 0x1 0x2 00:00:F8:04:9B:69 * eth0
192.168.2.15 0x1 0x2 00:0F:20:98:F8:86 * eth1
192.168.2.148 0x1 0x2 00:10:A4:F2:CF:CB * eth1
# ip neighbour show
192.168.0.4 dev eth0 lladdr 00:00:f8:04:9b:69 nud reachable
192.168.2.15 dev eth1 lladdr 00:0f:20:98:f8:86 nud reachable
192.168.2.148 dev eth1 lladdr 00:10:a4:f2:cf:cb nud stale
Note that hand-created entry appears in /proc and ip .. show
Machine 2: (similarly correct network)
# ip neighbour add to 192.62.204.15 lladdr 00:0F:20:98:F8:86\
nud reachable dev eth1
IP address HW type Flags HW address Mask
Device
193.62.204.1 0x1 0x2 00:0F:20:98:F8:87 * eth1
# ip neighbour show
192.62.204.15 dev eth1 lladdr 00:0f:20:98:f8:86 nud reachable
193.62.204.1 dev eth1 lladdr 00:0f:20:98:f8:87 nud stale
Here, hand-created interface is in ip .. show, but missing from /proc
There is some reason to believe that the functional ARP behaves as
/proc/net/arp (ie the hand-created entry is ignored) but I don't have
absolute proof of that yet.
Machine 1 (works) is 2.6.12.2 hand compiled
Machine 2 (broken) is Ubunutu's 2.6.10-5-386, but this has possibly been
seen in Debian 2.6.16.2 as well.
Please could someone suggest where I look next?
Cheers,
Simon.
^ permalink raw reply
* Re: ipsec tunnel asymmetrical mtu
From: Marco Berizzi @ 2006-04-26 12:20 UTC (permalink / raw)
To: herbert; +Cc: netdev
In-Reply-To: <20060426105546.GA11726@gondor.apana.org.au>
Herbert Xu wrote:
>On Mon, Apr 24, 2006 at 09:23:00AM +0000, Marco Berizzi wrote:
> >
> > What should I do? Mangling MSS with iptables --set-mss ?
> > Altering MSS to 1440 did the trick. See:
> > http://marc.theaimsgroup.com/?l=linux-netdev&m=114373067423528&w=2
>
>--clamp-mss-to-pmtu should be the best option.
Ok. thanks for the tip.
Have you discovered anything about the bug?
Do you need other info?
^ permalink raw reply
* Re: determine outgoing interface (eth0,eth1) for a packet according to the dest IP
From: Herbert Xu @ 2006-04-26 13:58 UTC (permalink / raw)
To: John Que; +Cc: ak, netdev
In-Reply-To: <ada605fb0604260324n4dc99556j300bfd433a9027d9@mail.gmail.com>
John Que <qwejohn@gmail.com> wrote:
>
> I had spent time trying to write something which
> uses RTA_SRC and RTA_DST and got some problems.
> (I probably made something stupid.)
> I googled for such examples and did not get much.
> I saw that the zebra project and iproute uses
> netlinks but it is complex.,
Have a look at
http://gondor.apana.org.au/~herbert/findsaddr-linux.c
which I wrote for traceroute some years back. It should be easy
to adapt to get the interface instead of the source address.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* BUG: e1000 Invalid truesize
From: Jens Axboe @ 2006-04-26 14:25 UTC (permalink / raw)
To: netdev; +Cc: john.ronciak, jesse.brandeburg, jeffrey.t.kirsher
Hi,
My problematic e1000 card (that sporadically gets transmit timeouts with
a driver newer than 2.6.14) hits new problems in current git after this
commit:
[NET]: Add skb->truesize assertion checking.
I thought I'd mention it, since it may help fix the real problem.
Basically I get tons of:
SKB BUG: Invalid truesize (592) len=712, sizeof(sk_buff)=208
SKB BUG: Invalid truesize (592) len=448, sizeof(sk_buff)=208
SKB BUG: Invalid truesize (592) len=712, sizeof(sk_buff)=208
SKB BUG: Invalid truesize (592) len=448, sizeof(sk_buff)=208
SKB BUG: Invalid truesize (592) len=500, sizeof(sk_buff)=208
SKB BUG: Invalid truesize (592) len=500, sizeof(sk_buff)=208
SKB BUG: Invalid truesize (592) len=500, sizeof(sk_buff)=208
[...]
and some net connections don't work well. Putting the 2.6.14 driver back
into current git makes things work smoothly, as always.
(Please be sure to cc me, I'm not on netdev)
--
Jens Axboe
^ permalink raw reply
* RE: e1000 Invalid truesize
From: Ronciak, John @ 2006-04-26 15:24 UTC (permalink / raw)
To: Jens Axboe, netdev; +Cc: Brandeburg, Jesse, Kirsher, Jeffrey T
Please follow what has been happening on netdev. Dave Miller added this
BUG to 2.6.17-rc as something we (Intel LAD) pointed out to them. Jeff
Garzik has, as of this morning, queued our e1000 patch for this. He's
been a little behind.
If you want to know more about the problem, please read the entire
netdev discussion about this.
Cheers,
John
-----------------------------------------------------------
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.", Benjamin
Franklin 1755
> -----Original Message-----
> From: Jens Axboe [mailto:axboe@suse.de]
> Sent: Wednesday, April 26, 2006 7:25 AM
> To: netdev@vger.kernel.org
> Cc: Ronciak, John; Brandeburg, Jesse; Kirsher, Jeffrey T
> Subject: BUG: e1000 Invalid truesize
>
>
> Hi,
>
> My problematic e1000 card (that sporadically gets transmit
> timeouts with
> a driver newer than 2.6.14) hits new problems in current git
> after this
> commit:
>
> [NET]: Add skb->truesize assertion checking.
>
> I thought I'd mention it, since it may help fix the real problem.
> Basically I get tons of:
>
> SKB BUG: Invalid truesize (592) len=712, sizeof(sk_buff)=208
> SKB BUG: Invalid truesize (592) len=448, sizeof(sk_buff)=208
> SKB BUG: Invalid truesize (592) len=712, sizeof(sk_buff)=208
> SKB BUG: Invalid truesize (592) len=448, sizeof(sk_buff)=208
> SKB BUG: Invalid truesize (592) len=500, sizeof(sk_buff)=208
> SKB BUG: Invalid truesize (592) len=500, sizeof(sk_buff)=208
> SKB BUG: Invalid truesize (592) len=500, sizeof(sk_buff)=208
> [...]
>
> and some net connections don't work well. Putting the 2.6.14
> driver back
> into current git makes things work smoothly, as always.
>
> (Please be sure to cc me, I'm not on netdev)
>
> --
> Jens Axboe
>
^ permalink raw reply
* Re: [PATCH] compile error in ieee80211_ioctl.c
From: Alex Davis @ 2006-04-26 16:29 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, linux-kernel
In-Reply-To: <20060425211236.GC19116@tuxdriver.com>
--- "John W. Linville" <linville@tuxdriver.com> wrote:
> On Tue, Apr 25, 2006 at 02:04:50PM -0700, Alex Davis wrote:
> > Hello:
> >
> > I sent this patch earlier and got no response, so I'm sending it again.
> >
> >
> > I cloned git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git
> > last night and got compile errors while compiling net/d80211/ieee80211_ioctl.c
> > into a module:
>
> You need to address Randy's concerns as well.
>
> Thanks,
>
> John
Here is an updated patch which addresses Randy's issues. I'm currently running
this with no problems:
Signed-off-by: Alex Davis <alex14641@yahoo.com>
diff --git a/net/d80211/ieee80211_ioctl.c b/net/d80211/ieee80211_ioctl.c
index 42a7abe..1b14e6c 100644
--- a/net/d80211/ieee80211_ioctl.c
+++ b/net/d80211/ieee80211_ioctl.c
@@ -30,7 +30,7 @@ #include "aes_ccm.h"
static int ieee80211_regdom = 0x10; /* FCC */
-MODULE_PARM(ieee80211_regdom, "i");
+module_param(ieee80211_regdom, int, 0666);
MODULE_PARM_DESC(ieee80211_regdom, "IEEE 802.11 regulatory domain; 64=MKK");
/*
@@ -40,7 +40,7 @@ MODULE_PARM_DESC(ieee80211_regdom, "IEEE
* module.
*/
static int ieee80211_japan_5ghz /* = 0 */;
-MODULE_PARM(ieee80211_japan_5ghz, "i");
+module_param(ieee80211_japan_5ghz, int, 0666);
MODULE_PARM_DESC(ieee80211_japan_5ghz, "Vendor-updated firmware for 5 GHz");
> John W. Linville
> linville@tuxdriver.com
>
I code, therefore I am
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply related
* Re: [PATCH] compile error in ieee80211_ioctl.c
From: Jiri Benc @ 2006-04-26 16:37 UTC (permalink / raw)
To: Alex Davis; +Cc: John W. Linville, netdev
In-Reply-To: <20060426162946.38818.qmail@web50212.mail.yahoo.com>
On Wed, 26 Apr 2006 09:29:46 -0700 (PDT), Alex Davis wrote:
> Here is an updated patch which addresses Randy's issues. I'm currently running
> this with no problems:
> [...]
> +module_param(ieee80211_regdom, int, 0666);
> MODULE_PARM_DESC(ieee80211_regdom, "IEEE 802.11 regulatory domain; 64=MKK");
NAK. Those parameters should not be writable yet.
Please see
http://marc.theaimsgroup.com/?l=linux-netdev&m=114565040832451&w=2 for
the correct patch (hopefully John will pull it soon).
Jiri
--
Jiri Benc
SUSE Labs
^ permalink raw reply
* Re: sky2 driver problems in 2.6.17-rc2-git6 (was: Re: kernel panic (on DHCP discover?) in sky2 driver of 2.6.17-rc1)
From: Stephen Hemminger @ 2006-04-26 16:44 UTC (permalink / raw)
To: Guenther Thomsen; +Cc: John W. Linville, netdev
In-Reply-To: <200604251706.25617.gthomsen@bluearc.com>
On Tue, 25 Apr 2006 17:06:25 -0700
Guenther Thomsen <gthomsen@bluearc.com> wrote:
> On Monday 17 April 2006 11:18, Stephen Hemminger wrote:
> > I don't know what you are doing different, but my 2 port SysKonnect
> > card is working fine. Running SMP AMD64 and 2.6.17 latest.
> >
> > Showing full speed on both ports.
> I missed that e-mail, sorry.
>
> I just gave it another try, this time with 2.6.16.11 . One port works
> fine (so far, I just did very limited testing with ttcp). The second port
> does negotiate IP address via DHCP, but the packgages it receives
> seem to be garbled:
>
> --8<--
> 0x0000: 0000 6175 6469 7428 3131 3435 3939 3430 ..audit(11459940
> 0x0010: 3031 2e39 3738 3a33 3829 3a20 7573 6572 01.978:38):.user
> 0x0020: 2070 6964 3d33 3230 3920 7569 643d .pid=3209.uid=
> 12:56:23.725090 00:00:00:00:00:00 > 30:6e:6d:00:00:00 null I (s=32,r=55,P) len=42
> 12:56:24.603274 00:00:21:00:00:00 > 00:00:00:00:00:00 null disc/C len=43
> 12:56:26.619326 00:00:00:00:00:00 > 00:00:00:00:00:00 null I (s=0,r=0,C) len=42
> 12:56:28.635346 00:00:00:00:00:00 > 00:00:00:00:00:00 null I (s=0,r=0,C) len=42
> 12:56:29.734046 00:00:00:00:00:00 > 00:00:00:00:00:00 null I (s=0,r=0,C) len=42
> 12:56:29.865239 00:00:00:00:00:00 > 00:00:00:00:00:00 null I (s=0,r=0,C) len=42
> 12:56:30.651371 00:00:00:00:00:00 > a6:00:00:00:4d:04, ethertype Unknown (0xe20c), length 60:
> 0x0000: 0000 6175 6469 7428 3131 3435 3939 3436 ..audit(11459946
> 0x0010: 3031 2e33 3639 3a34 3729 3a20 7573 6572 01.369:47):.user
> 0x0020: 2070 6964 3d33 3239 3820 7569 643d .pid=3298.uid=
> 12:56:30.916718 00:00:f0:71:61:00 > 28:37:03:5b:3a:00 null I (s=16,r=0,C) len=42
> 12:56:30.923558 00:00:21:00:00:00 > 00:00:00:00:00:00 null rnr (r=55,C) len=42
> 12:56:32.667413 00:00:d0:2e:30:42 > 10:60:61:00:00:00, ethertype Unknown (0x572b), length 60:
> 0x0000: 0000 d675 0d00 0000 0000 0200 0000 0000 ...u............
> 0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 0x0020: 0000 ffff ffff 0000 0000 1300 0000 ..............
> 12:56:33.296384 00:00:00:00:00:00 > 00:00:00:00:00:00 null I (s=0,r=0,C) len=42
> 12:56:33.303222 00:00:00:00:00:00 > 00:00:00:00:00:00 null I (s=0,r=0,C) len=42
> [..]
> 13:00:44.340062 00:00:00:00:00:00 > 5f:00:00:00:00:00 null I (s=0,r=0,C) len=42
> 13:00:44.672350 00:00:00:00:00:00 > 00:00:00:00:00:00 null I (s=0,r=0,C) len=42
> 13:00:44.868724 00:00:00:00:00:00 > 00:00:00:00:00:00 null I (s=0,r=0,C) len=42
> 13:00:45.340123 00:00:00:00:00:00 > 00:00:00:00:00:00 null I (s=0,r=0,C) len=42
> 13:00:46.340173 00:00:00:00:00:00 > 00:00:00:00:00:00 null I (s=0,r=0,C) len=42
> 13:00:46.688433 IP truncated-ip - 1454 bytes missing! 192.168.65.66.40313 > 192.168.65.65.5001: . 1426488980:1426490428(1448) ack 1790562292 win 1460 <nop,nop,timestamp[|tcp]>
> 13:00:48.704431 00:00:21:00:00:00 > 00:00:00:00:00:00 null I (s=17,r=18,C) len=42
> 13:00:48.886426 00:00:00:00:00:00 > 00:00:00:00:00:00 null I (s=0,r=0,C) len=42
> 13:00:50.720463 00:00:00:00:00:00 > 00:00:00:00:00:00 null I (s=0,r=0,C) len=42
> 13:00:52.736496 00:00:00:00:00:00 > 00:00:00:00:00:00 null I (s=0,r=0,C) len=42
> 13:00:54.752522 00:00:00:00:00:00 > 00:00:00:00:00:00 null I (s=0,r=0,C) len=42
> 13:00:54.927556 00:00:00:00:00:00 > 00:00:00:00:00:00 null I (s=0,r=0,C) len=42
> 13:00:54.934394 00:00:00:00:00:00 > 00:00:00:00:00:00 null I (s=0,r=0,C) len=42
> -->8--
> On a different host connected to the same switch, traffic looks more like:
> --8<--
> 2:01:49.388992 IP 192.168.64.1.ntp > 255.255.255.255.ntp: NTPv3, Broadcast, length 48
> 12:01:50.176550 802.1d config 8000.00:a0:d1:e1:b4:78.8026 root 8000.00:a0:d1:e1:b4:78 pathcost 0 age 0 max 20 hello 2 fdelay 15
> 12:01:51.235034 arp reply 192.168.64.32 is-at 00:0a:49:00:5e:8a
> 12:01:51.241857 arp reply 192.168.64.33 is-at 00:0a:49:00:5e:8b
> 12:01:51.891193 00:00:01:02:c8:58 > 45:c0:00:1c:00:20, ethertype Unknown (0xe000), length 60:
> 0x0000: 0001 1164 ee9b 0000 0000 0000 0000 0000 ...d............
> 0x0010: 0000 0000 0000 0000 0000 0000 2f6b 8c87 ............/k..
> 0x0020: 0000 0000 0000 0000 0000 0000 0000 ..............
> 12:01:52.192552 802.1d config 8000.00:a0:d1:e1:b4:78.8026 root 8000.00:a0:d1:e1:b4:78 pathcost 0 age 0 max 20 hello 2 fdelay 15
> 12:01:52.801392 arp reply 192.168.64.34 is-at 00:0a:49:00:5e:8c
> 12:01:52.808240 arp reply 192.168.64.35 is-at 00:0a:49:00:5e:8d
> 12:01:54.208495 802.1d config 8000.00:a0:d1:e1:b4:78.8026 root 8000.00:a0:d1:e1:b4:78 pathcost 0 age 0 max 20 hello 2 fdelay 15
> 12:01:56.224453 802.1d config 8000.00:a0:d1:e1:b4:78.8026 root 8000.00:a0:d1:e1:b4:78 pathcost 0 age 0 max 20 hello 2 fdelay 15
> 12:01:58.240464 802.1d config 8000.00:a0:d1:e1:b4:78.8026 root 8000.00:a0:d1:e1:b4:78 pathcost 0 age 0 max 20 hello 2 fdelay 15
> 12:02:00.029320 arp reply 192.168.64.39 is-at 00:0a:49:00:5e:ff
> 12:02:00.256420 802.1d config 8000.00:a0:d1:e1:b4:78.8026 root 8000.00:a0:d1:e1:b4:78 pathcost 0 age 0 max 20 hello 2 fdelay 15
> -->8--
>
> I noticed that the interrupt count is very low too (the interrupt count
> as shown in /proc/interrupts is much higher):
> --8<--
> [root@penguin1 ~]# ifconfig
> eth0 Link encap:Ethernet HWaddr 00:A0:D1:E1:F2:D8
> inet addr:192.168.65.65 Bcast:192.168.65.255 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:4559786 errors:0 dropped:0 overruns:0 frame:0
> TX packets:4071967 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:4680823977 (4.3 GiB) TX bytes:4332319475 (4.0 GiB)
> Interrupt:169
>
> eth1 Link encap:Ethernet HWaddr 00:A0:D1:E1:F2:D9
> inet addr:192.168.64.199 Bcast:192.168.64.255 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:2193 errors:0 dropped:0 overruns:0 frame:0
> TX packets:29 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:180137 (175.9 KiB) TX bytes:1856 (1.8 KiB)
> Interrupt:169
> -->8--
>
> I then tried 2.6.17-rc2-git6. At first it looked OK, the second ethernet
> device was configured properly and I got some traffic through. Once
> I started copying large files (some 5GB were successfully copied) over
> NFS using a (very) fast NFS server though, traffic received by eth1 got
> corrupted again:
>
> --8<--
> [root@penguin1 ~]# tcpdump -n -i eth1 -s 0
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
> 14:23:14.049450 arp who-has 192.168.64.199 tell 192.168.64.202
> 14:23:14.049519 arp reply 192.168.64.199 is-at 00:a0:d1:e1:f2:d9
> 14:23:14.745075 arp who-has 192.168.64.199 tell 192.168.64.202
> 14:23:14.745082 arp reply 192.168.64.199 is-at 00:a0:d1:e1:f2:d9
> 14:23:14.852108 IP truncated-ip - 1454 bytes missing! 192.168.64.110.nfs > 192.168.64.199.1021: . 159991419:159992879(1460) ack 3444328765 win 64240
> 14:23:14.944489 00:00:00:00:00:00 > a3:00:00:00:50:04, ethertype Unknown (0x210d), length 98:
> 0x0000: 0000 6175 6469 7428 3131 3436 3030 3030 ..audit(11460000
> 0x0010: 3032 2e31 3836 3a36 3329 3a20 7573 6572 02.186:63):.user
> 0x0020: 2070 6964 3d33 3336 3120 7569 643d 3020 .pid=3361.uid=0.
> 0x0030: 6175 6964 3d34 3239 3439 3637 3239 3520 auid=4294967295.
> 0x0040: 6d73 673d 2750 414d 2073 6574 6372 6564 msg='PAM.setcred
> 0x0050: 3a20 7573 :.us
> 14:23:15.944703 arp who-has 192.168.64.253 tell 192.168.79.254
> 14:23:16.868291 arp who-has 192.168.64.199 tell 192.168.64.202
> 14:23:16.868301 arp reply 192.168.64.199 is-at 00:a0:d1:e1:f2:d9
> 14:23:16.944907 IP truncated-ip - 12 bytes missing! 192.168.64.101.netbios-ns > 192.168.64.255.netbios-ns: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
> 14:23:17.945113 IP truncated-ip - 12 bytes missing! 192.168.64.101.netbios-ns > 192.168.64.255.netbios-ns: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
> 14:23:18.884430 arp who-has 192.168.64.199 tell 192.168.64.202
> 14:23:18.884441 arp reply 192.168.64.199 is-at 00:a0:d1:e1:f2:d9
> 14:23:18.945318 IP truncated-ip - 12 bytes missing! 192.168.64.101.netbios-ns > 192.168.64.255.netbios-ns: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
> -->8--
>
> The ".audit ... PAM.sedcred" string is interesting. This is most likely
> not traffic from the net, but a text inside the host's RAM. Did some
> pointer get mangled?
>
> I recompiled the kernel, now with RHFC4's gcc32. The result is similiar
> (only after some data was copied using NFS, the second interface goes
> bad):
> --8<--
> [root@penguin1 ~]# tcpdump -n -s 0 -i eth1
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
> 15:48:02.306927 IP 192.168.64.202 > 192.168.64.199: icmp 64: echo request seq 8801
> 15:48:02.316088 arp who-has 192.168.64.202 tell 192.168.64.199
> 15:48:02.316329 arp who-has 192.168.64.199 tell 192.168.79.254
> 15:48:02.316335 arp reply 192.168.64.199 is-at 00:a0:d1:e1:f2:d9
> 15:48:02.316338 802.1d config 8000.00:a0:d1:e1:b4:78.8025 root 8000.00:a0:d1:e1:b4:78 pathcost 0 age 0 max 20 hello 2 fdelay 15
> 15:48:03.307095 IP 192.168.64.202 > 192.168.64.199: icmp 64: echo request seq 8802
> 15:48:03.307289 IP truncated-ip - 38 bytes missing! 192.168.64.202 > 192.168.64.199: icmp 64: echo request seq 8803
> 15:48:03.316166 arp who-has 192.168.64.202 tell 192.168.64.199
> 15:48:03.316397 arp who-has 192.168.64.199 tell 192.168.79.254
> 15:48:03.316401 arp reply 192.168.64.199 is-at 00:a0:d1:e1:f2:d9
> 15:48:03.316404 802.1d config 8000.00:a0:d1:e1:b4:78.8025 root 8000.00:a0:d1:e1:b4:78 pathcost 0 age 0 max 20 hello 2 fdelay 15
> 15:48:03.784698 IP truncated-ip - 38 bytes missing! 192.168.64.202 > 192.168.64.199: icmp 64: echo request seq 8804
>
> 12 packets captured
> 12 packets received by filter
> 0 packets dropped by kernel
> -->8--
> No suspect text and no zero filled packets, only truncated ones now,
> but that's bad enough to stop NFS and cause bad packet loss:
> --8<--
> 64 bytes from 192.168.64.199: icmp_seq=83 ttl=64 time=147073 ms
> 64 bytes from 192.168.64.199: icmp_seq=84 ttl=64 time=149073 ms
> 64 bytes from 192.168.64.199: icmp_seq=85 ttl=64 time=149073 ms
> 64 bytes from 192.168.64.199: icmp_seq=87 ttl=64 time=149073 ms
> 64 bytes from 192.168.64.199: icmp_seq=88 ttl=64 time=149073 ms
> 64 bytes from 192.168.64.199: icmp_seq=233 ttl=64 time=82023 ms
> 64 bytes from 192.168.64.199: icmp_seq=236 ttl=64 time=80018 ms
> 64 bytes from 192.168.64.199: icmp_seq=241 ttl=64 time=81018 ms
> 64 bytes from 192.168.64.199: icmp_seq=243 ttl=64 time=81018 ms
> 64 bytes from 192.168.64.199: icmp_seq=253 ttl=64 time=85018 ms
> 64 bytes from 192.168.64.199: icmp_seq=255 ttl=64 time=85018 ms
> 64 bytes from 192.168.64.199: icmp_seq=256 ttl=64 time=85629 ms
> 64 bytes from 192.168.64.199: icmp_seq=257 ttl=64 time=87023 ms
>
> --- 192.168.64.199 ping statistics ---
> 346 packets transmitted, 63 received, +3 errors, 81% packet loss, time 345136ms
> rtt min/avg/max/mdev = 80018.748/119940.275/149073.885/21090.211 ms, pipe 151
> -->8--
>
> Considering the recent NFS changes, I tried to get the system into this
> state using just ttcp. With some determination, three more hosts and
> a few million packets, I succeeded. This time eth0 truncated packets
> and traffic slowed to a crawl (~1 good packet every 2s).
>
> Some progress has been made, but it's not quite solid yet.
>
Are you saturating both ports on the card or only one?
^ permalink raw reply
* [PATCH] fix unlikely usage in tcp_transmit_skb()
From: Hua Zhong @ 2006-04-26 16:50 UTC (permalink / raw)
To: davem; +Cc: netdev
[I hope this time it's OK - I'm sending from pine/Linux]
The following unlikely should be replaced by likely because the condition happens every time unless there is a hard error to transmit a packet.
Signed-off-by: Hua Zhong <hzhong@gmail.com>
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index a28ae59..743016b 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -465,7 +465,7 @@ #define SYSCTL_FLAG_SACK 0x4
TCP_INC_STATS(TCP_MIB_OUTSEGS);
err = icsk->icsk_af_ops->queue_xmit(skb, 0);
- if (unlikely(err <= 0))
+ if (likely(err <= 0))
return err;
tcp_enter_cwr(sk);
^ permalink raw reply related
* RE: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Caitlin Bestler @ 2006-04-26 16:57 UTC (permalink / raw)
To: David S. Miller, kelly; +Cc: netdev, rusty
netdev-owner@vger.kernel.org wrote:
> Ok I have comments already just glancing at the initial patch.
>
> With the 32-bit descriptors in the channel, you indeed end up
> with a fixed sized pool with a lot of hard-to-finesse sizing
> and lookup problems to solve.
>
> So what I wanted to do was finesse the entire issue by simply
> side-stepping it initially. Use a normal buffer with a tail
> descriptor, when you enqueue you give a tail descriptor pointer.
>
> Yes, it's weirder to handle this in hardware, but it's not
> impossible and using real pointers means two things:
>
> 1) You can design a simple netif_receive_skb() channel that works
> today, encapsulation of channel buffers into an SKB is like
> 15 lines of code and no funny lookups.
>
> 2) People can start porting the input path of drivers right now and
> retain full functionality and test anything they want. This is
> important for getting the drivers stable as fast as possible.
>
> And it also means we can tackle the buffer pool issue of the
> 32-bit descriptors later, if we actually want to do things
> that way, I think we probably don't.
>
> To be honest, I don't think using a 32-bit descriptor is so
> critical even from a hardware implementation perspective.
> Yes, on 64-bit you're dealing with a 64-bit quantity so the
> number of entries in the channel are halfed from what a 32-bit arch
> uses.
>
> Yes I say this for 2 reasons:
>
> 1) We have no idea whether it's critical to have "~512" entries
> in the channel which is about what a u32 queue entry type
> affords you on x86 with 4096 byte page size.
>
> 2) Furthermore, it is sized by page size, and most 64-bit platforms
> use an 8K base page size anyways, so the number of queue entries
> ends of being the same. Yes, I know some 64-bit platforms use
> a 4K page size, please see #1 :-)
>
> I really dislike the pools of buffers, partly because they
> are fixed size (or dynamically sized and even more expensive
> to implement), but moreso because there is all of this
> absolutely stupid state management you eat just to get at the
> real data. That's pointless, we're trying to make this as
> light as possible. Just use real pointers and describe the
> packet with a tail descriptor.
>
> We can use a u64 or whatever in a hardware implementation.
>
> Next, you can't even begin to work on the protocol channels
> before you do one very important piece of work. Integration
> of all of the ipv4 and ipv6 protocol hash tables into a
> central code, it's a total prerequisite. Then you modify
> things to use a generic
> inet_{,listen_}lookup() or inet6_{,listen_}lookup() that
> takes a protocol number as well as saddr/daddr/sport/dport
> and searches from a central table.
>
> So I think I'll continue working on my implementation, it's
> more transitional and that's how we have to do this kind of work. -
The major element I liked about Kelly's approach is that the ring
is clearly designed to allow a NIC to place packets directly into
a ring that is directly accessible by the user. Evolutionary steps
are good, but isn't direct placement into a user-accessible simple
ring buffer the ultimate justification of netchannels?
But that doesn't mean that we have to have a very artificial definition
of the ring based on presumptions that hardware only understands 512<<n
sized buffers. Hardware today is typically just as smart as the
processors
that IP networks were first designed on, if not more so.
Central integration also will need to be integrated with packet
filtering.
In particular, once a flow has been assigned to a netchannel ring, who
is
responsible for doing the packet filtering? Or is it enough to check the
packet filter when the net channel flow is created?
^ permalink raw reply
* Re: sky2 driver problems in 2.6.17-rc2-git6 (was: Re: kernel panic (on DHCP discover?) in sky2 driver of 2.6.17-rc1)
From: Guenther Thomsen @ 2006-04-26 17:41 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: John W. Linville, netdev
In-Reply-To: <20060426094445.6b892761@localhost.localdomain>
On Wednesday 26 April 2006 09:44, Stephen Hemminger wrote:
> On Tue, 25 Apr 2006 17:06:25 -0700
>
> Guenther Thomsen <gthomsen@bluearc.com> wrote:
[..]
> > Considering the recent NFS changes, I tried to get the system into
> > this state using just ttcp. With some determination, three more
> > hosts and a few million packets, I succeeded. This time eth0
> > truncated packets and traffic slowed to a crawl (~1 good packet
> > every 2s).
> >
> > Some progress has been made, but it's not quite solid yet.
>
> Are you saturating both ports on the card or only one?
On the system under test I started four ttcp sessions: two senders and
two receivers (the second one on a non-standard port). One pair for
each port (device). I'm not sure, to which degree the device was
saturated. It certainly should have been, since the remote hosts are
capable of line rate, but I found the sending ttcp sessions on the
system under test to be slow, as long as traffic was incoming.
best regards
Guenther
^ permalink raw reply
* [RFC] bridge: partial rtnetlink hooks
From: Stephen Hemminger @ 2006-04-26 17:45 UTC (permalink / raw)
To: netdev
This is the start of adding support for rtnetlink to the bridge code.
So far it only supports accessing the list of links and notifying
about link changes. It is just a prototype to get early feedback, don't
use to build your own masterpiece yet.
--- bridge-2.6.orig/net/bridge/Makefile
+++ bridge-2.6/net/bridge/Makefile
@@ -6,7 +6,7 @@ obj-$(CONFIG_BRIDGE) += bridge.o
bridge-y := br.o br_device.o br_fdb.o br_forward.o br_if.o br_input.o \
br_ioctl.o br_notify.o br_stp.o br_stp_bpdu.o \
- br_stp_if.o br_stp_timer.o
+ br_stp_if.o br_stp_timer.o br_netlink.o
bridge-$(CONFIG_SYSFS) += br_sysfs_if.o br_sysfs_br.o
--- bridge-2.6.orig/net/bridge/br.c
+++ bridge-2.6/net/bridge/br.c
@@ -30,17 +30,20 @@ static struct llc_sap *br_stp_sap;
static int __init br_init(void)
{
+ int err = -EADDRINUSE;
+
br_stp_sap = llc_sap_open(LLC_SAP_BSPAN, br_stp_rcv);
if (!br_stp_sap) {
printk(KERN_ERR "bridge: can't register sap for STP\n");
- return -EBUSY;
+ goto out;
}
br_fdb_init();
#ifdef CONFIG_BRIDGE_NETFILTER
- if (br_netfilter_init())
- return 1;
+ err = br_netfilter_init();
+ if (err)
+ goto unregister_sap;
#endif
brioctl_set(br_ioctl_deviceless_stub);
br_handle_frame_hook = br_handle_frame;
@@ -50,13 +53,23 @@ static int __init br_init(void)
register_netdevice_notifier(&br_device_notifier);
+ br_netlink_init();
+
return 0;
+#ifdef CONFIG_BRIDGE_NETFILTER
+ unregister_sap:
+ llc_sap_close(br_stp_sap);
+#endif
+ out:
+ return err;
}
static void __exit br_deinit(void)
{
llc_sap_close(br_stp_sap);
+ br_netlink_exit();
+
#ifdef CONFIG_BRIDGE_NETFILTER
br_netfilter_fini();
#endif
--- /dev/null
+++ bridge-2.6/net/bridge/br_netlink.c
@@ -0,0 +1,135 @@
+/*
+ * Bridge netlink control interface
+ *
+ * Authors:
+ * Stephen Hemminger <shemminger@osdl.org>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include <linux/kernel.h>
+#include <linux/rtnetlink.h>
+#include "br_private.h"
+
+static int br_fill_ifinfo(struct sk_buff *skb, const struct net_bridge_port *port,
+ u32 pid, u32 seq, int event, unsigned int flags)
+{
+ const struct net_bridge *br = port->br;
+ const struct net_device *dev = port->dev;
+ struct ifinfomsg *r;
+ struct nlmsghdr *nlh;
+ unsigned char *b = skb->tail;
+ u32 mtu = dev->mtu;
+ u8 operstate = netif_running(dev) ? dev->operstate : IF_OPER_DOWN;
+
+ printk(KERN_DEBUG "bridge fill %s %s\n", dev->name, br->dev->name);
+
+ nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*r), flags);
+ r = NLMSG_DATA(nlh);
+ r->ifi_family = AF_BRIDGE;
+ r->__ifi_pad = 0;
+ r->ifi_type = dev->type;
+ r->ifi_index = dev->ifindex;
+ r->ifi_flags = dev_get_flags(dev);
+ r->ifi_change = 0;
+
+ RTA_PUT(skb, IFLA_IFNAME, strlen(dev->name)+1, dev->name);
+
+ RTA_PUT(skb, IFLA_MASTER, sizeof(int), &br->dev->ifindex);
+
+ if (dev->addr_len)
+ RTA_PUT(skb, IFLA_ADDRESS, dev->addr_len, dev->dev_addr);
+
+ RTA_PUT(skb, IFLA_MTU, sizeof(mtu), &mtu);
+ if (dev->ifindex != dev->iflink)
+ RTA_PUT(skb, IFLA_LINK, sizeof(int), &dev->iflink);
+
+
+ RTA_PUT(skb, IFLA_OPERSTATE, sizeof(operstate), &operstate);
+
+ if (event == RTM_NEWLINK) {
+ struct brifinfo portstate = {
+ .state = port->state,
+ .cost = port->path_cost,
+ };
+ RTA_PUT(skb, IFLA_PROTINFO, sizeof(portstate), &portstate);
+ }
+
+ nlh->nlmsg_len = skb->tail - b;
+
+ return skb->len;
+
+nlmsg_failure:
+rtattr_failure:
+
+ skb_trim(skb, b - skb->data);
+ return -1;
+}
+
+
+void br_ifinfo_notify(int event, struct net_bridge_port *port)
+{
+ struct sk_buff *skb;
+
+ printk(KERN_DEBUG "bridge notify event=%d\n", event);
+ skb = alloc_skb(NLMSG_SPACE(sizeof(struct ifinfomsg) + 128),
+ GFP_ATOMIC);
+ if (!skb) {
+ netlink_set_err(rtnl, 0, RTNLGRP_BRIDGE_IFINFO, ENOBUFS);
+ return;
+ }
+ if (br_fill_ifinfo(skb, port, current->pid, 0, event, 0) < 0) {
+ kfree_skb(skb);
+ netlink_set_err(rtnl, 0, RTNLGRP_BRIDGE_IFINFO, EINVAL);
+ return;
+ }
+ NETLINK_CB(skb).dst_group = RTNLGRP_IPV6_IFINFO;
+ netlink_broadcast(rtnl, skb, 0, RTNLGRP_BRIDGE_IFINFO, GFP_ATOMIC);
+}
+
+static int br_dump_ifinfo(struct sk_buff *skb, struct netlink_callback *cb)
+{
+ struct net_device *dev;
+ int idx = 0;
+ int err = 0;
+
+ printk(KERN_DEBUG "bridge dump ifinfo\n");
+ for (dev = dev_base; dev; dev = dev->next) {
+ struct net_bridge_port *p = rcu_dereference(dev->br_port);
+
+ /* not a bridge port */
+ if (!p)
+ continue;
+ /* asking about a specific bridge */
+ if (cb->args[1] && cb->args[1] != p->br->dev->ifindex)
+ continue;
+
+ /* limit to N values */
+ if (idx >= cb->args[0])
+ break;
+ err = br_fill_ifinfo(skb, p, NETLINK_CB(cb->skb).pid,
+ cb->nlh->nlmsg_seq, RTM_NEWLINK, NLM_F_MULTI);
+ if (err <= 0)
+ break;
+ ++idx;
+ }
+ cb->args[0] = idx;
+ return err;
+}
+
+static struct rtnetlink_link bridge_rtnetlink_table[RTM_NR_MSGTYPES] = {
+ [RTM_GETLINK - RTM_BASE] = { .dumpit = br_dump_ifinfo, },
+};
+
+void __init br_netlink_init(void)
+{
+ rtnetlink_links[PF_BRIDGE] = bridge_rtnetlink_table;
+}
+
+void __exit br_netlink_exit(void)
+{
+ rtnetlink_links[PF_BRIDGE] = NULL;
+}
--- bridge-2.6.orig/net/bridge/br_private.h
+++ bridge-2.6/net/bridge/br_private.h
@@ -29,7 +29,7 @@
#define BR_PORT_DEBOUNCE (HZ/10)
-#define BR_VERSION "2.1"
+#define BR_VERSION "2.2"
typedef struct bridge_id bridge_id;
typedef struct mac_addr mac_addr;
@@ -232,6 +232,11 @@ extern struct net_bridge_fdb_entry *(*br
extern void (*br_fdb_put_hook)(struct net_bridge_fdb_entry *ent);
+/* br_netlink.c */
+extern void br_netlink_init(void);
+extern void br_netlink_exit(void);
+extern void br_ifinfo_notify(int event, struct net_bridge_port *port);
+
#ifdef CONFIG_SYSFS
/* br_sysfs_if.c */
extern struct sysfs_ops brport_sysfs_ops;
--- bridge-2.6.orig/include/linux/rtnetlink.h
+++ bridge-2.6/include/linux/rtnetlink.h
@@ -200,6 +200,7 @@ enum
#define RTPROT_DNROUTED 13 /* DECnet routing daemon */
#define RTPROT_XORP 14 /* XORP */
#define RTPROT_NTK 15 /* Netsukuku */
+#define RTPROT_STP 16 /* Bridge Spanning Tree Protocol */
/* rtm_scope
@@ -850,6 +851,7 @@ enum
#define RTMGRP_DECnet_ROUTE 0x4000
#define RTMGRP_IPV6_PREFIX 0x20000
+
#endif
/* RTnetlink multicast groups */
@@ -889,6 +891,10 @@ enum rtnetlink_groups {
RTNLGRP_NOP4,
RTNLGRP_IPV6_PREFIX,
#define RTNLGRP_IPV6_PREFIX RTNLGRP_IPV6_PREFIX
+ RTNLGRP_BRIDGE_IFINFO,
+#define RTNLGRP_BRIDGE_IFINFO RTNLGRP_BRIDGE_IFINFO
+ RTNLGRP_BRIDGE_FDB,
+#define RTNLGRP_BRIDGE_FDB RTNLGRP_BRIDGE_FDB
__RTNLGRP_MAX
};
#define RTNLGRP_MAX (__RTNLGRP_MAX - 1)
--- bridge-2.6.orig/include/linux/if_bridge.h
+++ bridge-2.6/include/linux/if_bridge.h
@@ -100,6 +100,11 @@ struct __fdb_entry
__u32 unused;
};
+struct brifinfo {
+ __u8 state;
+ __u32 cost;
+};
+
#ifdef __KERNEL__
#include <linux/netdevice.h>
--- bridge-2.6.orig/net/bridge/br_notify.c
+++ bridge-2.6/net/bridge/br_notify.c
@@ -14,6 +14,7 @@
*/
#include <linux/kernel.h>
+#include <linux/rtnetlink.h>
#include "br_private.h"
@@ -49,6 +50,7 @@ static int br_device_event(struct notifi
case NETDEV_CHANGEADDR:
br_fdb_changeaddr(p, dev->dev_addr);
+ br_ifinfo_notify(RTM_NEWLINK, p);
br_stp_recalculate_bridge_id(br);
break;
--- bridge-2.6.orig/net/bridge/br_stp_if.c
+++ bridge-2.6/net/bridge/br_stp_if.c
@@ -16,6 +16,7 @@
#include <linux/kernel.h>
#include <linux/smp_lock.h>
#include <linux/etherdevice.h>
+#include <linux/rtnetlink.h>
#include "br_private.h"
#include "br_private_stp.h"
@@ -86,6 +87,7 @@ void br_stp_disable_bridge(struct net_br
void br_stp_enable_port(struct net_bridge_port *p)
{
br_init_port(p);
+ br_ifinfo_notify(RTM_NEWLINK, p);
br_port_state_selection(p->br);
}
@@ -99,6 +101,8 @@ void br_stp_disable_port(struct net_brid
printk(KERN_INFO "%s: port %i(%s) entering %s state\n",
br->dev->name, p->port_no, p->dev->name, "disabled");
+ br_ifinfo_notify(RTM_DELLINK, p);
+
wasroot = br_is_root_bridge(br);
br_become_designated_port(p);
p->state = BR_STATE_DISABLED;
^ permalink raw reply
* Re: e1000 Invalid truesize
From: Jens Axboe @ 2006-04-26 17:58 UTC (permalink / raw)
To: Ronciak, John; +Cc: netdev, Brandeburg, Jesse, Kirsher, Jeffrey T
In-Reply-To: <F50A4280B6033741B1DD2B4E902258B13F4EAD@orsmsx411.amr.corp.intel.com>
On Wed, Apr 26 2006, Ronciak, John wrote:
> Please follow what has been happening on netdev. Dave Miller added this
> BUG to 2.6.17-rc as something we (Intel LAD) pointed out to them. Jeff
> Garzik has, as of this morning, queued our e1000 patch for this. He's
> been a little behind.
Ah ok, I guess I should have searched there first. I was just grasping
at straws, hoping perhaps some new debug aid exposed my e1000 problem
and it finally could get fixed.
> If you want to know more about the problem, please read the entire
> netdev discussion about this.
Thanks.
--
Jens Axboe
^ permalink raw reply
* [PATCH 2.6.16.11] updated bonding documentation
From: Mitch Williams @ 2006-04-26 18:05 UTC (permalink / raw)
To: bonding-devel, netdev; +Cc: fubar
Added new section describing the sysfs interface.
Renumbered sections to be sequential (section 4 was AWOL).
Minor spelling corrections.
Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
diff -urpN linux-2.6.16.11-clean/Documentation/networking/bonding.txt linux-2.6.16.11/Documentation/networking/bonding.txt
--- linux-2.6.16.11-clean/Documentation/networking/bonding.txt 2006-04-24 13:20:24.000000000 -0700
+++ linux-2.6.16.11/Documentation/networking/bonding.txt 2006-04-24 16:18:25.000000000 -0700
@@ -1,7 +1,7 @@
Linux Ethernet Bonding Driver HOWTO
- Latest update: 21 June 2005
+ Latest update: 24 April 2006
Initial release : Thomas Davis <tadavis at lbl.gov>
Corrections, HA extensions : 2000/10/03-15 :
@@ -12,6 +12,8 @@ Corrections, HA extensions : 2000/10/03-
- Jay Vosburgh <fubar at us dot ibm dot com>
Reorganized and updated Feb 2005 by Jay Vosburgh
+Added Sysfs information: 2006/04/24
+ - Mitch Williams <mitch.a.williams at intel.com>
Introduction
============
@@ -38,61 +40,62 @@ Table of Contents
2. Bonding Driver Options
3. Configuring Bonding Devices
-3.1 Configuration with sysconfig support
-3.1.1 Using DHCP with sysconfig
-3.1.2 Configuring Multiple Bonds with sysconfig
-3.2 Configuration with initscripts support
-3.2.1 Using DHCP with initscripts
-3.2.2 Configuring Multiple Bonds with initscripts
-3.3 Configuring Bonding Manually
+3.1 Configuration with Sysconfig Support
+3.1.1 Using DHCP with Sysconfig
+3.1.2 Configuring Multiple Bonds with Sysconfig
+3.2 Configuration with Initscripts Support
+3.2.1 Using DHCP with Initscripts
+3.2.2 Configuring Multiple Bonds with Initscripts
+3.3 Configuring Bonding Manually with Ifenslave
3.3.1 Configuring Multiple Bonds Manually
+3.4 Configuring Bonding Manually via Sysfs
-5. Querying Bonding Configuration
-5.1 Bonding Configuration
-5.2 Network Configuration
+4. Querying Bonding Configuration
+4.1 Bonding Configuration
+4.2 Network Configuration
-6. Switch Configuration
+5. Switch Configuration
-7. 802.1q VLAN Support
+6. 802.1q VLAN Support
-8. Link Monitoring
-8.1 ARP Monitor Operation
-8.2 Configuring Multiple ARP Targets
-8.3 MII Monitor Operation
+7. Link Monitoring
+7.1 ARP Monitor Operation
+7.2 Configuring Multiple ARP Targets
+7.3 MII Monitor Operation
-9. Potential Trouble Sources
-9.1 Adventures in Routing
-9.2 Ethernet Device Renaming
-9.3 Painfully Slow Or No Failed Link Detection By Miimon
+8. Potential Trouble Sources
+8.1 Adventures in Routing
+8.2 Ethernet Device Renaming
+8.3 Painfully Slow Or No Failed Link Detection By Miimon
-10. SNMP agents
+9. SNMP agents
-11. Promiscuous mode
+10. Promiscuous mode
-12. Configuring Bonding for High Availability
-12.1 High Availability in a Single Switch Topology
-12.2 High Availability in a Multiple Switch Topology
-12.2.1 HA Bonding Mode Selection for Multiple Switch Topology
-12.2.2 HA Link Monitoring for Multiple Switch Topology
+11. Configuring Bonding for High Availability
+11.1 High Availability in a Single Switch Topology
+11.2 High Availability in a Multiple Switch Topology
+11.2.1 HA Bonding Mode Selection for Multiple Switch Topology
+11.2.2 HA Link Monitoring for Multiple Switch Topology
-13. Configuring Bonding for Maximum Throughput
-13.1 Maximum Throughput in a Single Switch Topology
-13.1.1 MT Bonding Mode Selection for Single Switch Topology
-13.1.2 MT Link Monitoring for Single Switch Topology
-13.2 Maximum Throughput in a Multiple Switch Topology
-13.2.1 MT Bonding Mode Selection for Multiple Switch Topology
-13.2.2 MT Link Monitoring for Multiple Switch Topology
+12. Configuring Bonding for Maximum Throughput
+12.1 Maximum Throughput in a Single Switch Topology
+12.1.1 MT Bonding Mode Selection for Single Switch Topology
+12.1.2 MT Link Monitoring for Single Switch Topology
+12.2 Maximum Throughput in a Multiple Switch Topology
+12.2.1 MT Bonding Mode Selection for Multiple Switch Topology
+12.2.2 MT Link Monitoring for Multiple Switch Topology
-14. Switch Behavior Issues
-14.1 Link Establishment and Failover Delays
-14.2 Duplicated Incoming Packets
+13. Switch Behavior Issues
+13.1 Link Establishment and Failover Delays
+13.2 Duplicated Incoming Packets
-15. Hardware Specific Considerations
-15.1 IBM BladeCenter
+14. Hardware Specific Considerations
+14.1 IBM BladeCenter
-16. Frequently Asked Questions
+15. Frequently Asked Questions
-17. Resources and Links
+16. Resources and Links
1. Bonding Driver Installation
@@ -156,6 +159,9 @@ you're trying to build it for. Some dis
onwards) do not have /usr/include/linux symbolically linked to the
default kernel source include directory.
+SECOND IMPORTANT NOTE:
+ If you plan to configure bonding using sysfs, you do not need
+to use ifenslave.
2. Bonding Driver Options
=========================
@@ -270,7 +276,7 @@ mode
In bonding version 2.6.2 or later, when a failover
occurs in active-backup mode, bonding will issue one
or more gratuitous ARPs on the newly active slave.
- One gratutious ARP is issued for the bonding master
+ One gratuitous ARP is issued for the bonding master
interface and each VLAN interfaces configured above
it, provided that the interface has at least one IP
address configured. Gratuitous ARPs issued for VLAN
@@ -377,7 +383,7 @@ mode
When a link is reconnected or a new slave joins the
bond the receive traffic is redistributed among all
active slaves in the bond by initiating ARP Replies
- with the selected mac address to each of the
+ with the selected MAC address to each of the
clients. The updelay parameter (detailed below) must
be set to a value equal or greater than the switch's
forwarding delay so that the ARP Replies sent to the
@@ -498,11 +504,12 @@ not exist, and the layer2 policy is the
3. Configuring Bonding Devices
==============================
- There are, essentially, two methods for configuring bonding:
-with support from the distro's network initialization scripts, and
-without. Distros generally use one of two packages for the network
-initialization scripts: initscripts or sysconfig. Recent versions of
-these packages have support for bonding, while older versions do not.
+ You can configure bonding using either your distro's network
+initialization scripts, or manually using either ifenslave or the
+sysfs interface. Distros generally use one of two packages for the
+network initialization scripts: initscripts or sysconfig. Recent
+versions of these packages have support for bonding, while older
+versions do not.
We will first describe the options for configuring bonding for
distros using versions of initscripts and sysconfig with full or
@@ -530,7 +537,7 @@ $ grep ifenslave /sbin/ifup
If this returns any matches, then your initscripts or
sysconfig has support for bonding.
-3.1 Configuration with sysconfig support
+3.1 Configuration with Sysconfig Support
----------------------------------------
This section applies to distros using a version of sysconfig
@@ -538,7 +545,7 @@ with bonding support, for example, SuSE
SuSE SLES 9's networking configuration system does support
bonding, however, at this writing, the YaST system configuration
-frontend does not provide any means to work with bonding devices.
+front end does not provide any means to work with bonding devices.
Bonding devices can be managed by hand, however, as follows.
First, if they have not already been configured, configure the
@@ -660,7 +667,7 @@ format can be found in an example ifcfg
Note that the template does not document the various BONDING_
settings described above, but does describe many of the other options.
-3.1.1 Using DHCP with sysconfig
+3.1.1 Using DHCP with Sysconfig
-------------------------------
Under sysconfig, configuring a device with BOOTPROTO='dhcp'
@@ -670,7 +677,7 @@ attempt to obtain the device address fro
the slave devices. Without active slaves, the DHCP requests are not
sent to the network.
-3.1.2 Configuring Multiple Bonds with sysconfig
+3.1.2 Configuring Multiple Bonds with Sysconfig
-----------------------------------------------
The sysconfig network initialization system is capable of
@@ -685,7 +692,7 @@ ifcfg-bondX files.
options in the ifcfg-bondX file, it is not necessary to add them to
the system /etc/modules.conf or /etc/modprobe.conf configuration file.
-3.2 Configuration with initscripts support
+3.2 Configuration with Initscripts Support
------------------------------------------
This section applies to distros using a version of initscripts
@@ -756,7 +763,7 @@ options for your configuration.
will restart the networking subsystem and your bond link should be now
up and running.
-3.2.1 Using DHCP with initscripts
+3.2.1 Using DHCP with Initscripts
---------------------------------
Recent versions of initscripts (the version supplied with
@@ -768,7 +775,7 @@ above, except replace the line "BOOTPROT
and add a line consisting of "TYPE=Bonding". Note that the TYPE value
is case sensitive.
-3.2.2 Configuring Multiple Bonds with initscripts
+3.2.2 Configuring Multiple Bonds with Initscripts
-------------------------------------------------
At this writing, the initscripts package does not directly
@@ -784,8 +791,8 @@ Fedora Core kernels, and has been seen o
exhibiting this problem, it will be impossible to configure multiple
bonds with differing parameters.
-3.3 Configuring Bonding Manually
---------------------------------
+3.3 Configuring Bonding Manually with Ifenslave
+-----------------------------------------------
This section applies to distros whose network initialization
scripts (the sysconfig or initscripts package) do not have specific
@@ -889,11 +896,139 @@ install bond1 /sbin/modprobe --ignore-in
This may be repeated any number of times, specifying a new and
unique name in place of bond1 for each subsequent instance.
+3.4 Configuring Bonding Manually via Sysfs
+------------------------------------------
+
+ Starting with version 3.0, Channel Bonding may be configured
+via the sysfs interface. This interface allows dynamic configuration
+of all bonds in the system without unloading the module. It also
+allows for adding and removing bonds at runtime. Ifenslave is no
+longer required, though it is still supported.
+
+ Use of the sysfs interface allows you to use multiple bonds
+with different configurations without having to reload the module.
+It also allows you to use multiple, differently configured bonds when
+bonding is compiled into the kernel.
+
+ You must have the sysfs filesystem mounted to configure
+bonding this way. The examples in this document assume that you
+are using the standard mount point for sysfs, e.g. /sys. If your
+sysfs filesystem is mounted elsewhere, you will need to adjust the
+example paths accordingly.
+
+Creating and Destroying Bonds
+-----------------------------
+To add a new bond foo:
+# echo +foo > /sys/class/net/bonding_masters
+
+To remove an existing bond bar:
+# echo -bar > /sys/class/net/bonding_masters
+
+To show all existing bonds:
+# cat /sys/class/net/bonding_masters
+
+NOTE: due to 4K size limitation of sysfs files, this list may be
+truncated if you have more than a few hundred bonds. This is unlikely
+to occur under normal operating conditions.
+
+Adding and Removing Slaves
+--------------------------
+ Interfaces may be enslaved to a bond using the file
+/sys/class/net/<bond>/bonding/slaves. The semantics for this file
+are the same as for the bonding_masters file.
+
+To enslave interface eth0 to bond bond0:
+# ifconfig bond0 up
+# echo +eth0 > /sys/class/net/bond0/bonding/slaves
+
+To free slave eth0 from bond bond0:
+# echo -eth0 > /sys/class/net/bond0/bonding/slaves
+
+ NOTE: The bond must be up before slaves can be added. All
+slaves are freed when the interface is brought down.
+
+ When an interface is enslaved to a bond, symlinks between the
+two are created in the sysfs filesystem. In this case, you would get
+/sys/class/net/bond0/slave_eth0 pointing to /sys/class/net/eth0, and
+/sys/class/net/eth0/master pointing to /sys/class/net/bond0.
+
+ This means that you can tell quickly whether or not an
+interface is enslaved by looking for the master symlink. Thus:
+# echo -eth0 > /sys/class/net/eth0/master/bonding/slaves
+will free eth0 from whatever bond it is enslaved to, regardless of
+the name of the bond interface.
+
+Changing a Bond's Configuration
+-------------------------------
+ Each bond may be configured individually by manipulating the
+files located in /sys/class/net/<bond name>/bonding
+
+ The names of these files correspond directly with the command-
+line parameters described elsewhere in in this file, and, with the
+exception of arp_ip_target, they accept the same values. To see the
+current setting, simply cat the appropriate file.
+
+ A few examples will be given here; for specific usage
+guidelines for each parameter, see the appropriate section in this
+document.
+
+To configure bond0 for balance-alb mode:
+# ifconfig bond0 down
+# echo 6 > /sys/class/net/bond0/bonding/mode
+ - or -
+# echo balance-alb > /sys/class/net/bond0/bonding/mode
+ NOTE: The bond interface must be down before the mode can be
+changed.
+
+To enable MII monitoring on bond0 with a 1 second interval:
+# echo 1000 > /sys/class/net/bond0/bonding/miimon
+ NOTE: If ARP monitoring is enabled, it will disabled when MII
+monitoring is enabled, and vice-versa.
+
+To add ARP targets:
+# echo +192.168.0.100 > /sys/class/net/bond0/bonding/arp_ip_target
+# echo +192.168.0.101 > /sys/class/net/bond0/bonding/arp_ip_target
+ NOTE: up to 10 target addresses may be specified.
+
+To remove an ARP target:
+# echo -192.168.0.100 > /sys/class/net/bond0/bonding/arp_ip_target
+
+Example Configuration
+---------------------
+ We begin with the same example that is shown in section 3.3,
+executed with sysfs, and without using ifenslave.
+
+ To make a simple bond of two e100 devices (presumed to be eth0
+and eth1), and have it persist across reboots, edit the appropriate
+file (/etc/init.d/boot.local or /etc/rc.d/rc.local), and add the
+following:
+
+modprobe bonding
+modprobe e100
+echo balance-alb > /sys/class/net/bond0/bonding/mode
+ifconfig bond0 192.168.1.1 netmask 255.255.255.0 up
+echo 100 > /sys/class/net/bond0/bonding/miimon
+echo +eth0 > /sys/class/net/bond0/bonding/slaves
+echo +eth1 > /sys/class/net/bond0/bonding/slaves
+
+ To add a second bond, with two e1000 interfaces in
+active-backup mode, using ARP monitoring, add the following lines to
+your init script:
+
+modprobe e1000
+echo +bond1 > /sys/class/net/bonding_masters
+echo active-backup > /sys/class/net/bond1/bonding/mode
+ifconfig bond1 192.168.2.1 netmask 255.255.255.0 up
+echo +192.168.2.100 /sys/class/net/bond1/bonding/arp_ip_target
+echo 2000 > /sys/class/net/bond1/bonding/arp_interval
+echo +eth2 > /sys/class/net/bond1/bonding/slaves
+echo +eth3 > /sys/class/net/bond1/bonding/slaves
+
-5. Querying Bonding Configuration
+4. Querying Bonding Configuration
=================================
-5.1 Bonding Configuration
+4.1 Bonding Configuration
-------------------------
Each bonding device has a read-only file residing in the
@@ -923,7 +1058,7 @@ generally as follows:
The precise format and contents will change depending upon the
bonding configuration, state, and version of the bonding driver.
-5.2 Network configuration
+4.2 Network configuration
-------------------------
The network configuration can be inspected using the ifconfig
@@ -958,7 +1093,7 @@ eth1 Link encap:Ethernet HWaddr 00
collisions:0 txqueuelen:100
Interrupt:9 Base address:0x1400
-6. Switch Configuration
+5. Switch Configuration
=======================
For this section, "switch" refers to whatever system the
@@ -991,7 +1126,7 @@ transmit policy for an EtherChannel grou
with another EtherChannel group.
-7. 802.1q VLAN Support
+6. 802.1q VLAN Support
======================
It is possible to configure VLAN devices over a bond interface
@@ -1042,7 +1177,7 @@ underlying device -- i.e. the bonding in
mode, which might not be what you want.
-8. Link Monitoring
+7. Link Monitoring
==================
The bonding driver at present supports two schemes for
@@ -1053,7 +1188,7 @@ monitor.
bonding driver itself, it is not possible to enable both ARP and MII
monitoring simultaneously.
-8.1 ARP Monitor Operation
+7.1 ARP Monitor Operation
-------------------------
The ARP monitor operates as its name suggests: it sends ARP
@@ -1071,7 +1206,7 @@ those slaves will stay down. If network
shows the ARP requests and replies on the network, then it may be that
your device driver is not updating last_rx and trans_start.
-8.2 Configuring Multiple ARP Targets
+7.2 Configuring Multiple ARP Targets
------------------------------------
While ARP monitoring can be done with just one target, it can
@@ -1094,7 +1229,7 @@ alias bond0 bonding
options bond0 arp_interval=60 arp_ip_target=192.168.0.100
-8.3 MII Monitor Operation
+7.3 MII Monitor Operation
-------------------------
The MII monitor monitors only the carrier state of the local
@@ -1120,14 +1255,14 @@ does not support or had some error in pr
and ethtool requests), then the MII monitor will assume the link is
up.
-9. Potential Sources of Trouble
+8. Potential Sources of Trouble
===============================
-9.1 Adventures in Routing
+8.1 Adventures in Routing
-------------------------
When bonding is configured, it is important that the slave
-devices not have routes that supercede routes of the master (or,
+devices not have routes that supersede routes of the master (or,
generally, not have routes at all). For example, suppose the bonding
device bond0 has two slaves, eth0 and eth1, and the routing table is
as follows:
@@ -1154,11 +1289,11 @@ by the state of the routing table.
The solution here is simply to insure that slaves do not have
routes of their own, and if for some reason they must, those routes do
-not supercede routes of their master. This should generally be the
+not supersede routes of their master. This should generally be the
case, but unusual configurations or errant manual or automatic static
route additions may cause trouble.
-9.2 Ethernet Device Renaming
+8.2 Ethernet Device Renaming
----------------------------
On systems with network configuration scripts that do not
@@ -1207,7 +1342,7 @@ modprobe with --ignore-install to cause
place. Full documentation on this can be found in the modprobe.conf
and modprobe manual pages.
-9.3. Painfully Slow Or No Failed Link Detection By Miimon
+8.3. Painfully Slow Or No Failed Link Detection By Miimon
---------------------------------------------------------
By default, bonding enables the use_carrier option, which
@@ -1235,7 +1370,7 @@ carrier state. It has no way to determi
beyond other ports of a switch, or if a switch is refusing to pass
traffic while still maintaining carrier on.
-10. SNMP agents
+9. SNMP agents
===============
If running SNMP agents, the bonding driver should be loaded
@@ -1281,7 +1416,7 @@ ifDescr, the association between the IP
and SNMP functions such as Interface_Scan_Next will report that
association.
-11. Promiscuous mode
+10. Promiscuous mode
====================
When running network monitoring tools, e.g., tcpdump, it is
@@ -1308,7 +1443,7 @@ sending to peers that are unassigned or
the active slave changes (e.g., due to a link failure), the
promiscuous setting will be propagated to the new active slave.
-12. Configuring Bonding for High Availability
+11. Configuring Bonding for High Availability
=============================================
High Availability refers to configurations that provide
@@ -1318,7 +1453,7 @@ goal is to provide the maximum availabil
(i.e., the network always works), even though other configurations
could provide higher throughput.
-12.1 High Availability in a Single Switch Topology
+11.1 High Availability in a Single Switch Topology
--------------------------------------------------
If two hosts (or a host and a single switch) are directly
@@ -1332,7 +1467,7 @@ the load will be rebalanced across the r
See Section 13, "Configuring Bonding for Maximum Throughput"
for information on configuring bonding with one peer device.
-12.2 High Availability in a Multiple Switch Topology
+11.2 High Availability in a Multiple Switch Topology
----------------------------------------------------
With multiple switches, the configuration of bonding and the
@@ -1359,7 +1494,7 @@ switches (ISL, or inter switch link), an
the outside world ("port3" on each switch). There is no technical
reason that this could not be extended to a third switch.
-12.2.1 HA Bonding Mode Selection for Multiple Switch Topology
+11.2.1 HA Bonding Mode Selection for Multiple Switch Topology
-------------------------------------------------------------
In a topology such as the example above, the active-backup and
@@ -1381,7 +1516,7 @@ broadcast: This mode is really a special
necessary for some specific one-way traffic to reach both
independent networks, then the broadcast mode may be suitable.
-12.2.2 HA Link Monitoring Selection for Multiple Switch Topology
+11.2.2 HA Link Monitoring Selection for Multiple Switch Topology
----------------------------------------------------------------
The choice of link monitoring ultimately depends upon your
@@ -1402,10 +1537,10 @@ regardless of which switch is active, th
target to query.
-13. Configuring Bonding for Maximum Throughput
+12. Configuring Bonding for Maximum Throughput
==============================================
-13.1 Maximizing Throughput in a Single Switch Topology
+12.1 Maximizing Throughput in a Single Switch Topology
------------------------------------------------------
In a single switch configuration, the best method to maximize
@@ -1476,7 +1611,7 @@ destination to make load balancing decis
mode is described below.
-13.1.1 MT Bonding Mode Selection for Single Switch Topology
+12.1.1 MT Bonding Mode Selection for Single Switch Topology
-----------------------------------------------------------
This configuration is the easiest to set up and to understand,
@@ -1607,7 +1742,7 @@ balance-alb: This mode is everything tha
device driver must support changing the hardware address while
the device is open.
-13.1.2 MT Link Monitoring for Single Switch Topology
+12.1.2 MT Link Monitoring for Single Switch Topology
----------------------------------------------------
The choice of link monitoring may largely depend upon which
@@ -1616,7 +1751,7 @@ support the use of the ARP monitor, and
the MII monitor (which does not provide as high a level of end to end
assurance as the ARP monitor).
-13.2 Maximum Throughput in a Multiple Switch Topology
+12.2 Maximum Throughput in a Multiple Switch Topology
-----------------------------------------------------
Multiple switches may be utilized to optimize for throughput
@@ -1651,7 +1786,7 @@ a single 72 port switch.
can be equipped with an additional network device connected to an
external network; this host then additionally acts as a gateway.
-13.2.1 MT Bonding Mode Selection for Multiple Switch Topology
+12.2.1 MT Bonding Mode Selection for Multiple Switch Topology
-------------------------------------------------------------
In actual practice, the bonding mode typically employed in
@@ -1664,7 +1799,7 @@ packets has arrived). When employed in
mode allows individual connections between two hosts to effectively
utilize greater than one interface's bandwidth.
-13.2.2 MT Link Monitoring for Multiple Switch Topology
+12.2.2 MT Link Monitoring for Multiple Switch Topology
------------------------------------------------------
Again, in actual practice, the MII monitor is most often used
@@ -1674,10 +1809,10 @@ advantages over the MII monitor are miti
needed as the number of systems involved grows (remember that each
host in the network is configured with bonding).
-14. Switch Behavior Issues
+13. Switch Behavior Issues
==========================
-14.1 Link Establishment and Failover Delays
+13.1 Link Establishment and Failover Delays
-------------------------------------------
Some switches exhibit undesirable behavior with regard to the
@@ -1712,7 +1847,7 @@ switches take a long time to go into bac
to not activate a backup interface immediately after a link goes down.
Failover may be delayed via the downdelay bonding module option.
-14.2 Duplicated Incoming Packets
+13.2 Duplicated Incoming Packets
--------------------------------
It is not uncommon to observe a short burst of duplicated
@@ -1751,14 +1886,14 @@ behavior, it can be induced by clearing
most Cisco switches, the privileged command "clear mac address-table
dynamic" will accomplish this).
-15. Hardware Specific Considerations
+14. Hardware Specific Considerations
====================================
This section contains additional information for configuring
bonding on specific hardware platforms, or for interfacing bonding
with particular switches or other devices.
-15.1 IBM BladeCenter
+14.1 IBM BladeCenter
--------------------
This applies to the JS20 and similar systems.
@@ -1861,7 +1996,7 @@ bonding driver.
avoid fail-over delay issues when using bonding.
-16. Frequently Asked Questions
+15. Frequently Asked Questions
==============================
1. Is it SMP safe?
@@ -1925,7 +2060,7 @@ not have special switch requirements, bu
support specific features (described in the appropriate section under
module parameters, above).
- In 802.3ad mode, it works with with systems that support IEEE
+ In 802.3ad mode, it works with systems that support IEEE
802.3ad Dynamic Link Aggregation. Most managed and many unmanaged
switches currently available support 802.3ad.
^ permalink raw reply
* Re: [PATCH 8/10] d80211: get rid of default management interface
From: John W. Linville @ 2006-04-26 18:53 UTC (permalink / raw)
To: Jiri Benc; +Cc: Jouni Malinen, netdev
In-Reply-To: <20060424150148.642b057f@griffin.suse.cz>
On Mon, Apr 24, 2006 at 03:01:48PM +0200, Jiri Benc wrote:
> On Fri, 21 Apr 2006 19:44:31 -0700, Jouni Malinen wrote:
> > On Fri, Apr 21, 2006 at 10:53:28PM +0200, Jiri Benc wrote:
> > > Default management interface (wlanXap) confuses users. It is only needed for
> > > AP mode (and only until interfaces are converted to use native 802.11
> > > frames).
> >
> > Or when using user space MLME in client mode which is something that I
> > just got working as far as scanning and association is concerned. In
> > other words, wpa_supplicant will be needing this interface..
>
> I think we can (and should) wait with userspace MLME until the netlink
> interface is implemented.
>
> > That sounds like something that could break multi-BSSID/SSID aware
> > hostapd. Are you saying that there would be new wlanXap like interface
> > for each BSS/VLAN interface? What are the problems this is fixing with
> > multiple AP interfaces?
>
> Thinking about it more, only implementation problems. I was just lazy
> and implementing things the way I did seemed to be easier. My fault,
> sorry, didn't realize hostapd is aware of multiple BSSes.
>
> > So far, hostapd has been responsible for
> > receiving all management from a single interface and then internally
> > decide which BSS/multi-SSID entry to use for each.
> >
> > I would assume that hostapd could be changed to process frames from
> > multiple interfaces (at least if this is only for multi-BSSID, not for
> > multi-SSID/VLAN case).
>
> There is no point in changing hostapd as this solution is temporary only
> and hostapd will need to be changed for netlink anyway.
>
> I will fix the patch.
I'm going to skip this patch for now. I'll merge the rest.
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: David S. Miller @ 2006-04-26 19:23 UTC (permalink / raw)
To: caitlinb; +Cc: kelly, netdev, rusty
In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F143AE16@NT-SJCA-0751.brcm.ad.broadcom.com>
From: "Caitlin Bestler" <caitlinb@broadcom.com>
Date: Wed, 26 Apr 2006 09:57:22 -0700
> The major element I liked about Kelly's approach is that the ring
> is clearly designed to allow a NIC to place packets directly into
> a ring that is directly accessible by the user. Evolutionary steps
> are good, but isn't direct placement into a user-accessible simple
> ring buffer the ultimate justification of netchannels?
It is a very good point and one I actually need to think about
some more.
I'll be up front and say that I don't think it's actually necessary to
do channels all the way to userspace, just channeling to the in-kernel
networking protocol is more than sufficient. This will get us most of
the way without having to deal with any of the thorny issues of doing
protocols in userspace. I could be wrong but this is my gut instinct
at this time.
> Central integration also will need to be integrated with packet
> filtering. In particular, once a flow has been assigned to a
> netchannel ring, who is responsible for doing the packet filtering?
> Or is it enough to check the packet filter when the net channel flow
> is created?
Very good question and one that hasn't been discussed enough yet.
Eventually we should be able to do things such as allow netfilter
to register channels too.
Before we do that, we'll have to decide how we'll handle potential
conflicts between local sockets and firewall rules.
There is a school of opinion that would agree to a rule such as:
if a local socket exists, it can trump firewalling.
This would be a nice and simple way to deal with firewall rules that
potentially shadow local sockets. You couldn't have created that
fully bound socket in the first place if the firewall rules didn't
allow it. You'd need to insert rules subsequently that block the
connection's flow. If we want to support that we either have to do
netfilter channels from the get-go, or simply disable socket
netchannels altogether if netfilter is enabled.
I personally think allowing sockets to trump firewall rules is an
acceptable relaxation of the rules in order to simplify the
implementation.
^ permalink raw reply
* RE: [PATCH 00/11] ixgb: driver update (upstream)
From: Kirsher, Jeffrey T @ 2006-04-26 19:21 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, David Miller, Ronciak, John, Brandeburg, Jesse
Jeff Garzik wrote:
>pull failed:
>[jgarzik@pretzel netdev-2.6]$ git pull
>git://lost.foo-projects.org/linux-2.6.git ixgb-upstream
>error: no such remote ref refs/heads/ixgb-upstream
>Fetch failure: git://lost.foo-projects.org/linux-2.6.git
Hmm, I apologize, I gave the wrong URL.
git://lost.foo-projects.org/~jtkirshe/netdev-2.6 ixgb-upstream
cheers,
Jeff
^ permalink raw reply
* RE: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Caitlin Bestler @ 2006-04-26 19:30 UTC (permalink / raw)
To: David S. Miller; +Cc: kelly, netdev, rusty
David S. Miller wrote:
>
> I personally think allowing sockets to trump firewall rules
> is an acceptable relaxation of the rules in order to simplify
> the implementation.
I agree. I have never seen a set of netfilter rules that
would block arbitrary packets *within* an established connection.
Technically you can create such rules, but every single set
of rules actually deployed that I have ever seen started with
a rule to pass all packets for established connections, and
then proceeded to control which connections could be initiated
or accepted.
^ permalink raw reply
* Re: [PATCH 0/17] d80211 patches
From: John W. Linville @ 2006-04-26 19:39 UTC (permalink / raw)
To: Jiri Benc; +Cc: Michael Buesch, netdev
In-Reply-To: <20060421225210.36a0225b@griffin.suse.cz>
On Fri, Apr 21, 2006 at 10:52:10PM +0200, Jiri Benc wrote:
> On Fri, 21 Apr 2006 22:52:08 +0200, Michael Buesch wrote:
> > Can you please send your hacky patch for the bcm43xx
> > to me, so I can come up with a clean one?
>
> Sure, actually I planned to do it in a few minutes :-)
Hacky or not, I'm applying this patch to keep the bcm43xx driver
from breaking. I don't suppose you have a patch for the rt2x00 driver?
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Jeff Garzik @ 2006-04-26 19:46 UTC (permalink / raw)
To: Caitlin Bestler; +Cc: David S. Miller, kelly, netdev, rusty
In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F143AE6C@NT-SJCA-0751.brcm.ad.broadcom.com>
Caitlin Bestler wrote:
> David S. Miller wrote:
>
>> I personally think allowing sockets to trump firewall rules
>> is an acceptable relaxation of the rules in order to simplify
>> the implementation.
>
> I agree. I have never seen a set of netfilter rules that
> would block arbitrary packets *within* an established connection.
>
> Technically you can create such rules, but every single set
> of rules actually deployed that I have ever seen started with
> a rule to pass all packets for established connections, and
> then proceeded to control which connections could be initiated
> or accepted.
Oh, there are plenty of examples of filtering within an established
connection: input rules. I've seen "drop all packets from <these> IPs"
type rules frequently. Victims of DoS use those kinds of rules to stop
packets as early as possible.
Jeff
^ permalink raw reply
* wireless-dev tree updated
From: John W. Linville @ 2006-04-26 20:20 UTC (permalink / raw)
To: netdev
I know y'all were wondering if I was ever going to merge wireless-dev
patches...I apologize for the delay. :-)
Please recall that I have collapsed the branching, and now all the
Devicescape-based stuff is on the master branch here:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git
I also have the individual patches extracted and available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-dev/
The rt2x00 driver is currently broken in this tree, thanks to one of
Jiri's d80211 patches. Hopefully Jiri or someone else will submit
a patch to fix that soon.
This also includes a patch from Jouni to move the d80211-based drivers
to the drivers/net/wireless/d80211 directory...FYI.
We are working towards getting this tree ready to feed the -mm tree.
This means that I am accepting patches which address cleanups, compile
problems, and kernel coding style issues (as well as functional
changes). I am also happy to accept patches for new drivers or for
porting ieee80211+softmac-based drivers to the d80211 stack.
There was a surprising amount of agreement that we should be marching
toward the use of the Devicescape stack. That means that this tree
is the future. Let's get it whipped into shape!
Thanks,
John
---
The following changes since commit ebce6da892686429b8f2bdb152288ca22f4db58f:
John W. Linville:
Merge branch 'from-linus'
are found in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git
Adrian Bunk:
bcm43xx: fix dyn tssi2dbm memleak
Jiri Benc:
d80211: symlinks to wiphy in sysfs
d80211: allow WDS remote to by set by WE
d80211: add IBSS and monitor interface types
d80211: non-shared interface types
d80211: remove local->bssid variable
d80211: rename IEEE80211_SUB_IF_TYPE_ constants
d80211: ask driver for allowed iface combinations
d80211: remove obsolete stuff
d80211: fix interface configuration
d80211: rename adm_status to radio_enabled
d80211: interface types changeable by SIOCSIWMODE
d80211: master interface auto up/down
d80211: set_multicast_list
d80211: fix handling of received frames
d80211: fix monitor interfaces
d80211: fix AP interfaces
d80211: fix SIOCGIWESSID ioctl
d80211: use is_multicast_ether_addr
d80211: fix Oops caused by packets sent directly to master device
d80211: don't use pointer in ieee80211_tx_control
d80211: per-interface SSID
d80211: per-interface generic_elem
d80211: get rid of default AP interface
d80211: rename master interface
d80211: add one default interface
bcm43xx: fix breakage from d80211 patches
Jouni Malinen:
Move d80211-based drivers into new subdirectory
d80211: Replace MODULE_PARM with module_param
Michael Buesch:
bcm43xx-d80211: use pci_iomap() for convenience.
bcm43xx-d80211: protect tx_stat callback from uninitialized device
bcm43xx: fix pctl slowclock limit calculation
bcm43xx: sysfs code cleanup
drivers/net/wireless/Kconfig | 3
drivers/net/wireless/Makefile | 6
.../net/wireless/bcm43xx-d80211/bcm43xx_sysfs.h | 25
drivers/net/wireless/d80211/Kconfig | 2
drivers/net/wireless/d80211/Makefile | 2
drivers/net/wireless/d80211/README | 2
drivers/net/wireless/d80211/bcm43xx/Kconfig | 0
drivers/net/wireless/d80211/bcm43xx/Makefile | 0
drivers/net/wireless/d80211/bcm43xx/bcm43xx.h | 19
.../net/wireless/d80211/bcm43xx/bcm43xx_debugfs.c | 2
.../net/wireless/d80211/bcm43xx/bcm43xx_debugfs.h | 0
drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c | 0
drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.h | 0
.../net/wireless/d80211/bcm43xx/bcm43xx_ethtool.c | 0
.../net/wireless/d80211/bcm43xx/bcm43xx_ethtool.h | 0
drivers/net/wireless/d80211/bcm43xx/bcm43xx_ilt.c | 0
drivers/net/wireless/d80211/bcm43xx/bcm43xx_ilt.h | 0
drivers/net/wireless/d80211/bcm43xx/bcm43xx_leds.c | 0
drivers/net/wireless/d80211/bcm43xx/bcm43xx_leds.h | 0
drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c | 87 +
drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.h | 0
drivers/net/wireless/d80211/bcm43xx/bcm43xx_phy.c | 1
drivers/net/wireless/d80211/bcm43xx/bcm43xx_phy.h | 0
drivers/net/wireless/d80211/bcm43xx/bcm43xx_pio.c | 0
drivers/net/wireless/d80211/bcm43xx/bcm43xx_pio.h | 0
.../net/wireless/d80211/bcm43xx/bcm43xx_power.c | 115 +-
.../net/wireless/d80211/bcm43xx/bcm43xx_power.h | 9
.../net/wireless/d80211/bcm43xx/bcm43xx_radio.c | 0
.../net/wireless/d80211/bcm43xx/bcm43xx_radio.h | 0
.../net/wireless/d80211/bcm43xx/bcm43xx_sysfs.c | 115 +-
.../net/wireless/d80211/bcm43xx/bcm43xx_sysfs.h | 9
drivers/net/wireless/d80211/bcm43xx/bcm43xx_xmit.c | 0
drivers/net/wireless/d80211/bcm43xx/bcm43xx_xmit.h | 0
drivers/net/wireless/d80211/rt2x00/Kconfig | 0
drivers/net/wireless/d80211/rt2x00/Makefile | 0
drivers/net/wireless/d80211/rt2x00/rt2400pci.c | 0
drivers/net/wireless/d80211/rt2x00/rt2400pci.h | 0
drivers/net/wireless/d80211/rt2x00/rt2500pci.c | 0
drivers/net/wireless/d80211/rt2x00/rt2500pci.h | 0
drivers/net/wireless/d80211/rt2x00/rt2500usb.c | 0
drivers/net/wireless/d80211/rt2x00/rt2500usb.h | 0
drivers/net/wireless/d80211/rt2x00/rt2x00.h | 0
include/net/d80211.h | 212 ++-
net/d80211/Makefile | 1
net/d80211/hostapd_ioctl.h | 3
net/d80211/ieee80211.c | 1519 +++++++-------------
net/d80211/ieee80211_dev.c | 16
net/d80211/ieee80211_i.h | 82 +
net/d80211/ieee80211_iface.c | 303 ++++
net/d80211/ieee80211_ioctl.c | 443 +++---
net/d80211/ieee80211_proc.c | 40 -
net/d80211/ieee80211_sta.c | 75 +
net/d80211/ieee80211_sysfs.c | 88 +
net/d80211/wme.c | 2
54 files changed, 1660 insertions(+), 1521 deletions(-)
delete mode 100644 drivers/net/wireless/bcm43xx-d80211/bcm43xx_sysfs.h
create mode 100644 drivers/net/wireless/d80211/Kconfig
create mode 100644 drivers/net/wireless/d80211/Makefile
create mode 100644 drivers/net/wireless/d80211/README
rename drivers/net/wireless/{bcm43xx-d80211/Kconfig => d80211/bcm43xx/Kconfig} (100%)
rename drivers/net/wireless/{bcm43xx-d80211/Makefile => d80211/bcm43xx/Makefile} (100%)
rename drivers/net/wireless/{bcm43xx-d80211/bcm43xx.h => d80211/bcm43xx/bcm43xx.h} (99%)
rename drivers/net/wireless/{bcm43xx-d80211/bcm43xx_debugfs.c => d80211/bcm43xx/bcm43xx_debugfs.c} (100%)
rename drivers/net/wireless/{bcm43xx-d80211/bcm43xx_debugfs.h => d80211/bcm43xx/bcm43xx_debugfs.h} (100%)
rename drivers/net/wireless/{bcm43xx-d80211/bcm43xx_dma.c => d80211/bcm43xx/bcm43xx_dma.c} (100%)
rename drivers/net/wireless/{bcm43xx-d80211/bcm43xx_dma.h => d80211/bcm43xx/bcm43xx_dma.h} (100%)
rename drivers/net/wireless/{bcm43xx-d80211/bcm43xx_ethtool.c => d80211/bcm43xx/bcm43xx_ethtool.c} (100%)
rename drivers/net/wireless/{bcm43xx-d80211/bcm43xx_ethtool.h => d80211/bcm43xx/bcm43xx_ethtool.h} (100%)
rename drivers/net/wireless/{bcm43xx-d80211/bcm43xx_ilt.c => d80211/bcm43xx/bcm43xx_ilt.c} (100%)
rename drivers/net/wireless/{bcm43xx-d80211/bcm43xx_ilt.h => d80211/bcm43xx/bcm43xx_ilt.h} (100%)
rename drivers/net/wireless/{bcm43xx-d80211/bcm43xx_leds.c => d80211/bcm43xx/bcm43xx_leds.c} (100%)
rename drivers/net/wireless/{bcm43xx-d80211/bcm43xx_leds.h => d80211/bcm43xx/bcm43xx_leds.h} (100%)
rename drivers/net/wireless/{bcm43xx-d80211/bcm43xx_main.c => d80211/bcm43xx/bcm43xx_main.c} (99%)
rename drivers/net/wireless/{bcm43xx-d80211/bcm43xx_main.h => d80211/bcm43xx/bcm43xx_main.h} (100%)
rename drivers/net/wireless/{bcm43xx-d80211/bcm43xx_phy.c => d80211/bcm43xx/bcm43xx_phy.c} (100%)
rename drivers/net/wireless/{bcm43xx-d80211/bcm43xx_phy.h => d80211/bcm43xx/bcm43xx_phy.h} (100%)
rename drivers/net/wireless/{bcm43xx-d80211/bcm43xx_pio.c => d80211/bcm43xx/bcm43xx_pio.c} (100%)
rename drivers/net/wireless/{bcm43xx-d80211/bcm43xx_pio.h => d80211/bcm43xx/bcm43xx_pio.h} (100%)
rename drivers/net/wireless/{bcm43xx-d80211/bcm43xx_power.c => d80211/bcm43xx/bcm43xx_power.c} (82%)
rename drivers/net/wireless/{bcm43xx-d80211/bcm43xx_power.h => d80211/bcm43xx/bcm43xx_power.h} (88%)
rename drivers/net/wireless/{bcm43xx-d80211/bcm43xx_radio.c => d80211/bcm43xx/bcm43xx_radio.c} (100%)
rename drivers/net/wireless/{bcm43xx-d80211/bcm43xx_radio.h => d80211/bcm43xx/bcm43xx_radio.h} (100%)
rename drivers/net/wireless/{bcm43xx-d80211/bcm43xx_sysfs.c => d80211/bcm43xx/bcm43xx_sysfs.c} (67%)
create mode 100644 drivers/net/wireless/d80211/bcm43xx/bcm43xx_sysfs.h
rename drivers/net/wireless/{bcm43xx-d80211/bcm43xx_xmit.c => d80211/bcm43xx/bcm43xx_xmit.c} (100%)
rename drivers/net/wireless/{bcm43xx-d80211/bcm43xx_xmit.h => d80211/bcm43xx/bcm43xx_xmit.h} (100%)
rename drivers/net/wireless/{rt2x00/Kconfig => d80211/rt2x00/Kconfig} (100%)
rename drivers/net/wireless/{rt2x00/Makefile => d80211/rt2x00/Makefile} (100%)
rename drivers/net/wireless/{rt2x00/rt2400pci.c => d80211/rt2x00/rt2400pci.c} (100%)
rename drivers/net/wireless/{rt2x00/rt2400pci.h => d80211/rt2x00/rt2400pci.h} (100%)
rename drivers/net/wireless/{rt2x00/rt2500pci.c => d80211/rt2x00/rt2500pci.c} (100%)
rename drivers/net/wireless/{rt2x00/rt2500pci.h => d80211/rt2x00/rt2500pci.h} (100%)
rename drivers/net/wireless/{rt2x00/rt2500usb.c => d80211/rt2x00/rt2500usb.c} (100%)
rename drivers/net/wireless/{rt2x00/rt2500usb.h => d80211/rt2x00/rt2500usb.h} (100%)
rename drivers/net/wireless/{rt2x00/rt2x00.h => d80211/rt2x00/rt2x00.h} (100%)
create mode 100644 net/d80211/ieee80211_iface.c
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* RE: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Caitlin Bestler @ 2006-04-26 20:20 UTC (permalink / raw)
To: Jeff Garzik; +Cc: David S. Miller, kelly, netdev, rusty
Jeff Garzik wrote:
> Caitlin Bestler wrote:
>> David S. Miller wrote:
>>
>>> I personally think allowing sockets to trump firewall rules is an
>>> acceptable relaxation of the rules in order to simplify the
>>> implementation.
>>
>> I agree. I have never seen a set of netfilter rules that would block
>> arbitrary packets *within* an established connection.
>>
>> Technically you can create such rules, but every single set of rules
>> actually deployed that I have ever seen started with a rule to pass
>> all packets for established connections, and then proceeded to
>> control which connections could be initiated or accepted.
>
> Oh, there are plenty of examples of filtering within an established
> connection: input rules. I've seen "drop all packets from <these>
> IPs" type rules frequently. Victims of DoS use those kinds of
> rules to stop packets as early as possible.
>
> Jeff
If you are dropping all packets from IP X, then how was the connection
established? Obviously we are only dealing with connections that
were established before the rule to drop all packets from IP X
was created.
That calls for an ability to revoke the assignment of any flow to
a vj_netchannel when a new rule is created that would filter any
packet that would be classified by the flow.
Basically the rule is that a delegation to a vj_netchannel is
only allowed for flows where *all* packets assigned to that flow
(input or output) would receive a 'pass' from netchannels.
That makes sense. What I don't see a need for is examing *each*
delegated packet against the entire set of existing rules. Basically,
a flow should either be rule-compliant or not. If it is not, then
the delegation of the flow should be abandoned. If that requires
re-importing TCP state, then perhaps the TCP connection needs to
be aborted.
In any event, if netfilter is selectively rejecting packets in the
middle
of a connection then the connection is going to fail anyway.
^ permalink raw reply
* Re: [PATCH] compile error in ieee80211_ioctl.c
From: John W. Linville @ 2006-04-26 20:49 UTC (permalink / raw)
To: Jiri Benc; +Cc: Alex Davis, netdev
In-Reply-To: <20060426183734.4ac5dc6c@griffin.suse.cz>
On Wed, Apr 26, 2006 at 06:37:34PM +0200, Jiri Benc wrote:
> On Wed, 26 Apr 2006 09:29:46 -0700 (PDT), Alex Davis wrote:
> > Here is an updated patch which addresses Randy's issues. I'm currently running
> > this with no problems:
> > [...]
> > +module_param(ieee80211_regdom, int, 0666);
> > MODULE_PARM_DESC(ieee80211_regdom, "IEEE 802.11 regulatory domain; 64=MKK");
>
> NAK. Those parameters should not be writable yet.
>
> Please see
> http://marc.theaimsgroup.com/?l=linux-netdev&m=114565040832451&w=2 for
> the correct patch (hopefully John will pull it soon).
This has now been addressed.
Thanks!
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox