Modify

Opened 10 years ago

Closed 8 years ago

Last modified 2 years ago

#1222 closed defect (fixed)

wl0: Invalid argument

Reported by: phr3ak Owned by: developers
Priority: lowest Milestone: Barrier Breaker 14.07
Component: base system Version:
Keywords: Cc:

Description

this message appear when a wireless client connecting:

root@OpenWrt:~#  nas -P /tmp/nas.wl0.1lan.pid -H 34954 -i wl0 -A -m 128 -k keykeykey -s ssid -w 4 -g 3600
wl0: Invalid argument
wl0: Invalid argument

broadcom, wl500gp

Attachments (0)

Change History (38)

comment:1 Changed 10 years ago by Weedy <weedy2887@…>

i can conferm this.

Feb 13 10:59:58 (none) syslog.info -- MARK --
Feb 13 11:01:59 (none) user.info : wl0: Invalid argument
Feb 13 11:02:00 (none) daemon.info dnsmasq[710]: DHCPREQUEST(br-lan) <ip> <mac>
Feb 13 11:02:00 (none) daemon.info dnsmasq[710]: DHCPACK(br-lan) <ip> <mac> lappy-8ef5b40f5
Feb 13 11:02:02 (none) user.info : wl0: Invalid argument
Feb 13 11:02:03 (none) daemon.info dnsmasq[710]: DHCPRELEASE(br-lan) <ip> <mac>
Feb 13 11:02:03 (none) daemon.info dnsmasq[710]: DHCPDISCOVER(br-lan) <ip> <mac>
Feb 13 11:02:03 (none) daemon.info dnsmasq[710]: DHCPOFFER(br-lan) <ip> <mac>
Feb 13 11:02:03 (none) daemon.info dnsmasq[710]: DHCPREQUEST(br-lan) <ip> <mac>
Feb 13 11:02:03 (none) daemon.info dnsmasq[710]: DHCPACK(br-lan) <ip> <mac> lappy-8ef5b40f5
Feb 13 11:02:51 (none) daemon.info dnsmasq[710]: DHCPINFORM(br-lan) <ip> <mac>
Feb 13 11:02:51 (none) daemon.info dnsmasq[710]: DHCPACK(br-lan) <ip> <mac> lappy-8ef5b40f5

comment:2 Changed 10 years ago by Weedy <weedy2887@…>

confirm* damn typos

comment:3 Changed 10 years ago by anonymous

Oh right, I've the same problem, so it's nas which is causing that?
I also see the message when a client is connecting, just before a DHCPDISCOVER. But it's not always followed by dhcp messages :

Mar 31 14:27:00 (none) syslog.info -- MARK --
Mar 31 14:47:00 (none) syslog.info -- MARK --
Mar 31 15:05:06 (none) user.info : wl0: Invalid argument 
Mar 31 15:05:06 (none) user.info : wl0: Invalid argument 
Mar 31 15:05:06 (none) user.info : wl0: Invalid argument 
Mar 31 15:05:07 (none) user.info : wl0: Invalid argument 
Mar 31 15:05:08 (none) user.info : wl0: Invalid argument 
Mar 31 15:07:00 (none) syslog.info -- MARK --

nas command :

/usr/sbin/nas -P /var/run/nas.wl0.pid -H 34954 -l br-lan -i wl0 -A -m 128 -w 4 -s ssid -g 3600 -k key

comment:4 follow-up: Changed 9 years ago by anonymous

I see this error too... don't know yet if it has any effect on connection...

comment:5 in reply to: ↑ 4 ; follow-up: Changed 9 years ago by Weedy <weedy2887@…>

Replying to anonymous:

I see this error too... don't know yet if it has any effect on connection...

when it happends theres a "hiccup" in the wireless connection, since i switched to atheros on the client these "hiccups" have resulted in less connection drops (atheros seems to recover better). but things like irc, ssh while it sending data (top, verbose compile) die.

comment:6 in reply to: ↑ 5 Changed 9 years ago by anonymous

