Slip TCP connection between linux host and nrf52840


cpmcparland@...
 

Hi,

I need to get a sensor data stream flowing from a BT network into a linux host.  Have tried
to setup BT HCI interface but no luck getting hci0 interface to move from DOWN to UP.
So, thought I would take a different approach and put a dual stack on the nrf52 with the
ip link to the host going through a serial port. 

So, I would like to set up a slip tcp/ip connection between a linux host and a nrf52840.  I know
slip can be used to connect to a qemu simulation.  Has anyone used slip to talk to a physical
uart interface?  If so, can I use the nrf52840's console port or do I need to use a seperate
uart and interface via a FTDI usb cable?

Echo_server sample code seems to be a good base to start with....Any suggestions would help.

Regards,
Chuck McP


Andrei
 

Hi

On Thu, Oct 11, 2018 at 04:01:05PM -0700, cpmcparland@rtisys.org wrote:
Hi,

I need to get a sensor data stream flowing from a BT network into a linux
host.  Have tried
to setup BT HCI interface but no luck getting hci0 interface to move from
DOWN to UP.
So, thought I would take a different approach and put a dual stack on the
nrf52 with the
ip link to the host going through a serial port.
BTW, if you have USB you can enable Ethernet over USB and connect to
your PC.

Best regards
Andrei Emeltchenko


So, I would like to set up a slip tcp/ip connection between a linux host
and a nrf52840.  I know
slip can be used to connect to a qemu simulation.  Has anyone used slip to
talk to a physical
uart interface?  If so, can I use the nrf52840's console port or do I need
to use a seperate
uart and interface via a FTDI usb cable?

Echo_server sample code seems to be a good base to start with....Any
suggestions would help.

Regards,
Chuck McP


Jukka Rissanen
 

Hi Chuck,

there is nothing qemu specific in SLIP driver found in drivers/net/slip
directory. It only uses uart_pipe to transfer data. So if you manage to
configure the uart_pipe to use physical uart interface, then it should
work just fine.

Cheers,
Jukka

On Thu, 2018-10-11 at 16:01 -0700, cpmcparland@rtisys.org wrote:
Hi,

I need to get a sensor data stream flowing from a BT network into a
linux host. Have tried
to setup BT HCI interface but no luck getting hci0 interface to move
from DOWN to UP.
So, thought I would take a different approach and put a dual stack on
the nrf52 with the
ip link to the host going through a serial port.

So, I would like to set up a slip tcp/ip connection between a linux
host and a nrf52840. I know
slip can be used to connect to a qemu simulation. Has anyone used
slip to talk to a physical
uart interface? If so, can I use the nrf52840's console port or do I
need to use a seperate
uart and interface via a FTDI usb cable?

Echo_server sample code seems to be a good base to start with....Any
suggestions would help.

Regards,
Chuck McP


cpmcparland@...
 

Andrei,

THanks for the note....unfortuately, the USB interface is peripheral only. So, as I
understand it, I can't control USB/WiFi dongles which are also peripheral mode
devices. 

Cheers,
Chuck McP


cpmcparland@...
 

Jukka,

Thanks, I was hoping that was the case.  Have found the slip.c code and am looking through it.
Not too many examples for slip and the ones I have seen all point to Qemu.  Any idea or pointers
as to where uart pipe gets created?  I'm guessing its buried somewhere in the Qemu board support
config files. 

Regards,
Chuck McP


Andrei Emeltchenko <andrei.emeltchenko@...>
 

On Fri, Oct 12, 2018 at 10:35:23AM -0700, cpmcparland@rtisys.org wrote:
Andrei,

THanks for the note....unfortuately, the USB interface is peripheral only.
Your device can be USB Ethernet dongle itself, no need to connect extra
stuff.

Best regards
Andrei Emeltchenko


Serafin Leschke <serafin.leschke@...>
 

Forward to list:

Hi Chuck


I tried this myself (and failed.). There is a separate net-tools repo: https://github.com/zephyrproject-rtos/net-tools


