Re: [9fans] wavelan config problems

Re: [9fans] wavelan config problems

[jmk]

On Thu Apr 12 09:18:24 EDT 2001, Axel.Belinfante@cs.utwente.nl wrote:
> Oops. My debugging was erroneous: the failing w_cmd was _not_ for the
> strings writing, but for cmd type 0xfc22 meaning WType_XClear.
> The linux driver on the cd that came with the card doesn't do anything
> about this request (or I overlooked it). (driver: WVLAN49)
> For that request, in w_cmd the test (rc&WresSts) succeeds, causing it
> to return failure.
> What does this WresSts actually mean?

You probably have as much information about the hardware as I do, we failed
miserably to get any real documentation out of the Wavelan group. I only have
WVLAN47 and a very old draft of a document describing the Hardware Control
FUnctions (HCF) called HCF-Lite; all the interesting sections are missing
and it doesn't mention encryption aynwhere.

I believe that the returned status has the command code in the lower 7 bits,
a busy bit as bit 15 and the remaining bits are a result code, 0 means success.

> Can it be that this is not available in all cards?
> Or that the code (ltv.type) is wrong?
>
> Moreover, I had a second look at the strings writing in the linux driver.
> What they do there amounts to the following in ltv_outstr:
>
> 	// set len = strlen(val); or less if val too long
> 	...
> 	ltv.len = 2 +((len+1) & ~1)/2;
> 	ltv.type = type;
> 	ltv.slen = len;
> 	...
>
> I.e. ltv.len is not taken from the sizeof the record, but takes
> the variable length of the string into account, rounded up to even.
> ltv.slen is just the length of the string.

Here are the words from the HCF-Lite docs, clearly we're wrong in the
setting of slen, but you tell me if the value of ltv.len is variable
or not:

	10.1.3	cnfDesiredSSID
	Word Offset		Field name			Size (words)
	0				RecordLen: 18		1
	1				RID: FC02			1
	2				cnfDesiredSSID		17

	Field descriptions:
		Name:	CnfDesiredSSID
		Description: Identifies the Service Set the station is to connect to.
				 A zero length string indicates 'any' SSID.
		Format:	Byte String
		Values:	Range: StringLen: 0..32; Default: StringLen = 0

and the definition of Byte String is:
	Byte String		2 or more consecutive Words. The first Word is an Integer
					and the remainder is a Byte Area. The Integer contains the
					StringLen value, which indicates the number of significant
					bytes (0 or more) that are consecutively stored in the Byte
					Area, starting with the least-significant Byte of the Word
					that follows the Integer. If the Integer value is odd, the
					last Byte is located in the least-significant byte of the
					Word in which it is stored.

(Apologies for the formatting, but it's an RTF doc which I converted to TXT).


>
> Finally, some random things I noticed:
> Is ctrl->xclear initialised anywhere?

It's default value is 0 (include clear packets) and is initialised
when the Ctlr structure is created.

> The linux driver is full of htoas etc. translations
> (the BUGS section of the plan9 driver mentions need for endian checks).
> The linux driver allocates WNameLen+1 sized name buffers
> in its Ctrl struct (instead of WNameLen, which we do).

After looking at the above problems I'm going to go over the driver again
and try to weed out some of the endian issues before they come back to bite
us. I note, for instance, that the definition of the Wltv struct will not
work on an alpha (not that I can try that as our only alpha died last week).

> Wrt the 0x01 character appearing after the 'Current name' field
> in ifstats: I could not find where it comes from. From the card?
> I don't think the linux driver reads stuff back from the card,
> at least not in the same way as the plan9 one, I think
> (or, again, could be that I did not look far enough).
>
> Axel.

If we didn't use the stuff we write, we'd never find out how many bugs
it has. Thanks for taking the time to work over it.

--jim

Re: [9fans] wavelan config problems

[Axel Belinfante]

> On Thu Apr 12 09:18:24 EDT 2001, Axel.Belinfante@cs.utwente.nl wrote:
> > Oops. My debugging was erroneous: the failing w_cmd was _not_ for the
> > strings writing, but for cmd type 0xfc22 meaning WType_XClear.
> > For that request, in w_cmd the test (rc&WresSts) succeeds, causing it
> > to return failure.
> > What does this WresSts actually mean?
>
> You probably have as much information about the hardware as I do, we failed
> miserably to get any real documentation out of the Wavelan group.

I'm sorry to hear that.

> > Moreover, I had a second look at the strings writing in the linux driver.
[snip]
> > I.e. ltv.len is not taken from the sizeof the record, but takes
> > the variable length of the string into account, rounded up to even.
> > ltv.slen is just the length of the string.
>
> Here are the words from the HCF-Lite docs, clearly we're wrong in the
> setting of slen, but you tell me if the value of ltv.len is variable
> or not:
>
> 	10.1.3	cnfDesiredSSID
> 	Word Offset		Field name			Size (words)
> 	0				RecordLen: 18		1
> 	1				RID: FC02			1
> 	2				cnfDesiredSSID		17

Seems to be pretty fixed (non-variable). Seems I looked to much at the
linux driver, believing what I was reading there to be the truth...

> > The linux driver is full of htoas etc. translations
> > (the BUGS section of the plan9 driver mentions need for endian checks).
> > The linux driver allocates WNameLen+1 sized name buffers
> > in its Ctrl struct (instead of WNameLen, which we do).
>
> After looking at the above problems I'm going to go over the driver again
> and try to weed out some of the endian issues before they come back to bite
> us. I note, for instance, that the definition of the Wltv struct will not
> work on an alpha (not that I can try that as our only alpha died last week).

I'm glad to hear that (you going over the driver, not the alpha dying).

> If we didn't use the stuff we write, we'd never find out how many bugs
> it has. Thanks for taking the time to work over it.

You are more than welcome - it is the least (and right now, probably the
only thing) I can do to give something back.

Axel.

Re: [9fans] wavelan config problems

[Axel Belinfante]

> :  Wrt the 0x01 character appearing after the 'Current name' field
> :  in ifstats: I could not find where it comes from. From the card?
> :  I don't think the linux driver reads stuff back from the card,
> :  at least not in the same way as the plan9 one, I think
> :  (or, again, could be that I did not look far enough).
>
> I tried to get all the stats from the card, not from the driver code.
> The linux driver uses its own variables instead; But I think it's
> better to get values from the card---that way you know that it is the
> card (and not the driver) who agrees with those values.

Agreed wholeheartedly(sp?)!
Looking back at my previous emails in this thread: because the linux
driver was (is) the only source of information that I have next to
the plan9 driver, and because it (seems to) work(s), I (subconsciously)
took it too easy as 'the definition' (which it isn't, as Jim showed).

Thanks for looking into it (and for the driver, of course!),
Axel.

Re: [9fans] wavelan config problems

[nemo]

:  Wrt the 0x01 character appearing after the 'Current name' field
:  in ifstats: I could not find where it comes from. From the card?
:  I don't think the linux driver reads stuff back from the card,
:  at least not in the same way as the plan9 one, I think
:  (or, again, could be that I did not look far enough).

I tried to get all the stats from the card, not from the driver code.
The linux driver uses its own variables instead; But I think it's
better to get values from the card---that way you know that it is the
card (and not the driver) who agrees with those values.

Re: [9fans] wavelan config problems

[nemo]

> Yes, that indeed looks wrong (nemo, any idea why it's that way?).
> Can you bug the w_cmd to find what the error is? perhaps the timeout loop
> is too short.

Sorry, I have been diving these days and couldn't read my mail.
I'll take a look to all this and drop a line in case I find out
what's happening...

Re: [9fans] wavelan config problems

[Axel Belinfante]

> > 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.
>
> Yes, that indeed looks wrong (nemo, any idea why it's that way?).
> Can you bug the w_cmd to find what the error is? perhaps the timeout loop
> is too short.

(Some answers follow below.)
Oops. My debugging was erroneous: the failing w_cmd was _not_ for the
strings writing, but for cmd type 0xfc22 meaning WType_XClear.
The linux driver on the cd that came with the card doesn't do anything
about this request (or I overlooked it). (driver: WVLAN49)
For that request, in w_cmd the test (rc&WresSts) succeeds, causing it
to return failure.
What does this WresSts actually mean?
Can it be that this is not available in all cards?
Or that the code (ltv.type) is wrong?

Moreover, I had a second look at the strings writing in the linux driver.
What they do there amounts to the following in ltv_outstr:

	// set len = strlen(val); or less if val too long
	...
	ltv.len = 2 +((len+1) & ~1)/2;
	ltv.type = type;
	ltv.slen = len;
	...

I.e. ltv.len is not taken from the sizeof the record, but takes
the variable length of the string into account, rounded up to even.
ltv.slen is just the length of the string.

Finally, some random things I noticed:
Is ctrl->xclear initialised anywhere?
The linux driver is full of htoas etc. translations
(the BUGS section of the plan9 driver mentions need for endian checks).
The linux driver allocates WNameLen+1 sized name buffers
in its Ctrl struct (instead of WNameLen, which we do).

Wrt the 0x01 character appearing after the 'Current name' field
in ifstats: I could not find where it comes from. From the card?
I don't think the linux driver reads stuff back from the card,
at least not in the same way as the plan9 one, I think
(or, again, could be that I did not look far enough).

Axel.

Re: [9fans] wavelan config problems

[jmk]

On Wed Apr 11 10:39:24 EDT 2001, Axel.Belinfante@cs.utwente.nl wrote:
> > 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.

As it says in plan9.ini(8), the configuration defaults to managed mode with
encryption on if it is determined that the card supports it. In this case, as
you determined, encryption must be explicitly turned off if you don't want
to use it.

> 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.

Yes, that indeed looks wrong (nemo, any idea why it's that way?).
Can you bug the w_cmd to find what the error is? perhaps the timeout loop
is too short.

> 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)?

I believe the key numbers must match between the station and the access
point. Note that when you issue a 'keyX=YYYYY' the active key used by
the card will chanage to 'X' (actually X-1, see below), so if you have
	key1=foo key2=bar
in the config line you will be using key 2.

> 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.

Yes, the internal key slots are 0-3 while the external values used in
the ctl commands are 1-4. This was a concession to the Windows software
which numbers them 1-4; not everyone can map between the 2 easily...

> 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

Again, the ifstats check is a bug, it should be checking against
ctlr->hascrypt. The way encryption was set up and managed changed quite
a few times as the code was added and experience gained; that remnant
escaped me.

>
>
> > 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.

The fact that you could find these bugs by looking at the driver shows why
we changed to the driver nemo wrote (I added the encyption stuff), the
old driver was a valiant effort by a summer student but was unmaintainable.

>
> 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.

Thanks for the feedback.

--jim

Re: [9fans] wavelan config problems

[Axel Belinfante]

> 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.

Re: [9fans] wavelan config problems

[jmk]

This is what I use on my Thinkpad T21A:
	ether0=type=wavelan port=0x180 irq=10 essid=Our-Net key2=Our-Long-Key

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.

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.

--jim

[9fans] wavelan config problems

[Axel Belinfante]

I have been trying to get a wavelan/orinoco card working using the
driver in the March 27 distribution, without success.
(In the mean time I applied to portclock.c fix).
On the same laptop the card works without problems for win98 and linux.

I did not have a working plan9 network (card) on this laptop before, so I'm
configuring the network stuff at the same time. Could errors (or omissions)
made there explain my problems? I try to 'hardcode' the ip-gateway, ip-address
and network mask in the ip/ipconfig line in /rc/bin/termrc, but that doesn't
make much of a difference.

To sketch what is happening: say, our managed network name is OUR-NAME
(different, actually, but indeed all caps and including a hyphen)
Encryption keys shgo

In the plan9.ini I have:
ether0=type=wavelan

without anything else.
After booting, one green led on the card is on.
However, it seems that for each packet sent I get a transmit error.
At least, that is what I see in the stats window, and also in the
/net/ether0/0/ifstats and /net/ether0/0/stats status files.
However, stats reports one more packets sent than ifstats,
but the same number of errors. i.e.: stats: in=2 out=2 output-errors=1;
ifstats txpackets=0 rxpackets=0 txerrors=1 rxerrors=0 txrequests=1.
Does that mean that one packet got out without error?

/net/ether0/0/ifstats reports a.o. the following:
Current name: OUR-NAME\01
Net name: First WaveLAN II SSID

where the \01 represents hex 01. Wonder where the \01 comes from.

In attempt at debugging, I changed etherwavelan.c to check the return
value of the w_cmd call in w_outltv, in the same way as elsewhere
in the file, but this doesn't seem to give me much, becaue I get an
error message for each config command that I sent to the driver,
like: echo 'crypt on' > /net/ether0/0/ctl .


Earlier I tried to use a plan9.ini with
ether0=type=wavelan essid=OUR-NAME

which gives me in /net/ether0/0/ifstats
Current name: non-specified SSID!!
Net name: OUR-NAME

and the green led on the card is off.

Does this make sense to anyone?
I really have the feeling that I'm overlooking something simple...
Some things I could check/do to get more grip on the problem?


Regards,
Axel.