Re: Problem with WEP in one direction!?

Hi Jeremy,

On Tue, 10 Feb 2004, Jeremy Laidman wrote:

> After trawling the archives, I've found several postings that had similar
> problems.  While useful to compare, it seems my problem is in fact
> different.  Curiously though, their logs show an AUTHENTICATION stage that
> my device doesn't ever go into.  Not sure if this is a problem.

you run the atmel device in _adhoc_ mode acc. to your syslog, which is
fine, as your peer (ssid rebel-it) announces it as an IBSS (bit1 in
capability set, see the syslog). Furthermore its BSSID is a temporary
one (bit1 in first byte set: 02:00:25:68:0a:64).
With an IBSS there is no authentication stage before CONNECTing.

> I have another redhat box that the win2k laptop can talk to using WEP.  It's
> in managed mode, and runs a wavelan2_cs module for an enterasys PCMCIA card.
> This is what the atmel driver is CONNECTing to as an AP.  If I ping from
> this managed node to the atmel device, tcpdump running on the enterasys
> shows arp packets go out, but garbage coming back; tcpdump on the atmel
> shows arp in and arp-reply out.  It's as if the atmel can decrypt incoming
> packets with the key, but can't encrypt the packets it sends out.
>
> If I ping from the enterasys node, the atmel node puts an arp entry into its
> cache.  If I ping only the other way, no arp entry in cache.

> I've tried turning off encryption on both linux boxes, but arp replies don't
> seem to get back into the atmel node.

I'd start without WEP first. Switch it off on both sides, make sure no
other peer is running with the same SSID and try to ping. What does
tcpdump show on both sides? If this fails, try to start both peers in the
opposite order. The order may influence results, as the first peer has to
establish the IBSS (choosing the BSSID etc.), while the second simply
joins it (and takes over if the first one is switched off).

> Settings for enterasys node:
>
> eth2      Wireless  ESSID:"myessid"  Nickname:"enterasys"
>           Mode:Managed  Frequency:2.457GHz  Access Point: 02:62:77:01:2A:92

ESSID /mode contradicts the syslog lines below: rebel-it and adhoc both in
the parm lines and the scan table:

>at76c503.c: wlan0 param: ssid rebel-it (726562656C2D6974) mode adhoc ch
             10 wep enabled key 0 keylen 13
>at76c503.c: wlan0 param: preamble long rts 1536 frag 1536 txrate auto
             excl 0
>at76c503.c: wlan0 param: pm_mode 1 pm_period 0 auth_mode open scan_times
             10 120 scan_mode active

> at76c503.c: wlan0 BSS table (curr=00000000, new=00000000):
> at76c503.c: 0xc13654c0: bssid 02:00:25:68:0a:64 channel 10 ssid rebel-it
> (726562656C2D6974) capa x0012 rates 02 04 0B 16 rssi 1 link 0 noise 0
> ...
> at76c503.c: wlan0 join addr 02:00:25:68:0a:64 ssid rebel-it type 1 ch 10
> timeout 2000
> at76c503.c: wlan0: state 6 -> 7 (CONNECTED)
> at76c503.c: wlan0: rx newbss
> at76c503.c: ibss_change = 0x 1
> at76c503.c: using BSSID 02:62:77:01:2a:92

strange, there seems to be another, separate IBSS _on the same
channel_ with the BSSID 02:62:77:01:2a:92, which the Atmel device switches
to after been CONNECTED to 02:00:25:68:0a:64. Or the enterasys works like
some old Prism2 firmware, which restarted every 10 seconds and changed its
BSSID ?

The "rx newbss" feature of the Atmel firmware/device should IMHO
deal with the possible deadlock, when both adhoc peers are started at the
same time. Both scan for the peer, find none and start separate IBSS on
the same channel with the same SSID (which is possible with 802.11).
Then the Atmel firmware would signal "rx newbss", i.e. another IBSS with
the same SSID on the same channel and switch over to use this SSID.
In the above case it might be better to stay with the old one, as the
device hasn't started an own IBSS.

But this is not causing your problem.
If you are sure to have only two WLAN devices active, please do a periodic
scan with the Atmel device by putting it into _managed_ mode. It will scan
the channels every 5 or 10 seconds and print all (I)BSS into syslog.
I'd like to see if the enterasys peer keeps its BSSID.

/Jörg