Next-in-Thread Next Message

Question Windows-2-Linux communication problems

Date: 2000, Aug 06
From: Andrew Fernandes <>

I have three Lucent WaveLan/IEEE Gold cards, all with firmware-6.06. I use two of the cards in latops under win95 and win2k, and have no problems.

My linux box uses the VG469 ISA bridge, and the wvlan_cs driver *seems* to be working correctly. All the iwconfig commands work flawlessly, I can set/get all card parameters, and readling through the output of "pc_debug=65535" shows nothing out of the ordinary occurring.

I'm using Red Hat's 2.2.16 kernel, modified with pcmcia-cs-3.1.19.

Heck, if I tcpdump the wireless ethernet port, the transmition of the "arp-who-has" messages coincides precisely with the little flashing light on the pc-card. So, as far as I can tell, the card is working just fine.

The problem is that linux and the windoze boxen cannot communicate at all. They do not appear in the slightest on each other's radar. I have fiddled very carefully with every combination of ESSID (on or off), encryption, frequency, mode, bit rate, etc., etc., etc. that I can, on both the linux box and the windoze boxen, and the OSes completely ignore each other.

Communication is always swell between the windozen.

It doesn't matter if I rotate cards among machines.

A sample output of iwconfig is as follows. The essid, nickname, frequency, mode... etc. all can be changed quite flawlessly with iwconfig.

 eth2     IEEE 802.11-DS  ESSID:"Studio20"  Nickname:"Herbie"
          Frequency:2.457GHz  Sensitivity:1/3  Mode:Ad-Hoc  
          Access Point: 00:00:00:00:00:00
          Bit Rate:2Mb/s   RTS thr:off   Fragment thr:off   
          Encryption key:off
          Power Management:off
          Link quality:0  Signal level:0  Noise level:0
          Rx invalid nwid:0  invalid crypt:0  invalid misc:0

Notice that everything from "link quality" onwards is zero. Those numbers never change, no matter how many hundreds of packets that ifconfig reports have gone out over the interface. Ifconfig always reports zero Rx packets on the interface.

On the windows side, the "network spy" utilites refuse, no matter what settings I use, to see or recognize the linux box in any way.

I very, very rarely get (from the wvlan_cs driver)

 wvlan_cs: eth2 Tx timed out! Resetting card 

messages. These do not fill me with happiness. I don't seem to have interrupt conflicts, though... from the dmesg file:

 Linux PCMCIA Card Services 3.1.19
   kernel build: 2.2.16-4 #1 Thu Aug 3 11:12:13 EDT 2000
   options:  [pci] [cardbus] [apm] [pnp]
 PCI routing table version 1.0 at 0xf0d10
 PnP: PNP BIOS installation structure at 0xc00fd110
 PnP: PNP BIOS version 1.0, entry at f0000:d140, dseg at f0000
 Intel PCIC probe: 
   Vadem VG-469 rev 00 ISA-to-PCMCIA at port 0x3e2 ofs 0x00
     host opts [0]: none
     host opts [1]: none
     ISA irqs (default) = 11 polling interval = 500 ms
 cs: IO port probe 0x0c00-0x0cff: clean.
 cs: IO port probe 0x0800-0x08ff: clean.
 cs: IO port probe 0x0100-0x04ff: clean.
 cs: memory probe 0x0d0000-0x0dffff: clean.
 wvlan_cs: WaveLAN/IEEE PCMCIA driver v1.0.4
 wvlan_cs: (c) Andreas Neuhaus <>
 wvlan_cs: index 0x01: Vcc 5.0, irq 11, io 0x0100-0x013f
 wvlan_cs: Registered netdevice eth2
 wvlan_cs: Valid channels: 1 2 3 4 5 6 7 8 9 10 11 
 wvlan_cs: MAC address on eth2 is 00 60 1d f2 cb 55  

I have only two hints about what may be going on, but I don't know what they mean.

1) For the 21-July driver release from Lucent (NDIS 3 miniport driver 6.14, firmware 6.06), using a Point-to-Point network with a blank network-id causes the windoze drivers to lock up on both 95 and 2k. However, locking up the windows drivers sometimes makes the linux driver count a few "invalid misc" packets. This is the ONLY way I can get any received packets on the linux driver.

2) I tried using Lucent's wavelan2_cs driver (6.02)... it compiles and installs into the kernel just fine... but after the module initializes, the module hangs. Compling with debugging, and turning on full debugging gives me nothing more than an initialization string in "dmesg". The wvlan_cs driver has no problem getting the wireless ether device up and running... The inability to properly initialize may be a hint that Andy's wvlan_cs driver may only SEEM to be functioning properly... who knows?

