Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Standalone Native RPL Border Router #1021

Open
wants to merge 16 commits into
base: develop
from

Conversation

@yatch
Copy link
Member

yatch commented Aug 8, 2019

What is this PR?

This PR introduces examples/standalone-native-rpl-border-router, which resolves the same issue as what PR #952 tackles, running a TSCH network with a RPL border router on a Linux host.

A key architectural difference from PR #952 is that, a radio board connected with the Linux host acts as a complete RPL/IPv6 router, not as "slip-radio" which provides the Linux host with IEEE 802.15.4 MAC/PHY functionalities. This will be a solution for the known issue described in Wiki:

This approach has the advantage of running the BR on an unconstrained device. The main downside, however, is that it separates the low layers (radio and MAC) from the rest of the stack (NET and up). In networks with TSCH, this is a problem as we do not have yet a way to communicate schedules to the slip-radio over the serial interface. Currently only usable with CSMA or TSCH with 6TiSCH minimal schedule.

The projects under examples/standalone-native-rpl-border-router can work on top of the existing framework. , although this PR has several trivial fixes to the core system.

For further information, please consult README.md.

Tests

Four tests are provided under tests/17-tun-rpl-br; the proposed example is tested with:

  • RPL Lite + TSCH (10-standalone-native-6lbr-lite-tsch)
  • RPL Lite + CSMA (11-standalone-native-6lbr-lite-csma)
  • RPL Classic + TSCH (12-standalone-native-6lbr-classic-tsch)
  • RPL Classic + CSMA (13-standalone-native-6lbr-classic-csma)
  • RPL Lite + CSMA + IPv6 fragmentation (14-standalone-native-6lbr-lite-csma-frag)

A simulation file to test Orchestra, lite-tsch-orchestra.csc, is found at examples/standalone-native-rpl-border-router.

I did a simple test with two OpenMote-CC2538 and one Raspberry PI.

@debug-ito

This comment has been minimized.

Copy link
Contributor

debug-ito commented Aug 9, 2019

Thanks so much! Basically I like the idea. I'll review the p-r after 1-week vacation (sorry!)

I have a request at the moment, though. Could you make the "6lbr" and "6lr-with-slip" as independent modules (i.e. put under os/services)? We often need to implement application code on top of the native border router, so it's very important that we can use 6lbr etc as reusable modules. (in fact, I was gonna make a p-r to refactor slip-radio if #952 was merged.)

@yatch yatch force-pushed the yatch:pr/standalone-native-rpl-border-router branch from 2e7b1a7 to 7c5a713 Aug 9, 2019
@yatch

This comment has been minimized.

Copy link
Member Author

yatch commented Aug 9, 2019

@debug-ito

Could you make the "6lbr" and "6lr-with-slip" as independent modules (i.e. put under os/services)? We often need to implement application code on top of the native border router, so it's very important that we can use 6lbr etc as reusable modules.

I've added os/services/demux where the key components of standalone-native-rpl-border-router are placed. If you look at the current examples/standalone-native-rpl-border-router/6lbr, you will see it'd be easy to implement your custom border router having the same network capability as this 6lbr.

@debug-ito

This comment has been minimized.

Copy link
Contributor

debug-ito commented Aug 20, 2019

I reviewed the code at 7c5a713. The architecture of net-demux is a little tricky, but it's ok for me. Here are my commnets.

  • demux/README.md: typo "avaialble" -> "available"

  • mac-demux/README.md: typo "net-demux" -> "mac-demux"

  • mac-demux/README.md: typo NETWORK_CONF_NETWORK -> NETSTACK_CONF_NETWORK

  • net-demux/README.md: typo NETWORK_CONF_NETWORK -> NETSTACK_CONF_NETWORK

  • mac-demux, net-demux: Is it ok to use LOG_LEVEL_MAIN? I think we should make dedicated configuration items to set the log levels.

  • mac-demux/mac-uplink.c: L63: Why not use uipbuf_clear() here? Attributes should be cleared, I think.

  • net-demux/net-downlink.c: L481: What's this loop for??

  • net-demux/net-downlink.c: L484: We should check if the return value is EAGAIN or EWOULDBLOCK. It's not a fatal error. (Maybe we can ignore that case, though, because we already check its writability by select)

  • net-demux/net-downlink.c: L484: What if the write operation is partial, i.e., 0 <= ret < packet_len? Can we ignore that case?

  • net-demux/net-downlink.c: L607: Catastrophic typo: SLIP_END -> SLIP_ESC

  • net-demux/net-downlink.c: L509: We should check error returned from read. It can return a fatal error.

  • net-demux/net-downlink.c: L528: Unfortunately SICSLOWPAN_DISPATCH_FRAG1 == SLIP_END, so it's never at the first byte in a SLIP-escaped packet. I would unescape the received data first by replacing the read at L509 with a function like:

      int read_slip_unescaped(int serial_fd, char *got_unescaped_byte)
    

    where the return value is either 0 (it reads raw SLIP_END), 1 (it reads a data byte, which is stored in got_unescaped_byte) or -1 (error). What do you think?

  • net-demux/net-downlink.c: Is it necessary to export net_downlink_input? It's called from input in net-demux.c, but no one calls that, I think.

  • net-demux/net-uplink.c: L81: What's this packet processor for?

  • standalone-native-rpl-border-router/README.md: L44: This is a little misleading. Because the tun device (created by tun6-net) is assigned fd00::1/64 (and it's not configurable), the tun and slip interfaces share the same prefix ONLY IF the IPv6 prefix of the slip interface is fd00::/64. In practice, that prefix is configurable via UIP_CONF_DS6_DEFAULT_PREFIX, I think.

    • Maybe we should revise tun6-net to allow to configure the IPv6 address of the tun device (in a different p-r?)
    • On the other hand, os/services/rpl-border-router/native/tun-bridge.c provides a way to configure the address.
@yatch yatch force-pushed the yatch:pr/standalone-native-rpl-border-router branch from 7c5a713 to 9dfb303 Nov 14, 2019
@yatch

This comment has been minimized.

Copy link
Member Author

yatch commented Nov 14, 2019

@debug-ito Big thanks for your valuable comments. I've updated the branch addressing them.

One big addition is a test of IPv6 fragmentation using the border router: tests/17-tun-rpl-br/14-standalone-native-6lbr-lite-csma-frag

net-demux/net-downlink.c: L509: We should check error returned from read. It can return a fatal error.

What do you think we should do there?

@yatch yatch force-pushed the yatch:pr/standalone-native-rpl-border-router branch from 7bf6f76 to 46fb218 Nov 14, 2019
@debug-ito

This comment has been minimized.

Copy link
Contributor

debug-ito commented Nov 15, 2019

Thanks for update! Here is my code review on 46fb218

  • mac-demux/mac-uplink.c: mac_uplink_send function: uipbuf_clear destroys uip_ext_len, uip_last_proto and UIPBUF attributes, too. I think we should backup and restore them. Or, probably we can just use slip_write instead of slip_send, so we don't have to use uip_buf in the first place.
  • net-demux/net-downlink.c: L639: ringbufindex_put should be called just after all writing operations to idx are done. Otherwise, a consumer of the queue might access the item at idx while it's in a premature state (in this particular case, however, that should not happen because the consumer doesn't preempt the producer).
  • net-demux/net-downlink.c: L554: It says "0x60", but SLIP_END is 0xc0.
  • net-demux/net-downlink.c: L602: maybe we should use serial_clear_rxbuf here?
  • net-demux/net-downlink.c: L485, L536: well, I thought that read and write would return a fatal error when serial_fd is closed (e.g. by the peer in case it's a TCP connection) and that we should handle that case. However, read would just return 0 and write would raise SIGPIPE to kill the program anyway. Now I think the current code is ok.
  • net-demux/net-demux.c: L60: I think we should remove this, because network_driver.input method and net_downlink_input follow different contracts. network_driver.input (e.g. the one in sicslowpan.c) takes data from packetbuf and populates uip_buf. On the other hand, net_downlink_input takes data from serial_rxbuf and populates packetbuf. Their I/O specs are incompatible. Again, I don't think we have to expose net_downlink_input outside of net-downlink.c.
  • examples/standalone-native-rpl-border-router/README.md: probably we should mention tests/17-tun-rpl-br/14-standalone-native-6lbr-lite-csma-frag.csc.

I ran the tests (17-tun-rpl-br) locally on my PC using the Contiki-NG docker image (contiker), but it failed, even for old ones (e.g. 01-border-router-cooja). Well, I've never passed them on my PC anyway...

@yatch

This comment has been minimized.

Copy link
Member Author

yatch commented Nov 15, 2019

@debug-ito Thanks for the review! Updated the branch, addressing all your points.

net-demux/net-demux.c: L60: I think we should remove this, because network_driver.input method and net_downlink_input follow different contracts.

input() handler implemented there shouldn't be called anyway. Now, the handler does nothing meaningful.

I ran the tests (17-tun-rpl-br) locally on my PC using the Contiki-NG docker image (contiker), but it failed, even for old ones (e.g. 01-border-router-cooja). Well, I've never passed them on my PC anyway...

Do you have --sysctl net.ipv6.conf.all.disable_ipv6=0 in your contiker alias or docker command line? (#1023).

@debug-ito

This comment has been minimized.

Copy link
Contributor

debug-ito commented Nov 18, 2019

Thanks! All my comments are addressed.

With --sysctl net.ipv6.conf.all.disable_ipv6=0 option, contiker ran perfectly. Thanks!

yatch added 16 commits Aug 1, 2019
- net-demux: demultiplexer between tun and slip
- mac-demux: demultiplexer between slip and radio (IEEE 802.15.4)
- replace "uip_len = 0" with "uipbuf_clear()"
- remove unnecessary code
- LOG_MODULE: use "demux", "demux-down", or "demux-up"
- LOG_LEVEL: align with a corresponding layer (LOG_LEVEL_MAC or LOG_LEVEL_IPV6)
- mac-demux: use slip_write() instead of slip_send()
- net-demux: delay ringbufindex_put() until the buffer is ready
- net-demux: correction in a comment
- net-demux: replace serial_rxbuf_len = 0 with serial_clear_rxbuf()
- net-demux: make input() to do nothing, which shouldn't be called
- standalone-native-rpl-border-router: update README.md
@yatch yatch force-pushed the yatch:pr/standalone-native-rpl-border-router branch from 9edc93c to d8827f4 Dec 1, 2019
@yatch

This comment has been minimized.

Copy link
Member Author

yatch commented Dec 1, 2019

Rebased and added one commit for minor fixes.

It's working with MSF (#1000), which is now I'm improving (almost done, evaluation follows).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.