From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <200104171256.OAA07614@polya.cs.utwente.nl> To: 9fans@cse.psu.edu Subject: Re: [9fans] wavelan config problems In-reply-to: Your message of "Thu, 12 Apr 2001 13:26:42 -0400." <20010412172644.9B85C199E9@mail.cse.psu.edu> References: <20010412172644.9B85C199E9@mail.cse.psu.edu> From: Axel Belinfante Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 17 Apr 2001 14:56:21 +0200 Topicbox-Message-UUID: 843f81ca-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. > > 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.