and not the zd1211rw-mac80211 driver. Daniel Drake has
already provided a patch for the replacement of the softmac
driver, which this patch will break.
Signed-off-by: Ulrich Kunitz [EMAIL PROTECTED]
---
drivers/net/wireless/zd1211rw/zd_mac.c | 10 --
1 files changed, 8 insertions(+), 2
John W. Linville wrote:
So, did the patch below fix the problem? Should I apply it?
John
John,
the patch would have worked, but I have sent a second one to the
list, which is based on Herbert's and has an assert to be able to test
the patch on x86.
You should be notify that the mac80211
Johannes,
Hence, going back to the 802.11 header and the IP header alignment
requirement, if we get the IP header alignment requirement right now I
cannot possibly see any way we would use compare_ether_addr() on an
address that is not at least two-byte aligned as required.
ACK. I agree
Herbert Xu wrote:
So please try the following patch (instead of the original one)
which should fix all the unailgned accesses in do_rx.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
Sorry for joining the discussion so late, but I have a day job
requires sometimes all of my time.
John W. Linville wrote:
On Wed, Sep 19, 2007 at 11:08:16PM +0100, Daniel Drake wrote:
I would like to this until 2.6.25 until I have had time to clear up some
final issues and do more
Michael Buesch wrote:
On Saturday 22 September 2007 11:48:00 Ulrich Kunitz wrote:
A real high-quality driver will require Johannes' proposed
mac80211 driver interface changes to be merged and TX
confirmations handled in a way, that the semantics can really be
supported by the driver
On 07-05-01 12:34 Jiri Benc wrote:
On Tue, 1 May 2007 04:01:00 +0100 (BST), Daniel Drake wrote:
The old code allowed unlimited buffing of tx frames in URBs
submitted for transfer to the device. This patch stops the
ieee80211_hw queue(s) if to many URBs are ready for submit to the
On 07-05-01 23:10 Jiri Benc wrote:
Really? From what you wrote (if too many URBs are ready for submit) it
seems that the code is triggered when the queue is just full. That's not
necessarily an error condition and the only thing needed to do is to stop
the queue. Unless zd1211 is really
I'm still not convinced that papering over the problem in userspace is a
real solution.
johannes
Just my 2 cents. I support this. What are the options? I see only
two:
1. Use different magic numbers for 32 bit and 64 bit structures. A
flag is an alternative, but will be more difficult to
On 07-02-10 10:51 Joe Perches wrote:
On Sat, 2007-02-10 at 07:02 +0100, Michael Buesch wrote:
On Saturday 10 February 2007 02:27, Daniel Drake wrote:
Robert P.J. Day's recent commit (getting rid of all casts of
k[cmz]alloc()
calls) introduced a sparse warning for zd1211rw, related to
On 07-02-10 07:02 Michael Buesch wrote:
On Saturday 10 February 2007 02:27, Daniel Drake wrote:
Robert P.J. Day's recent commit (getting rid of all casts of k[cmz]alloc()
calls) introduced a sparse warning for zd1211rw, related to our
type-checking
of addresses.
On 07-02-04 10:42 James Courtier-Dutton wrote:
Hi,
Can Wireless network cards receive and transmit on two channels at once?
I am thinking of implementing a way for a wireless VoIP phone on Linux
being able to hand off from one AP to another without dropping the call.
For this to work, the
Hi,
while doing my first steps under d80211 I stumbled over a
soft lockup. It's on a real SMP machine (Core 2 Duo). After the
lockup the machine becomes unusable. I can reproduce it reliably
by unplugging the device.
The bug appears to be present in the John Linville's wireless-dev
master
Michael,
please detach a little bit from LEDs.
A trigger is a generic concept. It doesn't need to have a special
binding to what it triggers. It could be a buzzer, it could be
an LED, it could be text output on an LCD.
So we could have link status change trigger, for which functions
could be
On 06-12-11 00:44 Michael Wu wrote:
This makes zd1211rw-d80211 register an LED class to control the link LED
instead of trying to determine when the LED should be on based on the
current bssid. No default trigger is set since d80211 doesn't currently
have a link on/off LED trigger.
I cannot
On 06-12-06 18:52 Michael Buesch wrote:
All data in mac-associnfo is protected by mac-associnfo-mutex
and _not_ mac-lock.
Are you sure? One can find for instance the following function in
ieee80211softmac_assoc.c:
void
ieee80211softmac_disassoc(struct ieee80211softmac_device *mac)
{
On 06-12-06 21:52 Michael Buesch wrote:
On Wednesday 06 December 2006 21:17, Ulrich Kunitz wrote:
On 06-12-06 18:52 Michael Buesch wrote:
All data in mac-associnfo is protected by mac-associnfo-mutex
and _not_ mac-lock.
Are you sure?
Yes I am.
One can find for instance
Hi Michael,
I have finished a port of the zd1211 driver to the Devicescape 802.11
stack.
This is absolutely great news. I will look into it and check it
today.
- The original driver does not seem to check if a frame has been
successfully
TXed (as in RXed an ACK), so the
On 06-12-02 10:58 Daniel Drake wrote:
Michael Wu wrote:
Hi,
I have finished a port of the zd1211 driver to the Devicescape
802.11 stack.
Yeah!! thanks so much for doing this.
Are you willing to maintain this in terms of porting upcoming patches to
it? I think I also speak
On 06-11-30 20:57 Daniel Drake wrote:
Stephen Hemminger wrote:
Why all the trouble do it off work queue? Is someone calling
set_multicast_list with IRQ's disabled?
Register I/O involves sleeping, so we need to be in process context.
in_atomic() returns non-zero in the set_multicast_list
On 06-09-01 20:55 Michael Buesch wrote:
The real
problem with WE is, as I previously said, the ill-defined semantics of
both the user-space API and the in-kernel API.
I don't understand why you say it's ill defined, it 100%
documented in the iwconfig man page.
It is
On 06-08-29 10:45 Jouni Malinen wrote:
The only reason for adding nick command would be to maintain backwards
compatibility with some scripts. I do not use any distro configuration
mechanisms for setting up wireless, so I do not know what is currently
being used. I would not add these ioctls
On 06-08-18 09:12 Johannes Berg wrote:
On Fri, 2006-08-18 at 01:29 +0200, Ulrich Kunitz wrote:
Or are here people, who
really want to freely transmit on all frequencies their RF might
be able to generate?
Yes :P
Some amateur radio people asked me about extending the spectrum a bit
On 06-08-17 09:42 Simon Barber wrote:
The spec for RSSI is very loose - RSSI is just a 8 bit unsigned number,
guaranteed to be a monotonically increasing function of signal strength.
You don't get to know anything about the scale, or linearity of the
function. In essence RSSI is a vendor
On 06-08-15 18:38 Michael Buesch wrote:
On Tuesday 15 August 2006 18:29, Dan Williams wrote:
o Separate attributes for channel and frequency
No, channel and freq is the same. It's just another name
for the same child. I would say we only want to deal with channel numbers
in the API.
On 06-08-13 11:24 Michael Buesch wrote:
On Saturday 12 August 2006 19:00, Daniel Drake wrote:
--- linux-2.6.orig/drivers/net/wireless/zd1211rw/zd_mac.c
+++ linux-2.6/drivers/net/wireless/zd1211rw/zd_mac.c
@@ -127,11 +127,9 @@ out:
void zd_mac_clear(struct zd_mac *mac)
{
- /*
On 06-08-02 17:58 John W. Linville wrote:
On Tue, Aug 01, 2006 at 11:43:31PM +0200, Ulrich Kunitz wrote:
From: Daniel Drake [EMAIL PROTECTED]
We'll be needing these at some point...
This one doesn't really seem like a fix. But since the later fixes
seem to depend on it, I guess
On 06-08-01 15:58 Jiri Benc wrote:
pointing non-migrated drivers (ipw2[12]00, zd1211rw) at the old
code,
Yes. Rather than moving, zd1211 should be ported to d80211 - this will
also allow using of more advanced features of the hw.
I have currently no idea, when this will happen. Currently
faster code.
Signed-off-by: Ulrich Kunitz [EMAIL PROTECTED]
---
drivers/net/wireless/zd1211rw/zd_usb.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/zd1211rw/zd_usb.c
b/drivers/net/wireless/zd1211rw/zd_usb.c
index 2e3d77e..96551da 100644
From: Daniel Drake [EMAIL PROTECTED]
We'll be needing these at some point...
Signed-off-by: Daniel Drake [EMAIL PROTECTED]
Signed-off-by: Ulrich Kunitz [EMAIL PROTECTED]
---
drivers/net/wireless/zd1211rw/zd_chip.h |4 +++-
drivers/net/wireless/zd1211rw/zd_mac.c |6 --
2 files
There has been a problem in the radiotap header. Monitor mode
works now with tcpdump 3.94 + libpcap 0.9.4. ethereal 0.99.0 +
libpcap 0.9.4 is broken, because it doesn't find the right offset
for the IEEE 802.11 header.
Signed-off-by: Ulrich Kunitz [EMAIL PROTECTED]
---
drivers/net/wireless
From: Daniel Drake [EMAIL PROTECTED]
Apparently the ZD1211 doesn't mind, but the ZD1211B absolutely must be
told that encryption is happening in software.
Signed-off-by: Daniel Drake [EMAIL PROTECTED]
Signed-off-by: Ulrich Kunitz [EMAIL PROTECTED]
---
drivers/net/wireless/zd1211rw/zd_mac.c
Here are six fixes for the zd1211rw driver.
They fix
- radiotap issues for the monitor mode
- WEP encryption
- an endianess problem in the rx path
- reassociation after disassociation be the AP
If possible these patches should be included in 2.6.18
-- Uli
-
To unsubscribe from this list:
From: Daniel Drake [EMAIL PROTECTED]
This function is never called in interrupt context, and it doesn't
matter if it is called in IRQ context or not.
Signed-off-by: Daniel Drake [EMAIL PROTECTED]
Signed-off-by: Ulrich Kunitz [EMAIL PROTECTED]
---
drivers/net/wireless/zd1211rw/zd_usb.c |1
I had problems with my AVM Fritz!Box access point. It appeared
that the AP deauthorized me and the softmac didn't reconnect me.
This patch handles the problem.
Signed-off-by: Ulrich Kunitz [EMAIL PROTECTED]
---
drivers/net/wireless/zd1211rw/zd_chip.c |4 ++--
drivers/net/wireless/zd1211rw
On 06-07-16 14:17 Daniel Drake wrote:
Adrian Bunk wrote:
This patch contains the following possible cleanups:
- make needlessly global functions static
- #if 0 unused functions
Please review which of these functions do make sense and which do
conflict with pending patches.
Thanks
On 06-06-03 17:45 Larry Finger wrote:
This message shows each of the 2.4 GHz and 5 GHz bands split into indoor
and outdoor usage. For each group, the ISO name for that country is shown
before the channel listing. There are a lot of countries that do not belong
in the default group. I
Larry,
I've not read your patches your detail, so I comment only on your
description.
1. A new routine, ieee80211_init_geo has been written that is called by a
driver wishing to use this functionality. The arguments are an
ieee80211_device, a two-character ISO3661 country code, and a flag
On 06-06-11 11:46 Larry Finger wrote:
I don't see any means for the daemon to know its country other than the
driver or the user telling it. If such a means exists, I would like to
learn of it. My current working model is to supply the country code from a
module option when the driver is
for. So for ZD1211 we could support
two virtual interfaces. However in AP mode one virtual device
would have to send the beacons on its own. But there could be also
support for one interface in AP and the other in STA mode.
Uli
--
Ulrich Kunitz - [EMAIL PROTECTED]
-
To unsubscribe from this list
it.
Uli
--
Ulrich Kunitz - [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
with to the softmac or netdev wiki. Would that be
good/useful, or should we just put it into that driver writers guide?
Regarding the wireless extension ioctls, I think the best would be
to add kerneldoc comments.
Uli
--
Ulrich Kunitz - [EMAIL PROTECTED]
-
To unsubscribe from this list: send
an annoying (and
inaccurate) chunk of code from our driver.
Ideas/comments?
--
Ulrich Kunitz - [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 17 Apr 2006, Ulrich Kunitz wrote:
Oops! Sorry, but sometime ^X and ^C are to near to each other.
I just wanted to say, I agree with the approach, but wonder how
transmission timeouts come into play here, which should lead to a
decrease of the tranmission rate.
Daniel the patches
09186a008059c96f.html) has what seems to be the most complete listing of
country information. Neglecting any discussion of maximum power, I have been
able to arrange the countries into the following groups:
--
Ulrich Kunitz - [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe
--
Ulrich Kunitz - [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, 14 Jan 2006, Pete Zaitcev wrote:
On Sat, 14 Jan 2006 15:13:39 +0100 (CET), Ulrich Kunitz [EMAIL PROTECTED]
wrote:
[...] Register accesses in USB devices should be
able to sleep. However the 80211 stacks I've seen so far have a
fixed set of capabilities and do also assume
assumptions about the capabilities of lower
layer components. If these assumptions are wrong, the upper layer
code must be changed. If there is a configuration, which can't be
supported, the component configured should just say no.
--
Ulrich Kunitz - [EMAIL PROTECTED]
-
To unsubscribe from this list: send
--
Ulrich Kunitz - [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
great. Please
contact me if there is any action required on my side.
Cheers,
Uli
--
Ulrich Kunitz - [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo
Hi,
I'm also working since a few weeks on a rewrite of the ZD1211. I'm
a little bit more progressed than you, because my driver already
loads the firmware and I'm able to set and read registers and I
have the initialization code done. The next step is reading
(scanninng) a beacon frame. So
51 matches
Mail list logo
