sniffer_aggregator problems (A8-M3 nodes)

[fkerem]

Hi,

I have a testbed consisting of a single A8 node as a border router and 8 M3 nodes as sensor nodes. I set the sniffer profiles accordingly and run sniffer_aggregator -i experiment_id -o traffic.pcap. I run the command from the ssh frontend (of the grenoble site that I connected through ssh).

However, this results in a pcap file consisting of all [Malformed Packet: ZigBee] packets. I tried to use the raw option: -r, but the result is same. I also have the same destination and source always.

Example Pcap:

Debug Output:

My Monitoring Profiles:

My Experiment:

When I debug the sniffer, I got the same packets, this is not about the Sniffer software that I'm using (Wireshark).

I can verify that the firmware for the sensors and the border router were flushed correctly:

+++

I created a similar topology purely with M3 nodes. 1 border router and 7 sensor nodes and this time I don't see any packets captured. Am I doing something wrong?

+++

I appreciate your help.

[fsaintma]

Hi @fkerem

For the message "Malformed Packet: Zigbee" I suppose that it's a problem of wireshark dissector because the result of sniffer aggregator is not a Zigbee packet. View this page which explain the sniffer_aggregator output format (pcap-ZEP) : https://www.iot-lab.info/docs/tools/radio-monitoring/#sniffer-additional-informations

After for the src/dest of your packets it's not clear in my mind :) It seems that you use a setup with Contiki firmwares. On my side, I test sniffer_aggregator with a Contiki Border router and HTTP server firmwares (IoT-LAB gitbub repository) and M3 nodes and I can saw RPL packets (DODAG) exchanged between the nodes

You can see a part of the output at the end of this message

Maybe you must try again with a simple setup (only M3 nodes) and try to understand why you don't see the packets ?

Hope that helps you.

saintmar@devgrenoble:~$ sniffer_aggregator -r -d -o - | tshark -V -i -
Using custom api_url: https://devwww.iot-lab.info/api/
1613662668.871265;Aggregator started
....
Frame 17: 97 bytes on wire (776 bits), 97 bytes captured (776 bits) on interface 0
    Interface id: 0 (-)
        Interface name: -
    Encapsulation type: IEEE 802.15.4 Wireless PAN (104)
    Arrival Time: Feb 18, 2021 16:59:47.464464000 CET
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1613663987.464464000 seconds
    [Time delta from previous captured frame: 45.963856000 seconds]
    [Time delta from previous displayed frame: 45.963856000 seconds]
    [Time since reference or first frame: 88.664448000 seconds]
    Frame Number: 17
    Frame Length: 97 bytes (776 bits)
    Capture Length: 97 bytes (776 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: wpan:6lowpan:ipv6:icmpv6]
IEEE 802.15.4 Data, Dst: Broadcast, Src: 02:00:00:00:00:00:c4:68
    Frame Control Field: 0xd841, Frame Type: Data, PAN ID Compression, Destination Addressing Mode: Short/16-bit, Frame Version: IEEE Std 802.15.4-2006, Source Addressing Mode: Long/64-bit
        .... .... .... .001 = Frame Type: Data (0x1)
        .... .... .... 0... = Security Enabled: False
        .... .... ...0 .... = Frame Pending: False
        .... .... ..0. .... = Acknowledge Request: False
        .... .... .1.. .... = PAN ID Compression: True
        .... ...0 .... .... = Sequence Number Suppression: False
        .... ..0. .... .... = Information Elements Present: False
        .... 10.. .... .... = Destination Addressing Mode: Short/16-bit (0x2)
        ..01 .... .... .... = Frame Version: IEEE Std 802.15.4-2006 (1)
        11.. .... .... .... = Source Addressing Mode: Long/64-bit (0x3)
    Sequence Number: 85
    Destination PAN: 0xabcd
    Destination: 0xffff
    Extended Source: 02:00:00:00:00:00:c4:68 (02:00:00:00:00:00:c4:68)
    FCS: 0x3e07 (Correct)
6LoWPAN
    IPHC Header
        011. .... = Pattern: IP header compression (0x03)
        ...1 1... .... .... = Traffic class and flow label: Version, traffic class, and flow label compressed (0x3)
        .... .0.. .... .... = Next header: Inline
        .... ..10 .... .... = Hop limit: 64 (0x2)
        .... .... 0... .... = Context identifier extension: False
        .... .... .0.. .... = Source address compression: Stateless
        .... .... ..11 .... = Source address mode: Compressed (0x0003)
        .... .... .... 1... = Multicast address compression: True
        .... .... .... .0.. = Destination address compression: Stateless
        .... .... .... ..11 = Destination address mode: 8-bits inline (0x0003)
        [Source context: fe80::]
        [Destination context: fe80::]
    Next header: ICMPv6 (0x3a)
    Source: fe80::c468
    Destination: ff02::1a
Internet Protocol Version 6, Src: fe80::c468, Dst: ff02::1a
    0110 .... = Version: 6
    .... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00 (DSCP: CS0, ECN: Not-ECT)
        .... 0000 00.. .... .... .... .... .... = Differentiated Services Codepoint: Default (0)
        .... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    .... .... .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000
    Payload Length: 76
    Next Header: ICMPv6 (58)
    Hop Limit: 64
    Source: fe80::c468
    Destination: ff02::1a