Replying to Weedy <weedy2887@gmail.com>:

when it happends theres a "hiccup" in the wireless connection, since i switched to atheros on the client these "hiccups" have resulted in less connection drops (atheros seems to recover better). but things like irc, ssh while it sending data (top, verbose compile) die.

Yes, it definitely affects in-progress data transfers. My client is ipw2200.

comment:7 Changed 9 years ago by Sonic

I have same error when client connects to the ap, but wireless connection seems to work without problem after, just weird log
[code]OpenWrt user.info : wl0: Invalid argumentcode just before dhcp lease each time ...

comment:8 Changed 9 years ago by Simon Josefsson <simon@…>

I have the same problem as well, on a linksys wrt54g3g (broadcom) using kamikaze 7.09.

The problem appeared when I started to use WPA2/PSK2 instead of WEP.

Ideas?

comment:9 Changed 9 years ago by Fatus <pieter@…>

Same here with ipw2200 and kamikaze 7.07 on wl-500g.

comment:10 Changed 9 years ago by gloomrider

I would suggest this is more than just a cosmetic problem. If any data is being transfered when this happens, the ipw2200 stack on the client has to be restarted work. Confirmed I am also running WPA2/PSK2.

comment:11 follow-up: Changed 9 years ago by anonymous

Here's some news after some intensive research: I found two threads were my attention was borrowed to the hardware versions of the ipw2200 cards in use, unfortunately I don't remember the exact URLs, http://www.minitar.com/forums/lofiversion/index.php/t1175.html might be one of them.

The thing is: the ipw2200 Mini-PCI card is apparantly manufactured by different subcontractors for Intel, and there are three popular versions floating around:

  • 0.1.3 / 0.1.4 made in China
  • 2.x which is made somewhere else, I think Malysia
  • 6.x which is said to appear eg. in some HP laptops

Now the 0.1.3 (which I have) and the 0.1.4 seem to be the most problematic. For those, the workaround described in http://www.intel.com/support/wireless/wlan/sb/cs-006205.htm actually helped increase stability for me. Yet I will try to get a ipw2915 (which by the way seems to suffer from the same problems) in a usable revision.

So, it MIGHT be that OpenWRT has a bug here, seeing that the ipw2200 works fine with other APs, but at the same time the ipw2200 seems to be an unusual buggy component, for what one would usually expect from Intel.

comment:12 in reply to: ↑ 11 Changed 9 years ago by gloomrider

Replying to anonymous:

Here's some news after some intensive research: I found two threads were my attention was borrowed to the hardware versions of the ipw2200 cards in use, unfortunately I don't remember the exact URLs, http://www.minitar.com/forums/lofiversion/index.php/t1175.html might be one of them.

The thing is: the ipw2200 Mini-PCI card is apparantly manufactured by different subcontractors for Intel, and there are three popular versions floating around:

  • 0.1.3 / 0.1.4 made in China
  • 2.x which is made somewhere else, I think Malysia
  • 6.x which is said to appear eg. in some HP laptops

Now the 0.1.3 (which I have) and the 0.1.4 seem to be the most problematic. For those, the workaround described in http://www.intel.com/support/wireless/wlan/sb/cs-006205.htm actually helped increase stability for me. Yet I will try to get a ipw2915 (which by the way seems to suffer from the same problems) in a usable revision.

So, it MIGHT be that OpenWRT has a bug here, seeing that the ipw2200 works fine with other APs, but at the same time the ipw2200 seems to be an unusual buggy component, for what one would usually expect from Intel.

Yes, I'm using a laptop in battery mode. And I'm using Linux. I'm going to look into how to enable CAM mode under battery power and test stability. Thanks so much!.

comment:13 follow-up: Changed 9 years ago by Simon Josefsson <simon@…>

As a data point, one of my clients is a iwp3945 card. However, the problem happens between two boxes running openwrt 7.09, in the same network, too. (One asus wl-500gP and one Linksys WRT54Gv.) I have no iwp2200 cards in this network.

