• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 56 subscribers
  • Views 862 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

CC2530: Device Announcement, but not added to the Device List - ZIGBEE-LINUX-SENSOR-TO-CLOUD_1.0.1

CC2530: Network Route Request - No response from ZED because of encryption ? - ZIGBEE-LINUX-SENSOR-TO-CLOUD_1.0.1

Mario DW
Genius 3145 points

Part Number: CC2530

I am trying to understand the difficulties of associating ZEDs with the gateway.

In one of the steps, a Route Request is sent:

[2020-12-08 11:49:10.460930] < [AF/SREQ]        _20|04:02_  **DATA_REQUEST_EXT** #236 < EP:01 PAN:4F5D> {SRC EP:01 CLSTR:0402} TXOPT:00() RADIUS:30      ( 30)::fe19240202e32ebebebebebebe015d4f010204ec001e050000ec000000ff
[2020-12-08 11:49:10.477126] [RFSNIFFER]    42        0x0000 â†Broadcast    ZigBee 51 Route Request, Dst: 0x2ee3, Src: 0x0000^M
[2020-12-08 11:49:10.480875] > [AF/SRSP]        .60|04:02.  **DATA_REQUEST_EXT**        ZSuccess         (  6)::fe0164020067

But the ZED does not reply:

[2020-12-08 11:49:11.071923] > [AF/AREQ]         40|04:80   **DATA_CONFIRM** ZNwkNoRoute EP:01 Seq:236   (  8)::fe034480cd01ece7

I notice that the Route Request uses encryption:

Frame 1: 51 bytes on wire (408 bits), 51 bytes captured (408 bits) on interface unknown, id 0
    Interface id: 0 (unknown)
        Interface name: unknown
    Encapsulation type: IEEE 802.15.4 Wireless PAN (104)
    Arrival Time: Dec  8, 2020 12:48:03.232367000 Paris, Madrid
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1607428083.232367000 seconds
    [Time delta from previous captured frame: 0.000000000 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 0.000000000 seconds]
    Frame Number: 1
    Frame Length: 51 bytes (408 bits)
    Capture Length: 51 bytes (408 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: wpan:zbee_nwk]
IEEE 802.15.4 Data, Dst: Broadcast, Src: 0x0000
    Frame Control Field: 0x8841, Frame Type: Data, PAN ID Compression, Destination Addressing Mode: Short/16-bit, Frame Version: IEEE Std 802.15.4-2003, Source Addressing Mode: Short/16-bit
        .... .... .... .001 = Frame Type: Data (0x1)
        .... .... .... 0... = Security Enabled: False
        .... .... ...0 .... = Frame Pending: False
        .... .... ..0. .... = Acknowledge Request: False
        .... .... .1.. .... = PAN ID Compression: True
        .... .... 0... .... = Reserved: False
        .... ...0 .... .... = Sequence Number Suppression: False
        .... ..0. .... .... = Information Elements Present: False
        .... 10.. .... .... = Destination Addressing Mode: Short/16-bit (0x2)
        ..00 .... .... .... = Frame Version: IEEE Std 802.15.4-2003 (0)
        10.. .... .... .... = Source Addressing Mode: Short/16-bit (0x2)
    Sequence Number: 4
    Destination PAN: 0x4f5d
    Destination: 0xffff
    Source: 0x0000
    TI CC24xx-format metadata: FCS OK
        FCS Valid: True
        RSSI: 20 dB
        LQI Correlation Value: 108
