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

drivers: add ethernet over serial driver #4438

Merged
merged 3 commits into from
Feb 7, 2016

Conversation

kaspar030
Copy link
Contributor

I needed a one-cable solution for connecting boards with both network and console. So I came up with this driver, which is essentially l2 SLIP and additional support for multiplexing STDIO over the same serial connection.

It is an alternative to gnrc_slip / tuntap.

Differences:

  • it implements a netdev driver
  • it transfers l2 ethernet frames instead of IP packets
  • it enables network and stdio over just one serial cable
  • it uses a slightly more robust framing
  • it is more code
  • it is only tested on Linux
  • it uses more memory
  • it has slower ping times

The last two will probably be fixed.

In order to play with it, see dist/tools/ethos/README.md for what to add to your makefiles.

@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 Area: drivers Area: Device drivers labels Dec 8, 2015
@OlegHahm
Copy link
Member

OlegHahm commented Dec 8, 2015

Cool, that could help to run a 6LBR on the IoT-LAB testbed.

@OlegHahm OlegHahm modified the milestone: Release 2016.03 Dec 8, 2015
@cladmi
Copy link
Contributor

cladmi commented Dec 9, 2015

I also thought that the shell could also be available as a server. This way, the multiplexing would directly use the network stack.

It would just needed to set the first ip address automatically and print in on the serial line like as done in contiki examples.

@miri64
Copy link
Member

miri64 commented Dec 9, 2015

did not look into your implementation in detail, but shouldn't it be way simpler to just multiplex slip and shell input/output over one UART?

@kaspar030
Copy link
Contributor Author

I also thought that the shell could also be available as a server. This way, the multiplexing would directly use the network stack.

... which in turn would make it impossible to debug the network stack edit using stdio.

@kaspar030
Copy link
Contributor Author

did not look into your implementation in detail, but shouldn't it be way simpler to just multiplex slip and shell input/output over one UART?

It would end up being the same but on Layer 3 in principal, which honestly I realized when taking a look at how you did some things in gnrc_slip.

But ethos is also netdev based and thus works without gnrc.

@miri64
Copy link
Member

miri64 commented Dec 9, 2015

Ah, I missed the non-gnrc part :-)

tsrb_init(&dev->inbuf, (char*)buf, bufsize);
mutex_init(&dev->out_mutex);

uint32_t a = genrand_uint32();
Copy link
Member

Choose a reason for hiding this comment

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

I already hate the fact, that netdev2_tap has more or less random MAC addresses, but at least they are somewhat stable as long as you don't rebuild the TAP. Can't you use the CPUID to generate the MAC? It would make debugging and testing with these devices way easier ;-).

Copy link
Member

Choose a reason for hiding this comment

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

Also keep in mind that bits 7 (U/L) and 8 (I/G) have special meaning in 48-bit MAC addresses http://standards.ieee.org/develop/regauth/tut/eui.pdf

Copy link
Member

Choose a reason for hiding this comment

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

(address is globally unique if bit 7 is unset [so you need to set it, since you generated it], bit 8 needs to be unset since your address is a unicast address)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Totally. Will fix.

Copy link
Member

Choose a reason for hiding this comment

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

@kaspar030 do you have time to address @authmillenon's comment until the Hack'n'Ack session?

@emmanuelsearch
Copy link
Member

Is this too WIP to be an H&A candidate? Arguably it is a new functionality that could be improved later too... right?

@kYc0o
Copy link
Contributor

kYc0o commented Jan 25, 2016

Hey! I was about to ask the same, if I can ACK this PR let me know

@cgundogan
Copy link
Member

@emmanuelsearch I used this feature several times with great success. I would also vote for getting this merged as soon as @kaspar030 addressed @authmillenon's comments. I couldn't get ethos to work with the iotlab-testbed, though. I am not sure if this is due to ethos or whether it is some magic that I am unaware of when I tunnel the serial aggregator to my local machine in order to use it with ethos. @kaspar030 I'd like to talk to you about this f2f if you attend tomorrow's H&A.

@emmanuelsearch
Copy link
Member

@kYc0o did you already test this? On which hardware/config?

@emmanuelsearch
Copy link
Member

