Well, first of all, those truncated LTV records are consistent with what I'm seeing. I can also run wellenreiter without problem, but lock up the moment I touch the opie network app or iwconfig
my MAC is also scrambled, but some of the octets are recognizable. But all of our addresses here SHOULD be starting with 00, and they're not. So something is definitely borken
Now let's have a look at this dmesg log, specifically the names of the RIDs that are failing
STAIdentity (I'm betting the firmware revision is NOT 18-thousand some odd number, just a hunch)
hermes @ IO 0xf6000000: Truncating LTV record from 129544 to 8 bytes. (rid=0xfd20, len=0xfd05)
eth0: Station identity 0002:0001:4920:2000
eth0: Looks like a Lucent/Agere firmware version 18720.8192
eth0: Ad-hoc demo mode supported
eth0: IEEE standard IBSS ad-hoc mode supported
eth0: WEP supported, 104-bit key
cnfOwnMACAddress (note this is where the MAC is failing)
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc01) does not match type (0x5e00)
hermes @ IO 0xf6000000: Truncating LTV record from 129030 to 6 bytes. (rid=0xfc01, len=0xfc04)
eth0: MAC address 14:1C:01:00:20:49
cnfOwnName (not really sure what this value should be, but chances are "m I" is going to end up being wrong. Quick google shows me this is probably trying to set "Prism I")
hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc0e) does not match type (0x7200)
hermes @ IO 0xf6000000: Truncating LTV record from 129058 to 34 bytes. (rid=0xfc0e, len=0xfc12)
eth0: Station name "m I"
ChannelListhermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfd10) does not match type (0x72ff)
hermes @ IO 0xf6000000: Truncating LTV record from 129538 to 2 bytes. (rid=0xfd10, len=0xfd02)
cnfSystemScalehermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc06) does not match type (0x72ff)
hermes @ IO 0xf6000000: Truncating LTV record from 129022 to 2 bytes. (rid=0xfc06, len=0xfc00)
RTSThresholdhermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc83) does not match type (0x722b)
hermes @ IO 0xf6000000: Truncating LTV record from 129026 to 2 bytes. (rid=0xfc83, len=0xfc02)
cnfDefaultKey1hermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc25) does not match type (0x722b)
hermes @ IO 0xf6000000: Truncating LTV record from 129022 to 2 bytes. (rid=0xfc25, len=0xfc00)
cnfMaxSleepDurationhermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc0c) does not match type (0x7264)
hermes @ IO 0xf6000000: Truncating LTV record from 129026 to 2 bytes. (rid=0xfc0c, len=0xfc02)
cnfPMHoldoverDurationhermes @ IO 0xf6000000: hermes_read_ltv(): rid (0xfc0d) does not match type (0x7264)
hermes @ IO 0xf6000000: Truncating LTV record from 129026 to 2 bytes. (rid=0xfc0d, len=0xfc02)
eth0: ready
eth0: index 0x01: Vcc 3.3, irq 39, io 0xf6000000-0xf6000047
I also doubt each of these messages is supposed to be in excess of 128k.
I'm no kernel debugger here, but let's take a look at the MAC address record, for one:
hermes @ IO 0xf6000000: Truncating LTV record from 129030 to 6 bytes.
That makes sense. A MAC address should be 6 bytes long, not 129030. So it appears that we are doing the correct thing by truncating these records, but what we need to find out is why these records are over one hundred thousand bytes long to begin with.
Now, it appears that hermes.c defines the hermes_read_ltv function, which is called by orinoco.c - so that PROBABLY means that orinoco.c is doing Something Wrong or is being passed bad data from spectrum_cs.
It might be worthwhile checking what paramaters we can pass to these modules at load time, but gut feeling here is that these modules will need to be recompiled.
EDIT:
Looking at the following:
The other weird part is the mis-interpretation of the MAC address, it is really:
MAC 00 A0 F8 5E 14 1C
instead of the
MAC address 14:1C:01:00:02:88 that is shows above
We see that it seems to be getting the last 2 bytes of the MAC correct, but setting them as the FIRST two bytes in software (the rest is probably junk data).
Also noticing that in the cnfOwnName record, it's getting the last three bytes ("m I") correct. Presumably, it's getting the last four, since the fourth would be a null terminator - which is why we probably don't see any junk data after the "I".
I'm not really sure what this tells us about the driver itself, but it's possible that memory addresses are being shifted/transposed here, which may also have something to do with the length of these LTV records being horribly, horribly WRONG (ie. the variable that stores the record length isn't pointing at record length data).
