RE: Problem with WEP in one direction!?

Hi Jeremy,

On Wed, 11 Feb 2004, Jeremy Laidman wrote:

> Thanks, now I understand.  The ssid "rebel-it" was supposed to be
> obfuscated, but I didn't do a very good job, and missed a couple.
> Everywhere you see "myessid" was "rebel-it" - there was only one SSID.  I'm
> sorry to have confused the issue.  Below are the details again (without
> alteration).
hmm, I never thought the SSID should be hidden (especially as your nodes
broadcast them). Keys should, therefore no log entry dumps them.

> > 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?
>
> Yup, this works fine.
good.

>
> Now I do "iwconfig <dev> enc on" on both sides.
>
> Enterasys says:
> eth2      Wireless  ESSID:"rebel-it"  Nickname:"enterasys"
>           Mode:Managed  Frequency:2.457GHz  Access Point: 02:00:03:75:76:17
>           Sensitivity:1/0
>           RTS thr:off
>           Encryption key:1234-1234-1234-1234-1234-1234-99
>           Link Quality:0/0  Signal level:-102 dBm  Noise level:-102 dBm
>           Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
>           Tx excessive retries:0  Invalid misc:1   Missed beacon:0
> eth2      Link encap:Ethernet  HWaddr 00:E0:63:83:2C:ED
>           inet addr:192.168.16.1  Bcast:192.168.16.255  Mask:255.255.255.0
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:1960 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:1663 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:100
>           RX bytes:313863 (306.5 Kb)  TX bytes:300640 (293.5 Kb)
>           Interrupt:9 Base address:0x100

How did you put the enterasys into this mode, by
	iwconfig eth2 mode managed
? Mode managed usually means the device is a _client_ to an access point,
mode master is the one (not often supported) to turn the device into
an access point. If you'd put the Atmel device in managed mode, it would
endlessly scan for an AP with the given SSID...
The BSSID still is a temporary one. Bit of strange behaviour, but I've
never used the wavelan_cs driver.

> Atmel is:
> wlan0     IEEE 802.11-DS  ESSID:"rebel-it"  Nickname:"atmel"
>           Mode:Ad-Hoc  Channel:10  Cell: 02:00:03:75:76:17
>           Bit Rate:11Mb/s
>           RTS thr=1536 B   Fragment thr=1536 B
>           Encryption key:1234-1234-1234-1234-1234-1234-99   Encryption
> mode:open
>           Power Management:off
>           Link Quality:0  Signal level:60  Noise level:0
>           Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
>           Tx excessive retries:0  Invalid misc:0   Missed beacon:0
> wlan0     Link encap:Ethernet  HWaddr 00:06:F4:02:87:B7
>           inet addr:192.168.16.99  Bcast:192.168.16.255  Mask:255.255.255.0

> Atmel logs as follows, after setting enc to on:
>
> Feb 11 10:00:23 brick kernel: at76c503.c: wlan0 param: ssid rebel-it
> (726562656C2D6974) mode adhoc ch 10 wep enabled key 0 keylen 13
> Feb 11 10:00:23 brick kernel: at76c503.c: wlan0 param: preamble long rts
> 1536 frag 1536 txrate auto excl 0
> Feb 11 10:00:23 brick kernel: at76c503.c: wlan0 param: pm_mode 1 pm_period 0
> auth_mode open scan_times 10 120 scan_mode active
> Feb 11 10:00:24 brick kernel: at76c503.c: wlan0: state 0 -> 1 (SCANNING)
> Feb 11 10:00:26 brick kernel: at76c503.c: wlan0 BSS table (curr=00000000,
> new=00000000):
> Feb 11 10:00:26 brick kernel: at76c503.c: 0xcf53d440: bssid
> 02:00:c1:91:d0:40 channel 10 ssid rebel-it (726562656C2D6974) capa x0012
> rates 02 04 0B 16 rssi 23 link 0 noise 0
> Feb 11 10:00:26 brick kernel: at76c503.c: wlan0 BSS table (curr=00000000,
> new=00000000):
> Feb 11 10:00:26 brick kernel: at76c503.c: 0xcf53d440: bssid
> 02:00:c1:91:d0:40 channel 10 ssid rebel-it (726562656C2D6974) capa x0012
> rates 02 04 0B 16 rssi 23 link 0 noise 0
> Feb 11 10:00:26 brick kernel: at76c503.c: wlan0: state 1 -> 6 (JOINING)
> Feb 11 10:00:26 brick kernel: at76c503.c: wlan0 find_matching_bss: returned
> cf53d440
> Feb 11 10:00:26 brick kernel: at76c503.c: wlan0 join addr 02:00:c1:91:d0:40
> ssid rebel-it type 1 ch 10 timeout 2000
> Feb 11 10:00:26 brick kernel: at76c503.c: wlan0: state 6 -> 7 (CONNECTED)
>
> So again, everything seems OK to this point.

Except that the bssid in the syslog (02:00:c1:91:d0:40) does not match the
one iwconfig reports later (02:00:03:75:76:17). Could you please check if
this happens when you try without WEP and everything works fine?

> > 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 ?
>
> There were three wifi nodes on at the time.  I've turned the third one off
> to reduce any confusion. Could this have been the cause?
yes, if the third one was on the same channel using the same SSID.

> So now I use 'arping -c1 -I wlan0 192.168.16.1' to send one arp packet from
> atmel (192.168.16.99) to enterasys (192.168.16.1):
>
> Atmel tcpdump shows:
>   10:04:39.311622 arp who-has 192.168.16.1 (Broadcast) tell 192.168.16.99
>
> Enterasys shows:
>   10:10:22.142323 ad:de:f:d0:2c:ed 4d:17:fe:ca:ba:ab 7392 68:
>                          27e0 7b65 5774 0c06 c981 a457 9bc8 f011
>                          6876 4170 cc69 9504 e166 0beb 54f9 3de8
>                          ea02 bbd1 6517 e007 4668 e97b 7131 4d23
>                          b152 3f00 0a04
>
> I ping the other way:
>
> Atmel shows:
>   10:05:44.415681 arp who-has 192.168.16.99 (Broadcast) tell 192.168.16.1
>   10:05:44.415776 arp reply 192.168.16.99 is-at 0:6:f4:2:87:b7
>
> Enterasys shows:
>   10:11:27.246214 arp who-has 192.168.16.99 (Broadcast) tell 192.168.16.1
>   10:11:27.248439 0:e0:63:83:2c:ed 0:e0:63:83:3e:10 bdd7 68:
>                          95e3 3574 e019 04d3 83c6 21b1 e10c 0309
>                          3a24 d28c 9f51 cbef def7 ba2e 638b a521
>                          f2e9 7824 d89a 9077 57bf ec35 2d30 7218
>                          0332 3f00 0a04
>
> This seems to indicate that the atmel can decrypt the enterasys packets, but
> not the other way.  Either the enterasys has a problem decrypting the atmel
> packets, or the atmel can't encrypt the packets correctly.  Note that the
> enterasys works fine with a third device (enterasys on win2k).
yes, but this is the same brand ...

Try with the arping:
- switch off encryption on the Atmel side only
- set Atmel side to restricted encryption ("iwconfig wlan0 encr on restr"
  (?)). With your "open" setting you allow the device to process
  received unencrypted data. But it will always transmit encrypted.

Maybe the enterasys does not encrypt/decrypt ? Are you sure, that a simple
"iwconfig encr on" does turn WEP on for the enterasys (it does for the
Atmel driver, which restarts the device after that cmd)?
Some cards need the netdev to be taken down and up again:
	ifconfig eth2 down; ifconfig eth2 up

/Jörg