Date   

Re: echo-server ipv6 doesn't work

Goldman, Michael <michael.goldman@...>
 

Hi Paul,

I removed the entire zephyr project and re-pulled it and now it works, I don't have an explanation for that...
Sorry for that...

Thanks,
Michael

-----Original Message-----
From: Paul Sokolovsky [mailto:paul.sokolovsky@linaro.org]
Sent: Tuesday, March 28, 2017 13:59
To: Goldman, Michael <michael.goldman@intel.com>
Cc: devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] echo-server ipv6 doesn't work

On Tue, 28 Mar 2017 07:22:51 +0000
"Goldman, Michael" <michael.goldman@intel.com> wrote:

Maybe this will help, I see those prints in window I'm running
loop-slip-tap.sh in:

tunslip6: serial_to_tun: read: Interrupted system call ifconfig tap0
down netstat -nr | awk '{ if ($2 == "tap0") print "route delete -net
"$1; }' | sh tunslip6: can't open siodev ``2001:db8::1/64'': No such
file or directory tunslip6: can't open siodev ``2001:db8::1/64'': No
such file or directory tunslip6: can't open siodev
``2001:db8::1/64'': No such file or directory .
I get such messages when I don't have ./loop-socat.sh running (in another terminal window), so you may want to check you follow https://www.zephyrproject.org/doc/subsystems/networking/qemu_setup.html
closely.

Let me retest this on-spot, with the latests HEADs of both repos:

net-tools: 3c81e2a3e5a (few revisions before that had a bug)

zephyr: master 9d0c020a9b

$ cd samples/net/echo_server
$ make pristine
$ make run

In another terminal window:

$ ping 192.0.2.1
PING 192.0.2.1 (192.0.2.1) 56(84) bytes of data.
64 bytes from 192.0.2.1: icmp_seq=1 ttl=64 time=5.67 ms
64 bytes from 192.0.2.1: icmp_seq=2 ttl=64 time=6.15 ms

$ ping6 2001:db8::1
PING 2001:db8::1(2001:db8::1) 56 data bytes
64 bytes from 2001:db8::1: icmp_seq=1 ttl=64 time=17.8 ms
64 bytes from 2001:db8::1: icmp_seq=2 ttl=64 time=6.35 ms


I hope, you keep in mind that when you switch between qemu_x86 and real board networking testing, you need to kill loop-slip-tap.sh (or you'd have address conflict between network interfaces).

.
.

thanks,
Michael

-----Original Message-----
From: Perez-Gonzalez, Inaky
Sent: Monday, March 27, 2017 23:47
To: Goldman, Michael <michael.goldman@intel.com>; Jukka Rissanen
<jukka.rissanen@linux.intel.com>; devel@lists.zephyrproject.org
Subject: RE: [Zephyr-devel] echo-server ipv6 doesn't work

I haven't been able to test ipv6 on the automation framework yet, but
if past experience is to be heeded, I would not be surprised if
lurking issues were there. ________________________________________
From: zephyr-devel-bounces@lists.zephyrproject.org
[zephyr-devel-bounces@lists.zephyrproject.org] on behalf of Goldman,
Michael [michael.goldman@intel.com] Sent: Monday, March 27, 2017 1:05
PM To: Jukka Rissanen; devel@lists.zephyrproject.org Subject: Re:
[Zephyr-devel] echo-server ipv6 doesn't work

Hi all,

Sorry for not stating that I was testing it on Atmel SAMV71 board,
using the configuration file attached. Also tried running in qemu
(https://www.zephyrproject.org/doc/subsystems/networking/qemu_setup.ht
ml) and also there only IPV4 works - maybe it would help: I do not see
any IPv6 packets on the sniffer "tap0" interface, only IPV4 traffic.

Thanks,
Michael

-----Original Message-----
From: Jukka Rissanen [mailto:jukka.rissanen@linux.intel.com]
Sent: Monday, March 27, 2017 20:04
To: Goldman, Michael <michael.goldman@intel.com>;
devel@lists.zephyrproject.org Subject: Re: [Zephyr-devel] echo-server
ipv6 doesn't work

Hi Michael,

IPv6 should work just fine, I am using it daily.

What exactly is your setup, are you using qemu or real hw?
Can you show the config file?


Cheers,
Jukka


On Mon, 2017-03-27 at 14:40 +0000, Goldman, Michael wrote:
Hi all,

Does anyone try to test IPv6 on latest echo-server app?
IPv6 doesn't work for me (ping fails) and IPv4 works only if IPv6 is
disabled.

Thanks,
Michael

--------------------------------------------------------------------
- A member of the Intel Corporation group of companies This e-mail
and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by
others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


--
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
---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


Re: dhcp integration into the platform

Jukka Rissanen
 

Hi Piotr,

On Tue, 2017-03-28 at 11:11 +0200, Piotr Mienkowski wrote:
Hi Marcus,

Thanks for your extensive and very well written emails. Looking at
this thread it's clear that there indeed "there are two different
world views of the conceptual purpose of net_if_up() and
net_if_down()."

To add to the discussion I would like to remind here one design issue
related to Ethernet drivers which, I belive, is not yet clarified. As
principle Ethernet drivers are initialized before the network stack
is. Currently the initialization process involves bringing up the
interface and establishing a functioning data link. If at that time
Ethernet driver receives an RX frame it will try to forward it to the
network stack even if it may not be initialized yet. That's a race
condition. One way to solve it would be to have an interface
enable/disable function. The data link would be established only when
it is explicitly requested by the network stack.
Currently the interface is marked UP when we are ready to receive
packets. So far this has worked well and I propose we keep it like
this.


As you have mentioned a few times already we also need to handle a
scenario where a user unplugs the network cable and plugs it in some
time later possibly on a different LAN. So also for me the option 2)
seems like a more natural way forward.

