> 2) Today it doesn't reproduce. Plink establishment passes, altough, w=
arning remains:
>=20
> 3) Beaconing works, but not the way it should: like MPs don't hear ea=
ch other. Timestamps never get in sync
> and both MPs issue beacon during 0.1s beacon interval.
> I've seen it before, with stlc45xx. It shows when LMAC is set up with=
LMAC_SETUP_IBSS | LMAC_SETUP_TRANSPARENT flags.
> If there's no LMAC_SETUP_TRANSPARENT flag in LMAC setup then timestam=
ps get in sync.
=46YI: The TSF will always reset when a new beacon is submitted to the =
firmware.
The specs talks about that.
> 4) Pings don't go, because MPs don't answer ARP requests sent to it. =
Haven't tested for the root cause yet.
> But again, I have seen this with stlc45xx with two different causes:
> - when LMAC was set up without LMAC_SETUP_TRANSPARENT flag, ARP reque=
sts didn't pass LMAC packet filter
> and weren't reported to the driver;
Yup, that's because the firmware will filter out any frames which are n=
ot from/for the BSSID.
(the bssid the field right next to the device own MAC in p54_setup_mac)
> - when LMAC was set up with LMAC_SETUP_TRANSPARENT flag firmware seem=
to truncate last 2 bytes of the packet
> that it reports.
Heh, that's also a ISL3887 (USB 2nd gen) bug... But PCI devices are not=
affected.
The reason "why" has probably to do with the firmware's frame alignment=
code.
Unfortunately the firmware for (ISL3887 and SPI) is rounding "down" to =
4 bytes instead of up...
So the FCS will be clipped... But fortunately the firmware set a bit in=
the header that tells
us whenever the frames was corrupted or not (P54_HDR_FLAG_DATA_IN_FCS_G=
OOD).
what happens if you change p54spi_rx the following way:?=20
- skb =3D dev_alloc_skb(len);
+ skb =3D dev_alloc_skb(len + 4);
if (!skb) {
dev_err(&priv->spi->dev, "could not alloc skb");
return 0;
}
p54spi_spi_read(priv, SPI_ADRS_DMA_DATA, skb_put(skb, len), len=
);
p54spi_sleep(priv);
+ skb_put(skb, 4);=20
if (p54_rx(priv->hw, skb) =3D=3D 0)
dev_kfree_skb(skb);
=20
> > Is there anything else I can do, or something you want to know?
> Are there other p54 species that use 3826.arm firmware?
I guess no... there are pci/usb/spi and shmem devices but all have thei=
r own firmware.
> Are there other sources of information regarding LMAC interaction exc=
ept
> http://wireless.kernel.org/en/developers/Documentation/specs?action=3D=
AttachFile&do=3Dget&target=3DSTSW45x0C_LMAC_API_ED1P4.pdf ?
hmm, maybe the old islsm... But then, this driver is very old now...
=20
> Who should be contacted with questions about firmware behavior?
>=20
No idea, maybe nokia knows... because the "frame alignment" can also cl=
ip QoS-(Data) or WDS Frames.
Regards,
Chr
____________________________________________________________________
Psssst! Schon vom neuen WEB.DE MultiMessenger geh=F6rt?=20
Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3D3124
>> 3) Beaconing works, but not the way it should: like MPs don't hear e=
ach other. Timestamps never get in sync
>> and both MPs issue beacon during 0.1s beacon interval.
>> I've seen it before, with stlc45xx. It shows when LMAC is set up wit=
h LMAC_SETUP_IBSS | LMAC_SETUP_TRANSPARENT flags.
>> If there's no LMAC_SETUP_TRANSPARENT flag in LMAC setup then timesta=
mps get in sync.
>
> FYI: The TSF will always reset when a new beacon is submitted to the =
firmware.
> The specs talks about that.
I'd like to make it clear: there are timestamp field in the beacon and
timestamp associated with the received packet. These two do not
correlate. First gets reset at beacon submission (and why firmware
wouldn't pick up timestamp from the submitted beacon?). The second
only gets reset on firmware reset. And it seems to me that there's no
way to find out, what the current value of beacon timestamp is. TSF
reported in p54_rx_data is the second.
And if so, how timestamp syncing is expected to work in the following c=
ase:
<7>[ 353.579189] RX beacon SA=3D00:1d:6e:9b:ee:6d
BSSID=3D7e:2e:03:09:31:25 TSF=3D0x4aaa81 BCN=3D0x618f1f6 diff=3D-974047=
89
@1513
<7>[ 353.579250] wlan0: beacon TSF higher than local TSF - IBSS merge
with BSSID 7e:2e:03:09:31:25
After which stack submit new beacon which we send to LMAC, effectively
resetting timestamp in our beacon and not affecting TSF that we would
report on the next received frame.
I see constant beacon resubmission cycle. How does it work on pci/usb p=
54?
>> - when LMAC was set up with LMAC_SETUP_TRANSPARENT flag firmware see=
m to truncate last 2 bytes of the packet
>> =A0 that it reports.
> Heh, that's also a ISL3887 (USB 2nd gen) bug... But PCI devices are n=
ot affected.
> The reason "why" has probably to do with the firmware's frame alignme=
nt code.
> Unfortunately the firmware for (ISL3887 and SPI) is rounding "down" t=
o 4 bytes instead of up...
> So the FCS will be clipped... But fortunately the firmware set a bit =
in the header that tells
> us whenever the frames was corrupted or not (P54_HDR_FLAG_DATA_IN_FCS=
_GOOD).
Thank you for the explanation, it made me feel much better (:
> what happens if you change p54spi_rx the following way:?
Actually, I did this kind of thing. And it works this way.
But I considered it a major hack, as noone acknowledged that there's a
firmware problem:
https://garage.maemo.org/pipermail/stlc45xx-devel/2009-January/000126.h=
tml
But if there's real problem in firmware, I'd consider it mere
workaround and put it back.
--=20
Max