[riot-devel] RIOT-OS on telosb, issue with default example

Thomas Eichinger thomas.eichinger at fu-berlin.de
Fri Oct 17 17:20:06 CEST 2014


Hi Ivano,

thanks for reporting this. I just opened a pull request [1] to fix the `trans_p->data` artefact
and an update for the code used by `txtsnd`. Do you mind, testing this with your TelosBs?
(I have mine currently not with me).

Could you give me a pointer where `packet->frame.fcf.src_addr_m` is fixed to 0x12?

Anyways, if the problem persists, could you please open an github issue for this?
Thanks in advance!

Best, Thomas

[1] https://github.com/RIOT-OS/RIOT/pull/1830 <https://github.com/RIOT-OS/RIOT/pull/1830>


> On 17 Oct 2014, at 16:18, Ivano Calabrese <alphaemmeo at gmail.com> wrote:
> 
> Hi guys,
> 
> I installed RIOT-OS on a telosb and I began to discover the several feature starting from the default example.
> Using two telosb with the same program and different addr I'm not able to sent/receive pkt through them. Using a sniffer I could watch the sent packet has wrong fields.
> 
> If I send a message in this way:
> addr 2
> txtsnd 1 hello
> 
> I receive this pkt
> 
>   0 No.     Time           Source                Destination           Protocol Length Info
>   1       1 0.000000000    0x6c6c                0x0000                IEEE 802.15.4 15     Reserved, Dst: 0x0000, Src: 0x6c6c
>   2
>   3 Frame 1: 15 bytes on wire (120 bits), 15 bytes captured (120 bits) on interface 0
>   4 IEEE 802.15.4 Reserved, Dst: 0x0000, Src: 0x6c6c
>   5     Frame Control Field: Unknown (0x8806)
>   6         .... .... .... .110 = Frame Type: Unknown (0x0006)
>   7         .... .... .... 0... = Security Enabled: False
>   8         .... .... ...0 .... = Frame Pending: False
>   9         .... .... ..0. .... = Acknowledge Request: False
>  10         .... .... .0.. .... = Intra-PAN: False
>  11         .... 10.. .... .... = Destination Addressing Mode: Short/16-bit (0x0002)
>  12         ..00 .... .... .... = Frame Version: 0
>  13         10.. .... .... .... = Source Addressing Mode: Short/16-bit (0x0002)
>  14     Sequence Number: 3
>  15     Destination PAN: 0x6012
>  16     Destination: 0x0000
>  17     Source PAN: 0x6568
>  18     Source: 0x6c6c
>  19     FCS: 0xb59a (Correct)
>  20 Data (2 bytes)
>  23     Data: 6f00
>  24     [Length: 2]
> 
> where the hello payload is in Source PAN: 0x6568 (he), in Source: 0x6c6c (ll) and in Data: 6f00 (o).
> I noted that when I send a pkt the packet->frame.fcf.src_addr_m filed (in driver/cc2420/cc2420_tx.c) is fixed to 0x12. In a nutshell when the cc2420_send function is called, the check:
> if (packet->frame.fcf.src_addr_m == 2)
> ...
> else if (packet->frame.fcf.src_addr_m == 3)
> is never matched. 
> 
> ps. In the meant time I found a bug in  DEBUG("transceiver: Content: %s\n", trans_p->data);
> data field isn't define in ieee802154_packet_t trans_p struct.
> ____________________________________
> Ivano Calabrese, MSc.
> http://www.dei.unipd.it/~icalabre/ <http://www.dei.unipd.it/~icalabre/>
> https://www.linkedin.com/in/ivanocalabrese <https://www.linkedin.com/in/ivanocalabrese>
> _______________________________________________
> devel mailing list
> devel at riot-os.org
> http://lists.riot-os.org/mailman/listinfo/devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/devel/attachments/20141017/9f019745/attachment-0001.html>


More information about the devel mailing list