DISCLAIMER: Below I created a tutorial on ‘flashall’ method to get up and running with this firmware. I include 2 outside videos at the bottom for those who prefer GUI applications for upgrading firmware.
Modem recovery firmware available here, in case you mess up.
FLASHING MODEM FIRMWARE
Before following below, make sure to first install adb / android-tools. Required for ‘flashall’ script.
(see below screenshot to see above commands in action. Make sure to download the package.tar.gz into the ‘helpers’ directory, to allow ‘flashall’ to make use of it.)
After this, you will notice the modem going ‘down’. Then it will reappear / come back alive (reboots).
If you get an error, it can’t hurt to try ‘flashall’ again.
Just be sure you have android-tools / fastboot, and extract Biktor’s firmware into the same directory as tools/helpers (the location of the flashall script).
When all is successful, you should see a message from a dedicated number telling you about the success of your new modem firmware.
Notice problems with modem disappearing? Take a look at recommended settings here.
UPDATE: OUTSIDE VIDEO GUI RESOURCES BELOW
In this article I opted to share a quick commandline route.
For those who prefer a GUI tool (to upgrade the firmware), below I embedded 2 videos on this.
Scroll down to take this route.
RELATED: FIRMWARE UPDATER ON POSTMARKETOS
(Below offers 2 separate videos on the same tool – watch whichever you prefer.)
Who Should? For the few who love the idea of a Linux computer terminal in their pocket, more than they do a phone.
With a keyboard case, you can achieve over a full day of battery, carrying an additional 6,000 mAh charging battery. Placing your Pinephone into the keyboard case, allows it to attempt to charge via the pogo pins.
(there are some drawbacks to the keyboard case: you have to be careful not to attempt to charge the usb-c on the Pinephone, while it is plugged into the keyboard case)
Outside that, I would only recommend to the most hardcore of Linux nerds. Those who want to be part of the Linux mobile development process.
Too many Android users expect the same performance, apps, battery life… those people are surely to be disappointed.
On the Linux end, most apps you run on your desktop can run on the Pinephone.
On the other hand, without Pine64 creating an affordable Pinephone (original) project, we would not have near as large a Linux mobile community.
Purism also has played a big role in Linux mobile development, with Phosh (interface shown in video).
Should you get the Pinephone?
This is something only you can answer for yourself.
If you have no interest in development process, it’s probably not for you (at this point).
Pinephone has been my daily driver for 2 years now.
Today let’s talk a bit about what are commonly referred to universally as: “Stingrays” (popular model), and for Linux phone (Pinephone tested) users, sharing a small service for “4G Only” persistence (every boot): here).
Why? After noticing downgrades, wanted to see if it will affect my service over the long run (good coverage). Opted to try “4G only” for a while.
4G only restricts 2G / 3G and could cause service interruption during moments lacking 4G availability.
Includes tips for Android users. iPhone, not having as many options, does carry a “4G Only app“.
Cell Site Simulators (examples: “Stingrays”, “IMSI Catchers”): False Cell Towers appeal as “strongest signal in the area” for phones in nearby area (ex: 10,000 phones per device in some cases). Once connected, phone location can be tracked, and on lower security (ex: 2G), SMS / calls can be more easily captured)
SUMMARY:most Cell Site Simulators rely on downgrade attacks to cause your phone to connect to the less secure (encryption) 2G services (and other times 3G). We talk about how to mitigate for Linux phones (Pinephone service), Android, and iPhone (briefly).
INTRODUCTION
Video (older) introducing an Android tool for detection and mitigation of “cell site simulators”.
A basic introduction to what these devices are designed to do (mimic cell towers), and what various models may look like (including homemade), from the smallest (fitting in the palm of the hand), to the flying…
Downgrading phones to 2G service makes content easier to intercept (ie: calls and SMS txt, due to weak security in the 2G).
4G Cell Site devices run more expensive (comparing to 2G / 3G), generally offering location tracking.
Previously, price quotes (released a couple years back) marked “Hailstorm” devices for over $450,000.
Ultimately, for both criminal and official purposes, most rely on “downgrade” attacks.
Some may notice 4G blocked during certain areas of protest.
See: here, here, and here as examples where 4G was blocked during protest. Nearly all serious protests deal with this, (possibly) forcing connection to cell site simulators.
VULNERABILITY: SYMPTOMS OF ATTACK (Then Again… There Aren’t Always Signs)
Quicker than normal battery drain (push max battery usage)
High power usage forced on phones (amplification can allow farther operation distances)
Downgraded service to 2G, 3G (from stable 5G, 4G)
Service disruptions (problems sending SMS txt, calls, internet)We should ask ourselves: Why is there no tower provider authentication, to protect our phones from these devices? If providers desired so, it would be so.
Why Do Downgrade Attacks From 4G To 2G, 3G Happen?
Downgrade attacks occur to move phones to a more ‘receptive’ environment.
Since said false malicious cell spy towers utilize downgrade attacks to force all phones in the area to connect to their malicious cell site simulator…
We can attempt to mitigate downgrade attacks by forcing 4G only (keep in mind not all settings are saved after reboot – that is the idea of trying the 4g-only service for the Pinephone service: it forces 4G/LTE only, each reboot)
Set Your Preferred Network Type To LTE Only for 4G only (keep in mind this settings holds until reboot)
iPhone Users: 4G / LTE Only There is a reported 4G only app.
You can also access iPhone service options by following this page.
Pinephone / Linux Phone Users
Today I am writing today to intro a small example “4G Only” Service.
It’s something I wanted on my Pinephone (Linux phone) to prevent downgrade attacks.
Symptoms Of Malicious Intent
Phone jumps from its reliable 4G, down to 2G, or 3G
Phone has service disruption after this connection change
Internet may lose reliability, texts and calls may show issue / stalling
Apps like Android’s “Cell Spy Catcher”: take 24hr to map out all current cell towers (and locations), alerting you to towers which move or behave suspiciously, such as changing tower information, and location (ie: true cell towers are not moving around, changing location š¤)
RELATED STORY: In some areas, attacks could even be of foreign interests, even criminal networks.
Mitigation (For Most Cases / Devices): Force 4G Only.
Sure, settings in the Gnome / Phosh allow you to momentarily selecting 4G only, issue here is, it resets to allow 2g, 3g, 4g on the next boot. This service ensures 4G is the only available service to the modem (during service downgrade attempt).
Setting Up 4g-only Service
The service is simple to setup.
Simply download / clone package from Gitea onion (use torify git clone, or Tor Browser to view and download), and run the install.sh script (using sudo). This moves everything where it belongs, making a new command in our execution path, and enabling the service (by default starting 1st on your next reboot).
If you would like the service to start right away, you can run the command installed:
sudo 4g-only
Or (once running install.sh), you can start the service without reboot by issuing:
sudo systemctl start 4g-only.service
To avoid having to reboot.
What Does It Do?
First detects your current modem location (does change), setting “4G / LTE Only” for that modem, every reboot.
Running:
sudo 4g-only
forces 4g-only from the commandline.
If you need access to 3G as well, there is a single argument:
sudo 4g-only reset
Personally, I recommend 4G-only (not the reset) to prevent connection to these lower services linked to most malicious cell site simulators (note: during downgrade attack you may lose service – but at least you may know why..)
Checking Status Of 4g-only.service
Once installed (after a reboot), you can check the status of 4g-only.service.
sudo systemctl status 4g-only.service
Once you have run the install.sh, you will have 4g only every single boot 100% of the time.
If you need access to 4G + 3G (not recommended for most areas), I added the ability in the systemctl ‘stop’ command of the service.
And so:
sudo systemctl stop 4g-only
Won’t just allow 3G, it keeps 4G preferred.
But for myself, and most people, I do recommend leaving the service as is, allowing 4G Only (not including 3G), if you wish to mitigate downgrade maximally.
If you notice service disruptions on 4g Only, this could be a sign of downgrade attacks. That alone IMHO, can be useful to know.
Will share more options as tested in future (check back).
Hope you find useful. ā¤ļø š± š§
š Thanks for following this page and spreading the word!
Learning to check SSH fingerprints is a staple for using remote ssh safely. Failure to match fingerprints opens us to potential MiTM.
[ Did you miss ssh writeup Part I? We discuss how default Linux OS hostnames can sometimes give away default password, pitfalls in numerical passwords (changing default passwords should be priority #1).
First we identified the OS by default hostname, then we used a “most common numerical pin number wordlist” to crack the default SSH password in seconds, demonstrating how successful ssh cracking (using Hydra) looks, and offering solutions/advice HERE) ]
INTRODUCTION
Do you accept “new” ssh client key fingerprint prompts without checking them against the server in question’s own key fingerprint?
If you accept ssh key fingerprints (without verification), you may be setting yourself up to be an unwitting victim of a MITM (Man In The Middle Attack).
[This topic is covered in PART II (scroll down for Tutorial]
Additionally in PART II, we swap out weak default password authentication, to a much stronger (passwordless) RSA key authentication login assisted by ssh-keygen (we use to generate strong keys).
After which, we disable the password login option altogether (to prevent brute force attackers), and finally, we restart SSH for all changes to take effect.
As a Bonus, a video covers converting SSH server to a Tor Hidden .onion service, adding additional security/encryption benefits (without need for open ports).
(REFRESHER) PART I:
Part I video is below, covering weak default password examples in real Pinephone operating systems (applying to all Linux / UNIX machines / default logins).
In this scenario, we first scan machines on the LAN (as an attacker would), immediately identifying operating systems by their default hostname. After which we use Hydra (brute force cracker) to run known default username/pin number lists against the SSH server identified OS of our Pinephone.
After demonstrating how easy it can be to identify and crack SSH logins on machines sharing the same connection/LAN, we then go in to tighten up sshd_config settings to prevent future brute force attacks. As well as talk password security.
Today’s Video continues on from this SSHD Config angle.
As the introductory paragraph details, first we check key fingerprints shown by our ssh client against the server side’s ssh key fingerprint. We must ensure these fingerprints match, otherwise we risk MITM attack. Never accept new fingerprints without verifying.
ADD SSH KEY AUTHENTICATION (NO PASSWORD NEEDED)
(ssh more securely)
Have you ever accepted a fingerprint and wished to start over to be sure? (to: delete all saved keys for host / server and reconfirm fingerprint?)
REMOVE PREVIOUS KEY FINGERPRINTS (CLIENTSIDE):
ssh-keygen -R HostHere
CHECKING FINGERPRINT (SERVERSIDE):
ssh-keygen -lf /etc/ssh/ssh_host_ecdsa_key.pub
NOTE: THE ABOVE COMMAND IS ECDSA. LATEST AND GREATEST ADVICE IS FOR ED25519. CHECK THIS:
ssh-keygen -lf /etc/ssh/ssh_host_25519_key.pub
NEXT:
Connect (from clientside) to our SSH server to check the fingerprint output. Does it match the above “CHECKING FINGER (SERVERSIDE)” output?
See the screenshot below to watch this comparison in action.
SCREENSHOT CHECKING FINGERPRINT (COMMANDS ABOVE):
IMPORTANT: I felt the need to explain 01:56 — do not accept the key (unless you previously recognize it). This key fingerprint acceptance is to demonstrate the plain ‘password: ‘ prompt itself (fingerprint acceptance required to show). Follow below for fingerprint checking instruction (or follow video after 3min).
TIP #1 FINGERPRINT CHECKING: Check the server’s fingerprint from a separate network (if working remotely from it), or if you have physical access + a monitor, even better. By using a separate network to check the fingerprint upon connection, you are compartmentalizing both client checks from one another, further verifying fingerprints match from multiple networks.
Running the fingerprint checking locally (serverside) is always the best method (when possible).
TIP #2 FINGERPRINT CHECKING:
write hosts/fingerprints down , post them on your wall/corkboard/office: no risk in having a written list of your machines hostname/ip + correct ssh fingerprints. This can save you from having to check.
Why? You may one day need to login from a new machine without physical access to the server. Having record can help you check without risking the login/accepting fingerprints remotely.
After working on fingerprint checks, we add the key to our server, allowing our client machine to automatically login upon connection.
GENERATE RSA KEY PAIR
ssh-keygen -t rsa -b 4096
PASSWORD-FREE KEY AUTH: MORE SECURE SSH ACCESS
COPY KEY TO SERVER:
ssh-copy-id username@host
SEE SCREENSHOT BELOW FOR ABOVE STEPS IN ACTION
After successfully copying our key, we then connect by ssh to test it, if it lets us in without problem or password, we did it!
TESTING PASSWORD FREE KEY AUTHENTICATION
TIGHTEN UP SSHD_CONFIG (SERVERSIDE)
We add a few more lines to /etc/ssh/sshd_config, ensuring only our machine can login: (disabling password guessing by relying on our newly minted key alone)
/etc/ssh/sshd_config:
PasswordAuthentication no ChallengeResponseAuthentication no UsePAM no
Restarting SSH allows our configuration changes to take effect:
sudo systemctl restart ssh
[Timestamps are found inside the video description]
* BONUS: PART III: Tor SSH .Onion (Hidden Service):
This 3rd (optional) video shows how to setup SSH access as a Tor Hidden Service.
BENEFIT #1: By disabling ssh locally and allowing only the Tor ssh we prevent unknown machines from attempting brute force attacks (if we failed to follow previous videos). The only ssh attempts will be from those you give the onion address to.
BENEFIT #2: Additional layer of end to end encryption between the tor clients on ssh client and server side. Add to this the ssh encryption keys/fingerprints themselves on your client/software side, and you have a much more secure ssh setup.
Comments/Questions Welcome below:
Like content/videos like this? Share it with Linux users (Reddit, Telegram, Discord, IRC).
ā¤ļø If you appreciate content like this and want to ā Buy Me a Coffee hit ‘support’ button on: Home Page
Thoughts, comments and any questions welcome below.
Share this post with everyone. Leave your thoughts below.
(Share to help this grow. ā¤ļø ———————————————————————- PUBLIC COMMUNITY SERVERS: š§ š ANONYMOUS GITEA (.onion):Books, Code/Scripts, Wiki, more (make a repository) š§ š PASTEBIN (.onion): anon pastebin pw protect, zk-256bit, “Burn After Reading” + more ———————————————————————- š š¤ SUPPORT (If you like) š EXTRAS: something unique for your Support here ———————————————————————- FOLLOW: āš MASTODON š¦ TWITTER šŗ š PEERTUBE šŗ š BITCHUTE šŗ š ODYSEE šŗ š YOUTUBE ——————————————————————— ā CONTACT ————————————————————————
Next edit /etc/phosh/phoc.ini using either nano command or vim (nano shown to help all user levels):
In the above screenshot, we see our phoc.ini config file.
We can see where the white colored cursor is. The 1.25 on that line can be changed to meet your needs. Try 1, 1.25, 1.5, 1.75, 2. All will create a different variation of your interface scaling.
Find a setting that meets your needs.
Today was just a quick tip for permanently changing scaling (held for reboot).
Thank you for visiting! If you would like to help with coffee/sdcards/hardware costs for the channel/blog (ex: video rendering killed hard drive Jun 2022), Iād love that. Either way, I sincerely appreciate Likes, Shares and Comments! Thank you. š
Today, I can feel comfortable recommending Pinetime as a Smartwatch option to those who care about Privacy.
The above sentence may sound a bit odd to read at first. I’m about to explain why I hadn’t been able to explicitly recommended it for privacy (in the past).
To those who missed my previous Pinetimefirst impressions video, I received the open source smartwatch from a family member as a gift.
Mainly, I wanted it to help me track my heartrate goals, and steps during workouts.
Smart devices with data we can ‘own’! It had been at least 10 years since I carried a watch (with smartphones and everything providing time)! And I’m not exactly trusting of most “Smart” devices, especially considering some revelations coming out concerning smartwatch data sharing.
In January (when the first video was made), I knew bluetooth was on (all the time – at that time). This wasn’t such a big deal to me personally, I wanted to use it during workouts mainly… but deep down I always desire a way to turn bluetooth off!
PREVIOUS “FIRST IMPRESSIONS” VIDEO CAN BE SEEN HERE.
UPDATE
When I started recording this latest video, I was unaware of one thing: the newest firmware I was installing during video recording (1.9.0) offered the ability to disable Bluetooth.
Great News (To Me Anyways)
Of course you need to turn bluetooth back on anytime you wish to pair with a phone / update firmware, but to me, that’s no big deal. It’s not something you need outside those moments.
Everything else I’m using on the phone (heartrate monitor, pong game, step tracker), is self contained in the watch, not requiring bluetooth connection for my purposes.
Turning Off Bluetooth
Swipe screen right
Enter “Gear” Icon Settings
Scroll Down To Bluetooth:
Next Tap “Bluetooth” (Seen Above)
Bringing You To Enable / Disable Bluetooth:
That’s it. It’s now disabled. Make sure to go into these settings to enable it anytime you need to pair or upgrade firmware.
But… Is It Really Disabled? š¤
Quick Test
Scapy Python Script: Pinetime Setting: Bluetooth On:
And Now, Pinetime Bluetooth Off: (the grey boxes showing other bluetooth devices, Infinitime not showing up)
No Infinitime Devices seen during sniffing session with Bluetooth Disabled. Off to a good start. š
(Greyed out boxes to prevent displaying any local bluetooth identifiers [unrelated to Pinetime but local to me])
Now feel a bit more comfortable wearing it everywhere. And finally can say: it’s more privacy friendly!
Of course if you are paired, bluetooth will be on during that. Don’t forget to re-enable / disable, as needed.
Thanks for reading / watching.
Feel free to leave a comment / question.
Thank you for visiting! If you would like to help with coffee/sdcards/hardware costs for the channel/blog (ex: video rendering killed hard drive Jun 2022), Iād love that. Either way, I sincerely appreciate Likes, Shares and Comments! Thank you. š
Debian is one of the longest running GNU/Linux distributions around. Known for trust and reliability, it makes a great choice. Foundation to many Linux distributions (Tails, Whonix, Mint, Ubuntu, Devuan, Parrot, Pop!_OS, Kali and more).
Armbian is one of the original Linux single board computer operating systems out there.
PineDio is the latest hardware project coming out of Pine64. Pine64 was crowdsourced a few years ago and designs and introduces hardware for the open source/Linux community. Most famous of which is the Pinephone. A real Linux phone. š
This Gateway is powered by the Pine64 A64 LTS single board computer stacking up 2gb of ram (plenty of power for its purpose), wearing a RAKwireless RAK2287 concentrator (LoRa radio) + GPS ‘hat’.
Did You Know? The board itself made the basis fro the original Pinephone and has ample power for a LoRa gateway along with many small selfhosting server related projects/sensors.
Using Semtech LoRa chirpspread (radio), it’s able to send small packets (wireless) long distances (several km), comparative to its low power usage. This is typical for IoT sensor communication, but to expand the usability, take a look at interesting communication projects like meshtastic for an example of what can be done with LoRa.
Concentrator?
The concentrator hat on our single board computer (gateway) swings a more powerful radio than standard LoRa transceivers you might find on the latest microcontroller (ie: esp32). Able to run multiple channels, and overall capable of managing several devices running their own applications/sensors.
What To Do With It?
(use your imagination!)
Idea #1 TheThingsNetwork (join a few of us running gateways on TTN (TheThingsNetwork)
Idea #2: take a curious look at Helium, mine RF packets to help build coverage and maybe even earn money doing so if you live in an area where your miner would be in demand.
On helium: unfortunately, my area is completely bare of IoT.
Idea #3 Chirpstack: create your very own private LoRaWAN network (Chirpstack comes ready to login on this image). The Debian/Armbian image allows you to switch back and forth between TTN (TheThingsNetwork) and Chirpstack LoRaWAN network server.
Idea #4 Something entirely new, seek out projects you might like to contribute to/fork. (explore git repositories for ideas). Maybe you can fork something out there.
(Added Note: You need to add your gateway name/applications to meet your needs, but Chirpstack’s intuitive administration page makes this process easier, with visual graphs/log)
Commands Added Recently
chirpstack-onion Command (Add Encryption Easily)
You have the option of setting up https/TLS traditional route, as described in Chirpstack documentation…
Or you could try an automated web encryption adding command: chirpstack-onion, to take advantage of the Tor Network’s hidden service security benefits (proxies connection + encryption).
Using chirpstack-onion
Once Chirpstack is enabled inside the gateway-config command (inside the gateway-config menu, select ‘Other Channel’ instead of TTN), you can then run the optional chirpstack-onion command.
Next, running ‘sudo chirpstack-onion’ automatically creates/generates you a brand new Tor Hidden (.onion) end to end encryption domain for accessing your Chirpstack administration (using Tor Browser). This page can be accessed from any machine, anywhere. Instead of isolated to your LAN.
Only those you share the long onion address with will even know the Chirpstack page exists.
And if you are especially security conscious, you could enable further key authentication (really isn’t necessary for a chirpstack server!)
Nothing else required (outside enabling chirpstack and running the command).
No open port forwarding needed for access with chirpstack-onion (Tor) only need to be able to connect out to provide you the Tor Hidden onion service browser access (NAT punch).
Example Run: (.onion key/address removed from the screenshot)
New onion address prints right on the screen automatically.
Paste that .onion address in Tor Browser from any machine in the world (connected to the internet) and you will meet the Chirpstack login page.
The default login: admin. Password: admin.
Once you login your are greeted with the Chirpstack management page seen below:
gen-eui
If you want to change your EUI, gen-eui will generate a new random EUI and list a file for your (optional) editing.
Screenshot:
Fully Functional Debian Image: Chirpstack Or TTN
Functional Armbian (Debian) image for PineDio Gateway with LoRa mesh concentrator/GPS hardware configured and enabled.
Starting Concentrator Radio (LoRa) + GPS Log:
It’s stable, lightweight, and offers the built in options to switch between TheThingsNetwork and Chirpstack.
Example Excerpt Gateway Receiving RF Packets:
I’ve played around with Chirpstack as well, and it’s a great interface for setting up private LoRaWAN.
To jump ahead the working PineDio gateway image + checksums + credentials is available for everyone to download at:
(note: this post is being refined, could update/change later on)
(updated: Added links and making more clear step by step examples for the optional mac change flags – editing the file alone may be enough (see down below for instructions))
Changing LoRa Gateway EUI
FIRST: What Is An EUI?
“Extended Unique Identifier (EUI-64)“
Each Gateway on a given network must carry/be assigned a universally unique EUI.
The EUI is used both in registration and relaying data to the LoRa/Mesh network.
There may come a time on a network where you come across an EUI conflict.
Possible Scenarios:
Maybe you forgot to delete a gateway and are trying to re-register same EUI.
Maybe you bought a gateway where a previous owner did not remove the old EUI/Gateway from TTN or other network in question
Maybe this hardware model shares mac/EUI with another (ex: as manufactured, or another user happened to (by chance) spoof your EUI)
The above shows the EUI is being used already on TTN (TheThingsNetwork).
This is okay!
We can change Gateway EUI.
(SKIP TO SOLUTION SECTION TO SEE ANSWER)
The EUI is derived from the MAC address (see image below) of the network card inside our gateway.
Depending on your model, this could be ethernet, or WiFi mac address (used to create the EUI).
Some manufactures may share duplicate MAC addresses across the same hardware model – but generally the mac address is an extremely unique “serial number” of sorts. Identifying individual devices.
The OUI itself uniquely identifying the manufacturer of a piece of hardware.
Wait.. What Is An OUI?
OUI: Organizationally Unique Identifier. Each manufacturer has a unique OUI, acting as the preface to the remaining MAC address.
Each brand will carry a unique set of OUI address identifiers. This can make it easy to tell what device you are seeing on a network (ie: Apple, Samsung, Dell, etc)
The OUI makes up the first 3 octets (“sections”) as shown below:
On the PineDio (and other Gateways), you can view the current EUI by running:
gateway-version
Example Screenshot:
Should We Spoof MAC Address? Is This An EUI Duplicate Solution? (spoiler: spoofing mac may be optionalhere! Only tested with both changed.)
You might assume because the EUI is known to be derived from the network card’s MAC address, that spoofing this mac address directly would logically be enough to change to a new, unused EUI.
In actuality, within our setup, the EUI on our gateway comes directly from within a locally stored gateway configuration file (which can be edited directly).
This file pulls EUI generation from mac during LoRa software install.
In fact, at first I tried changing mac alone for testing. This did not change the EUI in itself.
We need to find where the EUI comes from… (continued)…
In tracing the gateway-version command/script:
We find the configuration file containing the current EUI resides at:
The inside of this file looks something like this (first and last 3 octets blurred out for privacy):
SOLUTIONS: DUPLICATE EUI ON SAME NETWORK
Change the value inside /opt/ttn-gateway/packetforwarder/lorapktfwd/localconf.json using a commandline editor such as nano, or vi.
As shown in the above blurred image, you can add FFFE in between the last, and first 3 octets (OUI) of the mac address, to create a new EUI. I preferred to statically spoof my mac address to easily relate between my EUI and ethernet mac address (changing both should be optional – but have only tested adding gateways with both changed:covered in next section).
Next: after editing file, restart your gateway’s ttn-gateway service:
sudo systemctl restart ttn-gateway
Then your gateway should be using the edited localconf.son identifier.
At this point you should be able to join the network again with the new EUI!
UPDATE: OPTIONAL ‘gen-eui’ COMMAND
You can run gen-eui to generate a new EUI for adding to the local_conf.json file. Created a small command for generating a new usable EUI for each run.
Screenshot example run:
OKAY. Even if optional, can we spoof the ethernet mac address to keep it matching the EUI anyway?
Sure. Some might like to create a new unique MAC address for whatever reason (including device/gateway local network privacy).
MAC Address Boot Option
Original plan was to use ethaddr= to change the mac: but needed to test something I was working on.
You are free to try this.
Try adding ethaddr=MACaddresshere in:
/boot/uEnv.txt:
Changing PineDio Ethernet MAC Address Command
PineDio gateway ethernet DOES support changing of mac address using commands:
SIMPLE COMMAND SOLUTION FOR MAC (TEMP/FOR TESTING)
ip link set dev eth0 down ip link set dev eth0 address NEWmacADDRESShere ip link set dev eth0 up
OR
Automated, Easy To Implement Option:
I chose to use wipri to hold a single eth0 mac address in wipri.service systemd service. You can try changing in boot/kernel otherwise.
ANOTHER OPTION FOR WIFI/ETHERNET
(decided to test script I was working on for various devices)
Changing the mac address should be largely optional for fixing the duplicate EUI (according to my own research into the matter: the config file is what mainly matters).
I was able to join TTN (successfully) after testing rejoining after editing the file mentioned earlier and changing the mac after installing new mac address service (optional) wipri.service. I have not tested editing the config file alone. This is why I decided to share wipri in this writeup- it’s just what I personally chose to rely on in my test.
If installed to run at boot, wipri/wipri-list keeps an eye to maintain the chosen mac address when installed as systemd service:
EARLIER: BEFORE (TTN EUI TEST)
I was testing duplicated mac address on TheThingsNetwork. I received the following message when I was sharing a mac address/EUI with another existing gateway:
I chose to correlate my EUI with my ethernet MAC address, to make it easier to remember, back and forth.
In this way I can always refer back between the current mac address my related EUI anytime.
UPDATE: AFTER (TTN EUI TESTS) [ * SUCCESS * ]
Restarting Concentrator/GPS Log:
After changing mac address and the local config file I was able to join successfully even where permanent mac addresses were shared:
JOIN GATEWAY SUCCESS SCREENSHOT (COMPARE TO PREVIOUS):
š Help grow this by sharing the URL to help grow the community.
ā„ļø Thank you for visiting! If you like what I do and want to help me with cost of ā coffee / sdcards / (frequent) hardware costs for bringing original content / Tutorials to this channel/blog (ex: video rendering killed hard drive Jun 2022), Iād really love that. Either way, I sincerely appreciate Likes, Shares and Comments!
Thank you. š
āļø Thanks for being a follower (it’s FREE!). Followers get only the most important posts by email.
Thoughts, comments and any questions welcome below.
š Thank you for Sharing this (Telegram/Social media)
———————————————————————- š§ š GITEA SERVICE (.onion):Books, Code/Scripts, Wiki, more (make a repository) š§ š PASTEBIN (.onion): options- password protect, zk-256bit, “Burn After Reading” + more ———————————————————————- š š¤ SUPPORT OPTIONS (If you like to) āšš Politictech Membership (monthly supporter option) š³ Politictech Main Page: (info + current links/addresses) ———————————————————————- FOLLOW: āšMASTODON š¦ TWITTER šŗ š PEERTUBE šŗ š BITCHUTE šŗ š ODYSEE šŗ š YOUTUBE ——————————————————————— ā CONTACT ————————————————————————- THANK YOU for Sharing this, Liking, and Subscribing. ————————————————————————- If you aren’t registered for Odysee I’d love to see you over there. Use my invite link: https://odysee.com/$invite/@RTP ————————————————————————–
HowTo: Privacy & Infosec 