Re: [PATCH v2 2/4] Port wpa supplicant to RTEMS.

[Christian Mauderer]

Hello Sichen,

I was able to establish a WPA encrypted connection. Really great. A few
details:

- I noted that most of the time wpa_supplicant exits, an assert is hit
(for example on a "wpa_supplicant_fork --help"). That's not really a
killer because in normal case wpa_supplicant shouldn't quit. But it is
not ideal too.

- Please don't add blank lines outside of __rtems__ guards to BSD code
(see comment below in the patch).

- There is one change that might could be upstreamed to the
wpa_supplicant repo (see comment in the patch).

- It would be great if you could write some notes how to use this to
some documentation or at least to the mailing list. Otherwise it's hard
to figure out what to do.

- You used the getentropy() but the BBB currently only has the default
implementation which provides just zeroes. That might could lead to weak
crypto.

To the RTEMS community: Should we already add that code? It's not
thoroughly tested and still has some problems (like the assert) but it
adds everything that is necessary for continuing that work. If we don't
merge it, it might get out of date during the next update to a newer
FreeBSD version.

Maybe some 'doc/libbsd-wifi.txt' could be added which contains the
problematic points listed above as well as a short guide how to set up a
wifi connection with the current version? With that a user has some
information about the current progress?

Regards

Christian

