Thread enable/start problem, Radio not TX

[Catalin I]

Hi everyone,

I am trying to port openThread on a new Radio modem. It compiled fine as FTD on my platform, but Thread doesn't seem to start. I've implemented for now, the functions (that failed linking) from platform/ alarm-milli.h, settings.h, logging.h and partially radio.h (for now I'm just debugging the radio usage).

I am starting openThread on a single node, to observe the behaviour of a network establishment.

My question is that after an initial call to otPlatRadioReceive(), (responding with a null packet), next no more call to any otPlatRadio* functions. Why? 

I see forever "Send Advertisement (ff02:0:0:0:0:0:0:1)" but no call to an actual otPlatRadioTransmit(). 

How should I debug next?

(Btw, I understood diag.h is a debugging for the Radio actual traffic, I don't think I'm there yet, but I'll implement it).

What I've done, basically I've followed the code behind the cli commands:
> panid 0x1234
> ifconfig up
> thread start

(Calling functions in this order: otInstanceInitSingle, otLinkSetPanId, otIp6SetEnabled, otThreadSetEnabled, all returned no error).

And enable the Logging on uart:

[DEBG]-MAC-----: SrcAddrMatch - Cleared all entries

[DEBG]-MAC-----: Idle mode: Radio receiving on channel 11

[INFO]-MAC-----: Frame rx failed, error:NoFrameReceived

[INFO]-MLE-----: Role -> Detached

[INFO]-MLE-----: Attempt to attach

[INFO]-CORE----: Non-volatile: Saved NetworkInfo {rloc:0x0000, extaddr:0000000000000000, role:Disabled, mode:0x00, keyseq:0x0, ...

[INFO]-CORE----: Non-volatile: ... pid:0x0, mlecntr:0x3e9, maccntr:0x3e8, mliid:0000000000000000}

[DEBG]-MLE-----: Store Network Information

[INFO]-MLE-----: Send Parent Request to routers (ff02:0:0:0:0:0:0:2)

[INFO]-MLE-----: Send Parent Request to routers and REEDs (ff02:0:0:0:0:0:0:2)

[INFO]-MLE-----: Allocate router id 9

[INFO]-MESH-CP-: Active dataset set

[INFO]-MESH-CP-: Generated local dataset

[INFO]-MLE-----: Role -> Leader 11862276

[INFO]-MLE-----: Send Advertisement (ff02:0:0:0:0:0:0:1)

[INFO]-MLE-----: Send Advertisement (ff02:0:0:0:0:0:0:1)

Thank you!

[Jonathan Hui]

After "Send Parent Request to routers", you should see the MAC attempt to transmit.  I expect to see something like "[DEBG]-MAC-----: Request to start operation "TransmitData"", but that does not appear in your logs.

Some things I would check:

1. Check if `MeshForwarder::SendMessage()` is being called.
2. Check if `MeshForwarder::ScheduleTransmissionTask()` is being called.
3. Check if `Mac::SendFrameRequest()` is being called.

Hope that helps.  For convenience, I've included the expected log output below:

$ ./ot-cli-ftd 1

[INFO]-CORE----: Notifier: StateChanged (0x1211) [ Ip6+ MLAddr NetData Ip6Mult+ ] 

> panid 0x1234

[INFO]-CLI-----: execute command: panid 0x1234

[WARN]-CORE----: Non-volatile: Error NotFound deleting OperationalDataset

[WARN]-CORE----: Non-volatile: Error NotFound deleting OperationalDataset

Done

> ifconfig up

[INFO]-CLI-----: execute command: ifconfig up

[DEBG]-MAC-----: Idle mode: Radio receiving on channel 11

Done

> thread start

[INFO]-CLI-----: execute command: thread start

[INFO]-MLE-----: Role Disabled -> Detached

[INFO]-MLE-----: AttachState Idle -> Start

Done

> [INFO]-CORE----: Notifier: StateChanged (0x0004) [ Role ] 

[INFO]-CORE----: Non-volatile: Saved NetworkInfo {rloc:0x0000, extaddr:0000000000000000, role:Disabled, mode:0x00, keyseq:0x0, 

[INFO]-CORE----: Non-volatile: ... pid:0x0, mlecntr:0x3e8, maccntr:0x3e8, mliid:0000000000000000}

[DEBG]-MLE-----: Store Network Information

[INFO]-MLE-----: Attempt to attach - attempt 1, any-partition 

[INFO]-MLE-----: AttachState Start -> ParentReqRouters

[INFO]-MLE-----: Send Parent Request to routers (ff02:0:0:0:0:0:0:2)

[DEBG]-MAC-----: Request to start operation "TransmitData"

[DEBG]-MAC-----: Starting operation "TransmitData"

==============================[TX len=063]===============================

| 41 D8 B4 34 12 FF FF 7B | D2 D8 C7 87 14 88 4A 7F | AX44...{RXG...J.

| 3B 02 F0 4D 4C 4D 4C 31 | BE 00 15 00 00 00 00 00 | ;.pMLML1>.......

| 00 00 00 01 05 6A 92 05 | 00 44 F8 74 33 EF B0 0C | .....j...Dxt3o0.

| 47 AD 35 12 B9 B8 06 80 | C9 B2 B0 6D 16 96 34 .. | G-5.98..I20m..4.

------------------------------------------------------------------------

[INFO]-MAC-----: Sent IPv6 UDP msg, len:84, chksum:31be, to:0xffff, sec:no, prio:high

[INFO]-MAC-----: src: fe80:0:0:0:4888:1487:c7d8:d27b

[INFO]-MAC-----: dst: ff02:0:0:0:0:0:0:2

[DEBG]-MAC-----: Finishing operation "TransmitData"

[DEBG]-MAC-----: Idle mode: Radio receiving on channel 11

[INFO]-MLE-----: AttachState ParentReqRouters -> ParentReqReeds

[INFO]-MLE-----: Send Parent Request to routers and REEDs (ff02:0:0:0:0:0:0:2)

[DEBG]-MAC-----: Request to start operation "TransmitData"

[DEBG]-MAC-----: Starting operation "TransmitData"

==============================[TX len=063]===============================

| 41 D8 B5 34 12 FF FF 7B | D2 D8 C7 87 14 88 4A 7F | AX54...{RXG...J.

| 3B 02 F0 4D 4C 4D 4C 2A | C0 00 15 01 00 00 00 00 | ;.pMLML*@.......

| 00 00 00 01 D4 D0 2D 53 | 46 A4 96 AC C6 8E 74 57 | ....TP-SF$.,F.tW

| 26 3D 5D 3C 40 9D 3F C2 | D5 9B 1C 73 2F 27 8B .. | &=]<@.?BU..s/'..

------------------------------------------------------------------------

[INFO]-MAC-----: Sent IPv6 UDP msg, len:84, chksum:2ac0, to:0xffff, sec:no, prio:high

[INFO]-MAC-----: src: fe80:0:0:0:4888:1487:c7d8:d27b

[INFO]-MAC-----: dst: ff02:0:0:0:0:0:0:2

[DEBG]-MAC-----: Finishing operation "TransmitData"

[DEBG]-MAC-----: Idle mode: Radio receiving on channel 11

[INFO]-MLE-----: AttachState ParentReqReeds -> Idle

[INFO]-MLE-----: Allocate router id 9

[INFO]-MLE-----: Role Detached -> Leader

[INFO]-MESH-CP-: Active dataset set

[INFO]-MESH-CP-: Generated local dataset

[INFO]-MLE-----: Leader partition id 0x434ddb

[INFO]-CORE----: Notifier: StateChanged (0x12a5) [ Ip6+ Role Rloc+ PartitionId NetData Ip6Mult+ ] 

[INFO]-MLE-----: Send Data Response (ff02:0:0:0:0:0:0:1)

[INFO]-CORE----: Non-volatile: Saved NetworkInfo {rloc:0x2400, extaddr:4a881487c7d8d27b, role:Leader, mode:0x0f, keyseq:0x0, ..

[INFO]-CORE----: Non-volatile: ... pid:0x434ddb, mlecntr:0x3eb, maccntr:0x3e8, mliid:98babe2beb4f0e25}

[DEBG]-MLE-----: Store Network Information

[DEBG]-MAC-----: Request to start operation "TransmitData"

[DEBG]-MAC-----: Starting operation "TransmitData"

==============================[TX len=075]===============================

| 41 D8 B6 34 12 FF FF 7B | D2 D8 C7 87 14 88 4A 7F | AX64...{RXG...J.

| 3B 01 F0 4D 4C 4D 4C 4E | 6B 00 15 02 00 00 00 00 | ;.pMLMLNk.......

| 00 00 00 01 46 D3 17 18 | 24 80 0B 0E EA 29 C5 0F | ....FS..$...j)E.

| 2A 26 D8 9E F6 04 16 85 | 9A 96 DF 72 82 D4 6C 54 | *&X.v....._r.TlT

| 6A 94 45 4E 2B E8 9E 1E | 4E 22 4C .. .. .. .. .. | j.EN+h..N"L.....

------------------------------------------------------------------------

[INFO]-MAC-----: Sent IPv6 UDP msg, len:96, chksum:4e6b, to:0xffff, sec:no, prio:high

[INFO]-MAC-----: src: fe80:0:0:0:4888:1487:c7d8:d27b

[INFO]-MAC-----: dst: ff02:0:0:0:0:0:0:1

[DEBG]-MAC-----: Finishing operation "TransmitData"

[DEBG]-MAC-----: Idle mode: Radio receiving on channel 11

[INFO]-MLE-----: Send Advertisement (ff02:0:0:0:0:0:0:1)

[DEBG]-MAC-----: Request to start operation "TransmitData"

[DEBG]-MAC-----: Starting operation "TransmitData"

==============================[TX len=069]===============================

| 41 D8 B7 34 12 FF FF 7B | D2 D8 C7 87 14 88 4A 7F | AX74...{RXG...J.

| 3B 01 F0 4D 4C 4D 4C 61 | C3 00 15 03 00 00 00 00 | ;.pMLMLaC.......

| 00 00 00 01 6D 72 F3 A1 | E7 0C 32 E5 E8 FE 3C DF | ....mrs!g.2eh~<_

| D4 A4 25 19 57 02 D7 C0 | EF F6 11 C1 79 BD 24 AD | T$%.W.W@ov.Ay=$-

| 68 81 5F 4E D0 .. .. .. | .. .. .. .. .. .. .. .. | h._NP...........

------------------------------------------------------------------------

[INFO]-MAC-----: Sent IPv6 UDP msg, len:90, chksum:61c3, to:0xffff, sec:no, prio:high

[INFO]-MAC-----: src: fe80:0:0:0:4888:1487:c7d8:d27b

[INFO]-MAC-----: dst: ff02:0:0:0:0:0:0:1

--

Jonathan Hui

--
You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.
To post to this group, send email to openthre...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/5f0b03c8-936c-4d32-a865-10a1fde638ff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Catalin I]

Thanks, Jonathan,

Unfortunately, none of those 3 functions are being called (MeshForwarder::SendMessage(), MeshForwarder::ScheduleTransmissionTask(), Mac::SendFrameRequest()).

But there are periodic calls to UdpSocket::SendTo() (these beacons/broadcast packages are UDP), so it has to be something in UDP/Transport or IP layers.

Another idea is to pull/update my local openthread repo, as I see your log messages are a bit different. I have a ~2months old repo.

I've printed my unicast addresses, and they look like in the example:

fdde:ad00:beef:0:0:ff:fe00:fc00

fdde:ad00:beef:0:0:ff:fe00:a400

fdde:ad00:beef:0:1289:c4e2:f1f8:fc7e

fe80:0:0:0:b4db:6db6:5b2d:964b

[Catalin I]

Continuing debugging, there seems that the tasklet Ip6::HandleSendQueue() it's also not called. Could be a problem with Tasklets on my platform? 

I guess it uses functionalities from platform/alarm-milli.h. I've verified the implementation of platform/alarm-milli.h, and otPlatAlarmMilliFired() is called every second, when no activity.

[Catalin I]

Oooh, I've missed completely that otTaskletsProcess() has to be continuously called (I thought tasklets are scheduled using otPlatAlarmMilliFired()).

Now, I'm into runtime errors; I suspect memory issues; are there any statistics (on different platforms) about memory usage (flash/ram)?

thanks,

catalin

[Jonathan Hui]

Yes, `otTaskletsProcess()` must be called whenever there are tasklets available to process.

By design, OpenThread is highly configurable.  At the same time, platform-specific drivers also contribute to the overall resource requirements.  We do not have the resource requirements published across the matrix of configurations and platforms.

You may find interest in a recent post that shares some numbers.

You can also review the build logs on Travis, where the "arm-gcc.." builds print the output of arm-none-eabi-size for the built binaries across the various platforms.

--

Jonathan Hui

--

You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.
To post to this group, send email to openthre...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/cf17bd18-7cf3-48d6-9a5b-99991592049e%40googlegroups.com.

[Catalin I]

Thanks, Jonathan!

I've got a little further with my port. Now, I have 2 nodes(FTD) they started to TX/RX packages, but the Mesh network is not created.

Few questions:

1. As far as I've understood, they are receiving each-other Advertisements (forever, some 10mins max I've tried) and [INFO]-MLE-----: Different partition (peer:4971684, local:7376247)... but the 2 partitions don't merge in a single Thread network, and I don't understand why. 

2. Due to my platform high latency (details bellow), any ideas what other parameters should I tune?

3. In general, for understanding and debugging MLE, what would you recommend? Checking the logs from codelabs platform/or running locally using posix emulator?

 

4. What's raw-link-api, I did not understood this feature, do I need it? It seems to be enabled, on my platform as I've used the openthread-windows-config.h.

I will attach the logs from both (Leader and potentially, Child).

Some notes about my platform:

* does not support by hardware 802.15.4, so I've adapted the 802.15.4 posix implementation (so software ACK seems to work)

* the RX/TX is quite slow (up to 4 seconds for a packet+ACK round-time, A->B->A), for this reason I've tuned some parameters:

- in mac.hpp: 

    kAckTimeout      = 4000,  ///< Timeout for waiting on an ACK (milliseconds).

    kDataPollTimeout = 5000, ///< Timeout for receiving Data Frame (milliseconds).

    kSleepDelay      = 5000, ///< Max sleep delay when frame is pending (milliseconds).

- in openthread-core-default-config.h

#define OPENTHREAD_CONFIG_ENABLE_SOFTWARE_ACK_TIMEOUT 1

#define OPENTHREAD_CONFIG_ENABLE_SOFTWARE_RETRANSMIT 1

#define OPENTHREAD_CONFIG_ATTACH_DATA_POLL_PERIOD 1000

* For now, I've not included Commissioner/Joiner role, just DHCP and single instance openthread.

[Catalin I]

Just a small update, I've localised the problem, I guess this message in the logs:
[WARN]-MLE-----: Error Parse: Failed to process Parent Response

Digging deeper, in mle.cpp this is failing: memcmp(response.GetResponse(), mParentRequest.mChallenge, response.GetLength()) == 0
They look quite different:
response.GetResponse(): 60 30 18  c 86 c3 61 b0
mParentRequest.mChallenge: d8 ec f6 fb fd fe ff ff

I guess these Ids are handled by MLE protocol, the low-level 802.15.4 doesn't touch them (this is where I'm most concerned).

 

Is there a packet desynchronisation/ endianess problem? Using a radio sniffer, I saw the packets in the right order, as far as I could check, comparing Log output with Sniffer Log.

On the other hand, I did compiled once as MTD for a device, but the Child did not associated with the Leader.

Any advice is highly appreciated, thanks a lot!

[Jonathan Hui]

As you mentioned, the communication delays on your platform are much higher than is expected for a standard IEEE 802.15.4 device.

In addition to increasing the ACK timeout at the MAC layer, you will also need to adjust various protocol parameters at the MLE layer.  You can find the protocol timing parameters in src/core/thread/mle_constants.hpp.

In particular, take a look at:

• kParentRequestRouterTimeout
  
• kParentRequestReedTimeout
  
• kUnicastRetransmissionDelay
  
• kMaxChildIdRequestTimeout
  
• kMaxChildUpdateResponseTimeout
  
• kMaxLinkRequestTimeout
  

Note that changing these values will make your implementation non-compliant with the Thread specification.

--

Jonathan Hui

--
You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.
To post to this group, send email to openthre...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/88535bf6-9b01-4338-b782-bb5d213e8020%40googlegroups.com.

[Catalin I]

Thanks a lot, Jonathan!

The plan is to optimise the Radio layer, if some UDP traffic will be transferred ok over Thread.

I've been tuning these parameters for the whole day, and finally now, I've got a network with a Leader and a Router :)

