Bug 73417 - Wireless no longer works for my Cisco Aironet 350
Wireless no longer works for my Cisco Aironet 350
Status: CLOSED DUPLICATE of bug 79869
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2002-09-04 09:07 EDT by David L. Parsley
Modified: 2007-04-18 12:46 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-21 13:49:34 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David L. Parsley 2002-09-04 09:07:12 EDT
Description of Problem:
I insert the card, it loads the drivers, but it just doesn't work.  'iwconfig'
shows no detected essid, and the access point is listed as all FF.

The access point seems to think it associated, but there's no indication of that
on the laptop.  I ran 'neat', configured and tried to activate the device, no
luck.  I booted the machine back into RH7.3, insert the card again, and right
away 'iwconfig' shows the correct essid and access point, and dhcpcd eth1 gets
an ip right away.

There's no wep or anything else interesting going on.

Version-Release number of selected component (if applicable):
I started with the stock (null), then upgraded the kernel and wireless-tools
from rawhide to:

How Reproducible:

Steps to Reproduce:
1. Insert Cisco Aironet 350 PCMCIA card
2. Try connecting to the network

Actual Results:
No detected essid, no detected wap
Comment 1 Need Real Name 2002-11-26 09:26:26 EST
I am having the same problem with the same symptoms.  It also worked in Red 
Hat 7.3 for me.
Comment 2 Maxx Lobo 2002-12-06 14:07:16 EST
I'm having a similar problem, running Redhat 8.0, with the stock kernel
(2.4.18-14) and a Cisco 350 802.11b WiFi card. The card came up fine the first
time, but ever since then it refuses to get an IP address from the DHCP server.
The verion of wireless-tools is wireless-tools-25-1.

To provide a background, the DHCP server is a Linux box running ISC's
DHCP-3.0.1pl2, and is on the same VLAN as the wireless access point, which is a
Cisco 340 AP. WEP is turned off. The Linux box also acts as a router to the
internet, and has the IP address The DHCP block is
- The laptop originally acquired the IP of from
the DHCP server the first time it was inserted.

Here is more debugging information that might help:

1) This is the output from tcpdump. is the IP address that the
card got when it was inserted for the first time. 
[maxx@seawulf maxx]$ sudo tcpdump -i eth1
tcpdump: WARNING: eth1: no IPv4 address assigned
tcpdump: listening on eth1
18:17:05.000178 >  xid:0x658db84b secs:5
[|bootp] [tos 0x10] 
18:17:19.000248 >  xid:0x2453f669
[|bootp] [tos 0x10] 
18:17:23.000185 >  xid:0x2453f669 secs:4
[|bootp] [tos 0x10] 
18:17:31.000185 >  xid:0x2453f669 secs:12
[|bootp] [tos 0x10] 
18:17:44.000186 >  xid:0x2453f669 secs:25
[|bootp] [tos 0x10] 
18:18:04.000181 >  xid:0x2453f669 secs:45
[|bootp] [tos 0x10] 
18:18:17.000190 >  xid:0x2453f669 secs:58
[|bootp] [tos 0x10] 
18:18:20.085530 arp who-has tell
18:18:21.084035 arp who-has tell
18:18:22.084032 arp who-has tell
tcpdump: pcap_loop: recvfrom: Network is down

2) While I have tcpdump running in an xterm, I attempt to restart the networking
by issuing an /etc/rc.d/init.d/network restart command (both this step and the
above step are performed in parallel)

[root@seawulf pcmcia]# /etc/rc.d/init.d/network restart
Shutting down interface eth0:                              [  OK  ]
Shutting down loopback interface:                          [  OK  ]
Setting network parameters:                                [  OK  ]
Bringing up loopback interface:                            [  OK  ]
Bringing up interface eth0:                                [  OK  ]
Bringing up interface eth1:  Error for wireless request "Set Encode" (8B2A) :
    SET failed on device eth1 ; Operation not supported.

Determining IP information for eth1...PING ( from : 56(84) bytes of data.

--- ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% loss, time 2002ms
, pipe 3
PING ( from : 56(84) bytes of data.

--- ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% loss, time 2012ms
, pipe 3

Then it drops me back to the prompt on both xterms. I noticed that there was a
similar ticket for RedHat 7.3 which seemed to be unresolved, and was wondering
if you guys know about/have a fix for this yet.

Comment 3 Arjan van de Ven 2002-12-06 14:11:19 EST
it would be interesting to see if the i586 kernel (as opposed to the i686
kernel) fixes this. If it does I have a better idea where to look ;(
Comment 4 Need Real Name 2002-12-09 15:47:23 EST
I tried it with the i586 kernel shipped with 8.0, (2.4.18-14-i586), and it does 
not work for me with this kernel either.  I did not try a complete reinstall, 
only using rpm -ivh --oldpackage to install the kernel.
Comment 5 Need Real Name 2003-01-01 23:00:44 EST
I installed PHOEBE yesterday, and the wireless card is working again with that 
beta version.  I haven't had time to try to look at what specifically might 
have fixed it, but I hope this helps somewhat :-)
Comment 6 Dennis Edmonds 2003-01-03 13:01:02 EST

Just noticed this when I was looking up the status of a previous bug...I have
had problems with the Cisco Aironet 352 and fixed them according to the
information I left in Bug# 79869.  It's been the fix for other people I work
with, maybe it will help solve some of these problems.

Basically, neat was setting the card rate for 11Mb/s and it worked fine after I
manually set it for auto.  I just had to edit the RATE entry in
/etc/sysconfig/network-scripts/ifcfg-eth0.  Kind of an easy fix, although I
don't understand why it refused to work when set at 11...
Comment 7 Alan Cox 2003-06-05 15:07:13 EDT

*** This bug has been marked as a duplicate of 79869 ***
Comment 8 Red Hat Bugzilla 2006-02-21 13:49:34 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

Note You need to log in before you can comment on or make changes to this bug.