2) We keep the enable/disable semantic.  This implies:
- We split net_if_up/down into net_if_enable/disable() and
net_if_up/down() such that net_if_enable calls l2->enable() while
net_if_up/down deals with NET_IF_UP and raising
net_event_if_up/down
- The hardwired net_if_up() calls at network stack boot are
switched
to call net_if_enable()
- The BT L2 enable callback is used to turn advertising on/off
- Every network device needs to call net_if_up() once it has a link
established (and net_if_down when it drops). (BT already does this)
I'm only not sure how an interface power up / power down
functionality fits in here. In any case the final say belongs to the
network stack maintainers. 

Cheers,
Piotr
Cheers,
Jukka


Re: echo-server ipv6 doesn't work

Paul Sokolovsky
 

On Tue, 28 Mar 2017 07:22:51 +0000
"Goldman, Michael" <michael.goldman@intel.com> wrote:

Maybe this will help, I see those prints in window I'm running
loop-slip-tap.sh in:

tunslip6: serial_to_tun: read: Interrupted system call
ifconfig tap0 down
netstat -nr | awk '{ if ($2 == "tap0") print "route delete -net
"$1; }' | sh tunslip6: can't open siodev ``2001:db8::1/64'': No such
file or directory tunslip6: can't open siodev ``2001:db8::1/64'': No
such file or directory tunslip6: can't open siodev
``2001:db8::1/64'': No such file or directory .
I get such messages when I don't have ./loop-socat.sh running (in
another terminal window), so you may want to check you follow
https://www.zephyrproject.org/doc/subsystems/networking/qemu_setup.html
closely.

Let me retest this on-spot, with the latests HEADs of both repos:

net-tools: 3c81e2a3e5a (few revisions before that had a bug)

zephyr: master 9d0c020a9b

$ cd samples/net/echo_server
$ make pristine
$ make run

In another terminal window:

$ ping 192.0.2.1
PING 192.0.2.1 (192.0.2.1) 56(84) bytes of data.
64 bytes from 192.0.2.1: icmp_seq=1 ttl=64 time=5.67 ms
64 bytes from 192.0.2.1: icmp_seq=2 ttl=64 time=6.15 ms

$ ping6 2001:db8::1
PING 2001:db8::1(2001:db8::1) 56 data bytes
64 bytes from 2001:db8::1: icmp_seq=1 ttl=64 time=17.8 ms
64 bytes from 2001:db8::1: icmp_seq=2 ttl=64 time=6.35 ms


I hope, you keep in mind that when you switch between qemu_x86 and real
board networking testing, you need to kill loop-slip-tap.sh (or you'd
have address conflict between network interfaces).

.
.

thanks,
Michael

-----Original Message-----
From: Perez-Gonzalez, Inaky
Sent: Monday, March 27, 2017 23:47
To: Goldman, Michael <michael.goldman@intel.com>; Jukka Rissanen
<jukka.rissanen@linux.intel.com>; devel@lists.zephyrproject.org
Subject: RE: [Zephyr-devel] echo-server ipv6 doesn't work

I haven't been able to test ipv6 on the automation framework yet, but
if past experience is to be heeded, I would not be surprised if
lurking issues were there. ________________________________________
From: zephyr-devel-bounces@lists.zephyrproject.org
[zephyr-devel-bounces@lists.zephyrproject.org] on behalf of Goldman,
Michael [michael.goldman@intel.com] Sent: Monday, March 27, 2017 1:05
PM To: Jukka Rissanen; devel@lists.zephyrproject.org Subject: Re:
[Zephyr-devel] echo-server ipv6 doesn't work

Hi all,

Sorry for not stating that I was testing it on Atmel SAMV71 board,
using the configuration file attached. Also tried running in qemu
(https://www.zephyrproject.org/doc/subsystems/networking/qemu_setup.html)
and also there only IPV4 works - maybe it would help: I do not see
any IPv6 packets on the sniffer "tap0" interface, only IPV4 traffic.

Thanks,
Michael

-----Original Message-----
From: Jukka Rissanen [mailto:jukka.rissanen@linux.intel.com]
Sent: Monday, March 27, 2017 20:04
To: Goldman, Michael <michael.goldman@intel.com>;
devel@lists.zephyrproject.org Subject: Re: [Zephyr-devel] echo-server
ipv6 doesn't work

Hi Michael,

IPv6 should work just fine, I am using it daily.

What exactly is your setup, are you using qemu or real hw?
Can you show the config file?


Cheers,
Jukka


On Mon, 2017-03-27 at 14:40 +0000, Goldman, Michael wrote:
Hi all,

Does anyone try to test IPv6 on latest echo-server app?
IPv6 doesn't work for me (ping fails) and IPv4 works only if IPv6
is disabled.

Thanks,
Michael

---------------------------------------------------------------------
A member of the Intel Corporation group of companies This e-mail
and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by
others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


--
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


Re: dhcp integration into the platform

Piotr Mienkowski
 

Hi Marcus,

Thanks for your extensive and very well written emails. Looking at this thread it's clear that there indeed "there are two different world views of the conceptual purpose of net_if_up() and net_if_down()."

To add to the discussion I would like to remind here one design issue related to Ethernet drivers which, I belive, is not yet clarified. As principle Ethernet drivers are initialized before the network stack is. Currently the initialization process involves bringing up the interface and establishing a functioning data link. If at that time Ethernet driver receives an RX frame it will try to forward it to the network stack even if it may not be initialized yet. That's a race condition. One way to solve it would be to have an interface enable/disable function. The data link would be established only when it is explicitly requested by the network stack.

As you have mentioned a few times already we also need to handle a scenario where a user unplugs the network cable and plugs it in some time later possibly on a different LAN. So also for me the option 2) seems like a more natural way forward.