Next, I will try some UDP traffic.

But the Routing table doesn't have anything, using otThreadGetRouterInfo().

The Router prints such info:
434962 [INFO]-MLE-----: Route table updated
434962 [INFO]-MLE-----: c800 -> fc00, cost:0 1, lqin:3, lqout:3
434962 [INFO]-MLE-----: e400 -> fc00, cost:0 16, lqin:0, lqout:0
435845 [DEBG]-MLE-----: network id timeout = 0
436845 [DEBG]-MLE-----: network id timeout = 1
437845 [DEBG]-MLE-----: network id timeout = 2
438845 [DEBG]-MLE-----: network id timeout = 3

[Jonathan Hui]

The log output you captured indicates that the route table is getting populated - an entry for the local device and an entry for the neighboring device.

Note that all Thread devices initially attach as an end device.  If an end device decides to become a router on its own, it selects a random time up to 2 minutes before doing so.

When you say `otThreadGetRouterInfo()` doesn't return anything, can you provide more detail?

--

Jonathan Hui

--

You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.
To post to this group, send email to openthre...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/1e9c5995-c031-494a-b3f9-2e9f13d532d2%40googlegroups.com.

[Catalin I]

Thanks again, Jonathan!

No more problems with routing table, I as able to add CLI module, so now I have access to all the wonderful commands.