In there you find tunslip6.c which should configure the slip on the host side, but I was not successful in getting the communication to work. (The host did send a packet down the serial line but newer got a response).


So if anybody finds out how to do this, it would be great if it would find it's way into the documentation.


Best regards

Serafin


On 12/10/18 19:39, cpmcparland@... wrote:
Jukka,

Thanks, I was hoping that was the case.  Have found the slip.c code and am looking through it.
Not too many examples for slip and the ones I have seen all point to Qemu.  Any idea or pointers
as to where uart pipe gets created?  I'm guessing its buried somewhere in the Qemu board support
config files. 

Regards,
Chuck McP


Dominik.Kilian@...
 

Hi Chuck,

I was also trying to get slip network driver running on nRF. I was using it to create secure TLS connection. It was in TAP mode. I disabled logs, so the driver was the only user of UART. Generally connection was really unstable. I don't know if it was fault of software on PC or board side. I give up after few tries of getting it working more stable. Are you also want to use secure TLS connection over SLIP?

Regards,
   Dominik


cpmcparland@...
 

All,

Thanks for the suggestions and sharing results.  I think I'll go with USB network device solution.  I've tried the sample "samples/net/echo_server" and, with the addition of the overlay-netusb(?) to the prj.config, it came up and worked.  The current docs have the 3 additional linux side commands to add the enumerated net device to the linux ip stack, bring it up and, lastly, provide a route.  Adding the overlay config file in the cmake is a nice trick, but took a bit of digging to find an example. I hope this solution will be stable...will report on results.  It seems to have fewer moving (and, perhaps, simpler)  parts on the linux side than using slip.

This issue has come up because my app needs to stream data from a ble (hopefully bluetooth 5) net into a linux platform.  Initially tried setting up a HCI connection to zephyr hci firmware running in the ble dongle; but, couldn't get the HCI interface to come up on the linux side. While wading through the btattach and config docs, I came across the usb network device option.  Fortunately, I have sufficient resources on the dongle to run a dual stack (ip/ble) and add an app to bring the stream into the linux box as ip - as opposed to hci + ble/ipv6.  At least that's my plan at the moment.  But, I am curious about how others are dealing with this issue....are folks using (or waiting for!) commercial ble/ip gateways to bridge this gap or is there another solution I'm not aware of yet?

Cheers,
Chuck


Marti Bolivar <marti@...>
 

Hi Chuck,

On Thu, Oct 18, 2018 at 12:22 PM <cpmcparland@...> wrote:
All,

Thanks for the suggestions and sharing results.  I think I'll go with USB network device solution.  I've tried the sample "samples/net/echo_server" and, with the addition of the overlay-netusb(?) to the prj.config, it came up and worked.  The current docs have the 3 additional linux side commands to add the enumerated net device to the linux ip stack, bring it up and, lastly, provide a route.  Adding the overlay config file in the cmake is a nice trick, but took a bit of digging to find an example. I hope this solution will be stable...will report on results.  It seems to have fewer moving (and, perhaps, simpler)  parts on the linux side than using slip.

This issue has come up because my app needs to stream data from a ble (hopefully bluetooth 5) net into a linux platform.  Initially tried setting up a HCI connection to zephyr hci firmware running in the ble dongle; but, couldn't get the HCI interface to come up on the linux side. While wading through the btattach and config docs, I came across the usb network device option.  Fortunately, I have sufficient resources on the dongle to run a dual stack (ip/ble) and add an app to bring the stream into the linux box as ip - as opposed to hci + ble/ipv6.  At least that's my plan at the moment.  But, I am curious about how others are dealing with this issue....are folks using (or waiting for!) commercial ble/ip gateways to bridge this gap or is there another solution I'm not aware of yet?