I'd be happy to provide (a) pizza, or (b) beer, if someone can help me figure this one out.

Many thanks,


Messages Inline: 0 1

Sad Ad-Hoc mode

Re: Question Windows-2-Linux communication problems (Andrew Fernandes)
Date: 2000, Aug 08
From: Jean Tourrilhes jt


  As far as I know, in Ad-Hoc mode the Windows driver force the usage of channel 3 (2.422 GHz) and doesn't use the ESSID at all (or it use to be that way).
  So, could you try to set the Wavelan on this channel ?

  Other things that may matter :
  The firmware 6.06 and windows driver 6.14 are supposed to have "improved ad-hoc networking". That may be a source of incompatibilities, so you may want to downgrade your Windows and card setup to earlier version.
  Some firmware release of the Wavelan don't like tcpdump.
  Try Linux-Linux communications if you can, that may tell you were the trouble is.


More Silly Lucent

Re: Question Windows-2-Linux communication problems (Andrew Fernandes)
Date: 2000, Aug 09
From: Andrew Fernandes <>

Thanks, Jean!

I've poked around the source for Lucent's wavelan2_cs (v 6.02) driver, and I found the cryptic comment that as of the 6.06 firmware, Lucent no longer supports their "ad-hoc" mode, which was a nonstandard quasi-IBSS-type service.

Instead, they are supporting full 802.11(b) IBSS standard peer-to-peer networking. Going from the Windoze drivers, this mode seems to need the ESSID, and can be on any channel, not just channel 3 (seems to auto-hunt and negotiate the channel). As far as I can tell, this is mainly a firmware issue, and driver software changes to support this should be small.

I'd take a look to see what Lucent's driver is doing, but it just hangs... even with full debugging on. Looks like I'll have to try to custom frutz their code to see what changes need to be made on the wvlan_cs code.

All my cards are on the same firmware (I doublechecked). I suspect that the software only needs a tweak to get it to run.

Lucent, I have three little letters for you... GPL!!! Grr...



News The problem is in Cardmgr!

Re: Question Windows-2-Linux communication problems (Andrew Fernandes)
Date: 2000, Aug 28
From: Andrew Fernandes <>


After an intense weekend of debugging, I've discovered that the Lucent driver actually (sort-of) DOES work!

The scenario: all cards and OSes have the 21-July release of Lucent's drivers and firmware. The wvlan_cs driver loads up, starts the net device, but can't talk to windows boxes. The wavelan2_cs driver won't even load up.

It turns out that the reason the wavelan2_cs driver doesn't load is because cardmgr dies BEFORE it can send the device a DS_BIND_DEVICE ioctl! Stepping through cardmgr with a debugger, it shows all the signs of classic memory corruption. Harmless calls like "syslog" lock up forever, and previously valid instructions cause "illegal instruction" and "segmentation fault" errors.

So... when using the wavelan2_cs driver: if I jump over all the "syslog" calls, which should theoretically not make any difference, the net device is correctly brought up by the module. Yay!

I still can't talk to the windows box, but there may still be something funny going on. Even thought I delicately stepped through cardmgr with my debugger (and things inside it were corrupted), it reported several "could not adjust resource" (memory and I/O errors).

So, until I (or David!) can track down the corruption in cardmgr, it may be possible to use Lucent's driver with the latest firmware to talk to windows boxes...



More 'Twas a buffer overflow error...

Re: News The problem is in Cardmgr! (Andrew Fernandes)
Date: 2000, Aug 31
From: Andrew Fernandes <>

It turns out that I was using a waaaaay too long

 module "wavelan2_cs" opts "irq_list=11 network_name=Studio20 port_type=3 station_name=Herbie channel=10 enable_encryption=y key_1=xxxxxxxxxxxxx transmit_key_id=1 pc_debug=0x7fffffff debug_flags=0xffffffff"

The line blew cardmgr's internal buffers.

That's the good news.

The bad news is now I can bring up both the Lucent and the GPL driver... and neither of them can talk to Windows.

I'm not impressed, Lucent...

I'll call their tech support and kvetch...

(David - I'll email my patch to you to look at)!


Windows-2-Linux communication problems

Members Subscribe No Admin Mode No Frames New Base Frame Help for HyperNews at 1.10
[ Edit This Forum ]