I've checked the IPv6 Addressing, I don't understand how a child inside a Thread network can send data to an Internet server. This function is handled by the Boarder Router?

Does the child has to know the IP address(es) of the Thread Leader, to send to it all its data? How can a Child/Router know the IP of the Leader?

Does DHCP needs to be enabled? First of all, I don't quite understand otDhcp6ClientUpdate() function parameters, why a DHCP client has to input IP addresses: https://openthread.io/reference/group/api-dhcp6#group__api-dhcp6_1gad825281530ef9034181165ef02ef852a

Is there any example of DHCP server/client usage?

Thanks again,

[Jonathan Hui]

A Border Router is a device that can forward IPv6 datagrams between a Thread interface and another IPv6 interface (e.g. Wi-Fi, Ethernet, or Cellular).  A Thread Child or End Device can operate as a Border Router.

DHCP does not need to be enabled.  OpenThread's DHCPv6 API requires a client to provide IPv6 address buffers so that OpenThread itself does not need to allocate the IPv6 buffers.  You can find example usage of DHCP APIs in src/cli/cli.cpp.

--

Jonathan Hui

--

You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.
To post to this group, send email to openthre...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/4d0e470e-f4a1-4a20-a064-36e410c41f53%40googlegroups.com.

[Catalin I]

Thanks, Jonathan!