> 2) We keep the enable/disable semantic.  This implies:
> - We split net_if_up/down into net_if_enable/disable() and
> net_if_up/down() such that net_if_enable calls l2->enable() while
> net_if_up/down deals with NET_IF_UP and raising net_event_if_up/down
> - The hardwired net_if_up() calls at network stack boot are switched
> to call net_if_enable()
> - The BT L2 enable callback is used to turn advertising on/off
> - Every network device needs to call net_if_up() once it has a link
> established (and net_if_down when it drops). (BT already does this)

I'm only not sure how an interface power up / power down functionality fits in here. In any case the final say belongs to the network stack maintainers. 

Cheers,
Piotr


Re: echo-server ipv6 doesn't work

Goldman, Michael <michael.goldman@...>
 

Maybe this will help, I see those prints in window I'm running loop-slip-tap.sh in:

tunslip6: serial_to_tun: read: Interrupted system call
ifconfig tap0 down
netstat -nr | awk '{ if ($2 == "tap0") print "route delete -net "$1; }' | sh
tunslip6: can't open siodev ``2001:db8::1/64'': No such file or directory
tunslip6: can't open siodev ``2001:db8::1/64'': No such file or directory
tunslip6: can't open siodev ``2001:db8::1/64'': No such file or directory
.
.
.

thanks,
Michael

-----Original Message-----
From: Perez-Gonzalez, Inaky
Sent: Monday, March 27, 2017 23:47
To: Goldman, Michael <michael.goldman@intel.com>; Jukka Rissanen <jukka.rissanen@linux.intel.com>; devel@lists.zephyrproject.org
Subject: RE: [Zephyr-devel] echo-server ipv6 doesn't work

I haven't been able to test ipv6 on the automation framework yet, but if past experience is to be heeded, I would not be surprised if lurking issues were there.
________________________________________
From: zephyr-devel-bounces@lists.zephyrproject.org [zephyr-devel-bounces@lists.zephyrproject.org] on behalf of Goldman, Michael [michael.goldman@intel.com]
Sent: Monday, March 27, 2017 1:05 PM
To: Jukka Rissanen; devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] echo-server ipv6 doesn't work

Hi all,

Sorry for not stating that I was testing it on Atmel SAMV71 board, using the configuration file attached.
Also tried running in qemu (https://www.zephyrproject.org/doc/subsystems/networking/qemu_setup.html) and also there only IPV4 works - maybe it would help: I do not see any IPv6 packets on the sniffer "tap0" interface, only IPV4 traffic.

Thanks,
Michael

-----Original Message-----
From: Jukka Rissanen [mailto:jukka.rissanen@linux.intel.com]
Sent: Monday, March 27, 2017 20:04
To: Goldman, Michael <michael.goldman@intel.com>; devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] echo-server ipv6 doesn't work

Hi Michael,

IPv6 should work just fine, I am using it daily.

What exactly is your setup, are you using qemu or real hw?
Can you show the config file?


Cheers,
Jukka


On Mon, 2017-03-27 at 14:40 +0000, Goldman, Michael wrote:
Hi all,

Does anyone try to test IPv6 on latest echo-server app?
IPv6 doesn't work for me (ping fails) and IPv4 works only if IPv6 is
disabled.

Thanks,
Michael

---------------------------------------------------------------------
A member of the Intel Corporation group of companies This e-mail and
any attachments may contain confidential material for the sole use of
the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please
contact the sender and delete all copies.
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


Re: RFC: BSD Socket (like) API

Gil Pitney
 

I think application developers would prefer to see ONE simple,
standard API for networking on which to build all higher level
networking protocols and applications.

However, I understand the Zephyr IP stack needs to target highly
memory constrained systems, and the decision has been made that the
standard POSIX APIs are just not suitable.

So, now the concern is that we are left with two "BSD-like" APIs doing
essentially the same thing, one purporting to use less data space,
though shifting more complexity and code-space up to the application,
and allowing applications to be written one of two (or both?) ways.

So, then, a couple recommendations:

1) Let's start with the standard POSIX APIs:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_10

and devolve from there with a list of exceptions with rationale for
why Zephyr cannot or should not comply with the standard.

For example, APIs dealing with file descriptors are reasonable
exceptions, because Zephyr does not support a POSIX file system.

