Re: [9fans] wavelan config problems

[Axel Belinfante <Axel.Belinfante@cs.utwente.nl>]

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