Sorry, I did not notice there is boarder_router.h API included in openthread (I was thinking at the Boarder Router project for Raspi/BeagleBone).

I am having troubles understanding how to use the functions from https://openthread.io/reference/group/api-border-router

Is there an example of boarder_router.h usage?

I've seen the CLI commands: 

* "netdataregister" - Register the current node as Boarder Router.

* "prefix" - Add a border router configuration to the local network data.

* "route" - Add an external route configuration to the local network data.

As I've understood:

* on Boarder Router, I have to issue a command "netdataregister".

* on all the other nodes, I have to issue "prefix add"

* on the Boarder Router I have to "route add" ?!? or on all Mesh nodes?

* so now, on Boarder Router, all the traffic from all the nodes is routed to, by default?

* using otBorderRouterGetNetData() I should be able to gather all the packets from the Mesh network? How to parse them?

* next, I need to do some sort of NAT, to RX/TX mesh network to some Wifi interface(and Internet).

Thanks a lot!

[Jonathan Hui]

The "prefix" CLI should be sufficient to demonstrate border routing.  You can see the "prefix" command details in the CLI readme.

The prefix CLI allows a border router:

1. Inject an on-mesh prefix, which is used to communicate beyond the IPv6 mesh network
   
2. Indicate that devices should try to autoconfigure an IPv6 address out of the on-mesh prefix
3. Indicate that the border router serves as a default route for the on-mesh prefix.