I'd avoid terms like "BSD-like", as the current Zephyr APIs are
arguably "BSD-like" to some degree - just not standard.

2) Enable TCP/IP offload from the socket layer.

The TI CC3220 completely offloads the TCP/IP stack onto a
co-processor, by marshalling BSD socket API calls over SPI to the
network coprocessor.

The current NET_OFFLOAD support in the Zephyr IP stack provides a hook
to call an offload engine. For the TI CC3220, this mapping of
net_context APIs to BSD socket APIs adds some overhead and code
complexity.

However, now that we're talking about adding a BSD socket layer to
Zephyr, offloading directly from the socket layer would be more
natural (something similar to the MyNewt solution, as pointed out by
Sterling).

Otherwise, we have to map BSD sockets -> net_context -> BSD sockets,
with all the required extra overhead of data structures, sync
primitives, and server thread(s) to handle mapping between the two
different networking API usage models.

By doing so, I understand we could potentially bypass the (TBD)
routing table. But that is a use case, AFAIK, not really needed for
the CC3220 typical client IoT node devices.

Then again, the POSIX socket standard specifies that sockets shall
support routing, so maybe we can just make that work somehow?

On 27 March 2017 at 06:27, Paul Sokolovsky <paul.sokolovsky@linaro.org> wrote:
Hello Jukka,

On Mon, 27 Mar 2017 12:37:40 +0300
Jukka Rissanen <jukka.rissanen@linux.intel.com> wrote:

[]
The current approach is that we value lightweight nature of Zephyr,
and
looking towards finding a minimal set of changes (additions) to
provide
BSD Sockets *like* API to Zephyr.
The definition of what is BSD Socket *like* system seems to differ
from person to person.
That's true, and the reason why I informally proposed the "process-wise"
definition above: "minimal set of changes (additions) to provide
BSD Sockets *like* API to Zephyr."

For me the current net_context API in Zephyr
is quite BSD socket like, meaning that the API provides similar
functions that are found in BSD socket API like open, close, bind,
connect, accept etc. So it is quite easy to port the application in
this respect.
That's also true, and I right from the start got a habit to call
net_context "a socket". The API calls you mention are all indeed work
(likely almost) the same. The big difference comes with recv() call -
whereas BSD Sockets API has it conventionally pull-style, in Zephyr
it's push-style, where data gets delivered to an app via a callback.
That's one single feature which makes porting 3rd-party applications
complicated and cumbersome.


The bigger difference between BSD socket API and Zephyr net_context
API is:
* net_context API uses net_buf to pass data. The net_buf does not
provide linear memory but data needs to be partitioned when sending
and read in chunks when receiving. We have helpers defined in nbuf.h
for handling reading/writing data in this case. The issue with linear
memory case is that it uses much more memory as we need to be prepared
to receive at least 1280 byte size chunks of data (IPv6 min data
packet size).
Right. And that part is covered by BSD Sockets' own API - the data is
passed via app-owned buffers, not system-owned buffers. That means that
by definition, BSD Sockets don't support zero-copy operation. While an
obvious drawback, it has its positive sides to, like it offers
possibility for better system vs app separation for security.

* The net_context is asynchronous and caller needs to have callbacks
defined. The BSD socket API is synchronous. The net_context can be
used in synchronous way so this is a smaller issue imho.
As you may already noticed, I prefer to call this distinction
"push-style vs pull-style", because it pinpoints the problem better. The
net_context used "in synchronous way" doesn't provide BSD Sockets
behavior for receives. For that to work, incoming (but unprocessed) data
needs to be queue *per socket*, until an app requests it. And indeed,
that's the one big initial change I would need to make.

Having a BSD socket API on top of net_context will use more memory so
if one is concerned about memory consumption, then using native API
should be preferred.
+100, BSD Sockets like API is not a replacement for native API, only a
helper to port existing applications (mostly libraries in the
real-world cases, I may imagine, but only practice will tell how
people will use it).

[]

--
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
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: echo-server ipv6 doesn't work

Perez-Gonzalez, Inaky <inaky.perez-gonzalez@...>
 

I haven't been able to test ipv6 on the automation framework yet, but if past experience is to be heeded, I would not be surprised if lurking issues were there.
________________________________________
From: zephyr-devel-bounces@lists.zephyrproject.org [zephyr-devel-bounces@lists.zephyrproject.org] on behalf of Goldman, Michael [michael.goldman@intel.com]
Sent: Monday, March 27, 2017 1:05 PM
To: Jukka Rissanen; devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] echo-server ipv6 doesn't work

Hi all,

Sorry for not stating that I was testing it on Atmel SAMV71 board, using the configuration file attached.
Also tried running in qemu (https://www.zephyrproject.org/doc/subsystems/networking/qemu_setup.html) and also there only IPV4 works - maybe it would help: I do not see any IPv6 packets on the sniffer "tap0" interface, only IPV4 traffic.

Thanks,
Michael

-----Original Message-----
From: Jukka Rissanen [mailto:jukka.rissanen@linux.intel.com]
Sent: Monday, March 27, 2017 20:04
To: Goldman, Michael <michael.goldman@intel.com>; devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] echo-server ipv6 doesn't work

Hi Michael,