Fwiw, I've reverted to WEP which works fine.

comment:14 in reply to: ↑ 13 ; follow-up: Changed 9 years ago by Weedy <weedy2887@…>

Replying to Simon Josefsson <simon@josefsson.org>:

As a data point, one of my clients is a iwp3945 card. However, the problem happens between two boxes running openwrt 7.09, in the same network, too. (One asus wl-500gP and one Linksys WRT54Gv.) I have no iwp2200 cards in this network.

Fwiw, I've reverted to WEP which works fine.

Thats because WEP doesnt use NAS, it's broadcoms NAS that sucks

comment:15 in reply to: ↑ 14 Changed 9 years ago by gloomrider

Replying to Weedy <weedy2887@gmail.com>:

Replying to Simon Josefsson <simon@josefsson.org>:

As a data point, one of my clients is a iwp3945 card. However, the problem happens between two boxes running openwrt 7.09, in the same network, too. (One asus wl-500gP and one Linksys WRT54Gv.) I have no iwp2200 cards in this network.

Fwiw, I've reverted to WEP which works fine.

Thats because WEP doesnt use NAS, it's broadcoms NAS that sucks

I'll be the first to admit I don't know exactly where this "nas" comes from. But I will say beyond a doubt that I never had these problems with HyperWRT-Thibor or DD-WRT. Are those packages using a different "nas"? Thanks in advance.

comment:16 Changed 9 years ago by Simon Josefsson <simon@…>

Another data point, from a wrt54g3g running kamikaze 7.09 with only one client (a powered off squeezebox, which talks dhcp sometimes), is that this seems to happen every hour repeatedly. There is no other traffic on this network.

Jan 4 07:36:52 grisslan daemon.info dnsmasq[424]: DHCPREQUEST(br-lan) 192.168.1.8 00:..
Jan 4 07:36:52 grisslan daemon.info dnsmasq[424]: DHCPACK(br-lan) 192.168.1.8 00:..
Jan 4 07:40:08 grisslan syslog.info -- MARK --
Jan 4 08:00:08 grisslan syslog.info -- MARK --
Jan 4 08:00:45 grisslan user.info : wl0: Invalid argument
Jan 4 08:20:08 grisslan syslog.info -- MARK --
Jan 4 08:40:08 grisslan syslog.info -- MARK --
Jan 4 09:00:08 grisslan syslog.info -- MARK --
Jan 4 09:00:44 grisslan user.info : wl0: Invalid argument
Jan 4 09:20:08 grisslan syslog.info -- MARK --
Jan 4 09:40:08 grisslan syslog.info -- MARK --
Jan 4 10:00:08 grisslan syslog.info -- MARK --
Jan 4 10:00:43 grisslan user.info : wl0: Invalid argument
Jan 4 10:20:08 grisslan syslog.info -- MARK --
Jan 4 10:40:08 grisslan syslog.info -- MARK --
Jan 4 11:00:08 grisslan syslog.info -- MARK --
Jan 4 11:00:42 grisslan user.info : wl0: Invalid argument
Jan 4 11:20:08 grisslan syslog.info -- MARK --
Jan 4 11:40:08 grisslan syslog.info -- MARK --
Jan 4 12:00:08 grisslan syslog.info -- MARK --
Jan 4 12:00:41 grisslan user.info : wl0: Invalid argument
Jan 4 12:20:08 grisslan syslog.info -- MARK --
Jan 4 12:40:08 grisslan syslog.info -- MARK --
Jan 4 13:00:08 grisslan syslog.info -- MARK --
Jan 4 13:00:40 grisslan user.info : wl0: Invalid argument
Jan 4 13:07:05 grisslan daemon.info dnsmasq[424]: DHCPREQUEST(br-lan) 192.168.1.8 00:..
Jan 4 13:07:05 grisslan daemon.info dnsmasq[424]: DHCPACK(br-lan) 192.168.1.8 00:...

comment:17 Changed 9 years ago by anonymous

I'm suffering from the same problem: every now and then I get a "wl0: Invalid argument" message on the console and then my wireless client card stops working. Sometimes the client recovers quickly, sometimes only disabling/re-enabling the client's networt interface helps.

I'm using WPA2/PSK with Kamikaze (7.06). The client is a Windows XP box using a cheap Realtek WLAN-NIC. I disabled Windows' built-in WLAN configuration and use the vendor-provided tool instead.

When the client card stops working the vendor tool still shows "connected" and signal/noise levels, but does not receive or transmit any packets.

comment:18 Changed 9 years ago by anonymous

Same problem on a Asus WL-500gP using WPA2/AES PSK

comment:19 Changed 9 years ago by FalconQC5

I'm having the same problem with Asus WL-500gP (running 7.09) with Intel Wireless 3945 on my laptop. The problem happens every time I connect to the router using the newest iwl3945 (iwlwifi) module (version 1.2.23). But it is working fine with the old ipw3945. I also use WPA2/AES PSK.

On my 2nd router, a WRT54GLv1.1 running White Russian 0.9, I don't have any problem with both modules and WPA2/AES PSK.

comment:20 Changed 9 years ago by anonymous

same problem. wireless interface on the laptop crashes. found this in my logs

comment:21 Changed 9 years ago by anonymous

I confirm this problem, started happening when I switched to WPA2. Altering the PSK's length didnt do any good; I experience both very slow connection speeds and dropped connections (with no way to reauth until I walk to a wired connection and issue "wifi" on the box).

The box is an ASUS WL-500g Premium, with broadcom nas package.

comment:22 Changed 8 years ago by anonymous

confirmed with wrt54gl and kamikaze 7.09 psk2

comment:23 Changed 8 years ago by pedrofaustino

I can confirm this on an Asus wl-500GP (broadcom) running kamikaze 7.09 kernel 2.4.

The message appears hourly, when the router sends a EAPoL-key packet. These are the packets I get when running wireshark on the client:

ROUTER -> CLIENT

802.1X Authentication
    Version: 2
    Type: Key (3)
    Length: 143
    Descriptor Type: EAPOL RSN key (2)
    Key Information: 0x1382
        .... .... .... .010 = Key Descriptor Version: HMAC-SHA1 for MIC and AES-CCMP for encryption (2)
        .... .... .... 0... = Key Type: Group key
        .... .... ..00 .... = Key Index: 0
        .... .... .0.. .... = Install flag: Not set
        .... .... 1... .... = Key Ack flag: Set
        .... ...1 .... .... = Key MIC flag: Set
        .... ..1. .... .... = Secure flag: Set
        .... .0.. .... .... = Error flag: Not set
        .... 0... .... .... = Request flag: Not set
        ...1 .... .... .... = Encrypted Key Data flag: Set
    Key Length: 0
    Replay Counter: 14
    Nonce: 000000000000000000000000000000000000000000000000...
    Key IV: 0194CE4D22F8FA1B3CBDBE3688DADC02
    WPA Key RSC: 0000000000000000
    WPA Key ID: 0000000000000000
    WPA Key MIC: CB5CB3D2D3D7ABB87426E089CE819D84
    WPA Key Length: 48
    WPA Key: 5F4FDCC4C07D4A12617A8AA34E0D5AD48D6E5FC2785E2824...

CLIENT->ROUTER

802.1X Authentication
    Version: 1
    Type: Key (3)
    Length: 95
    Descriptor Type: EAPOL RSN key (2)
    Key Information: 0x0302
        .... .... .... .010 = Key Descriptor Version: HMAC-SHA1 for MIC and AES-CCMP for encryption (2)
        .... .... .... 0... = Key Type: Group key
        .... .... ..00 .... = Key Index: 0
        .... .... .0.. .... = Install flag: Not set
        .... .... 0... .... = Key Ack flag: Not set
        .... ...1 .... .... = Key MIC flag: Set
        .... ..1. .... .... = Secure flag: Set
        .... .0.. .... .... = Error flag: Not set
        .... 0... .... .... = Request flag: Not set
        ...0 .... .... .... = Encrypted Key Data flag: Not set
    Key Length: 0
    Replay Counter: 14
    Nonce: 000000000000000000000000000000000000000000000000...
    Key IV: 00000000000000000000000000000000
    WPA Key RSC: 0000000000000000
    WPA Key ID: 0000000000000000
    WPA Key MIC: 787A0414A0BDE8363BEF1B209B0D2799
    WPA Key Length: 0

Does someone know how to further troubleshoot this? Which tool can we use on the router?

comment:24 Changed 8 years ago by Weedy <weedy2887@…>

i looks like they fixed this in trunk when the timing patch couple weeks ago. logs are clean for the past 3 days (weekend) when it would pop up hourly before.

comment:25 Changed 8 years ago by Simon Josefsson <simon@…>

Interesting! Do you have a more specific pointer to the patch? Any chance this could be back-ported back to 7.09? (I'm not sure how stable trunk is, or when there will be a new release...)

comment:26 Changed 8 years ago by Weedy <weedy2887@…>

Your better off building trunk, iptables in 7.09 is broken among other things. My trunk routers only reboot when i flash new images (ive had 30+ days).

comment:27 Changed 8 years ago by pedrofaustino

Besides the above mentioned problem, every ~48 hours my router would reboot.

I've just built from trunk (yesterday), flashed my WL-500GP and it has been stable over the past 12 hours. No "wl0: Invalid argument" and a much more stable wifi connection. At least this problem is indeed fixed, as pointed out by Weedy.

I just hope it won't reboot in the next hours ;)

comment:28 Changed 8 years ago by Weedy <weedy2887@…>

7.09 is a buggy pile of crap (less crap then stock but still). trunk right now is very nice.

comment:29 Changed 8 years ago by gi1242+openwrt@…

I have the same problem. Actually maybe mine is *worse* :). When I try to connect from my Linux laptop, my log file gets flooded (about 1000 lines) with the "wl0: invalid argument" message, and I am sometimes unable to connect. Other times it works great (just a few lines of this error, and I connect perfectly).

When I switched to WPA from WPA2, then I only get one line of this error message per log in attempt, and the login is smooth. I might have to reflash to white russian... ;(

GI

comment:30 Changed 8 years ago by Fatus

Did any of you succeed in running trunk on a WL-500g? Alternatively, are there other WL-500g users that can confirm #3392?

comment:31 Changed 8 years ago by Simon Josefsson <simon@…>

I'm building openwrt trunk right now, for my WL-500g Deluxe. I chose a 2.4 kernel, and ticked build all packages, we'll see if I get a image.

comment:32 Changed 8 years ago by Simon Josefsson <simon@…>

I installed trunk (r11058) on my two wl-500gp's and psk2 has been stable so far. I'm streaming audio to my soundbridge over it, and running WDS between the two boxes (also psk2).

I don't have a wl-500g so I can't confirm the problem in #3392, sorry.

Thanks!

comment:33 Changed 8 years ago by Simon Josefsson <simon@…>

As a way of thanking for fixing this bug, I wrote up all steps needed to get this working:

http://blog.josefsson.org/?p=44
http://josefsson.org/grisslan/wlan.html

It has now been working for several hours of streaming music so it seems relatively stable.

I hope this helps someone.

Thanks again,
Simon

comment:34 Changed 8 years ago by gi1242

I just installed trunk, and this problem is indeed fixed. I'm happily using WPA2 again ... :)

comment:35 Changed 8 years ago by jlayton@…

Does anyone have a pointer to the trac ticket for the actual fix for this problem? I'm mainly interested in whether this was a kernel or userspace bug...

comment:37 Changed 8 years ago by florian

  • Resolution set to fixed
  • Status changed from new to closed

This seems to have been fixed.

comment:38 Changed 2 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.