p54spi - mesh mode summary
Quoted 1 line
2) Today it doesn't reproduce. Plink establishment passes, altough, w=
arning remains:
Quoted 2 lines
=20
3) Beaconing works, but not the way it should: like MPs don't hear ea=
ch other. Timestamps never get in sync
Quoted 2 lines
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.
Quoted 1 line
If there's no
LMAC_SETUP_TRANSPARENTflag 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.
Quoted 1 line
4) Pings don't go, because MPs don't answer ARP requests sent to it. =
Haven't tested for the root cause yet.
Quoted 2 lines
But again, I have seen this with stlc45xx with two different causes:
- when LMAC was set up withoutLMAC_SETUP_TRANSPARENTflag, ARP reque=
sts didn't pass LMAC packet filter
Quoted 1 line
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)
Quoted 1 line
- when LMAC was set up with
LMAC_SETUP_TRANSPARENTflag firmware seem=
to truncate last 2 bytes of the packet
Quoted 1 line
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
Quoted 2 lines
Quoted 1 line
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.
Quoted 1 line
Are there other sources of information regarding LMAC interaction exc=
ept
AttachFile&do=3Dget&target=3DSTSW45x0C_LMAC_API_ED1P4.pdf ?
hmm, maybe the old islsm... But then, this driver is very old now... =20
Quoted 2 lines
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
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 1 line
Quoted 1 line
3) Beaconing works, but not the way it should: like MPs don't hear e=
ach other. Timestamps never get in sync
Quoted 2 lines
Quoted 2 lines
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.
Quoted 1 line
Quoted 1 line
If there's no
LMAC_SETUP_TRANSPARENTflag in LMAC setup then timesta=
mps get in sync.
Quoted 2 lines
FYI: The TSF will always reset when a new beacon is submitted to the =
firmware.
Quoted 1 line
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?
Quoted 1 line
Quoted 1 line
- when LMAC was set up with
LMAC_SETUP_TRANSPARENTflag firmware see=
m to truncate last 2 bytes of the packet
Quoted 2 lines
Quoted 1 line
=A0 that it reports.
Heh, that's also a ISL3887 (USB 2nd gen) bug... But PCI devices are n=
ot affected.
Quoted 1 line
The reason "why" has probably to do with the firmware's frame alignme=
nt code.
Quoted 1 line
Unfortunately the firmware for (ISL3887 and SPI) is rounding "down" t=
o 4 bytes instead of up...
Quoted 1 line
So the FCS will be clipped... But fortunately the firmware set a bit =
in the header that tells
Quoted 1 line
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 (:
Quoted 1 line
what happens if you change
p54spi_rxthe 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
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html