Am 12.10.2017 um 14:16 schrieb Sichen Zhao:
> Add wpa_supplicant lib support and shell command support in RTEMS.
> ---
>  builder.py |   1 +
>  freebsd/contrib/wpa/src/utils/os_unix.c|  11 +-
>  freebsd/contrib/wpa/wpa_supplicant/config.h|   3 +
>  freebsd/contrib/wpa/wpa_supplicant/main.c  |  21 ++
>  libbsd.py  | 286 
> +
>  libbsd_waf.py  | 115 -
>  rtemsbsd/include/bsp/nexus-devices.h   |   2 +
>  rtemsbsd/include/machine/rtems-bsd-commands.h  |   2 +
>  .../include/machine/rtems-wpa_supplicant-mutex.h   |  41 +++
>  rtemsbsd/include/rtems/netcmds-config.h|   2 +
>  rtemsbsd/rtems/rtems-bsd-shell-wpa_supplicant.c|  36 +++
>  rtemsbsd/rtems/rtems-wpa_supplicant_mutex.c|  47 
>  12 files changed, 562 insertions(+), 5 deletions(-)
>  create mode 100644 rtemsbsd/include/machine/rtems-wpa_supplicant-mutex.h
>  create mode 100644 rtemsbsd/rtems/rtems-bsd-shell-wpa_supplicant.c
>  create mode 100644 rtemsbsd/rtems/rtems-wpa_supplicant_mutex.c
> 
> diff --git a/builder.py b/builder.py
> index ae2e6ee..5124dc6 100755
> --- a/builder.py
> +++ b/builder.py
> @@ -173,6 +173,7 @@ def includes():
>  return ['-Irtemsbsd/include',
>  '-Ifreebsd/sys',
>  '-Ifreebsd/sys/contrib/pf',
> +'-Ifreebsd/crypto',
>  '-Ifreebsd/sys/net',
>  '-Ifreebsd/include',
>  '-Ifreebsd/lib',
> diff --git a/freebsd/contrib/wpa/src/utils/os_unix.c 
> b/freebsd/contrib/wpa/src/utils/os_unix.c
> index a3abce4..7f101d7 100644
> --- a/freebsd/contrib/wpa/src/utils/os_unix.c
> +++ b/freebsd/contrib/wpa/src/utils/os_unix.c
> @@ -25,6 +25,11 @@
>  #include 
>  #endif /* __MACH__ */
>  
> +#ifdef __rtems__
> +#include 
> +#endif /* __rtems__ */
> +
> +


At this point: Please no blank lines outside of the "#ifdef __rtems__"


>  #include "os.h"
>  #include "common.h"
>  
> @@ -225,7 +230,7 @@ static int os_daemon(int nochdir, int noclose)
>  
>  int os_daemonize(const char *pid_file)
>  {
> -#if defined(__uClinux__) || defined(__sun__)
> +#if defined(__uClinux__) || defined(__sun__) || defined(__rtems__)


I think that one should be upstreamed.


>   return -1;
>  #else /* defined(__uClinux__) || defined(__sun__) */
>  #ifdef __FreeBSD__
> @@ -282,6 +287,9 @@ int os_get_random(unsigned char *buf, size_t len)
>   if (TEST_FAIL())
>   return -1;
>  
> +#ifdef __rtems__
> + return getentropy(buf, len);
> +#else /* __rtems__ */
>   f = fopen("/dev/urandom", "rb");
>   if (f == NULL) {
>   printf("Could not open /dev/urandom.\n");
> @@ -292,6 +300,7 @@ int os_get_random(unsigned char *buf, size_t len)
>   fclose(f);
>  
>   return rc != len ? -1 : 0;
> +#endif /* __rtems__ */
>  }
>  
>  
> diff --git a/freebsd/contrib/wpa/wpa_supplicant/config.h 
> b/freebsd/contrib/wpa/wpa_supplicant/config.h
> index 627f38b..9de7e70 100644
> --- a/freebsd/contrib/wpa/wpa_supplicant/config.h
> +++ b/freebsd/contrib/wpa/wpa_supplicant/config.h
> @@ -45,6 +45,9 @@
>  #include "common/ieee802_11_defs.h"
>  #include "common/ieee802_11_common.h"
>  
> +#ifdef __rtems__
> +#include 
> +#endif /* __rtems__ */
>  
>  struct wpa_cred {
>   /**
> diff --git a/freebsd/contrib/wpa/wpa_supplicant/main.c 
> b/freebsd/contrib/wpa/wpa_supplicant/main.c
> index 0e86b93..40950d2 100644
> --- a/freebsd/contrib/wpa/wpa_supplicant/main.c
> +++ b/freeb

Re: [PATCH v2 2/4] Port wpa supplicant to RTEMS.

[Chris Johns]

On 14/10/17 6:14 am, Christian Mauderer wrote:
> To the RTEMS community: Should we already add that code? It's not
> thoroughly tested and still has some problems (like the assert) but it
> adds everything that is necessary for continuing that work. If we don't
> merge it, it might get out of date during the next update to a newer
> FreeBSD version.

I am fine with this being merged.

Sichen, thank you for the patch and these changes.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS milestones 4.13 and 5.0?

[Joel Sherrill]

On Oct 12, 2017 11:37 PM, "Sebastian Huber" <
sebastian.hu...@embedded-brains.de> wrote:

On 12/10/17 16:24, Chris Johns wrote:

> On 11/10/17 11:30 pm, Sebastian Huber wrote:
>
>> milestones 4.13 and 5.0 don't fit the new version scheme:
>>
>> https://devel.rtems.org/wiki/Developer/Release#RTEMSRelease5
>> SeriesAndHigherNumbering
>>
>>
>> I suggest to rename the 5.0 milestone to 5.1 and move all 4.13 tickets to
>> 5.1.
>>
>> A change to the major revision number requires a major change.
>

In the new version scheme the major number changes with every release.


The reality is
> 4.12 should be 5.0. The release and what it contains has grown
> considerable and
> we are currently attempting to converge on stability across all hosts and
> architectures before we branch. Looking at 4.12 now it appears to me to be
> a
> good 5.0 candidate so should this happen or is it too late?
>
> We have planned the move to 5.0 to be a build system change. The work to
> make
> this important and needed change is not small and I cannot do it without
> funding
> and I do not have any for this work. Moving to 5.0 after 4.12 without
> something
> major may result in a long wait while planned 5.0 changes are implemented.
> As a
> result we will have smaller things hanging on the development branch that
> should
> be released as we have with 4.12 now. We added 4.13 as a way to keep us
> keep
> moving with releases while we figure out now to make the build system
> change. I
> do not like having 4.13 but I do not see another path. Jumping to 5.0 is a
> solution.
>

Using 5.1 for the next release is probably less confusing for users since a
lot of stuff changed (current master would be 5.0.0, release is 5.1.0,
branch version after release is 5.1.1). Someone would have to do this
number change.



Historically we bumped the first digit on major architectural or feature
changes. IMO 4.11 should have been 5.0 due to addition of SMP. Now that it
is very optimized and we feel it is ready for production use, I think
bumping to 5.x is the right thing to do.



-- 
Sebastian Huber, embedd
ed brains
GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel