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

simplified border router setup #4725

Merged
merged 17 commits into from
Apr 12, 2016
Merged

Conversation

kaspar030
Copy link
Contributor

I've been trying to automate border router setup.

edit check discussion for up-to-date instructions

@kaspar030 kaspar030 added Area: network Area: Networking State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet Discussion: RFC The issue/PR is used as a discussion starting point about the item of the issue/PR labels Jan 31, 2016
@OlegHahm
Copy link
Member

(seems to work if the global adress of the target node happens to be in the neighbor cache, if not, sometimes the lookup doesn't work, don't know exactly why)

This is strange. Normally, no lookup should be necessary for a direct neighbor in 6lo.

@OlegHahm
Copy link
Member

ping between Linux and 6lbr 6lo-side

Why do you think this is important?

@OlegHahm
Copy link
Member

The last two issues may be fixed by #4714

@OlegHahm
Copy link
Member

Why is radvd required on the serial interface?

@kaspar030
Copy link
Contributor Author

ping between Linux and 6lbr 6lo-side

Why do you think this is important?
Because if I decide to use link-local addresses for routing because of simplicity, the 6lo configured address might be the only globally reachable one.
Also, because I would just expect a node to reply if all routing is set up correctly.

@kaspar030
Copy link
Contributor Author

Why is radvd required on the serial interface?

It is not needed, it was just there. I didn't want to hack prefix setup using induced shell commands or special handling within ethos. edit this is a kludge, as I said, we need to come up with something better, but the kludge is only 5 lines of code, so it's easily replacable.

@kaspar030
Copy link
Contributor Author

BTW, setting "START_RADVD" to anything else but "true" disables any hackery regarding prefixes. A prefix must be configured manually in that case.

@kYc0o
Copy link
Contributor

kYc0o commented Feb 1, 2016