Since you've asked, I guess it's not rude to note that my company (https://foundries.io/) does have Linux-based BLE/IP gateway software you can take a look at (with support for multiple architectures and boards). They're integrated with Zephyr; we provide detailed instructions in our docs for how to set them up etc. They work with nRF52840 on the Zephyr side, as well as other boards. The product is subscription-based but you get full source access.

Best,
Marti
 

Cheers,
Chuck


cpmcparland@...
 

Marti,

Not rude at all...will look over your web site.  Finding the right fit for a commercial
embedded, mostly software product is a tough problem.  Will be interested to see
where you folks fit in the "app stack".  Will contact foundries.io separately if I have
further product questions.

Cheers,
Chuck


Paul Sokolovsky
 

Hello,

On Thu, 18 Oct 2018 11:22:10 -0700
cpmcparland@rtisys.org wrote:

All,
[]

ble/ipv6.  At least that's my plan at the moment.  But, I am curious
about how others are dealing with this issue...
I'm sure that someone without imagination would just stream data over
old good serial connection - either in textual form, as a sequence of
lines, or with some simple binary protocol.

From my side, I can only encourage people to play with something more
advanced than that - we need people to try that, report back results,
us fix it as needed. Oftentimes it's indeed a matter of docs
[1] (including common pitfalls and troubleshooting sections). So indeed,
without poking, too little and too slow will happen, so thanks for
trying it!


[1] I for one ate enough dogfood on playing with BLE IPSP support and
tried to provide detailed enough walkthru on setting it up in the
corresponding docs:
https://docs.zephyrproject.org/latest/samples/bluetooth/ipsp/README.html



Cheers,
Chuck
--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Andrei Emeltchenko <andrei.emeltchenko@...>
 

Hi,

On Thu, Oct 18, 2018 at 11:22:10AM -0700, cpmcparland@rtisys.org wrote:
All,

Thanks for the suggestions and sharing results.  I think I'll go with USB
network device solution.  I've tried the sample "samples/net/echo_server"
and, with the addition of the overlay-netusb(?) to the prj.config, it came
up and worked.  The current docs have the 3 additional linux side commands
to add the enumerated net device to the linux ip stack, bring it up and,
lastly, provide a route. 
Some Linux distros might do most of work configuring interfaces for you.

If you enable IPv4 autoconfiguration and LLMNR or mDNS you should be able
to access zephyr with short name "zephyr" or "zephyr.local".
We need to document this though...

Best regards
Andrei Emeltchenko

Adding the overlay config file in the cmake is a
nice trick, but took a bit of digging to find an example. I hope this
solution will be stable...will report on results.  It seems to have fewer
moving (and, perhaps, simpler)  parts on the linux side than using slip.

This issue has come up because my app needs to stream data from a ble
(hopefully bluetooth 5) net into a linux platform.  Initially tried
setting up a HCI connection to zephyr hci firmware running in the ble
dongle; but, couldn't get the HCI interface to come up on the linux side.
While wading through the btattach and config docs, I came across the usb
network device option.  Fortunately, I have sufficient resources on the
dongle to run a dual stack (ip/ble) and add an app to bring the stream
into the linux box as ip - as opposed to hci + ble/ipv6.  At least that's
my plan at the moment.  But, I am curious about how others are dealing
with this issue....are folks using (or waiting for!) commercial ble/ip
gateways to bridge this gap or is there another solution I'm not aware of
yet?

Cheers,
Chuck


References

Visible links
1. https://lists.zephyrproject.org/g/devel/message/5263
2. mailto:cpmcparland@rtisys.org?subject=Private:%20Re:%20Re%3A%20%5BZephyr-devel%5D%20Slip%20TCP%20connection%20between%20linux%20host%20and%20nrf52840
3. mailto:devel@lists.zephyrproject.org?subject=Re:%20Re%3A%20%5BZephyr-devel%5D%20Slip%20TCP%20connection%20between%20linux%20host%20and%20nrf52840
4. https://lists.zephyrproject.org/mt/27261061/900599
5. https://lists.zephyrproject.org/g/devel/post
6. https://lists.zephyrproject.org/g/devel/editsub/900599
7. mailto:devel+owner@lists.zephyrproject.org
8. https://lists.zephyrproject.org/g/devel/unsub