From mboxrd@z Thu Jan  1 00:00:00 1970
From: jmk@plan9.bell-labs.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] wavelan config problems
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-Id: <20010412172644.9B85C199E9@mail.cse.psu.edu>
Date: Thu, 12 Apr 2001 13:26:42 -0400
Topicbox-Message-UUID: 818b17e6-eac9-11e9-9e20-41e7f4b1d025

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