You can use the `otBorderRouterGetNextOnMeshPrefix()` API to read out the on-mesh prefixes in a nice structure format without having the parse the network data TLVs directly.

The "netdataregister" command is not really necessary for FTDs.  The network data will eventually be propagated throughout the network.  The "netdataregister" command is only necessary if you want the actions to take place immediately.

The "route" command is only necessary for more-specific external routes.

NAT is only necessary if you are not able to attain a global IPv6 prefix that can be assigned to your Thread network.

Hope that helps.

--

Jonathan Hui

--
You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.
To post to this group, send email to openthre...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/2a33f529-a01c-4365-a975-d04fbdd55a12%40googlegroups.com.

[Catalin I]

I still don't understand how to use the Border Router concept. I need a way, on the Border Router device, to be able to get the IPv6 datagrams, which are generated by the whole mesh network and are addressing the exterior of the mesh.

I suppose, any mesh-node can try to send UDP packets to a destination having the IPv6 address with the prefix set with "prefix add" command.

My Border Router has another network interface (wifi) on which it needs to forward the IPv6 from the interior of mesh-network.

On Node A (Border Router):

> prefix add 2a02:220b:8040:8f1::/64 paros med

Done

> ipaddr

2a02:220b:8040:8f1:3b9d:4ea7:5329:140a

