search

ARMmbed / mbed-client-example-6lowpan

DEPRECATED: Example demonstrating 6LoWPAN mesh networking
https://cloud.mbed.com/docs/current
Other
19 stars 13 forks source link

Thread networking procedure and porting RF module problem #72

Closed SYuPing closed 8 years ago

SYuPing commented 8 years ago

Hi, I have two different testing senario which are both connect to a same gateway router for testing and verifying. I will explain what kind of problems I faced below.

The first testing senario is using k64f+6lowpan shield connect to gateway. Yes, this is the standard processing of this example, and also I used a sniffer to monitor the format of transmition packet. So, here is a question that before the k64f join to gateway router, why I can't observe the "Beacon Request" which is sent by k64f to request a network connection?

And the second testing senario which is that I want to port another RF module (uz2400) to replace the 6lowpan shield and exchange the atmel-rf-driver to this RF module's device driver code also, but the question as below.

  1. When the k64f+uz2400 try to connect to gateway, the frame packet (k64f+uz2400) is almost same as the frame packet which is from k64f+6lowpan shield are watched by sniffer, but the differnent is a packet from k64f+6lowpan will carry a ACK.req bit and let gateway response one ACK frame which length is 5, but the frame sent by k64f+uz2400 would not carry ACK.req. This problem let my device (k64f+uz2400) can't join to the thread network..., so is any condition which I shouldn't satisfied? Or what should I do to solve this problem?
  2. Also, the function "rf_address_write" where is to write the short addr, EUI 64 addr, PANID which are set into RF module. In k64f+6lowpan shield case, the address not only 16 but 64 is just read from RF module? Because in my device, the value of addr is by the device inside settings, just PANID is same as 6lowpan shield, is this correct? or it means my RF driver registeration fail? but the return value of rf_driver_register is 0, not -1, -2..etc.

Thanks.

ciarmcom commented 8 years ago

ARM Internal Ref: ONME-2557

mikter commented 8 years ago

Here is the answer to the following question "before the k64f join to gateway router, why I can't observe the "Beacon Request" which is sent by k64f to request a network connection? "

Thread does not use Beacons when attaching to an already known network. Beacons are used only in following cases:

kjbracey commented 8 years ago

"the frame sent by k64f+uz2400 would not carry ACK.req. This problem let my device (k64f+uz2400) can't join to the thread network."

Your driver/radio should be transmitting the Ack Request bit as set in the frame data. If for some reason your device can't set the Ack Request bit, I think it could still work as long as you issue the "PHY_LINK_TX_DONE" callback immediately when finished instead of "PHY_LINK_TX_SUCCESS", so the stack doesn't wait for an Ack.

I don't believe other devices should mind if you don't set the Ack Request bit. It just means you won't get acks, and you so you won't attempt MAC-level retransmits.

"In k64f+6lowpan shield case, the address not only 16 but 64 is just read from RF module? Because in my device, the value of addr is by the device inside settings, just PANID is same as 6lowpan shield, is this correct?"

The stack has various public and private APIs which can change the various addresses.

rf_address_write is where the stack tells the driver what addresses to use - set your RX filters appropriately.

On a normal (Thread) set-up, the 16-bit ID is automatically assigned, and (I think) the PAN ID is controlled by the application, maybe with an auto-reassignment on collision. The 64-bit address passed to rf_address_write may or may not be derived from the EUI-64 the driver passed to the stack as PHY_MAC on registration.

You should always set the 64-bit address the stack tells you to. Thread in particular may require you to use different MAC addresses at different start-up stages.

kjbracey commented 8 years ago

Ah, I've just realised one issue. If you are not setting the AR bit, when the header from the stack had it set, then you have modified the header.

If you modify the header, the Message Integrity Check of a integrity-protected secure packet will fail. So you must transmit the entire packet, including header, unmodified.

That will block you.

TuomoHautamaki commented 8 years ago

SYuPing, are you happy with the answers provided, this issue can be closed?

SYuPing commented 8 years ago

I'm very appriciate your suggestion and what your meaning is I have to call rf_address_write in a period time not just in the beginning? If that, I'll try it. And I'd like to show something for you...

Here are the packets from ATmel 6lowpan shield TX Buffer and my device what I observe by sniffer,as below,

ATmel 6lowpan shield 41 C8 A7 FA DE FF FF 94 B1 04 00 00 3D C2 FE 7C 3B FF 02 F0 4D 4C 4D 4C B2 CE 00 15 00 00 00 00 00 00 00 00 01 EC 7E 3C 06 AD A9 D6 A5 B7 34 C8 04 DD 75 73 79 FB E5 E6 60 2C C9 2C BA 80

my RF module (uz2400) 41 C8 A7 FA DE FF FF 94 B1 04 00 00 3D C2 FE 7C 3B FF 02 F0 4D 4C 4D 4C 40 38 00 15 00 00 00 00 00 00 00 00 01 EC 7E 3C A3 00 9D 9A 39 BB 5A 7A 04 DD 75 73 79 FB E5 E6 60 2C 02 A3 A9 D3

After I analysis this two packets, The MAC Header is : | 41 C8 | A7 | FA DE | FF FF | 94 B1 04 00 00 3D C2 FE | | (FCF) | (Seq#)| (PanID) | (SrcAddr) | (DstAddr) |

The LowPAN_IPHC Header is : | 7C 3B | | FF | 02 | | F0 4D 4C 4D 4C 40 38 | | IPHC | | HL | DAM | |UDP Header + SrcPort + DstPort + Check SUM |

Before here, my RF module packet is same as ATmel's, but... the following : 00 15 00 00 00 00 00 00 00 00 01 EC 7E 3C A3 00 9D 9A 39 BB 5A 7A 04 DD 75 73 79 FB E5 E6 60 2C 02 A3 A9 D3

I really don't understand what's the meaning for, is my analysis correct ? If it's correct, what's the meaning of the packet behind the CheckSum? is MLE command? or TVL format? or others?...and are these the reasons why I couldn't connect sucessfully?

Many Thanks.

kjbracey commented 8 years ago

rf_address_write will be called by the stack to change address filters at various points during run-time. You must support modifying the address filters while running.

Analysis is correct, except you have src addr and dst the wrong way round. Destination is FFFF (broadcast), source is 94:B1:04:00:00:3D:C2:FE. Which means your HW extended address filter should already have been set to that by rf_address_write.

It seems odd to me that both modules are using the same MAC source. In the Atmel driver, the MAC is read from an EEPROM on the module. Is that what you passed to the stack as PHY_MAC for the UZ2400? Did you hard-code this?

Those packets are secured MLE packets (UDP port 19788, first payload byte 0). Can't decode further than that, because they're secured. They should be some sort of association request. If the other node responds to the Atmel version of the packet, but not the UZ2400 it suggests one of:

1) FCS wrong (unlikely, if hardware computed it) 2) UDP checksum wrong (because source MAC is wrong, so source IP derived from it is wrong?) 3) Message Integrity Check in secured MLE packet fails (because key is wrong? Probably not - should be same as Atmel.) 4) Gateway is confused because you're using the same MAC as a different device.

Standard Wireshark can decode IEEE 802.15.4 and 6LoWPAN - I suggest you use it to confirm that the UDP checksum and IEEE 802.15.4 FCS are correct.

SYuPing commented 8 years ago

OK, I'll try to check the address filters condition of my RF module, and What 3) Message Integrity Check in secured MLE packet fails (because key is wrong? Probably not - should be same as Atmel.) as you said, Is there any way to check the key or to configure it?

Also, Can you explain the meaning of the first packet for me? For example, The meaning of the first message may be a joinner protocol what is defined in Thread spec. Just indicate what kind of message(what's the MLE message type? the TLV type? or Commission CoP procedure?) to be sent for me...

BTW, I still have some problem of secured MLE format need for help, but it may go through some source codes, I think it is not suitable for list them here, I'll make a new issue in somewhere, thank you very mush.

kjbracey commented 8 years ago

I'm not seeing much value in you performing deep investigation of what the packets contain. You're writing a network driver.

Pretty much all you have do is transmit the packets you're asked to, without modifying them, and deliver the packets your receive (according to the correct filter) without modifying them. If what gets passed to/from Nanostack matches what you see with the sniffer, there should be no issue.

Unfortunately public Wireshark contains no MLE support, so you don't have a way to check the MLE MIC. I don't think that is likely to show errors not already shown by the UDP checksum though. (Don't forget to enable UDP checksum verification - it's disabled by default in Wireshark).

If you can confirm that you're accurately transmitting and receiving, but the gateway isn't talking to you, and you haven't otherwise modified the test application other than substituting the driver, something a little more mysterious is happening. We may be able to advise if a pcap trace from the sniffer is posted.

SYuPing commented 8 years ago

Many thanks for @kjbracey-arm , @mikter , @TuomoHautamaki's suggestions, and sorry for my lack of knowledge... My rf-module can connect to mDS and also can read information by clicking the buttons from mDS, the problem is 1) I observed rf-module running under promiscous mode, but this mode may not auto-ack.. 2) My rf-module receive mode is diveded into unsecurity and security mode, it means that it should use two different kinds of method for (un-)/secure packets.

After I solve this two issues, the rf-module could connect to mDS and transmit data sucessfully. Many thanks for your supports and suggestions, these let me learn a lot!

Please close this issue, and thank you vey much!