Dead card after wrong pda and firmware flashing

Could not get own MAC address ( hfa384x_get_rid failed )

Hi,

I installed the latest cvs version (following the link from
http://hostap.epitest.fi) of the hostap driver on my arm based board using
intel chip IXP425. This board has a TI PCI1520 PCI-PCMCIA controller.
Currently the socket driver is yenta_socket.

When i inserted the prism2 based 16 bit pc-card, drivers hostap_cs,
hostap_crypt and hostap_crypt_wep were loaded but I am getting the MAC
address all zeros 00:00:00:00:00:00

While looking at the logs, it is seen that:

wlan0: could not get own MAC address
wlan0: Channel list read failed

While looking into the code, it is seen that hfa384x_get_rid failed twice
while getting the MAC address. The complete log is attached below.

BTW, I am able to run ifconfig wlan0 and set the ip address.
but the Hwaddr is seen as 00:00:00:00:00:00. No association is taking place
with any of the stations.

The debug output is given below (I have put some debug prints in ds_ioctl
function also)
---------------------------------------------------------------------
cs: setup_socket(c0cee000): applying power
cs: resetting socket c0cee000
cs: reset done on socket c0cee000
cs: send_event(sock 0, event 4, pri 0)
ds: ds_event(0x000004, 0, 0xc02bfd60)
ds_poll(socket 0)
ds_poll(socket 1)
ds_read(socket 0)
ds_ioctl(socket 0, 0x8004640b, 0xbffff9c8)
cs: memory probe 0x48000000-0x4bffffff: excluding 0x48000000-0x48ffffff
0x4bc00000-0x4bffffff
ds_ioctl(socket 0, 0xc0206404, 0xbffff9c8)
ds_ioctl(socket 0, 0xc2946406, 0xbffff9c8)
ds_ioctl(socket 0, 0xc2946407, 0xbffff9c8)
ds_ioctl(socket 0, 0xc0206404, 0xbffff9c8)
ds_ioctl(socket 0, 0xc2946406, 0xbffff9c8)
ds_ioctl(socket 0, 0xc2946407, 0xbffff9c8)
ds_ioctl(socket 0, 0xc0206404, 0xbffff9c8)
ds_ioctl(socket 0, 0xc2946406, 0xbffff9c8)
ds_ioctl(socket 0, 0xc2946407, 0xbffff9c8)
ds_ioctl(socket 0, 0xc0506403, 0xbffff940)
hostap_cs: 0.0.0 CVS (Jouni Malinen <jkmaline <at> cc.hut.fi>)
ds: register_pccard_driver('hostap_cs')
ds_ioctl(socket 0, 0xc050643c, 0x1a330)
bind_request(0, 'hostap_cs')
cs: bind_device(): client 0xc0fc2280, sock 0, dev hostap_cs
prism2_attach
hostap_cs: setting Vcc=33 (constant)
pcmcia_register_client()
cs: register_client(): client 0xc0fc2280, sock 0, dev hostap_cs
hostap_cs: CS_EVENT_CARD_INSERTION
prism2_config()
hostap_cs: setting Vcc=50 (from config)
Checking CFTABLE_ENTRY 0x01 (default 0x01)
IO window settings: cfg->io.nwin=1 dflt.io.nwin=1
io->flags = 0x0046, io.base=0x0000, len=64
hostap_cs: index 0x01: Vcc 5.0, irq 6, io 0x4100-0x413f
hostap_cs: Registered netdevice wlan0
prism2_hw_init()
wlan0: could not get own MAC address
wlan0: Channel list read failed
ds_ioctl(socket 0, 0xc050643d, 0x1a330)
ds_ioctl(socket 0, 0xc050643e, 0x1a388)
ds_poll(socket 0)
ds_poll(socket 1)

---------------------------------------------------------------------

Is this in someway trelated to the soket driver (yenta_socket)? Do I need to
try with i82365?

I have seen related errors on the list and web, but no answers.

please help.

TIA
anoop

Bus Master Mode

Hi,

I tried compiling up the latest CVS with PRISM2_BUS_MASTER enabled, but it's
giving errors on compile

In file included from driver/modules/hostap_pci.c:164:
driver/modules/hostap_hw.c: In function `prism2_bus_master_ev':
driver/modules/hostap_hw.c:3451: `local' undeclared (first use in this
function)
driver/modules/hostap_hw.c:3451: (Each undeclared identifier is reported
only once
driver/modules/hostap_hw.c:3451: for each function it appears in.)
make: *** [driver/modules/hostap_pci.o] Error 1

Any ideas?

--
Ian Cass

Re: Bus Master Mode

Ian Cass <ian.cass <at> mblox.com> wrote:
> Hi,
> 
> I tried compiling up the latest CVS with PRISM2_BUS_MASTER enabled,
> but it's giving errors on compile
> 
> In file included from driver/modules/hostap_pci.c:164:
> driver/modules/hostap_hw.c: In function `prism2_bus_master_ev':
> driver/modules/hostap_hw.c:3451: `local' undeclared (first use in this
> function)
> driver/modules/hostap_hw.c:3451: (Each undeclared identifier is
> reported only once
> driver/modules/hostap_hw.c:3451: for each function it appears in.)
> make: *** [driver/modules/hostap_pci.o] Error 1
> 
> Any ideas?

