I've had mos running on a Raspberry Pi for a couple of years using the above, but I've just tried to install on a new build and I'm getting errors as below:
go version go1.13.4 linux/arm
GOOS= GOARCH= CC= CXX= \
/usr/local/go/bin/go build -mod=vendor -tags '' -ldflags '-s -w ''' -o mos github.com/mongoose-os/mos/cli
# pkg-config --cflags -- libftdi1
Package libftdi1 was not found in the pkg-config search path.
Perhaps you should add the directory containing `libftdi1.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libftdi1' found
pkg-config: exit status 1
Makefile:93: recipe for target 'build-mos' failed
make: *** [build-mos] Error 2Anyone got any suggestions what might be causing this?
I already have
libftdi1 installed via sudo apt-get install libftdi1
libftdi1 is already the newest version (0.20-4).
libftdi1 set to manually installed.
I'm not a debian user, in my distro there are binary packages and developer packages, the headers are in the developer package. Those developer packages usually update the pkg-config database.
When manually installing compiled code
When manually installing compiled code
ldconfigdoes the trick of providing the needed info. I read you manually installed it, try running ldconfig as root.
Another possibility is to search for the .pc file as suggested and if it is outside of the expected path, you can add its path to
PKG_CONFIG_PATH.
ie,
env | grep PKG_CONFIG_PATH to see what the paths are
then
which lifftdi1 to see where that is installed. compare and contrast the base directory of lifftdi1 to the PKG_CONFIG_PATH
if it's not in there, add it to the environment variable. export PKG_CONFIG_PATH="$PKG_CONFIG_PATH:[insert path to lifftdi1]"
can make it permanent by adding it to your bashrc etc
can you do me a favour and flick me your working dns-sd configuration / code and confirmation whether you see any log messages on bootup matching 'dns' and 'SRV' ?
geezus. ok please ignore me. dns-sd is seeing (and updating) with old and new firmwares. last night i rebooted the mac as for some reason it wasn't acquiring a dhcp IP on two of our network SSIDs. I think something network related was borked on the mac.
solution for next time: https://media.giphy.com/media/DUtVdGeIU8lmo/source.gif
literally wasted about 8 hours over 2 days trying to diagnose it.
go version go1.15.7 linux/arm
GOOS= GOARCH= CC= CXX= \
/usr/local/go/bin/go build -mod=vendor -tags '' -ldflags '-s -w ''' -o mos github.com/mongoose-os/mos/cli
# runtime
/usr/local/go/src/runtime/mgclarge.go:142:26: mheap_.treapalloc undefined (type mheap has no field or method treapalloc)
/usr/local/go/src/runtime/mgclarge.go:193:8: mheap_.treapalloc undefined (type mheap has no field or method treapalloc)
/usr/local/go/src/runtime/mgclarge.go:249:9: undefined: scavengeTreapNode
/usr/local/go/src/runtime/signal_unix.go:525:5: crashing redeclared in this block
previous declaration at /usr/local/go/src/runtime/signal_sighandler.go:15:5
/usr/local/go/src/runtime/signal_unix.go:530:5: testSigtrap redeclared in this block
previous declaration at /usr/local/go/src/runtime/signal_sighandler.go:20:5
/usr/local/go/src/runtime/signal_unix.go:544:6: sighandler redeclared in this block
previous declaration at /usr/local/go/src/runtime/signal_sighandler.go:33:69
/usr/local/go/src/runtime/unaligned2.go:12:6: readUnaligned32 redeclared in this block
previous declaration at /usr/local/go/src/runtime/alg.go:374:40
/usr/local/go/src/runtime/unaligned2.go:17:6: readUnaligned64 redeclared in this block
previous declaration at /usr/local/go/src/runtime/alg.go:382:40
Makefile:93: recipe for target 'build-mos' failed
make: *** [build-mos] Error 2
(I’ve also updated go to 1.15.7)
Not sue if that is related to teh fact that this GPIO runs in output mode ( GPIO.Read reads GPIO16 that i have setup as input fine - it reads 0 or 1 properly )
TY
Hi, I am working around an project with esp8266 and pi loaded ubuntu as host. I have flash the firmware to esp and connected to n/w. The logs shows it first try to connect with n/w and get failed with error code 3 or 202. After 2/3 second again try to connect with n/w and got connected. And shows the ip as well and also on network device, the esp shows up in connected device list. After that I ran mos call Sys.GetInfo it shows :
`{
.....parameter....,
"wifi": {
"sta_ip": "",
"ap_ip": "",
"status": "connecting",
"ssid": ""
}
}' while the network device still shows it as connected
Any idea what could be the issue ?
That is quite a claim, since it works for every one else except for you.
You describe two issues:
1- If your device fails to connect and then connects later, sniff your network and check your AP logs.
2- If you don't see your IP in Sys.Getinfo, that can be because perhaps your device reboots when mos connects via serial to issue the command.
If your device is connected to WiFi, has an IP address, and you compiled in a web server, you can get the info by connecting via HTTP or using Websockets (I know it is not very useful since you have to know the IP beforehand... but at least you will see that the RPC returns the correct information); just use the --port flag followed by the URL.
You describe two issues:
1- If your device fails to connect and then connects later, sniff your network and check your AP logs.
2- If you don't see your IP in Sys.Getinfo, that can be because perhaps your device reboots when mos connects via serial to issue the command.
If your device is connected to WiFi, has an IP address, and you compiled in a web server, you can get the info by connecting via HTTP or using Websockets (I know it is not very useful since you have to know the IP beforehand... but at least you will see that the RPC returns the correct information); just use the --port flag followed by the URL.
You can also connect through MQTT
@scaprile well I am on work's place n/w so can't access the logs. But I came up with an observation the above mentioned issue cames only when device (esp) is connected to pi, while I connected the same device to my windows laptop and call Sys.GetInfo it gives me correct values.
Hi guys! I am having some problems with rpc_acl, namely that the ch_type is ignored:
Here is my rpc_acl:
[
{"method": "", "ch_type": "WSS_out", "acl":""},
{"method": "FS.", "acl":""},
{"method": "", "acl": "-"}
]
This should allow any users request from WSS_out (mdash), but block any other rpc on all channels (except for FS.), right?
With this rpc_acl, I can call any RPC from any channel, so it is not working.
If i change the first line to {"method": "", "ch_type": "WSS_out", "acl":"admin,-*"}, i need the admin creds to call any rpc but even using the mos tool over UART.
Any advice? My goal is to allow all rpc from mdash, but block some, allow others with admin and leave some free for all.
Here is my rpc_acl:
[
{"method": "", "ch_type": "WSS_out", "acl":""},
{"method": "FS.", "acl":""},
{"method": "", "acl": "-"}
]
This should allow any users request from WSS_out (mdash), but block any other rpc on all channels (except for FS.), right?
With this rpc_acl, I can call any RPC from any channel, so it is not working.
If i change the first line to {"method": "", "ch_type": "WSS_out", "acl":"admin,-*"}, i need the admin creds to call any rpc but even using the mos tool over UART.
Any advice? My goal is to allow all rpc from mdash, but block some, allow others with admin and leave some free for all.
@rojer thanks.