From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <200104111437.QAA24192@polya.cs.utwente.nl> To: 9fans@cse.psu.edu Subject: Re: [9fans] wavelan config problems In-reply-to: Your message of "Tue, 10 Apr 2001 11:58:33 -0400." <20010410155835.E746419B0F@mail.cse.psu.edu> References: <20010410155835.E746419B0F@mail.cse.psu.edu> From: Axel Belinfante Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 11 Apr 2001 16:37:55 +0200 Topicbox-Message-UUID: 80a724fa-eac9-11e9-9e20-41e7f4b1d025 > This is what I use on my Thinkpad T21A: > ether0=type=wavelan port=0x180 irq=10 essid=Our-Net key2=Our-Long-Key This did major part of the trick - it made me aware of an error message that I had overlooked (well, ignored): using the default irq for the wavelan triggered the error: irq shared but not level . Using irq=10 made this error go away. Disabling encryption made it finally work using default essid: ether0=type=wavelan irq=10 crypt=off > What type of card do you have (gold, silver), are you using it in > managed (with an access-point) or peer-to-peer mode, and are you using > encryption. We only use managed mode with encryption here so it's > possible something fell through the cracks. We have a silver one, used in managed mode. Encryption is enabled but not mandatory. Once the card worked, I had a look at why it fails to read our essid. In /sys/src/9/pc/etherwavelan.c:/^ltv_outstr I did not understand the line ltv.slen = (len+1) & ~1; It seems that it sets slen to be one to much: rounds up to the next even number. In our case, where len==7, this seems to fail; at least, after I replaced above statement by simple ltv.slen = len; it now recognizes our network when given as argument of essid. However, the w_cmd in the w_outltv now 'fails' (according to the return value) for those strings written by ltv_outstr; however, the card seems to be happy with them: the next line works: ether0=type=wavelan irq=10 crypt=off essid=OUR-NET I could imagine that a similar off-by-one length problem explains the hex 01 that I stll see in the 'Current name: OUR-NAME01' field in ifstats. Once the essid was recognized, I started looking at encryption. It turns out that it now also works if I add 'key1=our-key' and enable encryption, but it stops working if I add 'key2=our-key'. I don't really understand the key handling, both here, and in general. For the general case: is the key-number to be used something between me and my card (as long as I use the right key, it does not matter whether I configure it as key1, 2, 3 or 4), or something between me, the card and the base station (not only should I use the right key, but it should also be configured in the right slot)? For the driver code in particular: setting 'key1=our-key' results into ctrl->txkey to be set to 0. This suggests that the slot numbers are communicated to the card using origin 0, whereas the slot number in the configuration use origin 1. Is this correct? I.e. configuring 'key1=our-key' means that indeed that key is to be used? The value seems to be transfered to the card anyway. However, the ifstats code takes ctrl->txkey==0 to mean that no keys have to be shown. I'm a bit confused here - admittedly because I did not ready any documentation, just looked here and there at the code for the plan9 driver and for the linux driver code that comes on the cd with the card. The net result is that the following line works: ether0=type=wavelan irq=10 essid=OUR-NET key1=our-key > Also, look at the w_timer routine in etherwavelan.c and you will see > 4 lines commented out after a long comment. I commented those lines > out in an attempt to find the root cause of the problem nemo was seeing > when he wrote the driver, but i could never get the problem to happen; > I tried lots of gold and silver cards, even very old ones. I'm intrested > to know if anyone else sees that problem so we can try to fix it; our > old Wavelan driver didn't need any such fix. We can make it an option > if it proves to be card-specific. I did not look at that. To give slightly more background: part of my frustration in getting it to work was caused by the fact that I know Sape had it working here about a month ago using the old driver, as far as I know without doing much more than giving the config info (essid, key) at the right place in the right way. Anyway, I'm _very_ happy that it is working now (even though I don't really understand some of the 'why' it now works, especially regarding the encryption stuff). I'm slightly sorry about the length of this message, but it resembles the time spent on getting it working :-) Axel.