I've 'fixed' it by moving ...

local_info_t *local = (local_info_t *) dev->priv;

... outside the if .. then .. else structure.

I've no idea if this will actually work, but it fixes the compile problem.

--

-- 
Ian Cass

802.11 e draft

Hi Folks,

I am looking for the 802.11e draft/D2.0, I would be pleased to get
it form those of you already having it. If not the case, do you know
where I could find a public version of this draft.

Best regards,

Lassaad Gannoune,

some hostap_io_debug data

Hi...
  I've collected some hostap_io_debug data (gzip < /proc/... > file ) that
may interest you, Jouni.
  They are several files, caught by a 5min' cron "watchdog" which restarts the
pcmcia machinery when it detects disassociation by reading iwconfig output,
they are at: 
  http://jjo.homeip.net/hostap/

  I'm running latest CVS (weekend) plus attached patch (which have
enourmosly incremented stability, voiding "timeout after ... +resetting").
  This is a Pentium 166, stock linux 2.4.20 with a Compaq WL200 with fw
1.5.6 loaded in RAM.

Regards
-- 
--Juanjo

#  Juan Jose Ciarlante (JuanJo PGP) jjo ;at; mendoza.gov.ar              #
#  Key fingerprint = 76 60 A5 76 FD D2 53 E3  50 C7 90 20 22 8C F1 2D    #

Index: driver/modules/hostap_hw.c
===================================================================
RCS file: /cvs/hostap/driver/modules/hostap_hw.c,v
retrieving revision 1.77
diff -u -r1.77 hostap_hw.c
--- driver/modules/hostap_hw.c	1 Mar 2003 05:13:57 -0000	1.77
+++ driver/modules/hostap_hw.c	27 Mar 2003 03:25:07 -0000
 <at>  <at>  -558,7 +592,13  <at>  <at> 

 	while ((HFA384X_INW(o_off) & HFA384X_OFFSET_BUSY) && tries > 0) {
 		tries--;
-		udelay(1);
+		/* 	
+		 *  	jjo:
+		 *  	Replacing udelay(1) -> (2) yields same wlan-ng
+		 * 	"timings". For me this change eliminated those
+		 * 	pesky "timeout after ... resetting card" 
+		 */
+		udelay(2);
 	}
 	return (HFA384X_INW(o_off) & HFA384X_OFFSET_BUSY);
 }
 <at>  <at>  -570,6 +610,8  <at>  <at> 
 {
 	u16 o_off, s_off;
 	int ret = 0;
+	/* 	jjo: will disable hard IRQs */
+	unsigned int flags;

 	if (offset % 2 || bap > 1)
 		return -EINVAL;
 <at>  <at>  -582,6 +624,13  <at>  <at> 
 		s_off = HFA384X_SELECT0_OFF;
 	}

+	/* 
+	 * 	jjo: 
+	 * 	disabling hard IRQ here gave me more stability (less frequent
+	 * 	driver hang's). 
+	 * 	Already spinlock'd on &local->baplock by caller.
+	 */
+	local_irq_save(flags);
 	if (hfa384x_wait_offset(dev, o_off)) {
 		printk(KERN_DEBUG "%s: hfa384x_setup_bap - timeout before\n",
 		       dev->name);
 <at>  <at>  -590,6 +639,7  <at>  <at> 
 	}

 	HFA384X_OUTW(id, s_off);
+	/* udelay(10);				*//* jjo */
 	HFA384X_OUTW(offset, o_off);

 	if (hfa384x_wait_offset(dev, o_off)) {
 <at>  <at>  -608,6 +658,7  <at>  <at> 
 #endif

  out:
+	local_irq_restore(flags);	/* jjo: re-enable IRQs */
 	return ret;
 }

A question is asked about PEAP in hostap.

Although I am newcomer, I need your help well.

Although I want to using PEAP, it is not operating well.
Environment is the following.

The RADIUS server is using Win2000 ADVSVR.
(AuthSVR:IAS & AccountingSVR:Domain Controller are
operating with the same PC.)
The Supplicant is using Win2000 Pro+Q313664 patch.
The hostap is the CVS current as of today.

There is a point to ask. 
(1)What should be put into "acct_server_shared_secret" and
"eap_message" of hostapd.conf?

"hello" is put into "eap_message" now.
The same value as "auth_server_shared_secret" is contained
in "acct_server_shared_secret".

#MD5 did not have a problem in this state.

(2)Are some understood, although the following doubtful
LOG(s) will be outputted, if it is going to use PEAP?

A part is shown below.

IEEE 802.1X: Sending canned EAP packet FAILURE to
00:30:5b:00:3f:30 (identifier 0)

IEEE 802.1X: 84 bytes from 00:30:5b:00:3f:30
   IEEE 802.1X: version=1 type=0 length=80
   EAP: code=2 identifier=2 length=80 (response)
   EAP Response-Unknown   <---???