I completely agree with this PR. I discussed some days ago with Cenk even the need of a shell on a 6lbr. I think that it could be very useful for debugging purposes or fine configs. Otherwise I think a SLIP interface preconfigured with a prefix should do the job an initialize the network automatically (ok this is not magic but I don't think the scenario is impossible) without a shell.
I'll test your scripts and give feedback.

static void _clear_neighbor_cache(const char *ifname)
{
char tmp[20 + IFNAMSIZ];
snprintf(tmp, sizeof(tmp), "ip neigh flush dev %s", ifname);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this work for you?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I have an entry with status FAILED it stays there even after the flushing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works for me, but it needs ethos to be called with root right / sudo, did you do that?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did:

--> sudo ip a a beef::1/64 dev tap0
--> ping6 beef::2
PING beef::2(beef::2) 56 data bytes
^C
--- beef::2 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
--> ip n
...
beef::2 dev tap0  FAILED
...
--> sudo ip n flush dev tap0
--> ip n
...
beef::2 dev tap0  FAILED
...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the flush flushes positive cache entries.
You can see the effect of the flush call when you

  1. startup ethos
  2. ping from linux
  3. while linux is pinging, type "reboot" at ethos shell

The linux ping should continue seamlessly with that flush call enabled, if you comment it out, the linux ping stops after RIOT's reboot as RIOT's MAC address has changed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, okay. Do you know any way to wipe out "FAILED" entries? Because this is really annoying if you setup your tap interface and Linux decides to consider the prefix as on-link and then marks any 6lo node (except the 6LBR) as an unreachable neighbor.

@iseitani
Copy link

iseitani commented Feb 5, 2016

Dear all, I want to fix the Linux-6lo node connectivity issue ,is it possible to provide me some instructions?Thank you in advance!

@kaspar030 kaspar030 force-pushed the ethos_br_hack branch 2 times, most recently from 8c90e8b to e74e42a Compare February 5, 2016 18:46
@OlegHahm
Copy link
Member

OlegHahm commented Feb 6, 2016

@kaspar030, if the purpose of this PR is to automate everything, you should consider to add an arbitrary non-link-local address to a Linux network interface.

@OlegHahm
Copy link
Member

OlegHahm commented Feb 6, 2016

@iseitani

I want to fix the Linux-6lo node connectivity issue

Can you describe step-by-step which commands you executed and what is not working?

@kaspar030
Copy link
Contributor Author

@kaspar030, if the purpose of this PR is to automate everything, you should consider to add an arbitrary non-link-local address to a Linux network interface.

will do.

@OlegHahm
Copy link
Member

OlegHahm commented Feb 6, 2016

Maybe this is a case for ULA.

@kaspar030
Copy link
Contributor Author

Maybe this is a case for ULA.

Good idea!

@iseitani
Copy link

iseitani commented Feb 6, 2016

Dear @OlegHahm ,

  1. sudo sh start_network.sh /dev/ttyACM0 tap0 affe::/64 (copy-paste from[+])

  2. ifconfig 5 add affe::5840:2276:95d0:f32e (BR's if)

  3. ncache add 5 affe::5840:2478:8532:262a (Node's if)

  4. plug the Node
    5)export BOARD=samr21-xpro SERIAL='ATML2127031800003936' && make term

I tried both with and without step 3.
Steps 2 and 3 were validated with the output of ifconfig command in both R21 boards.
Moreover I used in both BR and Riot Node fibroute .
There is a record for affe:: with metric 1024 in my Linux rtable

I can ping from BR to the Node, the opposite is only successful when I ping the
IF that uses 802.15.4 .

What I want : How can the echo message start from the
node , get routed to the correct IF in BR and
get to the Linux.
Thank you!

[+] #4725

@kaspar030 kaspar030 force-pushed the ethos_br_hack branch 2 times, most recently from 23b18ec to 9abfb43 Compare February 7, 2016 14:53
@kaspar030
Copy link
Contributor Author

  • rebased
  • added ULA creation
  • added UHCP (micro host control protocol) prototype implementation
  • adapted gnrc_border_router & scripts

Tested with two samr21-xpro's.

To try:

  • "make" in dist/tools/uhcpd and dist/tools/ethos
  • compile & flash gnrc_border_router
  • "sudo sh start_network.sh /dev/ACMx tap0 2001:db8::/64" edit (in dist/tools/ethos)

Now the 6lbr should answer pings on fe80::2%tap0, and it should announce 2001:db8::/64 to the wireless interface.

TODO edit (IMHO to be done in the next iteration, this is functional enough for gnrc_border_router):

  • conn_udp needs timeouts and a way to get/specify the interface used for multicast & link-local
  • uhcpd needs to save it's state, support more than one client, automatically set up routes, watch it's interface, ...
  • UHCP protocol is just one day old, a lot is missing (e.g., lifetimes, documentation...)

edit

  • get rid of fe80::1/2 and use UCHP server/client link local addresses

known issues (edit: unrelated to this PR):

  • RIOT doesn't reply correctly to it's own address from prefix unless pinged from 6lo
  • it seems like neighbor caching on RIOT is flakey. sometimes a reboot of 6lbr is necessary to ping fe80::2 from Linux, and sometimes 6lr needs to be rebooted in order to be able to ping it from Linux.

edit fixed prefix in start_network.sh ...

@kaspar030
Copy link
Contributor Author

Forgot to mention: if started correctly, one command is enough now to set up global connectivity for the 6lowpan network.

@kaspar030 kaspar030 added this to the Release 2016.03 milestone Feb 7, 2016
@emmanuelsearch
Copy link
Member

So what is still WIP and what is not WIP anymore in this PR?
Can it be broken in several PRs or can additional functionalities be added later?

@kaspar030 kaspar030 added CI: needs squashing Commits in this PR need to be squashed; If set, CI systems will mark this PR as unmergable and removed State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet labels Feb 8, 2016
}
}

LOG_INFO("uhcpc: Using %u as border interface and %u as wireless interface.\n", gnrc_border_interface, gnrc_wireless_interface);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can the LOG_INFO be set for gnrc_uhcpc instead? here and in the other logs. This helps to make the difference between this and uhcpc (I got confused while debugging)

@aabadie
Copy link
Contributor

aabadie commented Apr 11, 2016

I rebased this branch on #5289 and I confirm that it's working now.
From a node running gnrc_networking example behind the BR, I can ping the Linux host on fd00::dead:beef::1.

@kaspar030
Copy link
Contributor Author

  • rebased
  • addressed comments

Using "NETOPT_IS_WIRED" flag now (good idea!), fixed gnrc_uhcpc log prefixes.

@kYc0o
Copy link
Contributor

kYc0o commented Apr 12, 2016

Last test works like a charm. Ping between nodes and BR works OK for the first ~15min, afterwards only the BR deleted the entries of the other nodes on the neighbour cache. After ~25min nodes can still be pinged between each other. So, I ACK this PR and independently of ND problems I think this should be merged. Any comments against that? @kaspar030 @authmillenon @OlegHahm @cgundogan

@OlegHahm
Copy link
Member

Sounds fair to me.

@aabadie
Copy link
Contributor

aabadie commented Apr 12, 2016

Just to let you know that I tested it yesterday with one of @haukepetersen's demo (node_imu).
Basically it generates a "lot" of traffic on the serial link as it sends CoAP messages every 50ms and after some time (a few seconds), ethos "disconnect" but it can recover. If one uses with another node behind the BR, ethos couldn't recover and I had to manually unplug/plug the BR usb link.
Appart from that, it's working well.

@haukepetersen
Copy link
Contributor

I have the same opinion: let's merge this PR for now and look at the open issues for this in follow-ups, so we can finally create the release branch and use that as base for further testing/fixing.

I 2nd @kYc0o's ACK, Murdock (and even Travis) is green -> let's go

@haukepetersen haukepetersen merged commit 5fe57b4 into RIOT-OS:master Apr 12, 2016
@kaspar030 kaspar030 deleted the ethos_br_hack branch April 12, 2016 16:30
@kaspar030
Copy link
Contributor Author

nice!

@emmanuelsearch
Copy link
Member

+1

1 similar comment
@miri64
Copy link
Member

miri64 commented Apr 13, 2016

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: network Area: Networking CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet