Thanks Marc.
I am not sure I understand but because I am a novice!
The command you suggested returns the MAC address in the HostOS terminal, I can see this OK. I am not sure how to make this persistent so that the ‘main’ process uses the MAC address when it starts the GW and connects to TTS?
I am guessing that the sed command can edit/insert but will this have pointed to the MAC address if I restart the services or reboot the device?
Thanks again
Garry
Hi Marc,
Unfortunately this still doesn’t work, restarting services or rebooting the device generates a random EUI each time with only the inserted ‘FFFE’ persistent each time. I can see from the console log that the ‘main’ service starts and immediately can not find the MAC address. Have a look at this from the log:
main cat: /sys/class/net/eth0/address: No such file or directory
main Gateway EUI:
main Using MODEL: SX1301
main Server: wss://eu1.cloud.thethings.network:8887
main Resetting gateway concentrator on GPIO 25
This will always be the case as there is no such folder as /sys/class/net/eth0/
To work in the Pi Zero2 W the path would need to be /sys/class/net/wlan0/address but I do not know if this is a cofiguration setting I can adjust of if this is baked into the ‘main’ code?
Is there some way to work around this as I can not even create this folder to put the characters in a ‘address’ file to try?
As I said before, I can paste the randomly generated EUI into my TTS gateway device settings and everything works but it is not persistent over a restart. Does this need a change and pull a new file?
Thanks in advance
Garry
Can anybody suggest how I can point my ‘main’ code to the folder path .../wlan0/address ?
I still can not restart my gateway or it picks a random MAC, generates a random EUI and loses connection to TTS server?
Thanks
Garry
@GryKyo i don’t have a Pi Zero2 W to test myself and the repo is still not compatible with Pi Zero W (armv6) (there is a PR that does not work for me).
Having said that, could you please try to edit this line (below) changing eth0 for wlan0? That might solve the issue! Let us know if that work?
That makes sense but if I could ask where I will find the start.sh? I am not accustomed to using a terminal within a container which appears what I am doing in my device’s dashboard?
I can see what the change will do but not sure where the file is that I must modify! I can see it in the Github repo but not sure do I need to change on the device or clone the repo, make changes etc…?
Many thanks, Garry
Hello @GryKyo
The steps to follow are:
start.sh filebalena login
balena push <name of your fleet on balena cloud>
that might deploy everything with the wlan0 mac address as EUI.
that might deploy everything with the
wlan0mac address asEUI.
This makes sense and as all of the other devices in the fleet are wired with PoE this will take down the whole fleet!
I can see how to work around this now, it may mean a fleet of Wireless devices, possibly a fleet of 1 device but that will work. If I open an console in the main environment I can see the start.sh script and understand how pushing a cloned and edited repo will work.
As an aside, is there a case to fork from the main Basic Station to customise for wireless connected gateways?
Thanks for your help
Garry
@GryKyo if you have a fleet of devices, maybe you may pin a release for the wlan0 gateways and another pinned release for the eth0 gateways. Not sure if that makes sense to you! Let me add some documentation here Release policy - Balena Documentation
Thanks a million Marc, I will read for sure and have a go at two pinned releases, looks like precisely what I need to do
G
Things were looking great until they weren’t! Changing the path to the address folder was just fine, it looked like it was pushing the code correctly but it throws some errors building the application on the server. I can’t enterpret any of the errors so maybe you can heve a look and see if you can recognise what is stopping the build?
thanks![Info] Building on arm04
[Info] Pulling previous images for caching purposes...
[Success] Successfully pulled cache images
[main] Step 1/11 : FROM balenalib/raspberrypi0-2w-64-debian:buster-build as builder
[main] ---> f5a8d195475b
[main] Step 2/11 : WORKDIR /usr/src/app
[main] Using cache
[main] ---> 05c14e54a056
[main] Step 3/11 : COPY . .
[main] Using cache
[main] ---> 08a906b132b5
[main] Step 4/11 : RUN make platform=rpi variant=std arch=aarch64
[main] ---> Running in 0400495d3693
[main] Here are a few details about this Docker image (For more information please visit https://www.balena.io/docs/reference/base-images/base-images/):
[main] Architecture: ARM v8
[main] OS: Debian Buster
[main] Variant: build variant
[main] Default variable(s): UDEV=off
[main] Extra features:
[main] - Easy way to install packages with `install_packages <package-name>` command
[main] - Run anywhere with cross-build feature (for ARM only)
[main] - Keep the container idling with `balena-idle` command
[main] - Show base image details with `balena-info` command
[main] mkdir -p build-local/bin
[main] gcc -std=gnu11 -Isrc -DCFG_prog_crc32 src/crc32.c -o build-local/bin/crc32
[main] mkdir -p build-local/bin
[main] gcc -std=gnu11 -Isrc -DCFG_prog_genkwcrcs src/genkwcrcs.c -o build-local/bin/genkwcrcs
[main] build-local/bin/genkwcrcs $(cat src/kwlist.txt | sed -e '/^#/d;s/[ \t]\+#.*//') > build-local/temp-kwcrc.h
[main] mv build-local/temp-kwcrc.h src/kwcrc.h
[main] platform=rpi variant=std make -C deps/mbedtls
[main] make[1]: Entering directory '/usr/src/app/deps/mbedtls'
[main] platform=rpi variant=std ./prep.sh
[main] /bin/sh: 1: ./prep.sh: Permission denied
[main]
[main] make[1]: *** [makefile:55: platform-rpi] Error 126
[main]
[main] make[1]: Leaving directory '/usr/src/app/deps/mbedtls'
[main] make: *** [makefile:67: deps/mbedtls] Error 2
[main]
[main] Removing intermediate container 0400495d3693
[main] The command '/bin/sh -c make platform=rpi variant=std arch=aarch64' returned a non-zero code: 2
[Info] Uploading images
[Success] Successfully uploaded images
[Error] Some services failed to build:
[Error] Service: main
[Error] Error: The command '/bin/sh -c make platform=rpi variant=std arch=aarch64' returned a non-zero code: 2
[Info] Built on arm04
[Error] Not deploying release.
Remote build failed
I figure if we can get this release onto the device I can pin to stop future changes from taking it down but would be stoked if you could see why it’s not building?
Thanks
Garry
That’s correct @GryKyo i had this issue pending to solve and today i made the PR! Test it and let me know if that works!
Hi again, sorry to be full of bad news but same result as before?
[main] Step 4/11 : RUN make platform=rpi variant=std arch=aarch64
[main] ---> Running in b1f4bd56c076
[main] Here are a few details about this Docker image (For more information please visit https://www.balena.io/docs/reference/base-images/base-images/):
[main] Architecture: ARM v8
[main] OS: Debian Buster
[main] Variant: build variant
[main] Default variable(s): UDEV=off
[main] Extra features:
[main] - Easy way to install packages with `install_packages <package-name>` command
[main] - Run anywhere with cross-build feature (for ARM only)
[main] - Keep the container idling with `balena-idle` command
[main] - Show base image details with `balena-info` command
[main] mkdir -p build-local/bin
[main] gcc -std=gnu11 -Isrc -DCFG_prog_crc32 src/crc32.c -o build-local/bin/crc32
[main] mkdir -p build-local/bin
[main] gcc -std=gnu11 -Isrc -DCFG_prog_genkwcrcs src/genkwcrcs.c -o build-local/bin/genkwcrcs
[main] build-local/bin/genkwcrcs $(cat src/kwlist.txt | sed -e '/^#/d;s/[ \t]\+#.*//') > build-local/temp-kwcrc.h
[main] mv build-local/temp-kwcrc.h src/kwcrc.h
[main] platform=rpi variant=std make -C deps/mbedtls
[main] make[1]: Entering directory '/usr/src/app/deps/mbedtls'
[main] platform=rpi variant=std ./prep.sh
[main] /bin/sh: 1: ./prep.sh: Permission denied
[main]
[main] make[1]: *** [makefile:55: platform-rpi] Error 126
[main]
[main] make[1]: Leaving directory '/usr/src/app/deps/mbedtls'
[main] make: *** [makefile:67: deps/mbedtls] Error 2
[main]
[main] Removing intermediate container b1f4bd56c076
[main] The command '/bin/sh -c make platform=rpi variant=std arch=aarch64' returned a non-zero code: 2
[Info] Uploading images
[Success] Successfully uploaded images
[Error] Some services failed to build:
[Error] Service: main
[Error] Error: The command '/bin/sh -c make platform=rpi variant=std arch=aarch64' returned a non-zero code: 2
[Info] Built on arm04
[Error] Not deploying release.
Remote build failed
Build still fails, no container to deploy? Am I doing something wrong?
All I do:
Change ‘eth0’ to ‘wlan0’, save the script ‘start.sh’
balena push
I am a novice so very likely it is me 
Garry
@GryKyo probably you need to do git pull and update the repository you have on your computer. As i made a PR and it changed. Could you please confirm if updating your repo, it builds?
Unfortunately no! I also cloned the repo to a different machine in work earlier, 14 hours after you merged the source and I got an indentical error in Powershell.
I just tried it now on my own PC, git pull, check the start.sh is correct for wlan0 interface and then balena push
I get the exact same errors, fails build at the same point. FYI I can see a message on the fleet dashboard that the new release is being built but just stops at the same errors in builder
Curious?
Thanks, G
@GryKyo i tried to reproduce and it’s building properly on my side!
share a screenshot of your fleet definition. Is this for Raspberry Pi 4? or Pi 3?
on the other hand you call balena push <the-name-of-your-fleet>?
i’m a bit lost, just let me know more details to try to reproduce myself!
And the latest…
Looks good but no cigar yet!
I tried pushing the repo from a raspberry pi at home with the modified start.sh and it builds! It may be something to do with CR/LF line-endings using the two different Windows10 machines I had tried before, both failed!
Unfortunately however, while runnng the modified start.sh code now generates the same EUI from the device MAC address, the device seems to try and connect each restart with a completely randomly generated EUI each reboot?
This first console outuput here is the very first few lines as the main service starts
main Gateway EUI: e45f01fffe3c42dc
main Using MODEL: SX1301
main Server: wss://eu1.cloud.thethings.network:8887
main Resetting gateway concentrator on GPIO 25
In this instance the EUI here is generated by the start.sh code.
If however I look further down the log I can see that the connection is refused by TTS as the gateway EUI submitted by this device is a completely random number and has no relation to the EUI above. Look at this from circa 30 lines below the last console output in the same reboot:
main key usage : Key Cert Sign, CRL Sign
main 2022-01-16 21:26:02.638 [AIO:INFO] tc has no cert configured - running server auth and client auth with token
main 2022-01-16 21:26:02.732 [TCE:INFO] Connecting to INFOS: wss://eu1.cloud.thethings.network:8887
main 2022-01-16 21:26:03.032 [TCE:ERRO] Infos error: ::0 Failed to fetch gateway: error:pkg/gatewayserver:gateway_eui_not_registered (gateway EUI `02426FFFFE0F12EA` is not registered)
I am not sure how this spurious number is being sent to TTS as the EUI? Is there somewhere else where this number can be generated?
If however I copy/paste the random EUI: 02426FFFFE0F12EA to the TTS gateway “general settings > EUI” it connects but I am back where I started with a gateway that can not re-connect after a restart?
Thanks
G
@GryKyo do you have the gateway with that EUI registered at the The Things Stack interface? could you please share? 
BTW what concentrator do you use? (sorry if i missed that)
thanks!
Marc