@cgundogan you used successfully this with SAMR21, I suppose?

@cgundogan
Copy link
Member

yes, the typical scenario: samr21-xpro running the border router example

@kYc0o
Copy link
Contributor

kYc0o commented Jan 25, 2016

I didn't already test but I plan to do it as soon as possible on IoT-Lab


#include <netinet/in.h>
#include <linux/if.h>
#include <linux/if_tun.h>
Copy link
Member

Choose a reason for hiding this comment

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

Please mention in the README or somewhere else this is only usable with linux.

@cgundogan
Copy link
Member

interesting - tested with iotlab-m3 and I didn't receive any output from ethos. Tried with samr21-xpro afterwards and there was also no output from ethos. Will check more thoroughly tomorrow

@kaspar030 kaspar030 force-pushed the add_eth_over_serial branch from 713a369 to 665786c Compare January 26, 2016 11:08
@kaspar030
Copy link
Contributor Author

  • addressed comments

@kaspar030
Copy link
Contributor Author

I had some trouble using this on a uclibc-based OpenWrt as host.

@kaspar030
Copy link
Contributor Author

I just realized that ethos doesn't work until I've used the board once using "make term". Probably something is missing in ethos' linux side terminal setup.

@kaspar030
Copy link
Contributor Author

I ACK this PR too. However, please notice this https://lists.riot-os.org/pipermail/devel/2016-February/003386.html since I had the same issue.

RIOT doesn't answer to pings for addresses that were not the interface the echo request came in. See #4456.

@OlegHahm
Copy link
Member

OlegHahm commented Feb 3, 2016

Confirmed.

@kaspar030 kaspar030 force-pushed the add_eth_over_serial branch from 44a5243 to 871add0 Compare February 4, 2016 16:16
@kaspar030
Copy link
Contributor Author

  • fixed stupid bug on linux side, rebased

@kYc0o
Copy link
Contributor

kYc0o commented Feb 4, 2016

Now is also working on my side. I think if travis is happy the PR can be merged

@kYc0o kYc0o added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Feb 4, 2016
@kaspar030
Copy link
Contributor Author

I'll have to squash first...

@OlegHahm OlegHahm added the CI: needs squashing Commits in this PR need to be squashed; If set, CI systems will mark this PR as unmergable label Feb 4, 2016
@kaspar030 kaspar030 force-pushed the add_eth_over_serial branch from 871add0 to dce8927 Compare February 5, 2016 11:54
@kaspar030 kaspar030 removed CI: needs squashing Commits in this PR need to be squashed; If set, CI systems will mark this PR as unmergable Discussion: RFC The issue/PR is used as a discussion starting point about the item of the issue/PR labels Feb 5, 2016
@kaspar030
Copy link
Contributor Author

  • squashed

@kYc0o kYc0o added CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR and removed CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Feb 5, 2016
@kaspar030 kaspar030 force-pushed the add_eth_over_serial branch from dce8927 to fa15d31 Compare February 5, 2016 17:52
@kaspar030
Copy link
Contributor Author

Travis seem lazy. :)

@kaspar030 kaspar030 force-pushed the add_eth_over_serial branch from fa15d31 to ecf70f3 Compare February 5, 2016 18:33
@OlegHahm
Copy link
Member

OlegHahm commented Feb 6, 2016

>file has an unknown license header: 'dist/tools/ethos/ethos.c'

@kaspar030 kaspar030 force-pushed the add_eth_over_serial branch from 63327ee to c762a6f Compare February 7, 2016 18:17
@kaspar030
Copy link
Contributor Author

  • fixed license header problem, doxygen, static code checker nitpicks

@kaspar030
Copy link
Contributor Author

Mr. T. is all green. Anyone cares to say ACK and press merge?

@kYc0o
Copy link
Contributor

kYc0o commented Feb 7, 2016

ACK :)

kYc0o added a commit that referenced this pull request Feb 7, 2016
drivers: add ethernet over serial driver
@kYc0o kYc0o merged commit 66dab58 into RIOT-OS:master Feb 7, 2016
@kaspar030 kaspar030 deleted the add_eth_over_serial branch February 8, 2016 09:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: drivers Area: Device drivers Area: network Area: Networking CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants