@rozpruwacz Sounds good.
"When I forced the build to use gpio kernel driver all works without problem when running as non root". How have you done that?

If you show me the right command, I could work on a patch on the configuration file and ask for a pull request

Currently, I'm using this command for configuration

 ./configure --soc=BCM2835 --my-gateway=ethernet --my-port=5003 --my-rf24-encryption-enabled --my-rf24-channel={{ rf24_channel }}

@rozpruwacz Thanks, I will try

#ifdef LINUX_ARCH_RASPBERRYPI
#include "RPi.h"
#define pinMode(pin, direction) RPi.pinMode(pin, direction)
#define digitalWrite(pin, value) RPi.digitalWrite(pin, value)
#define digitalRead(pin) RPi.digitalRead(pin)
#define digitalPinToInterrupt(pin) RPi.digitalPinToInterrupt(pin)
#else
#include "GPIO.h"
#define pinMode(pin, direction) GPIO.pinMode(pin, direction)
#define digitalWrite(pin, value) GPIO.digitalWrite(pin, value)
#define digitalRead(pin) GPIO.digitalRead(pin)
#define digitalPinToInterrupt(pin) GPIO.digitalPinToInterrupt(pin)
#endif

By reading the code, it looks like this path is only for raspberry and, if it works, I see a proper fix such as: just remove the if and do what is in GPIO whatever the platform is.

However, I have doubts this block was added by mistake. I need to understand how automated tests would catch any side effects of this fix (regressions?). This specific code was written few years ago: therefore, maybe it was required before but is no more needed now.

Will do that:

• Test it on my setup (my raspberry gateway is connected with 10+ sensors (arduinos with nrf))
• If it works end to end, I will have to understand a little bit more how automated tests are launched on mysensors code base. If it seems OK, I will submit a PR.

Just for traces, this is the commit which seems to add this code block:
https://github.com/mysensors/MySensors/pull/734/commits/074f016a69fd5d67e033b6473b3e39535fd9e2d5

Ok. Good news and bad news.

Good news:

• Updating the library is no brainer, just copy/paste and rebuild. Signatures have not changed
• After the build mysensors just works as before in root
• With non root user, you don't get any segfault.

Bad news:

• You still get an error (SPI requires root privilege => which is better than a segfault). Actually, the library doesn't require root for GPIO but it's still required for SPI and I2C.
• I've read the code of the library and some other blog posts on this subject and currently, using SPI and I2C without root seems not to be an option. The library is initializing itself by defining memory pointers => for SPI and I2C, it's undefined and there's no clear approach to set them (root and non-root init is really different for GPIO)

I still believe updating the library is good idea: cleaner error message and get some other fixes.

I have opened a thread on the library google group to get more information on the reasons: https://groups.google.com/forum/#!topic/bcm2835/i3LvA2c38j4

Alexandre

@rozpruwacz Sorry, it's hard for me to work on this subject during week days.
I2C is in the code, I'm just trying to find a generic solution. Currently, my raspberry has only the nrf24, therefore, I'm probably not using I2C.

My configure options are:

./configure --soc=BCM2835 --my-gateway=ethernet --my-port=5003 --my-rf24-encryption-enabled --my-rf24-channel={{ rf24_channel }}

Note that since my network is only sending information (nothing is controlled), I'm not worried about not using signatures between nodes. I enabled it in the past but then, disabled it.

Ok. Good news and bad news.

Good news:

• Updating the library is no brainer, just copy/paste and rebuild. Signatures have not changed
• After the build mysensors just works as before in root
• With non root user, you don't get any segfault.

Bad news:

• You still get an error (SPI requires root privilege => which is better than a segfault). Actually, the library doesn't require root for GPIO but it's still required for SPI and I2C.
• I've read the code of the library and some other blog posts on this subject and currently, using SPI and I2C without root seems not to be an option. The library is initializing itself by defining memory pointers => for SPI and I2C, it's undefined and there's no clear approach to set them (root and non-root init is really different for GPIO)

I still believe updating the library is good idea: cleaner error message and get some other fixes.

I have opened a thread on the library google group to get more information on the reasons: https://groups.google.com/forum/#!topic/bcm2835/i3LvA2c38j4

Alexandre

Hi,

As a follow-up:

• I tried your patch but it doesn't compile on my raspberry
• Whatever, I believe that, if it's the right problem, we might have a better solution

Solutions:

• I've looked to the code and it happens that, by following the calls, the final call are made to /drivers/BCM/bcm2835.h/cpp
• This library is imported from here and is currently on v1.50 in MySensors codebase. Latest release is 1.57.
• 1.50 of this library introduced the right to run as non root.
• 1.51 is fixing a bug and its description is "1.51 2016-11-03 Added documentation about SPI clock divider and resulting SPI speeds on RPi3. Fixed a problem where seg fault could occur in bcm2835_delayMicroseconds() if not running as root. Patch from Pok."

This is the related thread on the patch: https://groups.google.com/forum/#!topic/bcm2835/5VqsHKISDfQ

My best plan is then just to update the library version included in mysensors to its latest release

Will keep this thread updated.

Just for traces, this is the commit which seems to add this code block:
https://github.com/mysensors/MySensors/pull/734/commits/074f016a69fd5d67e033b6473b3e39535fd9e2d5

@rozpruwacz Thanks, I will try

#ifdef LINUX_ARCH_RASPBERRYPI
#include "RPi.h"
#define pinMode(pin, direction) RPi.pinMode(pin, direction)
#define digitalWrite(pin, value) RPi.digitalWrite(pin, value)
#define digitalRead(pin) RPi.digitalRead(pin)
#define digitalPinToInterrupt(pin) RPi.digitalPinToInterrupt(pin)
#else
#include "GPIO.h"
#define pinMode(pin, direction) GPIO.pinMode(pin, direction)
#define digitalWrite(pin, value) GPIO.digitalWrite(pin, value)
#define digitalRead(pin) GPIO.digitalRead(pin)
#define digitalPinToInterrupt(pin) GPIO.digitalPinToInterrupt(pin)
#endif

By reading the code, it looks like this path is only for raspberry and, if it works, I see a proper fix such as: just remove the if and do what is in GPIO whatever the platform is.

However, I have doubts this block was added by mistake. I need to understand how automated tests would catch any side effects of this fix (regressions?). This specific code was written few years ago: therefore, maybe it was required before but is no more needed now.

Will do that:

• Test it on my setup (my raspberry gateway is connected with 10+ sensors (arduinos with nrf))
• If it works end to end, I will have to understand a little bit more how automated tests are launched on mysensors code base. If it seems OK, I will submit a PR.

@rozpruwacz Sounds good.
"When I forced the build to use gpio kernel driver all works without problem when running as non root". How have you done that?

If you show me the right command, I could work on a patch on the configuration file and ask for a pull request

Currently, I'm using this command for configuration

 ./configure --soc=BCM2835 --my-gateway=ethernet --my-port=5003 --my-rf24-encryption-enabled --my-rf24-channel={{ rf24_channel }}

Hi,

I'm not able to quickly understand the code base.

I guess the problem is with transport (call to _transportSM.currentState->Update())
Any idea of what kind of call might create the segfault when user is not root (since everything works fine with root on this system)

My setup is:

• Hardware: Raspberry pi 1B
• OS: Raspbian
• Mysensors: latest release (2.3.0)

User is already member of groups GPIO and SPI.

Any hint would be appreciated

Alexandre

I've added some traces.
Seems like seg fault happens on these lines of MyTransport.cpp

void transportUpdateSM(void)
{
        if (_transportSM.currentState) {
                _transportSM.currentState->Update();
        }
}

Ok, then let me try to help.

Right now, I have added a user named mysensors. He is member of its own group + GPIO + SPI:

mysensors@pi$ groups mysensors
mysensors : mysensors spi gpio

I'm running mysensors 2.3.0. If I run it with this user, I currently get:

mysensors@pi$ mysgw
Sep 23 14:58:56 INFO  Starting gateway...
Sep 23 14:58:56 INFO  Protocol version - 2.3.0
Sep 23 14:58:56 DEBUG MCO:BGN:INIT GW,CP=RNNGL--X,VER=2.3.0
Sep 23 14:58:56 DEBUG TSF:LRT:OK
Sep 23 14:58:56 DEBUG TSM:INIT
Sep 23 14:58:56 DEBUG TSF:WUR:MS=0
Segmentation fault

Everything works well with root:

root@pi:~# mysgw
Sep 23 15:01:34 INFO  Starting gateway...
Sep 23 15:01:34 INFO  Protocol version - 2.3.0
Sep 23 15:01:34 DEBUG MCO:BGN:INIT GW,CP=RNNGL--X,VER=2.3.0
Sep 23 15:01:34 DEBUG TSF:LRT:OK
Sep 23 15:01:34 DEBUG TSM:INIT
Sep 23 15:01:34 DEBUG TSF:WUR:MS=0
Sep 23 15:01:34 DEBUG TSM:INIT:TSP OK
Sep 23 15:01:34 DEBUG TSM:INIT:GW MODE
Sep 23 15:01:34 DEBUG TSM:READY:ID=0,PAR=0,DIS=0
Sep 23 15:01:34 DEBUG MCO:REG:NOT NEEDED
Sep 23 15:01:34 DEBUG Listening for connections on 0.0.0.0:5003
Sep 23 15:01:34 DEBUG MCO:BGN:STP
Sep 23 15:01:34 DEBUG MCO:BGN:INIT OK,TSP=1

Any idea of the possible missing rights that I need to avoid the segfault? Or to get better error message?

Will continue to look at it...

Hi,

Sorry for bringing back an old topic but it seems an important one nowadays. I've been running MySensors for 2 years now and I truly believe its community did an awesome work.

I have similar goal (defence in depth): running a daemon as root is kind of an issue. While I'm sure developers do their best to avoid a security issue, we never know. Even if it can sound a little bit paranoid, an attacker could try to inject packets that would execute a command on the gateway host.

I'm running the mysgw on raspbian (raspberry 1b). As Julien, I've created a new user.

First results:

• First error: Could not open /sys/class/gpio directory => just add the user to the gpio group
• Second error: You need root privilege to use SPI

It would be awesome to solve this concern. I've seen Julien didn't get any reply.
Does it mean the community doesn't see any advantages or just it mean you just need some help? I can contribute to documentation.

I guess it's a low concern for gateways on microcontrolers while it's a bigger one for microprocessors one.

Let me know if I can help

Alexandre