Hi,
i today tried the in tree rt2x00 driver the first time and it immediatly
felt a little sluggish. It sometimes feels a little as the driver is
actually not using interrupts but rather polls at HZ rate or something.
I can actually see the device generating interrupts in /proc/interrupts
but still.
Machine is a 2Ghz P4 with an PCI Ralink RT2500:
0000:01:02.0 Network controller: RaLink Ralink RT2500 802.11 Cardbus Reference Card (rev 01)
Subsystem: SiteCom Europe BV: Unknown device 9073
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32, Cache Line Size: 0x20 (128 bytes)
Interrupt: pin A routed to IRQ 18
Region 0: Memory at dfdfe000 (32-bit, non-prefetchable) [size=8K]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Kernel is current git ecd744eec3aa8bbc949ec04ed3fbf7ecb2958a0e.
NonTickless, HZ is 1000, HiresTimes enabled, no CPUFREQ
While running an "find /" via ssh the output comes in and a second terminal shows this:
64 bytes from heisenberg.domain (192.168.251.215): icmp_seq=7 ttl=64 time=3.02 ms
64 bytes from heisenberg.domain (192.168.251.215): icmp_seq=8 ttl=64 time=3.01 ms
64 bytes from heisenberg.domain (192.168.251.215): icmp_seq=9 ttl=64 time=2.87 ms
64 bytes from heisenberg.domain (192.168.251.215): icmp_seq=10 ttl=64 time=2.90 ms
64 bytes from heisenberg.domain (192.168.251.215): icmp_seq=11 ttl=64 time=46.5 ms
64 bytes from heisenberg.domain (192.168.251.215): icmp_seq=12 ttl=64 time=2.86 ms
64 bytes from heisenberg.domain (192.168.251.215): icmp_seq=13 ttl=64 time=13675 ms
64 bytes from heisenberg.domain (192.168.251.215): icmp_seq=14 ttl=64 time=12749 ms
64 bytes from heisenberg.domain (192.168.251.215): icmp_seq=15 ttl=64 time=11853 ms
64 bytes from heisenberg.domain (192.168.251.215): icmp_seq=16 ttl=64 time=10949 ms
64 bytes from heisenberg.domain (192.168.251.215): icmp_seq=17 ttl=64 time=10024 ms
64 bytes from heisenberg.domain (192.168.251.215): icmp_seq=18 ttl=64 time=9095 ms
64 bytes from heisenberg.domain (192.168.251.215): icmp_seq=19 ttl=64 time=8161 ms
64 bytes from heisenberg.domain (192.168.251.215): icmp_seq=20 ttl=64 time=7620 ms
64 bytes from heisenberg.domain (192.168.251.215): icmp_seq=21 ttl=64 time=6694 ms
64 bytes from heisenberg.domain (192.168.251.215): icmp_seq=22 ttl=64 time=5753 ms
64 bytes from heisenberg.domain (192.168.251.215): icmp_seq=23 ttl=64 time=4830 ms
64 bytes from heisenberg.domain (192.168.251.215): icmp_seq=24 ttl=64 time=3893 ms
64 bytes from heisenberg.domain (192.168.251.215): icmp_seq=25 ttl=64 time=2962 ms
64 bytes from heisenberg.domain (192.168.251.215): icmp_seq=26 ttl=64 time=2070 ms
64 bytes from heisenberg.domain (192.168.251.215): icmp_seq=27 ttl=64 time=1342 ms
64 bytes from heisenberg.domain (192.168.251.215): icmp_seq=28 ttl=64 time=423 ms
64 bytes from heisenberg.domain (192.168.251.215): icmp_seq=29 ttl=64 time=2.89 ms
64 bytes from heisenberg.domain (192.168.251.215): icmp_seq=30 ttl=64 time=2.89 ms
Flo
--
Florian Lohoff [email protected] +49-171-2280134
Those who would give up a little freedom to get a little
security shall soon have neither - Benjamin Franklin
On Wed, 2007-11-14 at 21:40 -0500, Will Dyson wrote:
> On Nov 14, 2007 4:13 PM, John W. Linville <[email protected]> wrote:
>
> > > http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/ivd/rt2x00.git;a=commit;h=d37cabfb5f60a3bb56585a74fd3f140ba2960fe0
> > >
> > > The patch is in the wireless-2.6/everything tree, but not Linus's tree.
> >
> > Most of the patch seems like a no-op, except this bit:
> >
> > if (is_rts_frame(frame_control) || is_cts_frame(frame_control)) {
> > __set_bit(ENTRY_TXD_BURST, &desc.flags);
> > - if (is_rts_frame(frame_control))
> > + if (is_rts_frame(frame_control)) {
> > __set_bit(ENTRY_TXD_RTS_FRAME, &desc.flags);
> > + __set_bit(ENTRY_TXD_ACK, &desc.flags);
> > + } else
> > + __clear_bit(ENTRY_TXD_ACK, &desc.flags);
> > if (control->rts_cts_rate)
> > tx_rate = control->rts_cts_rate;
> > }
> >
> > Is this correct? I'm not sure about the actual meaning of TXD_W0_ACK
> > (which keys off ENTRY_TXD_ACK)...
>
> Adding Mattias (the patch's author), Ivo and the rt2x00 list to the CC.
>
> TXD_W0_ACK seems to mean that the firmware should expect an ack for
> the packet represented by that tx descriptor. That is how it is being
> used (and looking at the vendor driver confirms it).
Correct.
>
> The rest of the patch moves the logic for setting this bit (or not) to
> a central location, so that the interesting bit is not repeated in
> each chip-specific driver file.
Not quite. Thing is that we only have one ieee80211_tx_control
structure, which we received from mac80211 for the original frame. Some
parameters, e.g. the transmission queue are valid for both the
rts/cts-to-self frame and the data frame. So we use the same control
structure when setting up both frames. Before the patch, the driver
incorrectly assumed that the IEEE80211_TXCTL_NO_ACK flag determines
whether to expect an ACK, which is simply incorrect for rts/cts frames.
>
> Although now that I really look at the patch, I wonder why the
> IEEE80211_TXCTL_NO_ACK bit is not already set correctly for RTS and
> CTS-to-self frames. It doesn't look like any other driver does this
> kind of calculation, so perhaps the problem solved by this patch is
> also present elsewhere?
>
That depends on how the driver/hardware generates rts/cts-to-self
frames. One way to clean this up would be to change mac80211 to generate
a new tx control structure in ieee80211_ctstoself_get and
ieee80211_rts_get for the rts/cts-to-self frame. But IMHO that's just
adding overhead.
Mattias
On Nov 11, 2007 5:23 AM, Florian Lohoff <[email protected]> wrote:
>
> Hi,
> i today tried the in tree rt2x00 driver the first time and it immediatly
> felt a little sluggish. It sometimes feels a little as the driver is
> actually not using interrupts but rather polls at HZ rate or something.
> I can actually see the device generating interrupts in /proc/interrupts
> but still.
>
> Machine is a 2Ghz P4 with an PCI Ralink RT2500:
> While running an "find /" via ssh the output comes in and a second terminal shows this:
That is some pretty nasty latency. You didn't describe the setup for
your test, so I don't really have any insight into this problem. You
might want to check the wireless bitrate using the "iwconfig" command.
If the bitrate is really low, then the network latency problem is
explained. When the bitrate is low, it is much easier for a single
stream to saturate the connection (making for bad latency).
The output of "iwconfig" and "dmesg | grep rt2x00" would really help
in debugging this issue.
--
Will Dyson
On Thursday 15 November 2007, Mattias Nissler wrote:
>
> On Wed, 2007-11-14 at 21:40 -0500, Will Dyson wrote:
> > On Nov 14, 2007 4:13 PM, John W. Linville <[email protected]> wrote:
> >
> > > > http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/ivd/rt2x00.git;a=commit;h=d37cabfb5f60a3bb56585a74fd3f140ba2960fe0
> > > >
> > > > The patch is in the wireless-2.6/everything tree, but not Linus's tree.
> > >
> > > Most of the patch seems like a no-op, except this bit:
> > >
> > > if (is_rts_frame(frame_control) || is_cts_frame(frame_control)) {
> > > __set_bit(ENTRY_TXD_BURST, &desc.flags);
> > > - if (is_rts_frame(frame_control))
> > > + if (is_rts_frame(frame_control)) {
> > > __set_bit(ENTRY_TXD_RTS_FRAME, &desc.flags);
> > > + __set_bit(ENTRY_TXD_ACK, &desc.flags);
> > > + } else
> > > + __clear_bit(ENTRY_TXD_ACK, &desc.flags);
> > > if (control->rts_cts_rate)
> > > tx_rate = control->rts_cts_rate;
> > > }
> > >
> > > Is this correct? I'm not sure about the actual meaning of TXD_W0_ACK
> > > (which keys off ENTRY_TXD_ACK)...
> >
> > Adding Mattias (the patch's author), Ivo and the rt2x00 list to the CC.
> >
> > TXD_W0_ACK seems to mean that the firmware should expect an ack for
> > the packet represented by that tx descriptor. That is how it is being
> > used (and looking at the vendor driver confirms it).
>
> Correct.
>
> >
> > The rest of the patch moves the logic for setting this bit (or not) to
> > a central location, so that the interesting bit is not repeated in
> > each chip-specific driver file.
>
> Not quite. Thing is that we only have one ieee80211_tx_control
> structure, which we received from mac80211 for the original frame. Some
> parameters, e.g. the transmission queue are valid for both the
> rts/cts-to-self frame and the data frame. So we use the same control
> structure when setting up both frames. Before the patch, the driver
> incorrectly assumed that the IEEE80211_TXCTL_NO_ACK flag determines
> whether to expect an ACK, which is simply incorrect for rts/cts frames.
Perhaps we should test if clearing the ENTRY_TXD_ACK unconditionally
for cts and rts frames would help. (patch located at the bottom).
In fact I wonder if clearing that flag would fix the rt61pci to run txdone
for all frames (opposed to skipping an occasional entry).
> > Although now that I really look at the patch, I wonder why the
> > IEEE80211_TXCTL_NO_ACK bit is not already set correctly for RTS and
> > CTS-to-self frames. It doesn't look like any other driver does this
> > kind of calculation, so perhaps the problem solved by this patch is
> > also present elsewhere?
> >
>
> That depends on how the driver/hardware generates rts/cts-to-self
> frames. One way to clean this up would be to change mac80211 to generate
> a new tx control structure in ieee80211_ctstoself_get and
> ieee80211_rts_get for the rts/cts-to-self frame. But IMHO that's just
> adding overhead.
Agreed, we should use the same tx_control structure, and just check what flags
apply to rts and cts frames.
Ivo
---
diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c b/drivers/net/wireless/rt2x00/rt2x00dev.c
index 3ab1fb9..2e3e822 100644
--- a/drivers/net/wireless/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
@@ -639,11 +639,11 @@ void rt2x00lib_write_tx_desc(struct rt2x00_dev *rt2x00dev,
*/
if (is_rts_frame(frame_control) || is_cts_frame(frame_control)) {
__set_bit(ENTRY_TXD_BURST, &desc.flags);
- if (is_rts_frame(frame_control)) {
+ __clear_bit(ENTRY_TXD_ACK, &desc.flags);
+
+ if (is_rts_frame(frame_control))
__set_bit(ENTRY_TXD_RTS_FRAME, &desc.flags);
- __set_bit(ENTRY_TXD_ACK, &desc.flags);
- } else
- __clear_bit(ENTRY_TXD_ACK, &desc.flags);
+
if (control->rts_cts_rate)
tx_rate = control->rts_cts_rate;
}
Hi,
> > Perhaps we should test if clearing the ENTRY_TXD_ACK unconditionally
> > for cts and rts frames would help. (patch located at the bottom).
> > In fact I wonder if clearing that flag would fix the rt61pci to run txdone
> > for all frames (opposed to skipping an occasional entry).
>
> Hm, I would think we actually should *set* the flag for rts frames,
> cause we expected them to be acked by cts, right? IIRC, this actually is
> what the legacy driver does.
True we expect them to be acked, but we also set the RTS flag which
*could* mean that setting that flag tells the device to wait for the cts response.
So perhaps it is worth a shot to see if not setting the ACK flag actually
helps in the responsiveness.
> Concerning the rt61 problem, I've done an experiment: I changed the
> code to drop out of the interrupt handler on every second interrupt
> without doing anything. That way, the driver doesn't execute the txdone
> logic for some txdone interrupts. This change triggered the missing tx
> report messages. So the rt61 hardware probably proceeds to the next
> entry after the interrupt is handled by the host. Question now is
> whether it is possible that we actually miss an interrupt? This would be
> an explanation for the missing tx status reports. I plan to have a
> closer look at interrupt handling in the kernel to see whether I can
> find something.
Ivo
On Wed, Nov 14, 2007 at 01:57:52PM -0500, Will Dyson wrote:
> On Nov 14, 2007 10:33 AM, Florian Lohoff <[email protected]> wrote:
>
> > Did you actually try setting the rate manually? I just tried
> > when i came home from work. I set it to 36MBit/s and it actually
> > works ... I am now transferring with 2.5MByte/s instead of 30Kbyte/s
> >
> > So i guess the auto rate selection is broken ... Or 1 MBit/s is default
> > or something ...
>
> Ah, that is probably this isssue:
>
> http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/ivd/rt2x00.git;a=commit;h=d37cabfb5f60a3bb56585a74fd3f140ba2960fe0
>
> The patch is in the wireless-2.6/everything tree, but not Linus's tree.
Most of the patch seems like a no-op, except this bit:
if (is_rts_frame(frame_control) || is_cts_frame(frame_control)) {
__set_bit(ENTRY_TXD_BURST, &desc.flags);
- if (is_rts_frame(frame_control))
+ if (is_rts_frame(frame_control)) {
__set_bit(ENTRY_TXD_RTS_FRAME, &desc.flags);
+ __set_bit(ENTRY_TXD_ACK, &desc.flags);
+ } else
+ __clear_bit(ENTRY_TXD_ACK, &desc.flags);
if (control->rts_cts_rate)
tx_rate = control->rts_cts_rate;
}
Is this correct? I'm not sure about the actual meaning of TXD_W0_ACK
(which keys off ENTRY_TXD_ACK)...
John
--
John W. Linville
[email protected]
On Thu, 2007-11-15 at 20:58 +0100, Ivo van Doorn wrote:
>
> Perhaps we should test if clearing the ENTRY_TXD_ACK unconditionally
> for cts and rts frames would help. (patch located at the bottom).
> In fact I wonder if clearing that flag would fix the rt61pci to run txdone
> for all frames (opposed to skipping an occasional entry).
Hm, I would think we actually should *set* the flag for rts frames,
cause we expected them to be acked by cts, right? IIRC, this actually is
what the legacy driver does.
Concerning the rt61 problem, I've done an experiment: I changed the
code to drop out of the interrupt handler on every second interrupt
without doing anything. That way, the driver doesn't execute the txdone
logic for some txdone interrupts. This change triggered the missing tx
report messages. So the rt61 hardware probably proceeds to the next
entry after the interrupt is handled by the host. Question now is
whether it is possible that we actually miss an interrupt? This would be
an explanation for the missing tx status reports. I plan to have a
closer look at interrupt handling in the kernel to see whether I can
find something.
Mattias
On Wed, Nov 14, 2007 at 09:58:44AM +0100, Marcus Better wrote:
> Florian Lohoff wrote:
> > You are right - its caused by a VERY low bitrate:
>
> Looks similar to the problem I have:
>
> http://permalink.gmane.org/gmane.linux.kernel.wireless.general/6830
> http://bugzilla.kernel.org/show_bug.cgi?id=9273
As you mention a quite young tree (2.6.23-rc3) - did you try bisecting
it on the wireless-dev tree?
It sound like the exact same problem i am seeing ...
Flo
--
Florian Lohoff [email protected] +49-171-2280134
Those who would give up a little freedom to get a little
security shall soon have neither - Benjamin Franklin
Florian Lohoff wrote:
> You are right - its caused by a VERY low bitrate:
Looks similar to the problem I have:
http://permalink.gmane.org/gmane.linux.kernel.wireless.general/6830
http://bugzilla.kernel.org/show_bug.cgi?id=9273
Marcus
Florian Lohoff skrev:
> As you mention a quite young tree (2.6.23-rc3) - did you try bisecting
> it on the wireless-dev tree?
I don't think that's possible since the tree was rebased.
Marcus
On Wed, Nov 14, 2007 at 01:19:16PM +0100, Marcus Better wrote:
> Florian Lohoff skrev:
> >As you mention a quite young tree (2.6.23-rc3) - did you try bisecting
> >it on the wireless-dev tree?
>
> I don't think that's possible since the tree was rebased.
You can try using the wireless-legacy tree, specifically the
wireless-dev-2007-09-24 branch.
John
--
John W. Linville
[email protected]
Florian Lohoff wrote:
> Did you actually try setting the rate manually? I just tried
> when i came home from work. I set it to 36MBit/s and it actually
> works ...
Yes, it works for me too. I can't believe I didn't try this before.
Marcus
On Nov 14, 2007 10:33 AM, Florian Lohoff <[email protected]> wrote:
> Did you actually try setting the rate manually? I just tried
> when i came home from work. I set it to 36MBit/s and it actually
> works ... I am now transferring with 2.5MByte/s instead of 30Kbyte/s
>
> So i guess the auto rate selection is broken ... Or 1 MBit/s is default
> or something ...
Ah, that is probably this isssue:
http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/ivd/rt2x00.git;a=commit;h=d37cabfb5f60a3bb56585a74fd3f140ba2960fe0
The patch is in the wireless-2.6/everything tree, but not Linus's tree.
--
Will Dyson
On Nov 14, 2007 4:13 PM, John W. Linville <[email protected]> wrote:
> > http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/ivd/rt2x00.git;a=commit;h=d37cabfb5f60a3bb56585a74fd3f140ba2960fe0
> >
> > The patch is in the wireless-2.6/everything tree, but not Linus's tree.
>
> Most of the patch seems like a no-op, except this bit:
>
> if (is_rts_frame(frame_control) || is_cts_frame(frame_control)) {
> __set_bit(ENTRY_TXD_BURST, &desc.flags);
> - if (is_rts_frame(frame_control))
> + if (is_rts_frame(frame_control)) {
> __set_bit(ENTRY_TXD_RTS_FRAME, &desc.flags);
> + __set_bit(ENTRY_TXD_ACK, &desc.flags);
> + } else
> + __clear_bit(ENTRY_TXD_ACK, &desc.flags);
> if (control->rts_cts_rate)
> tx_rate = control->rts_cts_rate;
> }
>
> Is this correct? I'm not sure about the actual meaning of TXD_W0_ACK
> (which keys off ENTRY_TXD_ACK)...
Adding Mattias (the patch's author), Ivo and the rt2x00 list to the CC.
TXD_W0_ACK seems to mean that the firmware should expect an ack for
the packet represented by that tx descriptor. That is how it is being
used (and looking at the vendor driver confirms it).
The rest of the patch moves the logic for setting this bit (or not) to
a central location, so that the interesting bit is not repeated in
each chip-specific driver file.
Although now that I really look at the patch, I wonder why the
IEEE80211_TXCTL_NO_ACK bit is not already set correctly for RTS and
CTS-to-self frames. It doesn't look like any other driver does this
kind of calculation, so perhaps the problem solved by this patch is
also present elsewhere?
--
Will Dyson
On Wed, Nov 14, 2007 at 09:58:44AM +0100, Marcus Better wrote:
> Florian Lohoff wrote:
> > You are right - its caused by a VERY low bitrate:
>
> Looks similar to the problem I have:
>
> http://permalink.gmane.org/gmane.linux.kernel.wireless.general/6830
> http://bugzilla.kernel.org/show_bug.cgi?id=9273
Did you actually try setting the rate manually? I just tried
when i came home from work. I set it to 36MBit/s and it actually
works ... I am now transferring with 2.5MByte/s instead of 30Kbyte/s
So i guess the auto rate selection is broken ... Or 1 MBit/s is default
or something ...
Flo
--
Florian Lohoff [email protected] +49-171-2280134
Those who would give up a little freedom to get a little
security shall soon have neither - Benjamin Franklin
On Mon, Nov 12, 2007 at 05:59:25PM -0500, Will Dyson wrote:
> That is some pretty nasty latency. You didn't describe the setup for
> your test, so I don't really have any insight into this problem. You
> might want to check the wireless bitrate using the "iwconfig" command.
>
> If the bitrate is really low, then the network latency problem is
> explained. When the bitrate is low, it is much easier for a single
> stream to saturate the connection (making for bad latency).
>
> The output of "iwconfig" and "dmesg | grep rt2x00" would really help
> in debugging this issue.
You are right - its caused by a VERY low bitrate:
flo@heisenberg:~$ sudo iwconfig ra0
ra0 IEEE 802.11g ESSID:"home.rfc822.org"
Mode:Managed Frequency:2.452 GHz Access Point: 00:0C:41:DE:17:FC
Bit Rate=1 Mb/s Tx-Power=27 dBm
Retry min limit:7 RTS thr:off Fragment thr=2346 B
Encryption key:off
Link Quality=47/100 Signal level=-49 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
This is kind of "interesting" as the machine is just next table
as the Access Point - Direct line of sight - about 2m.
The point is that i didnt experience the same problem
back with 2.6.16.16 and the out-of-tree ralink driver.
Here is the driver i didnt experience the problem with:
flo@heisenberg:~$ sudo modinfo /lib/modules/2.6.16.16-heisenberg/extra/rt2500.ko
filename: /lib/modules/2.6.16.16-heisenberg/extra/rt2500.ko
license: GPL
description: Ralink RT2500 802.11g WLAN driver 1.1.0 BETA3 2005/07/31
author: http://rt2x00.serialmonkey.com
alias: pci:v00001814d00000201sv*sd*bc*sc*i*
depends:
vermagic: 2.6.16.16-heisenberg preempt PENTIUM4 gcc-4.0
parm: debug:Enable level: accepted values: 1 to switch debug on, 0 to switch debug off. (i)
parm: ifname:Network device name (default ra%d) (s)
With 2.6.24-rc2 current git the rt2x00 driver is compiled fixed into
the kernel - No rt2x00 messages but here is what i found:
flo@heisenberg:~$ dmesg | egrep "rt2x00|ra0|phy0"
phy0: Selected rate control algorithm 'simple'
ADDRCONF(NETDEV_UP): ra0: link is not ready
ra0: Initial auth_alg=0
ra0: authenticate with AP 00:0c:41:de:17:fc
ra0: RX authentication from 00:0c:41:de:17:fc (alg=0 transaction=2 status=0)
ra0: authenticated
ra0: associate with AP 00:0c:41:de:17:fc
ra0: RX AssocResp from 00:0c:41:de:17:fc (capab=0x401 status=0 aid=1)
ra0: associated
ra0: switched to short barker preamble (BSSID=00:0c:41:de:17:fc)
ADDRCONF(NETDEV_CHANGE): ra0: link becomes ready
ra0: Initial auth_alg=0
ra0: authenticate with AP 00:0c:41:de:17:fc
ra0: RX authentication from 00:0c:41:de:17:fc (alg=0 transaction=2 status=0)
ra0: authenticated
ra0: associate with AP 00:0c:41:de:17:fc
ra0: authentication frame received from 00:0c:41:de:17:fc, but not in authenticate state - ignored
ra0: authentication frame received from 00:0c:41:de:17:fc, but not in authenticate state - ignored
ra0: authentication frame received from 00:0c:41:de:17:fc, but not in authenticate state - ignored
ra0: authentication frame received from 00:0c:41:de:17:fc, but not in authenticate state - ignored
ra0: authentication frame received from 00:0c:41:de:17:fc, but not in authenticate state - ignored
ra0: authentication frame received from 00:0c:41:de:17:fc, but not in authenticate state - ignored
ra0: authentication frame received from 00:0c:41:de:17:fc, but not in authenticate state - ignored
ra0: RX ReassocResp from 00:0c:41:de:17:fc (capab=0x401 status=0 aid=1)
ra0: associated
ra0: association frame received from 00:0c:41:de:17:fc, but not in associate state - ignored
ra0: association frame received from 00:0c:41:de:17:fc, but not in associate state - ignored
ra0: association frame received from 00:0c:41:de:17:fc, but not in associate state - ignored
ra0: association frame received from 00:0c:41:de:17:fc, but not in associate state - ignored
ra0: association frame received from 00:0c:41:de:17:fc, but not in associate state - ignored
ra0: association frame received from 00:0c:41:de:17:fc, but not in associate state - ignored
ra0: association frame received from 00:0c:41:de:17:fc, but not in associate state - ignored
ra0: no IPv6 routers present
Another interesting point is that at the back of the PCI Card the
"TxLink" led is permanently lit - I dont think this was the case
with the older driver - at least i cant remember it beeing lit.
Flo
--
Florian Lohoff [email protected] +49-171-2280134
Those who would give up a little freedom to get a little
security shall soon have neither - Benjamin Franklin