Internet Control Message Protocol v6
    Type: RPL Control (155)
    Code: 1 (DODAG Information Object)
    Checksum: 0x06c6 [correct]
    [Checksum Status: Good]
    RPLInstanceID: 30
    Version: 240
    Rank: 281
    Flags: 0x10, Mode of Operation (MOP): Storing Mode of Operation with no multicast support
        0... .... = Grounded (G): False
        .0.. .... = Zero: False
        ..01 0... = Mode of Operation (MOP): Storing Mode of Operation with no multicast support (0x2)
        .... .000 = DODAG Preference: 0
    Destination Advertisement Trigger Sequence Number (DTSN): 242
    Flags: 0x00
    Reserved: 00
    DODAGID: 2001:660:5307:31c1::b783
    ICMPv6 RPL Option (DODAG configuration)
        Type: DODAG configuration (4)
        Length: 14
        Flag: 0x00
            0000 .... = Reserved: 0
            .... 0... = Authentication Enabled: Not set
            .... .000 = Path Control Size: 0
        DIOIntervalDoublings: 8
        DIOIntervalMin: 12
        DIORedundancyConstant: 10
        MaxRankInc: 896
        MinHopRankInc: 128
        OCP (Objective Code Point): 1
        Reserved: 0
        Default Lifetime: 30
        Lifetime Unit: 60
    ICMPv6 RPL Option (Prefix Information 2001:660:5307:31c1::/64)
        Type: Prefix Information (8)
        Length: 30
        Prefix Length: 64
        Flag: 0x40, Auto Address Config
            0... .... = On Link: Not set
            .1.. .... = Auto Address Config: Set
            ..0. .... = Router Address: Not set
            ...0 0000 = Reserved: 0
        Valid Lifetime: 0
        Preferred Lifetime: 0
        Reserved
        Destination Prefix: 2001:660:5307:31c1::

[fkerem]

Thank you very much for your help and kind response @fsaintma. I carry out a series of experiments to identify the root cause.

1 - M3 vs A8-M3

When I experiment with Contiki (not Contiki-ng) "Border router" and "HTTP server" (or "hello world") examples flashed on M3 boards only, I don't have such a problem. I have IEEE 802.15.4, RPL and 6LoWPAN messages captured correctly:

But, when I create an identical experiment with only A8-M3 boards this time, I capture malformed packets and RPL control messages:

2 - Contiki vs Contiki-NG

Also, when I use Contiki-NG (https://github.com/iot-lab/iot-lab-contiki-ng) but not Contiki (https://github.com/iot-lab/contiki) firmwares, sniffer_aggregator or the sniffers do not work at all. I cannot capture any packets using M3 boards, pcap file is fully empty.

I'll update here as I get more comparable results.

[fsaintma]

@fkerem Just a quick answer for Contiki-NG and only M3 nodes. I have just tried and it worked. Be careful in Contiki-NG the default channel of your firmware is 26 (define IEEE802154_CONF_DEFAULT_CHANNEL 26) It's not the same with Contiki which is positioned at 11 from memory. So use a monitoring profile with the good channel and it should work. After for A8 nodes I have no idea what the problem is. As soon as I have some time I will try. I guess we have a problem in the A8-M3 port with a configuration that doesn't apply and is present for M3.

[fkerem]

Oh yes @fsaintma! Thank you very much, sniffers for M3 nodes with Contiki-NG firmware are working now. Thank you very much, im looking forward to hear from you regarding the A8-M3 nodes.

[fkerem]

Any updates? :)

[fkerem]

Still waiting for help, thank you very much.

[fsaintma]

Hi, sorry for the late answer, I will see that tomorrow and give you my feedback. Best regards.

[fsaintma]

Hi @fkerem I haven't found out why we have these packets :( I will try to investigate more in Contiki-NG port and find the issue. I keep you informed. Best regards.

[fsaintma]

Hi @fkerem, After discussion with a colleague (on the IoT-LAB Strasbourg site) who is doing sniffer tests (BR A8-M3 and M3 nodes) and is not encounter the problem, it is possible that on the Grenoble site we have equipment(s) transmitting near the A8 nodes (located in the false ceilings of the building). It could be a faulty IoT-LAB node or a researcher's equipment. Can you do your tests on the A8 nodes at Saclay site which offers a more radio controlled environment (a room in the building) and tell me if you have these packets? If the problem is only present on the Grenoble site I would have to do maintenance site to find the culprit ... Best regards.

PS: my colleague use the Strasbourg site this afternoon and it's better to use Saclay :)

[fkerem]

Dear @fsaintma, the issue has gone when I used Saclay site today, thank you very much for your help. :)

[fsaintma]

@fkerem Good news for you and bad news for me :) Now I must find on the Grenoble site which hardware send these packets ...

[fkerem]

Oh yes @fsaintma, hope it doesn't take too long for you :) Best wishes,