Since a setup of (1) is doubtful, can't PEAP be used?
Is there what should be set up also except a setup by (1)?

If some may be understood, please let me know. Thank you
for your consideration.

Thanks,
Hiroshi

__________________________________________________
Do You Yahoo!?
Yahoo! BB is Broadband by Yahoo!  http://bb.yahoo.co.jp/

Re: Question on HostAP, IAPP link layer update and bridge station cache

28 March 2003 Jouni Malinen wrote:
> On Mon, Mar 24, 2003 at 01:38:25PM +0100, Jon-Olov Vatn wrote:
> ...
> > Now to my question. If one would like to fix this problem, I can see
> > two different approaches, and I wonder what way to go:
> > * "Interaction between hostAP and briding code"
> > * "Inserting link layer update frame in wlan0 input queue"
> 
> I think it would be useful to implement more interaction between Host AP
> and bridging code.

Before I saw your answer I started to work on a solution according to
my second alternative, i.e., upon a successful (re)association the
hostapd would build the IAPP link layer update packet and then to
ask the hostap driver (by ioctl) to treat this packet as if it
came in on the wlan interface (put it in an sk_buff and call netif_rx).

A good way with doing it this way is that the link layer update packet
will then be forwarded on all bridge interfaces except the wlan (e.g. wlan0)
interface where the STA resides. In particular this could be beneficial
if we are putting up WDS links to other APs dynamically.

I made my some changes to the hostap cvs version as of March 24 and in
my small testbed it seems to work. Since this is my first kernel hack
I know that there are probably several ways in which it can be
improved ...
Both the patch and the source of the cvs version of March 24 can be
found at http://www.it.kth.se/~vatn/hostap (for at least a week)
for the ones interested. 
To apply the patch first download "hostap-cvs-20030324.tgz"
and "patch-linklayerupdate" to some suitable location then

$> tar zxvf hostap-cvs-20030324.tgz
$> cd hostap-cvs-20030324
$> patch -p1 < ../patch-linklayerupdate

Note, in the patch I have modified the hostapd/hostap.conf file
to use "br0" as IAPP interface. Maybe it is better to use "eth0".
In any case the IAPP interface needs an IP address (see Jouni's
comment below).

> However, before doing this, I would add third option
> to your list:
> * use IAPP to update the previous AP
> 
> Current version of hostapd has quite limited version of this, but it
> should work in the case you described, i.e., having the APs sharing same
> shared physical medium so that they can receive broadcast packets from
> eachother. This requires IP addresses (so that you do not need to
> comment our the initialization). If the APs cannot receive broadcast
> frames from eachother, more complete IAPP implementation would be
> needed.
Thanks. I was using a setup where with a bridge interface (br0) and
two physical interfaces (wlan0 and eth0) associated with br0. eth0
was my "IAPP interface", but only br0 had an IP address. Now I am
using br0 as "IAPP interface" instead.

Paradox using FreeSwan and hostap_cs

I've had a hostap_cs based access point for some time now, and instead
of worrying about WEP, I've been using a FreeSwan based IPSEC vpn for
all my wireless traffic. 

In general it works well, but I have had a horrible time sometimes with
my startup/shutdown scripts when the PCMCIA card is ejected.

I recently purchased a Zaurus and Linksys card, and wanted it to play
nice with my Hostap access point...vpn and all. I installed OpenZaurus
2.3, and to my surprise, it also uses the Hostap driver in managed mode.

I installed FreeSwan and got it working, no problems there. What I did
find, however, is that when I pull the wireless card, cardmgr never
calls the shutdown scripts I have set up to bring down the network and
Freeswan drivers.

I believe I've tracked it down to the hostap_cs driver. In syslog, I get
the following:

klogd: hostap_cs: CS_EVENT_CARD_REMOVAL
klogd: sa1100_pcmcia_init(0)
klogd: prism2_release
klogd: hostap_cs: release postponed, 'wlan0' still open

And the the pcmcia drivers grind to a halt, until I manually stop the
Freeswan driver (ipsec0 device). At that point, cardmgr is called and
everything shuts down.

What I believe is happening is that the ipsec0 device keeps wlan0 open
and this section of hostap_cs.c puts the driver into standby mode until
wlan0 is released:

<SNIP!>
        if (link->open) {
                printk("%s: release postponed, '%s' still open\n",
                      dev_info, link->dev->dev_name);
                link->state |= DEV_STALE_CONFIG;
                return;
        }
<SNIP!>

So I have a paradox. I need cardmgr to shut down Freeswan (ipsec0) to
free up wlan0 so the driver can be unloaded, but that can't happen until
wlan0 is released by Freeswan.

Is this expected behavior? Any ideas on how to work around this?

Thanks,

jf

--

-- 
John Fulmer <jfulmer <at> hrblock.com>

WDS in managed mode

Is WDS supported in master mode and managed mode?  The hostAP driver could
be changed to support it, but does the Intersil firmware have issues with
it?

Patrick