* Re: [1/1] netlink: fix broadcasting to the wrong group.
From: Evgeniy Polyakov @ 2006-04-18 5:18 UTC (permalink / raw)
To: Patrick McHardy; +Cc: David S. Miller, netdev
In-Reply-To: <4444211F.3030000@trash.net>
On Tue, Apr 18, 2006 at 01:13:35AM +0200, Patrick McHardy (kaber@trash.net) wrote:
> I went over your mails again, but I don't understand the problem you're
> seeing. Please just make a simple example showing the operation +
> the arguments you're using to bind to group 5 which would result in
> bit 0 beeing set or the kernel deciding to send to group 1 for some
> other reason.
Example:
at bind time group 5 was selected and then socket was subscribed to that
group. This end up in 0b10101 bitmask, which allows to multicast to
group 16 which has nothing in common with either group number 5 or
bitmask 5.
I think that if socket uses bitmask at bind time, then it should not be
allowed to subscribe.
So for above example at bind time (1<<4) should be used and this is what
happens with subscription. We discussed already that itmask
functionality was never used, and current behaviour introduces big
ambiguity.
Well, if you forces this to not be changed, I will update documentation
about this behaviour.
--
Evgeniy Polyakov
^ permalink raw reply
* Re: [PATCH] ip_route_input panic fix
From: Herbert Xu @ 2006-04-18 2:54 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: davem, netdev
In-Reply-To: <20060417194931.032aba02@localhost.localdomain>
On Mon, Apr 17, 2006 at 07:49:31PM -0700, Stephen Hemminger wrote:
>
> Not really, just that ip_check_mc looks at the proto for !IGMP. And maybe
> some tool like coverity or sparse would be smart enough to look for
> uninitialized data usage.
That's a good point.
Thanks Stephen,
--
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
* Re: [PATCH] ip_route_input panic fix
From: Stephen Hemminger @ 2006-04-18 2:49 UTC (permalink / raw)
To: Herbert Xu; +Cc: davem, netdev
In-Reply-To: <E1FVfxQ-0008Tf-00@gondolin.me.apana.org.au>
On Tue, 18 Apr 2006 12:28:48 +1000
Herbert Xu <herbert@gondor.apana.org.au> wrote:
> Hi Stephen:
>
> Stephen Hemminger <shemminger@osdl.org> wrote:
> > This fixes http://bugzilla.kernel.org/show_bug.cgi?id=6388
> > The bug is caused by ip_route_input dereferencing skb->nh.protocol of
> > the dummy skb passed dow from inet_rtm_getroute (Thanks Thomas for seeing
> > it). It only happens if the route requested is for a multicast IP
> > address.
>
> Good catch.
>
> > - skb->mac.raw = skb->data;
> > + skb->mac.raw = skb->nh.raw = skb->data;
>
> This should fix it.
>
> > + /* Bugfix: need to give ip_route_input enough of an IP header to not gag. */
> > + skb->nh.iph->protocol = IPPROTO_ICMP;
>
> Do we really need this? After all we can get completely bogus values
> coming in through the network too.
Not really, just that ip_check_mc looks at the proto for !IGMP. And maybe
some tool like coverity or sparse would be smart enough to look for
uninitialized data usage.
^ permalink raw reply
* Re: [PATCH] ip_route_input panic fix
From: Herbert Xu @ 2006-04-18 2:28 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: davem, netdev
In-Reply-To: <20060417171253.4e988afc@localhost.localdomain>
Hi Stephen:
Stephen Hemminger <shemminger@osdl.org> wrote:
> This fixes http://bugzilla.kernel.org/show_bug.cgi?id=6388
> The bug is caused by ip_route_input dereferencing skb->nh.protocol of
> the dummy skb passed dow from inet_rtm_getroute (Thanks Thomas for seeing
> it). It only happens if the route requested is for a multicast IP
> address.
Good catch.
> - skb->mac.raw = skb->data;
> + skb->mac.raw = skb->nh.raw = skb->data;
This should fix it.
> + /* Bugfix: need to give ip_route_input enough of an IP header to not gag. */
> + skb->nh.iph->protocol = IPPROTO_ICMP;
Do we really need this? After all we can get completely bogus values
coming in through the network too.
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
* Re: [PATCH][RFC] Security marking
From: James Morris @ 2006-04-18 1:01 UTC (permalink / raw)
To: edwin; +Cc: netdev, fireflier-devel, Patrick McHardy
In-Reply-To: <20060417184053.6D618378FD@localhost.localdomain>
On Mon, 17 Apr 2006, edwin@gurde.com wrote:
> Secmark, or skfilter is exactly what fireflier needs to solve the shared
> socket issue. Thanks for working on this. If this gets integrated in
> mainline, fireflier LSM will be dropped.
I think you probably need skfilter as a standalone option.
> Is it possible to have an SELinux policy that reinjects the packets if didn't match any rules?
> I.e. if a program that listens on port 80 doesn't have access to the packet, (because it doesn't have the proper domain,)
> and the SELinux won't allow the program to read the packet: is it possible to reinject this packet in the netfilter chain,
> instead of dropping it?
>
> This would allow creating rules interactively (fireflier).
This could be done with nfqueue, modular policy and a pretty simple tool.
Although, nfqueue doesn't work at the socket layer (but perhaps would with
skfilter).
> What does the secmark currently do with packets that aren't allowed by policy to be received?
Under SELinux, they'd be silently dropped.
> P.S.: Where can I get the full secmark patches, so I can test them to see if they really fit my needs?
> Do you have an estimate timeline for mainline integration? (in terms of n weeks, m months)
The rest of the secmark related patches don't exist yet, I posted the core
changes needed, and the others will be SELinux-specific. Mainline
integration would hopefully be 2.6.18, if it all works out ok.
If you're looking for skfilter:
http://people.redhat.com/jmorris/selinux/skfilter/
Patrick McHardy has some ideas on resolving some of the skfilter issues.
- James
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: r8169 locks up in 2.6.16.5
From: Thomas A. Oehser @ 2006-04-18 0:43 UTC (permalink / raw)
To: Francois Romieu; +Cc: Thomas A. Oehser, netdev
In-Reply-To: <20060417230927.GA8893@electric-eye.fr.zoreil.com>
> Thanks for the report. It is quite clear. The device is (almost surely)
> killed by a rx fifo overflow. Expect a patch shortly.
> I wonder why it overflows in the first place though. How much time does
> the 170 Mb transfer need ?
It is actually about a 30GB transfer, it was just after the first
170Mb that it failed. The command in question is just a simple
"nc -l -p 12345|buffer|cpio -iumdB", and the sender may well be
able to generate the data faster than the receiving disk can save
it, as the sender is a raid-1 mirror and the receiver is a raid-5
array, I would expect the raid-5 write penalty and the raid-1 read
speed to make it have to block for most of the transfer. It didn't
take long to get that far- um, I think only 2 or 3 minutes before
it locked up.
-Tom
--
May 4, 1970: Alison Krause, Jeffrey Miller, Sandra Scheuer, William Schroeder.
^ permalink raw reply
* [PATCH] ip_route_input panic fix
From: Stephen Hemminger @ 2006-04-18 0:12 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
This fixes http://bugzilla.kernel.org/show_bug.cgi?id=6388
The bug is caused by ip_route_input dereferencing skb->nh.protocol of
the dummy skb passed dow from inet_rtm_getroute (Thanks Thomas for seeing
it). It only happens if the route requested is for a multicast IP
address.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
--- linux-2.6.16.6.orig/net/ipv4/route.c
+++ linux-2.6.16.6/net/ipv4/route.c
@@ -2750,7 +2750,10 @@ int inet_rtm_getroute(struct sk_buff *in
/* Reserve room for dummy headers, this skb can pass
through good chunk of routing engine.
*/
- skb->mac.raw = skb->data;
+ skb->mac.raw = skb->nh.raw = skb->data;
+
+ /* Bugfix: need to give ip_route_input enough of an IP header to not gag. */
+ skb->nh.iph->protocol = IPPROTO_ICMP;
skb_reserve(skb, MAX_HEADER + sizeof(struct iphdr));
if (rta[RTA_SRC - 1])
^ permalink raw reply
* Re: [1/1] netlink: fix broadcasting to the wrong group.
From: Patrick McHardy @ 2006-04-17 23:13 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: David S. Miller, netdev
In-Reply-To: <20060417202150.GA10764@2ka.mipt.ru>
Evgeniy Polyakov wrote:
> On Mon, Apr 17, 2006 at 10:14:58PM +0200, Patrick McHardy (kaber@trash.net) wrote:
>
>>Not exactly, its not related to the group number. groups used in bind()
>>are considered as bitmask and groups used for setsockopt are considered
>>as group numbers. We can't change bind() because this behaviour is
>>required for compatibility.
>
>
> So bind and subscribing are almost exclusive and should not be used
> simultaneously?
No. You have to use bind() if you want to use a socket for sending.
bind() will overwrite the lower 32 groups with whatever is specified
in struct nladdr, if you have used setsockopt(NETLINK_ADD_MEMBERSHIP)
before the call to bind() for a group <= 32 you have to specify the
same group mask or it will get changed. Usually you would call bind()
first if you intend to use the socket for sending and subscribe
to multicast groups afterwards.
>>>But this introduce some problem with subscribing - if one subscribes to
>>>group 5 and is bound to the same group it allows to broadcast not only
>>>to group 5, and those which have the same bits set, but also to group 16
>>>(1<<(5-1)), which has nothing in common with the requested group number.
>>
>>Only if you use group numbers for bind(), which is plainly wrong.
>
>
> Even if one uses group bitmask at bind time and later subscribes to
> some group from that bitmask, this will introduce wrong behaviour with
> unrelated gropus.
> Maybe we should not allow to subscribe if group bitmask different from 1
> was used at bind() time?
I went over your mails again, but I don't understand the problem you're
seeing. Please just make a simple example showing the operation +
the arguments you're using to bind to group 5 which would result in
bit 0 beeing set or the kernel deciding to send to group 1 for some
other reason.
^ permalink raw reply
* Re: r8169 locks up in 2.6.16.5
From: Francois Romieu @ 2006-04-17 23:09 UTC (permalink / raw)
To: Thomas A. Oehser; +Cc: netdev
In-Reply-To: <20060416225843.GA2274@jupiter.toms.net>
Thomas A. Oehser <tom@toms.net> :
[...]
> Ok, here it all is, the attached archive has:
>
> - .before is right after the interface came up
> - .mid is after flooding it with ping -f commands from 2 machines at once
> - .bad is after doing the cpio over nc that killed it after 170MB
> - .back is after ifconfig down / ifconfig up that restored it
Thanks for the report. It is quite clear. The device is (almost surely)
killed by a rx fifo overflow. Expect a patch shortly.
I wonder why it overflows in the first place though. How much time does
the 170 Mb transfer need ?
--
Ueimor
^ permalink raw reply
* Re: want to randomly drop packets based on percent
From: George Nychis @ 2006-04-17 23:08 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: linux-kernel, netdev
In-Reply-To: <20060417103211.24115952@localhost.localdomain>
Stephen Hemminger wrote:
>O
>
>
>>>>>>I wanted to insert artificial packet loss based on a percent so i found:
>>>>>>network emulab qdisc could do it, so i compiled support into the kernel
>>>>>>and tried:
>>>>>>tc qdisc change dev eth0 root netem loss .1%
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>> ^^^^^^
>>>
>>>You need to do add not change. Add will set the queue discipline
>>>to netem (default is pfifo_fast). Change is for changing netem parameters
>>>after it is loaded.
>>>
>>>
>>>
>>>
>>>
>>bahhh I see... the wiki has "change" instead of add. Now i'm running
>>into another problem, I have an XCP qdisc that I have already added via:
>>tc qdisc add dev ath0 root xcp capacity 54Mbit size 500
>>
>>
>>
>
>Wiki reads as a set of examples. First uses, "add" after that "change".
>
>
>
>
>>therefore when I also try to incorperate loss:
>>tcq disc add dev ath0 root netem loss .1%
>>
>>I get:
>>RTNETLINK answers: File exists
>>
>>Is it possible to use two qdiscs on the same interface?
>>
>>
>>
>
>No, but netem is "classful" so you can put xcp inside netem.
>Look at the token bucket example on the wiki.
>
>
>
Sorry, I was looking at the LARTC guide, completely skipped over the
blatently obvious block of commands you were pointing me too :P
Thanks!
George
^ permalink raw reply
* Re: want to randomly drop packets based on percent
From: George Nychis @ 2006-04-17 23:04 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: linux-kernel, netdev
In-Reply-To: <20060417103211.24115952@localhost.localdomain>
Stephen Hemminger wrote:
>O
>
>
>>>>>>I wanted to insert artificial packet loss based on a percent so i found:
>>>>>>network emulab qdisc could do it, so i compiled support into the kernel
>>>>>>and tried:
>>>>>>tc qdisc change dev eth0 root netem loss .1%
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>> ^^^^^^
>>>
>>>You need to do add not change. Add will set the queue discipline
>>>to netem (default is pfifo_fast). Change is for changing netem parameters
>>>after it is loaded.
>>>
>>>
>>>
>>>
>>>
>>bahhh I see... the wiki has "change" instead of add. Now i'm running
>>into another problem, I have an XCP qdisc that I have already added via:
>>tc qdisc add dev ath0 root xcp capacity 54Mbit size 500
>>
>>
>>
>
>Wiki reads as a set of examples. First uses, "add" after that "change".
>
>
>
>
>>therefore when I also try to incorperate loss:
>>tcq disc add dev ath0 root netem loss .1%
>>
>>I get:
>>RTNETLINK answers: File exists
>>
>>Is it possible to use two qdiscs on the same interface?
>>
>>
>>
>
>No, but netem is "classful" so you can put xcp inside netem.
>Look at the token bucket example on the wiki.
>
>
>
Okay I'm slightly confused... I would like to have the traffic traverse
both the XCP qdisc and the netem qdisc... looking through the wiki it
shows me how to classify two sets of traffic, but how do i push all
traffic through both?
^ permalink raw reply
* Fw: [Bugme-new] [Bug 6402] New: KERNEL 2.6.16-rX (Gentoo) && PPPD && SNAT
From: Andrew Morton @ 2006-04-17 22:27 UTC (permalink / raw)
To: netdev; +Cc: slavon, bugme-daemon@kernel-bugs.osdl.org
Begin forwarded message:
Date: Mon, 17 Apr 2006 14:57:03 -0700
From: bugme-daemon@bugzilla.kernel.org
To: bugme-new@lists.osdl.org
Subject: [Bugme-new] [Bug 6402] New: KERNEL 2.6.16-rX (Gentoo) && PPPD && SNAT
http://bugzilla.kernel.org/show_bug.cgi?id=6402
Summary: KERNEL 2.6.16-rX (Gentoo) && PPPD && SNAT
Kernel Version: 2.6.16.ALL
Status: NEW
Severity: high
Owner: shemminger@osdl.org
Submitter: slavon@bigtelecom.ru
After start download file its stop after 4-10 mb and network is down.
Interface ppp0 is UP.
No new dmeseg or debug of syslog
try to ping ppp client:
slavon ~ # ping 192.168.0.2
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
#ifconfig ppp0
ppp0 Link encap:Point-to-Point Protocol
inet addr:192.168.0.1 P-t-P:192.168.0.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1396 Metric:1
RX packets:1648 errors:0 dropped:0 overruns:0 frame:0
TX packets:2407 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:75765 (73.9 Kb) TX bytes:3242633 (3.0 Mb)
#iptables-save
*nat
:PREROUTING ACCEPT [6826:411515]
:POSTROUTING ACCEPT [11117:531811]
:OUTPUT ACCEPT [11118:531895]
-A POSTROUTING -s 192.168.0.0/255.255.255.0 -j SNAT --to-source XXX.XXX.XXX.XXX
COMMIT
slavon ~ # pppd --version
pppd version 2.4.3
slavon ~ # pptpd --version
pptpd v1.3.1
I try it in 3 Computers 2 - x86 and 1 - x86-64 - All have this trouble
its gentoo patches for kernel
* Applying 1000_linux-2.6.16.1.patch (-p0+)
* Applying 1001_linux-2.6.16.2.patch (-p0+)
* Applying 1002_linux-2.6.16.3.patch (-p0+)
* Applying 1003_linux-2.6.16.4.patch (-p0+)
* Applying 1700_sparc-obp64-naming.patch (-p0+)
* Applying 1705_sparc-U1-hme-lockup.patch (-p0+)
* Applying 1710_sparc-sparsemem.patch (-p0+)
* Applying 1715_ppc32-crosscc-ssp.patch (-p0+)
* Applying 2400_sky2-1.1.patch (-p0+)
* Applying 2405_skge-1.5.patch (-p0+)
* Applying 2600_input-mod-devicetable.patch (-p0+)
* Applying 4000_deprecate-sk98lin.patch (-p0+)
* Applying 4100_libata-enable-atapi.patch (-p0+)
* Applying 4105_dm-bbr.patch (-p0+)
* Applying 4110_promise-pdc2037x.patch (-p0+)
* Applying 4200_fbsplash-0.9.2-r5.patch (-p0+)
* Applying 4205_vesafb-tng-1.0-rc1-r3.patch (-p0+)
* Applying 4300_squashfs-3.0.patch (-p0+)
* Applying 4400_speakup-20060103.patch (-p0+)
* Applying 4401_speakup-highlight-tracking-amd64.patch (-p0+)
* Applying 4405_alpha-sysctl-uac.patch (-p0+)
!! In 2.6.15 kernel ALL WORK.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply
* Re: Fw: [Bugme-new] [Bug 6401] New: tg3 hardware address issue
From: Michael Chan @ 2006-04-17 20:21 UTC (permalink / raw)
To: Andrew Morton; +Cc: netdev, zef, bugme-daemon@kernel-bugs.osdl.org
In-Reply-To: <20060417141715.30afbdd8.akpm@osdl.org>
On Mon, 2006-04-17 at 14:17 -0700, Andrew Morton wrote:
> Right now I am using the tg3.c contained in linus's git tree with a 2.6.15
> kernel because this driver version (3.56) seems to be least broken, or atleast
> hides it best.
The reason it hides it best is because the is_valid_ether_addr() is
somewhat broken in 2.6.15. tg3 continues to load despite the invalid MAC
address of ff:ff:ff:ff:ff:ff.
Please send the output of lspci -vvvxxx -s0:3:0.0 and lspci -vvvxxx -
s0:4:0.0. Thanks.
^ permalink raw reply
* Re: fixing sk_stream_rfree()
From: Jesse Brandeburg @ 2006-04-17 21:56 UTC (permalink / raw)
To: Herbert Xu; +Cc: Brandeburg, Jesse, David S. Miller, netdev
In-Reply-To: <20060417214054.GA30730@gondor.apana.org.au>
On Mon, 17 Apr 2006, Herbert Xu wrote:
>
> On Mon, Apr 17, 2006 at 02:09:43PM -0700, Jesse Brandeburg wrote:
> >
> > we explicitly enabled TSO before performing the test.
> > attached bz2 due to size:
>
> Thanks a lot. Are those promiscuous mode messages caused by tcpdump?
> If so could you try it without doing a tcpdump or any other af_packet
> applications?
yes, the promiscuous up/down messages are from tcpdump. We were checking
whether TSO was enabled by looking at the traffic. The interface was NOT
in promiscuous mode while running the test.
> > Let me know if there is anything else I can do,
>
> Since you can reproduce this at will now, please modify one of those
> warning messages to print out the actual value of sk_forward_alloc.
> It can gives a clue. For instance if it happens to be a multiple of
> PAGE_SIZE, then we know it may be related to the reclaim stuff.
will do.
^ permalink raw reply
* Re: fixing sk_stream_rfree()
From: Herbert Xu @ 2006-04-17 21:40 UTC (permalink / raw)
To: Jesse Brandeburg; +Cc: David S. Miller, netdev
In-Reply-To: <Pine.WNT.4.63.0604171405470.3848@jbrandeb-desk.amr.corp.intel.com>
On Mon, Apr 17, 2006 at 02:09:43PM -0700, Jesse Brandeburg wrote:
>
> we explicitly enabled TSO before performing the test.
> attached bz2 due to size:
Thanks a lot. Are those promiscuous mode messages caused by tcpdump?
If so could you try it without doing a tcpdump or any other af_packet
applications?
> Let me know if there is anything else I can do,
Since you can reproduce this at will now, please modify one of those
warning messages to print out the actual value of sk_forward_alloc.
It can gives a clue. For instance if it happens to be a multiple of
PAGE_SIZE, then we know it may be related to the reclaim stuff.
Thanks,
--
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
* Fw: [Bugme-new] [Bug 6401] New: tg3 hardware address issue
From: Andrew Morton @ 2006-04-17 21:17 UTC (permalink / raw)
To: netdev; +Cc: zef, bugme-daemon@kernel-bugs.osdl.org
Begin forwarded message:
Date: Mon, 17 Apr 2006 13:39:47 -0700
From: bugme-daemon@bugzilla.kernel.org
To: bugme-new@lists.osdl.org
Subject: [Bugme-new] [Bug 6401] New: tg3 hardware address issue
http://bugzilla.kernel.org/show_bug.cgi?id=6401
Summary: tg3 hardware address issue
Kernel Version: > 2.6.14
Status: NEW
Severity: normal
Owner: jgarzik@pobox.com
Submitter: zef@cektek.net
Most recent kernel where this bug did not occur: Havent tried anything older
than 2.6.14 and it was also affected.
Distribution: Fedora Core 4
Hardware Environment: Dual Core Opteron on Nforce Professional Mobo
Software Environment: Minimal FC4 Install
Problem Description:
Onboard Broadcom BCM5721 dual port gigabit ethernet (pci express) is not
functioning, have tried reverting all the way back to 2.6.14 based on this
thread suggesting it was not an issue in earlier versions: http://www.spinics.
net/lists/netdev/msg01858.html.
Right now I am using the tg3.c contained in linus's git tree with a 2.6.15
kernel because this driver version (3.56) seems to be least broken, or atleast
hides it best.
dmesg upon loading (modprobe):
tg3.c:v3.56 (Apr 1, 2006)
ACPI: PCI Interrupt 0000:04:00.0[A] -> Link [LNKB] -> GSI 19 (level, low) -> IRQ
50
PCI: Setting latency timer of device 0000:04:00.0 to 64
eth1: Tigon3 [partno(none) rev 4101 PHY(5750)] (PCI Express) 10/100/1000BaseT
Ethernet ff:ff:ff:ff:ff:ff
eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1]
eth1: dma_rwctrl[76180000] dma_mask[64-bit]
ACPI: PCI Interrupt 0000:03:00.0[A] -> Link [LNKA] -> GSI 18 (level, low) -> IRQ
58
PCI: Setting latency timer of device 0000:03:00.0 to 64
eth2: Tigon3 [partno(none) rev 4101 PHY(5750)] (PCI Express) 10/100/1000BaseT
Ethernet ff:ff:ff:ff:ff:ff
eth2: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1]
eth2: dma_rwctrl[76180000] dma_mask[64-bit]
ADDRCONF(NETDEV_UP): eth0: link is not ready
dmesg after `ifconfig eth1 up 192.168.2.122'
tg3: tg3_reset_hw timed out for eth1, firmwared will not restart magic=4b657654
tg3: tg3_reset_hw timed out for eth1, firmwared will not restart magic=4b657654
tg3: tg3_reset_hw timed out for eth1, firmwared will not restart magic=4b657654
tg3: tg3_reset_hw timed out for eth1, firmwared will not restart magic=4b657654
Note: this is my relevant dmesg from any older version of tg3.c I have tried:
PCI: Enabling device 0000:04:00.0
ACPI: PCI Interrupt 0000:04:00.0[A] -> GSI 18 (level, low) -> IRQ 50
tg3: Could not obtain valid ethernet address, aborting.
ACPI: PCI interrupt for device 0000:04:00.0 disabled
tg3: probe of 0000:04:00.0 failed with error -22
Neither of the nic's dual interfaces show up when doing `ifconfig -a' after
this.
Steps to reproduce:
Load module, attempt to bring up interface.
I am willing to grant access to this machine if i can figure out how since it
doesnt really have networking abilities atm.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply
* Re: fixing sk_stream_rfree()
From: Jesse Brandeburg @ 2006-04-17 21:09 UTC (permalink / raw)
To: David S. Miller; +Cc: herbert, netdev, Brandeburg, Jesse
In-Reply-To: <20060417.132904.55913090.davem@davemloft.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 908 bytes --]
On Mon, 17 Apr 2006, David S. Miller wrote:
>
> From: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Mon, 17 Apr 2006 16:17:00 +1000
>
> > On Sun, Apr 16, 2006 at 10:32:03PM -0700, David S. Miller wrote:
> > > So it nearly has to be a send side issue that can only trigger with
> > > TSO enabled, and my next planned chore is to audit the TSO splitting
> > > during ACK processing. We may be doing something stupid there.
> >
> > BTW, do we have a dmesg log from the machine that did this with tg3?
>
> I don't know, Jesse do you have it?
>
> Jesse, my previously lead was a dead end, we're looking into other
> possibilities, so if you have the kernel log from reproducing this
> BUG(!sk_forward_alloc) problem with tg3 it would be very valuable at
> this point.
we explicitly enabled TSO before performing the test.
attached bz2 due to size:
Let me know if there is anything else I can do,
Jesse
[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 6806 bytes --]
^ permalink raw reply
* Re: fixing sk_stream_rfree()
From: David S. Miller @ 2006-04-17 20:29 UTC (permalink / raw)
To: herbert; +Cc: netdev, jesse.brandeburg
In-Reply-To: <20060417061700.GA21709@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Mon, 17 Apr 2006 16:17:00 +1000
> On Sun, Apr 16, 2006 at 10:32:03PM -0700, David S. Miller wrote:
> > So it nearly has to be a send side issue that can only trigger with
> > TSO enabled, and my next planned chore is to audit the TSO splitting
> > during ACK processing. We may be doing something stupid there.
>
> BTW, do we have a dmesg log from the machine that did this with tg3?
I don't know, Jesse do you have it?
Jesse, my previously lead was a dead end, we're looking into other
possibilities, so if you have the kernel log from reproducing this
BUG(!sk_forward_alloc) problem with tg3 it would be very valuable at
this point.
Thanks.
^ permalink raw reply
* Re: fixing sk_stream_rfree()
From: Jesse Brandeburg @ 2006-04-17 20:27 UTC (permalink / raw)
To: Herbert Xu; +Cc: David S. Miller, netdev
In-Reply-To: <20060417061700.GA21709@gondor.apana.org.au>
On 4/16/06, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Sun, Apr 16, 2006 at 10:32:03PM -0700, David S. Miller wrote:
> >
> > Let me save you some time, later in the thread you'll find
> > out that this whole thing is a dead end.
>
> Thanks. I even read the message but managed to miss your conclusion :)
>
> > So it nearly has to be a send side issue that can only trigger with
> > TSO enabled, and my next planned chore is to audit the TSO splitting
> > during ACK processing. We may be doing something stupid there.
>
> BTW, do we have a dmesg log from the machine that did this with tg3?
Unfortunately doesn't seem to be any difference between the failures.
Here were the lines:
2.6.16 kernel
KERNEL: assertion (!sk->sk_forward_alloc) failed at /net/core/stream.c (283)
KERNEL: assertion (!sk->sk_forward_alloc) failed at /net/ipv4/af_inet.c (150)
I'll be glad to test anything to help nail this down. Herbert did you
see that we used tbench (from dbench package) to reproduce this
reliably?
Jesse
^ permalink raw reply
* Re: [1/1] netlink: fix broadcasting to the wrong group.
From: Evgeniy Polyakov @ 2006-04-17 20:21 UTC (permalink / raw)
To: Patrick McHardy; +Cc: David S. Miller, netdev
In-Reply-To: <4443F742.9020508@trash.net>
On Mon, Apr 17, 2006 at 10:14:58PM +0200, Patrick McHardy (kaber@trash.net) wrote:
> Evgeniy Polyakov wrote:
> > On Mon, Apr 17, 2006 at 05:35:04PM +0200, Patrick McHardy (kaber@trash.net) wrote:
> >
> >>This seems to be a misunderstanding, subscribing to groups using bind()
> >>is kept for compatibility and doesn't use group numbers but bitmasks.
> >
> >
> > So groups less than 32 are considered as bitmask, and other groups as
> > group numbers, and there is no way to have them consistent and behave
> > like group numbers?
>
> Not exactly, its not related to the group number. groups used in bind()
> are considered as bitmask and groups used for setsockopt are considered
> as group numbers. We can't change bind() because this behaviour is
> required for compatibility.
So bind and subscribing are almost exclusive and should not be used
simultaneously?
> > But this introduce some problem with subscribing - if one subscribes to
> > group 5 and is bound to the same group it allows to broadcast not only
> > to group 5, and those which have the same bits set, but also to group 16
> > (1<<(5-1)), which has nothing in common with the requested group number.
>
> Only if you use group numbers for bind(), which is plainly wrong.
Even if one uses group bitmask at bind time and later subscribes to
some group from that bitmask, this will introduce wrong behaviour with
unrelated gropus.
Maybe we should not allow to subscribe if group bitmask different from 1
was used at bind() time?
--
Evgeniy Polyakov
^ permalink raw reply
* Re: softmac: semantics of SIOCSIWFREQ
From: Johannes Berg @ 2006-04-17 20:19 UTC (permalink / raw)
To: jt; +Cc: netdev, softmac-dev, Ulrich Kunitz
In-Reply-To: <20060417200139.GA28626@bougret.hpl.hp.com>
[-- Attachment #1: Type: text/plain, Size: 565 bytes --]
On Mon, 2006-04-17 at 13:01 -0700, Jean Tourrilhes wrote:
> Who sent the beacon is different from who created the IBSS. If
> you don't like this proposal, here is another one : if in ad-hoc mode
> the actual IBSS freq is the same as what the user set, then set the
> 'fixed' flag, otherwise report the actual freq without the 'fixed'
> flag.
I don't really see the point of this either.
> Or if you have another meaningful use of the flag in ad-hoc
> mode, just shout.
I don't have any meaningful use for it in ad-hoc mode at all :)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: [1/1] netlink: fix broadcasting to the wrong group.
From: Patrick McHardy @ 2006-04-17 20:14 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: David S. Miller, netdev
In-Reply-To: <20060417194904.GA5237@2ka.mipt.ru>
Evgeniy Polyakov wrote:
> On Mon, Apr 17, 2006 at 05:35:04PM +0200, Patrick McHardy (kaber@trash.net) wrote:
>
>>This seems to be a misunderstanding, subscribing to groups using bind()
>>is kept for compatibility and doesn't use group numbers but bitmasks.
>
>
> So groups less than 32 are considered as bitmask, and other groups as
> group numbers, and there is no way to have them consistent and behave
> like group numbers?
Not exactly, its not related to the group number. groups used in bind()
are considered as bitmask and groups used for setsockopt are considered
as group numbers. We can't change bind() because this behaviour is
required for compatibility.
> But this introduce some problem with subscribing - if one subscribes to
> group 5 and is bound to the same group it allows to broadcast not only
> to group 5, and those which have the same bits set, but also to group 16
> (1<<(5-1)), which has nothing in common with the requested group number.
Only if you use group numbers for bind(), which is plainly wrong.
^ permalink raw reply
* Re: softmac: semantics of SIOCSIWFREQ
From: Jean Tourrilhes @ 2006-04-17 20:01 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, softmac-dev, Ulrich Kunitz
In-Reply-To: <1145302029.4116.14.camel@localhost>
On Mon, Apr 17, 2006 at 09:27:09PM +0200, Johannes Berg wrote:
> On Mon, 2006-04-17 at 12:06 -0700, Jean Tourrilhes wrote:
>
> > Definitely. I was just pointing out that scanning behaviour is
> > not dictated by current setting of the drivers (except when the
> > hardware does it, cf. Ornoco).
>
> Yeah, I was just repeating it for Ulrich :)
>
> > For freq, it's simpler. In managed mode, it's never 'fixed',
> > because the card/driver choose the frequency. In master mode, it's
> > almost always 'fixed', because the user has to set the frequency. In
> > ad-hoc mode, it depend in the node creates or not the IBSS.
>
> But isn't that a detail the user shouldn't have to know? See, if a node
> with a higher TSF joins the IBSS, then it gets to send out the beacons
> for it, IIRC.
Who sent the beacon is different from who created the IBSS. If
you don't like this proposal, here is another one : if in ad-hoc mode
the actual IBSS freq is the same as what the user set, then set the
'fixed' flag, otherwise report the actual freq without the 'fixed'
flag.
Or if you have another meaningful use of the flag in ad-hoc
mode, just shout.
> johannes
Jean
^ permalink raw reply
* Re: [1/1] netlink: fix broadcasting to the wrong group.
From: Evgeniy Polyakov @ 2006-04-17 19:49 UTC (permalink / raw)
To: Patrick McHardy; +Cc: David S. Miller, netdev
In-Reply-To: <4443B5A8.9010604@trash.net>
On Mon, Apr 17, 2006 at 05:35:04PM +0200, Patrick McHardy (kaber@trash.net) wrote:
> This seems to be a misunderstanding, subscribing to groups using bind()
> is kept for compatibility and doesn't use group numbers but bitmasks.
So groups less than 32 are considered as bitmask, and other groups as
group numbers, and there is no way to have them consistent and behave
like group numbers?
But this introduce some problem with subscribing - if one subscribes to
group 5 and is bound to the same group it allows to broadcast not only
to group 5, and those which have the same bits set, but also to group 16
(1<<(5-1)), which has nothing in common with the requested group number.
--
Evgeniy Polyakov
^ permalink raw reply
* [PATCH] softmac: suggest per-frame-type TX rate
From: Daniel Drake @ 2006-04-17 19:33 UTC (permalink / raw)
To: linville; +Cc: johannes, netdev, softmac-dev, kune, sam
This patch is the first step towards rate control inside softmac.
The txrates substructure has been extended to provide different fields for
different types of packets (management/data, unicast/multicast). These fields
are updated on association to values compatible with the access point we are
associating to.
Drivers can then use the new ieee80211softmac_suggest_txrate() function call
when deciding which rate to transmit each frame at. This is immensely useful
for ZD1211, and bcm can use it too.
The user can still specify a rate through iwconfig, which is matched for all
transmissions (assuming the rate they have specified is in the rate set
required by the AP).
At a later date, we can incorporate automatic rate management into the
ieee80211softmac_recalc_txrates() function.
This patch also removes the mcast_fallback field. Sam Leffler pointed out that
this field is meaningless, because no driver will ever be retransmitting mcast
frames (they are not acked).
Signed-off-by: Daniel Drake <dsd@gentoo.org>
--- linux/include/net/ieee80211softmac.h.orig 2006-04-16 23:37:32.000000000 +0100
+++ linux/include/net/ieee80211softmac.h 2006-04-17 20:19:15.000000000 +0100
@@ -86,6 +86,9 @@ struct ieee80211softmac_assoc_info {
/* BSSID we're trying to associate to */
char bssid[ETH_ALEN];
+
+ /* Rates supported by the network */
+ struct ieee80211softmac_ratesinfo supported_rates;
/* some flags.
* static_essid is valid if the essid is constant,
@@ -129,23 +132,26 @@ enum {
struct ieee80211softmac_txrates {
/* The Bit-Rate to be used for multicast frames. */
u8 mcast_rate;
- /* The Bit-Rate to be used for multicast fallback
- * (If the device supports fallback and hardware-retry)
- */
- u8 mcast_fallback;
+
+ /* The Bit-Rate to be used for multicast management frames. */
+ u8 mgt_mcast_rate;
+
/* The Bit-Rate to be used for any other (normal) data packet. */
u8 default_rate;
/* The Bit-Rate to be used for default fallback
* (If the device supports fallback and hardware-retry)
*/
u8 default_fallback;
+
+ /* This is the rate that the user asked for */
+ u8 user_rate;
};
/* Bits for txrates_change callback. */
#define IEEE80211SOFTMAC_TXRATECHG_DEFAULT (1 << 0) /* default_rate */
#define IEEE80211SOFTMAC_TXRATECHG_DEFAULT_FBACK (1 << 1) /* default_fallback */
#define IEEE80211SOFTMAC_TXRATECHG_MCAST (1 << 2) /* mcast_rate */
-#define IEEE80211SOFTMAC_TXRATECHG_MCAST_FBACK (1 << 3) /* mcast_fallback */
+#define IEEE80211SOFTMAC_TXRATECHG_MGT_MCAST (1 << 3) /* mgt_mcast_rate */
struct ieee80211softmac_device {
/* 802.11 structure for data stuff */
@@ -246,6 +252,28 @@ extern void ieee80211softmac_fragment_lo
* Note that the rates need to be sorted. */
extern void ieee80211softmac_set_rates(struct net_device *dev, u8 count, u8 *rates);
+/* Helper function which advises you the rate at which a frame should be
+ * transmitted at. */
+static inline u8 ieee80211softmac_suggest_txrate(struct ieee80211softmac_device *mac,
+ int is_multicast,
+ int is_mgt)
+{
+ struct ieee80211softmac_txrates *txrates = &mac->txrates;
+
+ if (!mac->associated)
+ return txrates->mgt_mcast_rate;
+
+ /* We are associated, sending unicast frame */
+ if (!is_multicast)
+ return txrates->default_rate;
+
+ /* We are associated, sending multicast frame */
+ if (is_mgt)
+ return txrates->mgt_mcast_rate;
+ else
+ return txrates->mcast_rate;
+}
+
/* Start the SoftMAC. Call this after you initialized the device
* and it is ready to run.
*/
--- linux/net/ieee80211/softmac/ieee80211softmac_assoc.c.orig 2006-04-16 23:55:23.000000000 +0100
+++ linux/net/ieee80211/softmac/ieee80211softmac_assoc.c 2006-04-17 17:17:59.000000000 +0100
@@ -101,30 +101,22 @@ ieee80211softmac_disassoc(struct ieee802
/* Do NOT clear bssvalid as that will break ieee80211softmac_assoc_work! */
mac->associated = 0;
mac->associnfo.associating = 0;
+ ieee80211softmac_init_txrates(mac);
spin_unlock_irqrestore(&mac->lock, flags);
}
static inline int
we_support_all_basic_rates(struct ieee80211softmac_device *mac, u8 *from, u8 from_len)
{
- int idx, search, found;
- u8 rate, search_rate;
+ int idx;
+ u8 rate;
for (idx = 0; idx < (from_len); idx++) {
rate = (from)[idx];
if (!(rate & IEEE80211_BASIC_RATE_MASK))
continue;
- found = 0;
rate &= ~IEEE80211_BASIC_RATE_MASK;
- for (search = 0; search < mac->ratesinfo.count; search++) {
- search_rate = mac->ratesinfo.rates[search];
- search_rate &= ~IEEE80211_BASIC_RATE_MASK;
- if (rate == search_rate) {
- found = 1;
- break;
- }
- }
- if (!found)
+ if (!ieee80211softmac_ratesinfo_rate_supported(&mac->ratesinfo, rate))
return 0;
}
return 1;
@@ -283,6 +275,9 @@ ieee80211softmac_associated(struct ieee8
struct ieee80211softmac_network *net)
{
mac->associnfo.associating = 0;
+ mac->associnfo.supported_rates = net->supported_rates;
+ ieee80211softmac_recalc_txrates(mac);
+
mac->associated = 1;
if (mac->set_bssid_filter)
mac->set_bssid_filter(mac->dev, net->bssid);
@@ -373,6 +368,7 @@ ieee80211softmac_handle_disassoc(struct
spin_lock_irqsave(&mac->lock, flags);
mac->associnfo.bssvalid = 0;
mac->associated = 0;
+ ieee80211softmac_init_txrates(mac);
schedule_work(&mac->associnfo.work);
spin_unlock_irqrestore(&mac->lock, flags);
--- linux/net/ieee80211/softmac/ieee80211softmac_module.c.orig 2006-04-17 01:04:42.000000000 +0100
+++ linux/net/ieee80211/softmac/ieee80211softmac_module.c 2006-04-17 20:21:11.000000000 +0100
@@ -26,6 +26,7 @@
#include "ieee80211softmac_priv.h"
#include <linux/sort.h>
+#include <linux/etherdevice.h>
struct net_device *alloc_ieee80211softmac(int sizeof_priv)
{
@@ -59,14 +60,6 @@ struct net_device *alloc_ieee80211softma
softmac->wait_for_scan = ieee80211softmac_wait_for_scan_implementation;
softmac->stop_scan = ieee80211softmac_stop_scan_implementation;
- //TODO: The mcast rate has to be assigned dynamically somewhere (in scanning, association. Not sure...)
- // It has to be set to the highest rate all stations in the current network can handle.
- softmac->txrates.mcast_rate = IEEE80211_CCK_RATE_1MB;
- softmac->txrates.mcast_fallback = IEEE80211_CCK_RATE_1MB;
- /* This is reassigned in ieee80211softmac_start to sane values. */
- softmac->txrates.default_rate = IEEE80211_CCK_RATE_1MB;
- softmac->txrates.default_fallback = IEEE80211_CCK_RATE_1MB;
-
/* to start with, we can't send anything ... */
netif_carrier_off(dev);
@@ -166,15 +159,82 @@ static void ieee80211softmac_start_check
}
}
-void ieee80211softmac_start(struct net_device *dev)
+int ieee80211softmac_ratesinfo_rate_supported(struct ieee80211softmac_ratesinfo *ri, u8 rate)
+{
+ int search;
+ u8 search_rate;
+
+ for (search = 0; search < ri->count; search++) {
+ search_rate = ri->rates[search];
+ search_rate &= ~IEEE80211_BASIC_RATE_MASK;
+ if (rate == search_rate)
+ return 1;
+ }
+
+ return 0;
+}
+
+/* Finds the highest rate which is:
+ * 1. Present in ri (optionally a basic rate)
+ * 2. Supported by the device
+ * 3. Less than or equal to the user-defined rate
+ */
+static u8 highest_supported_rate(struct ieee80211softmac_device *mac,
+ struct ieee80211softmac_ratesinfo *ri, int basic_only)
+{
+ u8 user_rate = mac->txrates.user_rate;
+ int i;
+
+ if (ri->count == 0) {
+ dprintk(KERN_ERROR PFX "empty ratesinfo?n");
+ return IEEE80211_CCK_RATE_1MB;
+ }
+
+ for (i = ri->count - 1; i >= 0; i--) {
+ u8 rate = ri->rates[i];
+ if (basic_only && !(rate & IEEE80211_BASIC_RATE_MASK))
+ continue;
+ rate &= ~IEEE80211_BASIC_RATE_MASK;
+ if (rate > user_rate)
+ continue;
+ if (ieee80211softmac_ratesinfo_rate_supported(&mac->ratesinfo, rate))
+ return rate;
+ }
+
+ /* If we haven't found a suitable rate by now, just trust the user */
+ return user_rate;
+}
+
+void ieee80211softmac_recalc_txrates(struct ieee80211softmac_device *mac)
+{
+ struct ieee80211softmac_txrates *txrates = &mac->txrates;
+ struct ieee80211softmac_txrates oldrates;
+ u32 change = 0;
+
+ if (mac->txrates_change)
+ oldrates = mac->txrates;
+
+ change |= IEEE80211SOFTMAC_TXRATECHG_DEFAULT;
+ txrates->default_rate = highest_supported_rate(mac, &mac->associnfo.supported_rates, 0);
+
+ change |= IEEE80211SOFTMAC_TXRATECHG_DEFAULT_FBACK;
+ txrates->default_fallback = lower_rate(mac, txrates->default_rate);
+
+ change |= IEEE80211SOFTMAC_TXRATECHG_MCAST;
+ txrates->mcast_rate = highest_supported_rate(mac, &mac->associnfo.supported_rates, 1);
+
+ if (mac->txrates_change)
+ mac->txrates_change(mac->dev, change, &oldrates);
+
+}
+
+void ieee80211softmac_init_txrates(struct ieee80211softmac_device *mac)
{
- struct ieee80211softmac_device *mac = ieee80211_priv(dev);
struct ieee80211_device *ieee = mac->ieee;
u32 change = 0;
+ struct ieee80211softmac_txrates *txrates = &mac->txrates;
struct ieee80211softmac_txrates oldrates;
- ieee80211softmac_start_check_rates(mac);
-
/* TODO: We need some kind of state machine to lower the default rates
* if we loose too many packets.
*/
@@ -189,19 +249,34 @@ void ieee80211softmac_start(struct net_d
more reliable. Note similar logic in
ieee80211softmac_wx_set_rate() */
if (ieee->modulation & IEEE80211_CCK_MODULATION) {
- mac->txrates.default_rate = IEEE80211_CCK_RATE_11MB;
- change |= IEEE80211SOFTMAC_TXRATECHG_DEFAULT;
- mac->txrates.default_fallback = IEEE80211_CCK_RATE_5MB;
- change |= IEEE80211SOFTMAC_TXRATECHG_DEFAULT_FBACK;
+ txrates->user_rate = IEEE80211_CCK_RATE_11MB;
} else if (ieee->modulation & IEEE80211_OFDM_MODULATION) {
- mac->txrates.default_rate = IEEE80211_OFDM_RATE_54MB;
- change |= IEEE80211SOFTMAC_TXRATECHG_DEFAULT;
- mac->txrates.default_fallback = IEEE80211_OFDM_RATE_24MB;
- change |= IEEE80211SOFTMAC_TXRATECHG_DEFAULT_FBACK;
+ txrates->user_rate = IEEE80211_OFDM_RATE_54MB;
} else
assert(0);
+
+ txrates->default_rate = IEEE80211_CCK_RATE_1MB;
+ change |= IEEE80211SOFTMAC_TXRATECHG_DEFAULT;
+
+ txrates->default_fallback = IEEE80211_CCK_RATE_1MB;
+ change |= IEEE80211SOFTMAC_TXRATECHG_DEFAULT_FBACK;
+
+ txrates->mcast_rate = IEEE80211_CCK_RATE_1MB;
+ change |= IEEE80211SOFTMAC_TXRATECHG_MCAST;
+
+ txrates->mgt_mcast_rate = IEEE80211_CCK_RATE_1MB;
+ change |= IEEE80211SOFTMAC_TXRATECHG_MGT_MCAST;
+
if (mac->txrates_change)
- mac->txrates_change(dev, change, &oldrates);
+ mac->txrates_change(mac->dev, change, &oldrates);
+}
+
+void ieee80211softmac_start(struct net_device *dev)
+{
+ struct ieee80211softmac_device *mac = ieee80211_priv(dev);
+
+ ieee80211softmac_start_check_rates(mac);
+ ieee80211softmac_init_txrates(mac);
}
EXPORT_SYMBOL_GPL(ieee80211softmac_start);
--- linux/net/ieee80211/softmac/ieee80211softmac_wx.c.orig 2006-04-17 16:45:51.000000000 +0100
+++ linux/net/ieee80211/softmac/ieee80211softmac_wx.c 2006-04-17 20:17:37.000000000 +0100
@@ -201,8 +201,8 @@ ieee80211softmac_wx_set_rate(struct net_
if (is_ofdm && !(ieee->modulation & IEEE80211_OFDM_MODULATION))
goto out_unlock;
- mac->txrates.default_rate = rate;
- mac->txrates.default_fallback = lower_rate(mac, rate);
+ mac->txrates.user_rate = rate;
+ ieee80211softmac_recalc_txrates(mac);
err = 0;
out_unlock:
--- linux/net/ieee80211/softmac/ieee80211softmac_priv.h.orig 2006-04-17 16:46:09.000000000 +0100
+++ linux/net/ieee80211/softmac/ieee80211softmac_priv.h 2006-04-17 17:09:08.000000000 +0100
@@ -116,7 +116,10 @@ ieee80211softmac_get_network_by_essid(st
struct ieee80211softmac_essid *essid);
/* Rates related */
+int ieee80211softmac_ratesinfo_rate_supported(struct ieee80211softmac_ratesinfo *ri, u8 rate);
u8 ieee80211softmac_lower_rate_delta(struct ieee80211softmac_device *mac, u8 rate, int delta);
+void ieee80211softmac_init_txrates(struct ieee80211softmac_device *mac);
+void ieee80211softmac_recalc_txrates(struct ieee80211softmac_device *mac);
static inline u8 lower_rate(struct ieee80211softmac_device *mac, u8 rate) {
return ieee80211softmac_lower_rate_delta(mac, rate, 1);
}
^ 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