IPv6 should work just fine, I am using it daily.

What exactly is your setup, are you using qemu or real hw?
Can you show the config file?


Cheers,
Jukka


On Mon, 2017-03-27 at 14:40 +0000, Goldman, Michael wrote:
Hi all,

Does anyone try to test IPv6 on latest echo-server app?
IPv6 doesn’t work for me (ping fails) and IPv4 works only if IPv6 is
disabled.

Thanks,
Michael

---------------------------------------------------------------------
A member of the Intel Corporation group of companies This e-mail and
any attachments may contain confidential material for the sole use of
the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please
contact the sender and delete all copies.
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


Re: echo-server ipv6 doesn't work

Goldman, Michael <michael.goldman@...>
 

Hi all,

Sorry for not stating that I was testing it on Atmel SAMV71 board, using the configuration file attached.
Also tried running in qemu (https://www.zephyrproject.org/doc/subsystems/networking/qemu_setup.html) and also there only IPV4 works - maybe it would help: I do not see any IPv6 packets on the sniffer "tap0" interface, only IPV4 traffic.

Thanks,
Michael

-----Original Message-----
From: Jukka Rissanen [mailto:jukka.rissanen@linux.intel.com]
Sent: Monday, March 27, 2017 20:04
To: Goldman, Michael <michael.goldman@intel.com>; devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] echo-server ipv6 doesn't work

Hi Michael,

IPv6 should work just fine, I am using it daily.

What exactly is your setup, are you using qemu or real hw?
Can you show the config file?


Cheers,
Jukka


On Mon, 2017-03-27 at 14:40 +0000, Goldman, Michael wrote:
Hi all,
 
Does anyone try to test IPv6 on latest echo-server app?
IPv6 doesn’t work for me (ping fails) and IPv4 works only if IPv6 is
disabled.
 
Thanks,
Michael
 
---------------------------------------------------------------------
A member of the Intel Corporation group of companies This e-mail and
any attachments may contain confidential material for the sole use of
the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please
contact the sender and delete all copies.
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


External SRAM

Justin
 

Has anyone implemented external SRAM with a board? I looked through all the board defconfig files. I saw nothing indicating setup of a parallel bus (PMP, Flexbus, SMC, etc) to an external RAM chip. I also didn't see a driver for external RAM chips.

To add external RAM should I add code in the board directory to setup the parallel bus and initialize the RAM? How do I let Zephyr know that I have more RAM at a specific address?


Re: echo-server ipv6 doesn't work

Jukka Rissanen
 

Hi Michael,

IPv6 should work just fine, I am using it daily.

What exactly is your setup, are you using qemu or real hw?
Can you show the config file?


Cheers,
Jukka

On Mon, 2017-03-27 at 14:40 +0000, Goldman, Michael wrote:
Hi all,
 
Does anyone try to test IPv6 on latest echo-server app?
IPv6 doesn’t work for me (ping fails) and IPv4 works only if IPv6 is
disabled.
 
Thanks,
Michael
 
---------------------------------------------------------------------
A member of the Intel Corporation group of companies
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: echo-server ipv6 doesn't work

Luiz Augusto von Dentz
 

Hi Michael,

On Mon, Mar 27, 2017 at 6:07 PM, Paul Sokolovsky
<paul.sokolovsky@linaro.org> wrote:
Hello,

On Mon, 27 Mar 2017 14:40:13 +0000
"Goldman, Michael" <michael.goldman@intel.com> wrote:

Hi all,