fdde:ad00:beef:0:0:ff:fe00:fc00

fdde:ad00:beef:0:0:ff:fe00:e000

fdde:ad00:beef:0:8140:2010:88c4:6231

fe80:0:0:0:d86d:b65b:2d16:b05

Done

On Node B, the prefix was propagated, as I can see an unicast IPv6 address having the Border Router prefix:

> lora.cli("ipaddr")

2a02:220b:8040:8f1:5bad:d6eb:f57a:bdde

fdde:ad00:beef:0:0:ff:fe00:2c00

fdde:ad00:beef:0:5128:944a:a5d2:69b4

fe80:0:0:0:1:8040:2010:8844

Done

> udp open

Done

> udp send 2a02:220b:8040:8f1:3b9d:4ea7:5329:140b 1235 hello

Done

So now, I was hopping, there is a way on Node A, Border Router, to receive this UDPv6 datagram, because it's addressed to the same network with Border Router prefix, but the IPv6 is not Border Router IP.

Of course, next the Border Router should be able to forward all IPv6 trafic not addressed to the mesh-internal network (DNS requests, TCP sockets,etc.). 

Thank you!

[Catalin I]

On, a second thought, I've found a solution/workaround. But would be nice to understand the mechanism of "Border Router" in openthread.

All the nodes inside the thread-network, can send data (on UDP) to the Border Router IPv6 having the on-mesh "prefix" 

(Question: how do all the mesh-nodes know the Border Router IP? I guess the Border Router has to broadcast UDP packets with his IPv6.)

Next, the Border Router, could have a UDP socket bind on a port, receive all datagrams, unpack them(application level), and repack/send them to some Internet server on wifi socket.

[Jonathan Hui]

To forward IPv6 packets at the border router to another IPv6 interface, you'll need to capture the raw IPv6 datagrams as they are received - you can use the otIp6ReceiveCallback to achieve this.

The OpenThread Border Router provides and example with wpantund and NCP.  The NCP forwards raw IPv6 datagrams over a serial link to wpantund running as a linux user process.  wpantund then injects the IPv6 packet into linux's IPv6 network stack using a linux tun interface.  After that, it's standard linux IPv6 networking.

--

Jonathan Hui

--

You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.
To post to this group, send email to openthre...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/fb02978d-67eb-4552-811e-634bb0b56009%40googlegroups.com.

[Catalin I]

Thanks a lot, Jonathan, I will look into it!