Hello,
the file drivers/net/wireless/orinoco.c in 2.4.17 contains
on the line 1424:
priv->has_wep = (firmver >= 0x00008);
I have the Siemens I-GATE 11M PCI card, which is a PrismII based
PCMCIA card in the PLX9052 PCI-PCMCIA adapter. This card has
firmware version 0.7.6 and definitely supports WEP - I am using
128-bit WEP in Windows without problems.
If I change the line to enable the WEP for fw 7, I get mixed
results in 2.4.19-pre6:
- I can ping, but I cannot telnet.
- My dmesg is full of
eth1: Null event in orinoco_interrupt!
and ocassionally I get
eth1: Undecryptable frame on Rx. Frame dropped.
- when I ping I seem to get double replies sometimes (depending
on who I ping - never for the access point, always for another
client) - either I am somehow seeing both the packet from
the client to the AP and from AP to me, or there is some
problem in the receiving routines
Does the driver support interrupt sharing? I have quite a lot
devices on the PCI bus, the plx board is not able to get
a dedicated interrupt and shares it with the USB controller.
I have a SMP board, which can be a factor too.
Anyway, if I can ping and see the traffic of another clients
using tcpdump, the has_wep check is obviously too strict.
I would suggest to either lower the requirement to firmware 7,
or (if this is an exception and another cards are different)
to add a module parameter to override it.
BTW, 2.4.19-pre6 is better than 2.4.17 - in 2.4.17 I was not
able to get a single packet through. Keep up the good work
and let me know if I can help in testing patches etc.
linux-wlan does not work for me - most probably because
of a shared interrupt.
Upgrading the firmware to 0.8.x is not an option - tried the
update once and the card was on the way to manufacturer
(fortunately Siemens replaced it without problems).
L-K readers: experiences with a similar setup anyone?
Thanks
--
Stano
On Sat, Apr 13, 2002 at 09:21:17PM +0200, Stanislav Meduna wrote:
> Hello,
>
> the file drivers/net/wireless/orinoco.c in 2.4.17 contains
> on the line 1424:
>
> priv->has_wep = (firmver >= 0x00008);
>
> I have the Siemens I-GATE 11M PCI card, which is a PrismII based
> PCMCIA card in the PLX9052 PCI-PCMCIA adapter. This card has
> firmware version 0.7.6 and definitely supports WEP - I am using
> 128-bit WEP in Windows without problems.
The firmware supports WEP, but it is configured differently than
version 0.8 and later, and I've never managed to work out how to
properly activate it.
> If I change the line to enable the WEP for fw 7, I get mixed
> results in 2.4.19-pre6:
>
> - I can ping, but I cannot telnet.
> - My dmesg is full of
> eth1: Null event in orinoco_interrupt!
That's unrelated, due to a shared interrupt.
> and ocassionally I get
> eth1: Undecryptable frame on Rx. Frame dropped.
> - when I ping I seem to get double replies sometimes (depending
> on who I ping - never for the access point, always for another
> client) - either I am somehow seeing both the packet from
> the client to the AP and from AP to me, or there is some
> problem in the receiving routines
>
> Does the driver support interrupt sharing? I have quite a lot
> devices on the PCI bus, the plx board is not able to get
> a dedicated interrupt and shares it with the USB controller.
> I have a SMP board, which can be a factor too.
Yes it does, except for that "Null event" message which is gone in
more recent versions (not yet pushed to Linus and Marcelo).
> Anyway, if I can ping and see the traffic of another clients
> using tcpdump, the has_wep check is obviously too strict.
> I would suggest to either lower the requirement to firmware 7,
> or (if this is an exception and another cards are different)
> to add a module parameter to override it.
Yes, but the interface doesn't actually work properly.
--
David Gibson | For every complex problem there is a
[email protected] | solution which is simple, neat and
| wrong. -- H.L. Mencken
http://www.ozlabs.org/people/dgibson
Hello,
> > I have the Siemens I-GATE 11M PCI card, which is a PrismII based
> > PCMCIA card in the PLX9052 PCI-PCMCIA adapter. This card has
> > firmware version 0.7.6 and definitely supports WEP - I am using
> > 128-bit WEP in Windows without problems.
>
> The firmware supports WEP, but it is configured differently than
> version 0.8 and later, and I've never managed to work out how to
> properly activate it.
I looked at what does actually fail and have some interesting
datapoints. I used ethereal to watch two scenarios -
1. a communication between another client (a Pocket PC)
and the access point/router and machines behind it
2. a communication between own machine and the AP
The failures seem to be connected with the data transmitted.
In the case 1 I had no problems to watch lengthy HTTP
communications. However I have never seen the POP request
going out (only answers).
Sometimes I got lenghty conversations also in the case 2, but
I also got a consistent failure mode - TCP checksum on the
receiving direction incorrect and exactly one byte garbled -
the last one. The resulting retry mostly had again the last byte
garbled, but to a different one. In one case the retry
succeeded and the following conversation was then flawless.
The failed packets were short (less than 256 bytes long), so this
is nothing that can be related to a fragment reassembling
or something like that.
That it is consistently the last byte that is garbled seems to
suggest some kind of off-by-one bug. Maybe in the driver,
maybe in the firmware...
What is the legal situation regarding RC4 now - can it be used
in the GPL software without risk, or is this still a grey area?
I think there is a possibility to do the WEP in software
(at least one source code I found does implement the encryption
to avoid the weak IVs) and I am probably going to set the
host en-/decrypt flags and give it a try. Would you accept
such (optional) patch?
Regards
--
Stano