Does anyone try to test IPv6 on latest echo-server app?
IPv6 doesn't work for me (ping fails) and IPv4 works only if IPv6 is
disabled.
What BOARD? I believe I tested it on Sat with qemu_x86 and saw IPv6
pings (but didn't try actual data echoing).
It also works for me with Bluetooth, the only problem Im having is
when using global addresses it seems there is something dropping the
packets before it reaches the echo-client process, but that can be
something in the Linux side.

--
Luiz Augusto von Dentz


Re: echo-server ipv6 doesn't work

Paul Sokolovsky
 

Hello,

On Mon, 27 Mar 2017 14:40:13 +0000
"Goldman, Michael" <michael.goldman@intel.com> wrote:

Hi all,

Does anyone try to test IPv6 on latest echo-server app?
IPv6 doesn't work for me (ping fails) and IPv4 works only if IPv6 is
disabled.
What BOARD? I believe I tested it on Sat with qemu_x86 and saw IPv6
pings (but didn't try actual data echoing).


Thanks,
Michael
[]

--
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


echo-server ipv6 doesn't work

Goldman, Michael <michael.goldman@...>
 

Hi all,

 

Does anyone try to test IPv6 on latest echo-server app?

IPv6 doesn’t work for me (ping fails) and IPv4 works only if IPv6 is disabled.

 

Thanks,

Michael

 

---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


Re: RFC: BSD Socket (like) API

Paul Sokolovsky
 

Hello Jukka,

On Mon, 27 Mar 2017 12:37:40 +0300
Jukka Rissanen <jukka.rissanen@linux.intel.com> wrote:

[]
The current approach is that we value lightweight nature of Zephyr,
and
looking towards finding a minimal set of changes (additions) to
provide
BSD Sockets *like* API to Zephyr.
The definition of what is BSD Socket *like* system seems to differ
from person to person.
That's true, and the reason why I informally proposed the "process-wise"
definition above: "minimal set of changes (additions) to provide
BSD Sockets *like* API to Zephyr."

For me the current net_context API in Zephyr
is quite BSD socket like, meaning that the API provides similar
functions that are found in BSD socket API like open, close, bind,
connect, accept etc. So it is quite easy to port the application in
this respect.
That's also true, and I right from the start got a habit to call
net_context "a socket". The API calls you mention are all indeed work
(likely almost) the same. The big difference comes with recv() call -
whereas BSD Sockets API has it conventionally pull-style, in Zephyr
it's push-style, where data gets delivered to an app via a callback.
That's one single feature which makes porting 3rd-party applications
complicated and cumbersome.


The bigger difference between BSD socket API and Zephyr net_context
API is:
* net_context API uses net_buf to pass data. The net_buf does not
provide linear memory but data needs to be partitioned when sending
and read in chunks when receiving. We have helpers defined in nbuf.h
for handling reading/writing data in this case. The issue with linear
memory case is that it uses much more memory as we need to be prepared
to receive at least 1280 byte size chunks of data (IPv6 min data
packet size).
Right. And that part is covered by BSD Sockets' own API - the data is
passed via app-owned buffers, not system-owned buffers. That means that
by definition, BSD Sockets don't support zero-copy operation. While an
obvious drawback, it has its positive sides to, like it offers
possibility for better system vs app separation for security.

* The net_context is asynchronous and caller needs to have callbacks
defined. The BSD socket API is synchronous. The net_context can be
used in synchronous way so this is a smaller issue imho.
As you may already noticed, I prefer to call this distinction
"push-style vs pull-style", because it pinpoints the problem better. The
net_context used "in synchronous way" doesn't provide BSD Sockets
behavior for receives. For that to work, incoming (but unprocessed) data
needs to be queue *per socket*, until an app requests it. And indeed,
that's the one big initial change I would need to make.

Having a BSD socket API on top of net_context will use more memory so
if one is concerned about memory consumption, then using native API
should be preferred.
+100, BSD Sockets like API is not a replacement for native API, only a
helper to port existing applications (mostly libraries in the
real-world cases, I may imagine, but only practice will tell how
people will use it).

[]

--
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


Re: RFC: BSD Socket (like) API

Tomasz Bursztyka
 

Hi Paul,

3- Allow for multiple socket providers
(https://github.com/apache/incubator-mynewt-core/blob/develop/net/ip/mn_socket/include/mn_socket/mn_socket_ops.h),
that way it should be easy to “offload” the IP stack for cases
(e.g. WINC1500) where the IP stack is not on-chip, or where
somebody wants to use an existing commercial/industrial IP stack.
Offloading is already handled through net_context, so it will
seamlessly work already.
One of Gil's point was that CC3200 native interface is exactly BSD
Sockets. So, now he needs to convert that API to push-style native
Zephyr API. Then for this work, I will convert Z native push style to
pull style again. That would mean double "impedance conversion" for a
case like CC3200, and an idea to look if it's possible to avoid it. But
leave that topic to Gil, I'm not an offloading specialist.
The problem with direct offloading - i.e. without net_context etc... - is that it won't integrate
at all properly with systems having multiple network interfaces: ones offering offload, and ones not.
That's why current offload still tightens the "offload device" to a network interface, the core
network stack can handle among other. That will be necessary there will be routing done from
one net-if to another, etc...

The problem of non-linearity of buffer can be solved another way, so I don't see this as a problem here.

In the end, also, it will be way much less work for your layer: it just has to work on top of net_context and
should not care at all about the logic of the network device below.

Br,

Tomasz


Re: RFC: BSD Socket (like) API

Paul Sokolovsky
 

On Mon, 27 Mar 2017 13:19:16 +0200
Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com> wrote:

[]

That's the thing: there won't be any other wrappers.
There is Zephyr's net stack with net_context, and there will be BSD
socket layer Paul is working on, and that's it.
Nope, then (later, one sweet (or sour) day) there will be a more
general POSIX layer on top of it (and other APIs, threading,
filsystem, console, etc.), and then there will be LIBC on top of it. I'm
not a stakeholder for adding all those layers, but I know that there
are such (and likely will be more as Zephyr gets more adoption), so we
should plan for that.

I think that's positive after all - we don't need to plan how to get
all-the-POSIX compliant sockets right away, at least for now.
Instead, can plan for how to get the most juicy BSD Sockets features
while adding the least code (aka bloat). Then at later time, other folks
can provide their arguments for getting more POSIX compliance (at the
expense of adding more code of course).


Tomasz
--
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


Re: RFC: BSD Socket (like) API

Paul Sokolovsky
 

Hello Tomasz,

On Mon, 27 Mar 2017 09:29:31 +0200
Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com> wrote:

Hi Hughes,


https://github.com/apache/incubator-mynewt-core/tree/develop/net/ip/mn_socket/include/mn_socket


I’d like to point to Mynewt’s socket APIs as a reference here, a
couple of things we considered:

1- Don’t keep POSIX names unless you are going to be POSIX
compliant. When running the system simulated, it’s often helpful to
use system sockets to communicate and do things, if you use POSIX
names you have conflicts.
1a- This also allows you to have a “true” POSIX mapping layer
on top, for people who have more memory and truly want socket-level
compatibility.

2- FDs just waste memory, add locking and make things harder to
debug, use socket structures.
I don't know Mynewt, but if I want BSD socket API in Zephyr, I would
like to see no prefix in front of types and functions.
Sure, it's not going to be 100% Posix compliant, and it's not the
point here yes.

But I really want to use socket, bind, listen, as I mostly would in
any other OS.
Please note that these names belong to LIBC namespace, not Zephyr
namespace. So, in our case it's up to Newlib to define them in any it
wants (which is hopefully what we want). I think that good initial
target would be to have a compatibility headers, as I mentioned in
reply to Sterling:

#define socket net_sock_socket
#define listen net_sock_listen
...

(net_sock_ prefix is made and doesn't constitute any specific proposal
- so far).

For the FD, I hope we can make any struct pointer to look alike.
Maybe there are limitations however, not sure.
Right. There may be some limitation, but we should be good to start
with just casting structure pointers to integers and use that as
"socket identifiers". E.g. POSIX (via its publicly available SUSv2
rendition) says:
http://pubs.opengroup.org/onlinepubs/7908799/xns/socket.html "Otherwise
a value of -1 is returned and errno is set to indicate the error.". We
can easily provide that and thus be POSIX compliant.

However, we know that some real-world software likes to test for
negative return value instead:

int fd = socket(...);
if (fd < 0) ...

And indeed, the link above also says "Upon successful completion,
socket() returns a nonnegative integer, the socket file descriptor."
Well, that would be an example of limitation you talk about. But it's
my intuitive impression that majority (well, many) MCUs try to map
RAM/ROM into lower half/quarter of addresspace, so we should be good
here too, subject to actual checking over a long range of various
architectures.


Anyway, I don't want to burden this initial discussion with narrow
issues like above, the point is that there're indeed may be some
limitations to consider, I have some inventory of them in my mind
already, ready to research more, and then will bring up at appropriate
time.




3- Allow for multiple socket providers
(https://github.com/apache/incubator-mynewt-core/blob/develop/net/ip/mn_socket/include/mn_socket/mn_socket_ops.h),
that way it should be easy to “offload” the IP stack for cases
(e.g. WINC1500) where the IP stack is not on-chip, or where
somebody wants to use an existing commercial/industrial IP stack.
Offloading is already handled through net_context, so it will
seamlessly work already.
One of Gil's point was that CC3200 native interface is exactly BSD
Sockets. So, now he needs to convert that API to push-style native
Zephyr API. Then for this work, I will convert Z native push style to
pull style again. That would mean double "impedance conversion" for a
case like CC3200, and an idea to look if it's possible to avoid it. But
leave that topic to Gil, I'm not an offloading specialist.



Br,

Tomasz


--
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


Re: RFC: BSD Socket (like) API

Daniel Thompson <daniel.thompson@...>
 

On 27/03/17 12:19, Tomasz Bursztyka wrote:
2- FDs just waste memory, add locking and make things harder to debug,
use socket structures.
I don't know Mynewt, but if I want BSD socket API in Zephyr, I would
like to see no prefix in front of types and functions.
Sure, it's not going to be 100% Posix compliant, and it's not the point
here yes.

But I really want to use socket, bind, listen, as I mostly would in any
other OS.
A commonly used pattern for BSD-like interfaces is to have a prefixed
API (e.g. net_socket, net_bind) and, introduce a separate mechanism,
to alias the name (either linker magic or just #define socket
net_socket in a separate header).

The reason for this is to do with the multiple definitions of
BSD-like. Making the aliasing *optional* allows an application to
provide alternative wrappers if it needs it...
That's the thing: there won't be any other wrappers.
There is Zephyr's net stack with net_context, and there will be BSD
socket layer Paul is working on, and that's it.
I was regarding as the mechanism to rename symbols
(net_sock_bind -> bind) to be a form of wrapper around BSD-like sockets, albeit a trivial one.

However providing that renaming is optional it does not preclude the application from providing more advanced wrappers if it needs to. For sure, if the BSD-like sockets follow the advice/prior-art in MyNewt and avoid using FDs, allowing the application to opt-out of that decision probably matters.


Daniel.


Re: RFC: BSD Socket (like) API

Tomasz Bursztyka
 

Hi Daniel,


https://github.com/apache/incubator-mynewt-core/tree/develop/net/ip/mn_socket/include/mn_socket


I’d like to point to Mynewt’s socket APIs as a reference here, a
couple of things we considered:

1- Don’t keep POSIX names unless you are going to be POSIX compliant.
When running the system simulated, it’s often helpful to use system
sockets to communicate and do things, if you use POSIX names you have
conflicts.
1a- This also allows you to have a “true” POSIX mapping layer on
top, for people who have more memory and truly want socket-level
compatibility.

2- FDs just waste memory, add locking and make things harder to debug,
use socket structures.
I don't know Mynewt, but if I want BSD socket API in Zephyr, I would
like to see no prefix in front of types and functions.
Sure, it's not going to be 100% Posix compliant, and it's not the point
here yes.

But I really want to use socket, bind, listen, as I mostly would in any
other OS.
A commonly used pattern for BSD-like interfaces is to have a prefixed API (e.g. net_socket, net_bind) and, introduce a separate mechanism, to alias the name (either linker magic or just #define socket net_socket in a separate header).

The reason for this is to do with the multiple definitions of BSD-like. Making the aliasing *optional* allows an application to provide alternative wrappers if it needs it...
That's the thing: there won't be any other wrappers.
There is Zephyr's net stack with net_context, and there will be BSD socket layer Paul is working on, and that's it.

Tomasz


Re: RFC: BSD Socket (like) API

Paul Sokolovsky
 

Hello Sterling,

Thanks for the prompt feedback!

On Sun, 26 Mar 2017 09:37:07 -0700
"Sterling Hughes" <sterling@runtime.io> wrote:

+1

https://github.com/apache/incubator-mynewt-core/tree/develop/net/ip/mn_socket/include/mn_socket

I’d like to point to Mynewt’s socket APIs as a reference here, a
couple of things we considered:
Thanks for MyNewt references on the matter, I'll finally have a good
excuse to look into again (the time for which I couldn't find for a
while) ;-).


1- Don’t keep POSIX names unless you are going to be POSIX
compliant. When running the system simulated, it’s often helpful to
use system sockets to communicate and do things, if you use POSIX
names you have conflicts.
Sure, the "BSD Sockets like API" functions would be still
prefixed/namespaced (I actually wanted to bring up a separate
discussion on namespacing of Zephyr APIs). Then if/when it reaches
enough parity that there could be a talk of porting existing apps with
minimal changes, there would be just a header with stuff like:

#define bind net_sock_bind

1a- This also allows you to have a “true” POSIX mapping layer
on top, for people who have more memory and truly want socket-level
compatibility.

2- FDs just waste memory, add locking and make things harder to
debug, use socket structures.
Agree. That was one of the 1st question I got at the minisummit, and my
answer was: "well, we could waste some memory by adding the FD table to
map small integers to underlying structures, but why?". Indeed, by just
casting pointers to integers, we can go a long, long way of using this
API and porting existing apps.

Generally, the work of adding well-known APIs is just a precursor (or
a subset) of implementing much bigger chunk of POSIX functionality and
making Zephyr much more POSIX compliant. So, I leave FDs introduction,
etc. to these later stages of work.

3- Allow for multiple socket providers
(https://github.com/apache/incubator-mynewt-core/blob/develop/net/ip/mn_socket/include/mn_socket/mn_socket_ops.h),
that way it should be easy to “offload” the IP stack for cases (e.g.
WINC1500) where the IP stack is not on-chip, or where somebody wants
to use an existing commercial/industrial IP stack.
Right. Our initial prototyping team here at Linaro consists of Gil
Pitney and me. Gil works on integrating TI CC3200 into Zephyr, and it
has networking offloading at many different levels, and the point is
exactly to consider whether it makes sense to consider offloading on BSD
Sockets API layer, in addition to various layers he already works on.
So, good point, and thanks for the pointer, we'll have a look how
MyNewt does that.

4- If you are interested in unifying this API with Mynewt, we’d be
happy to talk about agreeing on a unified API for sub-embedded
sockets.
I'll definitely have a look and see what commonality can be achieved,
hope Gil will provide feedback too.


Best,

Sterling

On 26 Mar 2017, at 9:06, Paul Sokolovsky wrote:

Hello,

Support for BSD Sockets API in Zephyr is one of the frequently asked
features from different parties. Possibility of such support was a
topic
of discussions at the recent OpenIoT Summit Portland and Zephyr
Mini-summit Budapest. I'm happy to report that I didn't hear a
single "cons" vote, most people I heard or talked with were
positive that they
either interested in it themselves, or it least OK with it if it's
properly layered and doesn't bloat existing networking API.

So, based on that, Linaro Zephyr team would like to proceed with
bootstrapping work on this, collecting initial requirements, and
starting prototyping. I submitted a Jira Epic
https://jira.zephyrproject.org/browse/ZEP-1921 for this feature,
which has a detailed, even if maybe somewhat unstructured
discussion of initial ideas/requirements.

I won't paste it here, instead inviting interested parties to read
it there. Instead, here's a summary of the initial ideas:

1. There's no talk about implementing complete 100% (or 99.9%) POSIX
compliant sockets API. We may get there eventually, but that would
require stakeholders for each expensive or hard to implement
feature. The current approach is that we value lightweight nature
of Zephyr, and
looking towards finding a minimal set of changes (additions) to
provide
BSD Sockets *like* API to Zephyr.

2. The specific featureset of the initial interest is as follows.
The current Z networking API is push-based, where the OS pushes
data into an application (via a callback). Whereas BSD Sockets API
is pull-based,
where an application asks OS for new data to process, when an
application feels like. Implementing this pull-style API is the
initial focus of the effort.

3. The work is going to be guided by porting efforts of an actual
application which needs BSD Sockets API (MicroPython). That would
serve
as an initial (out-of-tree) prototype, with relevant code to be
optimized and merged in-tree for wider reuse.


Consequently, questions to the Zephyr community:

1. Are you interested in BSD Sockets like API?
2. Does the plan above sound good? Any important points to take
care of right from the beginning?
3. Or would you do something differently?
4. Any other feedback is appreciated.



Thanks,
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
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


--
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

5361 - 5380 of 8032