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

Ivano Calabrese alphaemmeo at gmail.com
Mon Oct 20 09:37:52 CEST 2014


Hi Thomas,
friday I solved the issue above. This morning before to sent you a mail, I
notice you just fixed this problem.
In a nutshell in my  .../RIOT/sys/shell/commands/sc_transceiver.c file
there was not  p.frame.fcf.src_addr_m = IEEE_802154_SHORT_ADDR_M; line.

Thanks a lot

____________________________________
*Ivano Calabrese*, MSc.
http://www.dei.unipd.it/~icalabre/
https://www.linkedin.com/in/ivanocalabrese

On 17 October 2014 17:20, Thomas Eichinger <thomas.eichinger at fu-berlin.de>
wrote:

> 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
>
>
> 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/
> https://www.linkedin.com/in/ivanocalabrese
>  _______________________________________________
> devel mailing list
> devel at riot-os.org
> http://lists.riot-os.org/mailman/listinfo/devel
>
>
>
> _______________________________________________
> 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/20141020/4e12b561/attachment-0001.html>


More information about the devel mailing list