ZigBee Network Layer Command, Dst: Broadcast, Src: 0x0000
    Frame Control Field: 0x1209, Frame Type: Command, Discover Route: Suppress, Security, Extended Source Command
        .... .... .... ..01 = Frame Type: Command (0x1)
        .... .... ..00 10.. = Protocol Version: 2
        .... .... 00.. .... = Discover Route: Suppress (0x0)
        .... ...0 .... .... = Multicast: False
        .... ..1. .... .... = Security: True
        .... .0.. .... .... = Source Route: False
        .... 0... .... .... = Destination: False
        ...1 .... .... .... = Extended Source: True
        ..0. .... .... .... = End Device Initiator: False
    Destination: 0xfffd
    Source: 0x0000
    Radius: 30
    Sequence Number: 62
    Extended Source: TexasIns_00:10:22:82:77 (00:12:4b:00:10:22:82:77)
    ZigBee Security Header
        Security Control Field: 0x28, Key Id: Network Key, Extended Nonce
            ...0 1... = Key Id: Network Key (0x1)
            ..1. .... = Extended Nonce: True
        Frame Counter: 32872
        Extended Source: TexasIns_00:10:22:82:77 (00:12:4b:00:10:22:82:77)
        Key Sequence Number: 0
        Message Integrity Code: 617b609c
        [Key: 94fa2f43dd315a747987a1a2bbd9f2fa]
        [Key Label: 22]
    Command Frame: Route Request
        Command Identifier: Route Request (0x01)
        Command Options: 0x00, Many-to-One Discovery: Not Many-to-One
            .0.. .... = Multicast: False
            ..0. .... = Extended Destination: False
            ...0 0... = Many-to-One Discovery: Not Many-to-One (0x0)
        Route ID: 64

I read the Zigbee specifciation 3.4.1 "Route Request Command", and read in 3.4.1.1 that the MAC Data Service Requirements indicates "The frame control field shall be set to specify that the frame is a MAC data frame with MAC security disabled, ..."

So I wonder if a ZED must respond to this request if it is encrypted and if the existance of section 3.4.1.1 does not simply mandate the use of the unencrypted MAC Data Service.

What is the right interpretation?

  • 0
    Genius 3145 points

    I'll reply to myself as I just understood the subtletee:

    - The MAC Layer could have its own encryption, but it does not in this case,

    - Instead, the NWK Layer encryption is used.

    However the NWK Destination is set to 0xfffd which means that only devices that have RxOnwhenIdle will respond.

    In this case the ZED is such a device (even it it is no a router), so it seems that in theory it should respond.

  • 0 in reply to Mario DW
    TI__Guru**** 221977 points

    Hello Mario,

    Nodes will only respond to Route Requests if they are routing devices, the parent ZR should respond to the Route Request in place of the ZED.  If the ZC is the parent then child information should already be stored inside its association tables and no Route Request need be sent in the first place.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Genius 3145 points

    Ok, as a result of this explication, I need to find out why the gateway requests/sends route requests when it is the parent.

    However, my reading of the specification indicates that always on ZEDs should also respond.

    Excerpt:

    "The route reply command allows the specified destination device of a route request command to inform the originator of the route request that the request has been received. It also allows ZigBee routers along the path taken by the route request to establish state information that will enable frames sent from the source device to the destination device to travel more efficiently."

    The word "also" suggests that routers are not the same as the "specified destination device".

    Other excerpt:

    "The route request command allows a device to request other devices within radio range to engage in a search for a particular destination device and establish a state within the network that will allow messages to be routed to that destination more easily"

    It seems logical to me that always on ZEDs can (should?) themselves reply to the Network Route request where as sleepy ZEDs should not. 

    This is confirmed by the destination address set in the NWK layer which is 0xFFFD and not 0xFFFC.

    So if the only routers should reply to this request, then the destination address should have been 0xFFFC, which would add the question "why isn't it 0xfffc" in the Gateway/ZSTACK 3.0.2 combination?

  • 0 in reply to Mario DW
    TI__Guru**** 221977 points

    Although 0xFFFD indicates everyone with RxOnWhenIdle = TRUE, NWK_MTO_RTG_REQ_EVT events are only enabled for ZSTACK_ROUTER_BUILD devices.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Genius 3145 points

    As far as I undertstand, NWK_MTO_RTG_REQ_EVT  is only to trigger the requests and does not imply that only coordinators and routers can respond.

    I think that codewise the anwser for the ZSTACK 3.0.2 implementation lies in RTG_ProcessRreq. .

    Whatever the zigbee specification says, if what is implemented is that the ZED does not respond to these requests, then the system has to adapt to that.