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
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 inse
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 ~{PmV>HI~} <[EMAIL PROTECTED]>
> Home Page: http://gondor.apana.org.au/~he
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 c
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 real
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 t
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
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
>
> 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
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 zd1211r
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.
> >
> > z
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
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 branch,
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 reg
On 06-12-11 21:20 Michael Wu wrote:
> On Monday 11 December 2006 20:07, Daniel Drake wrote:
> > Michael Wu wrote:
> > > zd1211rw-d80211: Use ieee80211_tx_status
> >
> > I've thought some more about this and I'm not so sure that this is the
> > right approach.
> >
> > Can't devicescape be tau
On 06-12-11 20:32 Michael Wu wrote:
> On Monday 11 December 2006 17:55, Ulrich Kunitz wrote:
> > I cannot accknowledge this patch. Michael, the LED does not only
> > show the link status, but also indicate that packets are sent,
> > which is done by the firmware. However the
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 cann
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.
>
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)
{
In 2.6.19 a deauthentication from the AP doesn't start a
reassociation by the softmac code. It appears that
mac->associnfo.associating must be set and the
ieee80211softmac_assoc_work function must be scheduled. This patch
fixes that.
Signed-off-by: Ulrich Kunitz <[EMAIL PROTECTED
On 06-12-02 13:55 Daniel Drake wrote:
> Ulrich Kunitz wrote:
> >I intend to track the d80211 stack, care for the forward porting
> >and see also a number of things, which should be done for d80211.
>
> OK, sorry for the false assumptions in my last mail.
It's true, I
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
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-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_multica
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.
>
On 06-08-30 15:06 Michael Buesch wrote:
> Because this clearly is a workaround for broken compilers to me,
> I would rather do the following:
>
> +} /* __attribute__((packed)) */;
>
>
> This way it's still clear to the reader, that these structs
> must be packed and are most likely for communic
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 ioct
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 m
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-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 s
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 sinc
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/wir
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/wirele
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/n
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]>
---
driver
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: sen
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
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. Cur
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.
>
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 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-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 we
On 06-06-04 00:25 Oliver Neukum wrote:
> > > +static void disconnect(struct usb_interface *intf)
> > > This is racy. It allows io to disconnected devices. You must take the
> > > lock and set a flag that you test after you've taken the lock elsewhere.
> >
> > Will fix, thanks.
>
> You're welcome
ond RX address, I
wondered, what this is good 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 - [E
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 on
ly like wrapping hard_start_xmit inside softmac, etc
> etc...
>
> Note that even in it's current form, this patch eliminates an annoying (and
> inaccurate) chunk of code from our driver.
>
> Ideas/comments?
>
--
Ulrich Kunitz - [EMAIL PROTECTED]
-
To unsubscribe fr
> I was thinking of adding all the 'what is this ioctl supposed to do'
> things we came up 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 b
to implement 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
ducts_configuration_guide_chapter
> 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
10 - 13
Spain 10 - 11
--
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
> >
ne-taler.de/snapshots/.
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
ve to have general understanding
> that at some point (not too far away), one of the stacks would have
> to disappear.
See above.
--
Ulrich Kunitz - [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
M
they get to the WiPHY device?
Maybe the active and passive interface concept could help here. I
don't think, that the upper layer should filter conflicts, because
this code must make assumptions about the capabilities of lower
layer components. If these assumptions are wrong, the upper layer
ree that the firmware load sequence is strange, TOD has code
which seems to support a kind of auto-address mode, I implemented
it and it didn't work.
Cheers,
Uli
--
Ulrich Kunitz - [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
t
me the docs it would be really 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
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 actua
59 matches
Mail list logo