ASL-Fallback-AP

Has there been a very recent change in ASL-Fallback-AP functions?

I have nodes that are WIFI connected that when the normal connected Wi-Fi AP goes down that the nodes go into asl-fallback-ap mode - and stick there until rebooted.

Thank you.

73, N0GIK

There's a wifi fallback in ASL, like Pi-Star/WPSD..? News to me...

There is a beta version that has a new fallback AP function. It hasn't been widely publicized. Can you you explain more completely what you're experiencing? What do you mean by "AP goes down"?

Ah... a beta. Now that I've looked at that under Cockpit/WiFi, it is likely the issue.

On my network, the AP gets power cycled once weekly. (been doing this for a couple years) It's simply a timer that turns power off for 1 minute to clear the routing table, solving issues that could likely be remedied by simply replacing the AP. (which I will be looking at doing, finally, ~ 8 years old)

I appreciate the response!! Thank you.

73 Matt - N0GIK

No the WI-Fi fall back as you cal lit is function of Rasperian (The Raspberry Pi operatring system) and most other Wi-Fi enabled. and once it connects to a router it sticks with it till it goes away.
It has no reason to keep searching unless it gets a REBOOT command.

Some of my Pi's do that (Reboot) under Crontab.. Some do not. But unless either the system reboots (In which case it re-does the search for connection) or I "Kill" (Turn off) the alt-wi-fi, it remains with the one that's working.

This applies to every wi-fi enabled device I have, Pi's Windows, Chrome books, androids, "Devices" (If they can support a list) Everything.

ASL runs on a computer The Wi-Fi support is on the host (Computer OS) side and does include the ability to multi-connect, same as your phone can connect to multiple wi-fi or your computer.

How to set it up varies.

I have four asl3/pi on wifi and a 5th (clearnode/asl3 for a radio club/repeater link) that is cabled.

The four pi were configured for wifi only connections. No cabled ethernet. Their wifi settings were from the RPI-IMAGER settings and show in the list as 'preconfigured'. They HAD only looked/connected to what was flashed to the micro-sd - my AP. Now, even though the AP functions after a reboot, reconnecting all the devices on the network - just the four pi that were preconfigured identically - hang at becoming a fallback-ap.

All four of those - were showing they were in AP-Fallback as a scan of the wifi networks at my home, showed FOUR unique 'AllStarLink_macaddress'. This morning, there is a single fallback AP showing, so something certainly not functioning as intended.

Under Cockpit wifi settings are the following order.

preconfigured MY_AP_5GHz
asl-fallback-ap Always last AllStarLink_D83ADD740BA6

Whatever is at issue, I'd like to see about its correction is or how to undo the auto-fallback function. I don't believe, or recall, entering the beta channel. Two of these pi are meant to be installed at repeater sites in the near future, so won't be of consequence as will be hard-wired.

In the end, I hope anything discovered during this is helpful to the AllStarLink system - so a BIG Thank You to the engineers and support staff!

Respectfully, Matt N0GIK

Actually, in this case, it is not. This is a custom-built fallback AP that integrates properly with NetworkManager and will work across a variety of devices not just Raspberry Pis.

You can check your currently selected ASL package channel with the sudo asl-repo-switch command. For the production/main packages you should see :

rpi:~ $ sudo asl-repo-switch 
trixie: main  

If you had used asl-repo-switch to include the beta packages you would see :

rpi:~ $ sudo asl-repo-switch 
trixie: main beta

That seems odd and unexpected. The asl-fallback-ap connection has the lowest priority of -999 so literally anything else should connect first. Please give me the output of nmcli -t -f NAME,AUTOCONNECT-PRIORITY connection show. It should look something like:

$ nmcli -t -f NAME,AUTOCONNECT-PRIORITY connection show
MF-Devices:1
lo:0
TestABDC:2
Wired connection 1:-999
asl-fallback-ap:-999

Most notably, I'd be interested to see what the priority of "preconfigured" is coming out to be in your case. It SHOULD be 0 as long as you didn't change anything else.

You can delete it with the following commands:

systemctl stop fallback-ap.timer
systemctl disable fallback-ap.timer
nmcli connection delete asl-fallback-ap

However be aware that it will become re-enabled with further package updates from the appliance.

At some point you must have changed the package stream to beta. The following should fix you:

asl-repo-switch -l main
apt update 
apt install --reinstall asl3-appliance

n0gik@node661962:~ $ sudo asl-repo-switch
trixie: main beta devel

Absolutely did not make this change - unless there was another script that was ran to make the change adding beta and devel channels. Certainly all four of these are acting the same way. Two of the units have Allscan installed - only. Other two (destined for repeater service) are plain vanilla thus far.

Will work to get this back to just the main channel.

Today, all four were unreachable with their AP-Fallback SSID advertising on WiFi.

Thanks for the pointers to restore.

Matt

Someone replied to your post.

| WA3WCO ASL Community Admin
August 29 |

  • | - |

N0GIK:

I don't believe, or recall, entering the beta channel.

You can check your currently selected ASL package channel with the sudo asl-repo-switch command. For the production/main packages you should see :

rpi:~ $ sudo asl-repo-switch 
trixie: main  

If you had used asl-repo-switch to include the beta packages you would see :

rpi:~ $ sudo asl-repo-switch 
trixie: main beta

···

On Saturday, August 29, 2026 at 11:06:39 AM CDT, Allan N noreply@community.allstarlink.org wrote:


Visit Topic or reply to this email to respond.

To unsubscribe from these emails, click here.

This tells me that, at some point in time, you selected the "devel" package stream.

To select the production/main package stream, use :

sudo asl-repo-switch -l main
sudo apt update

Note: switching back to the "main" stream will NOT revert the packages back to the earlier pre-devel/pre-beta versions.

Not knowingly. I understand my personal limitations in this regard and would NOT have done so. Especially on all four nodes, with two being geared-up to be deployed soon at remote sites.

I have set the repo to main only - stopped, disabled and removed the fallback.timer from all four nodes.

I appreciate all of the assistance.

73 - Matt - N0GIK

Someone replied to your post.

| WA3WCO ASL Community Admin
August 30 |

  • | - |

N0GIK:

n0gik@node661962:~ $ sudo asl-repo-switch
trixie: main beta devel

This tells me that, at some point in time, you selected the "devel" package stream.

N0GIK:

Will work to get this back to just the main channel.

To select the production/main package stream, use :

sudo asl-repo-switch -l main
sudo apt update

Note: switching back to the "main" stream will NOT revert the packages back to the earlier pre-devel/pre-beta versions.

···

On Sunday, August 30, 2026 at 12:20:28 PM CDT, Allan N noreply@community.allstarlink.org wrote:


Visit Topic or reply to this email to respond.

To unsubscribe from these emails, click here.

A new version asl3-appliance-pi 2.2.1-1.deb13 has been released to the beta stream. This makes the fallback AP optional. If you want this feature to be enabled, you must manually enable it with systemctl enable fallback-ap.timer.

Just for giggles I ran the command "sudo asl-repo-switch" and got = trixie: main beta

Seems I am indeed on the beta. I did not ask for this and not sure how it happened. (guessing it happened about the time my MOTD got overwritten during last "normal" update(?) I'm not complaining, I just thought I should have been notified in some way of the latest update being pushed to me as a "beta" (extra banner when SSH opens?). Especially if there's problems that need to be reported.

Example: About an hour ago, 4AM, my node seemingly "froze" (I just happened to be awake to witness it)

I have a script that auto runs via Cocpit>Services>Timers to auto connect to various nodes running nets throughout the week (and spawns an "auto disconnect and remove" script). The first one of the day is labeled "Link: The Morning Brew Crew – 4am" (Path

/etc/systemd/system/asl-connect-45225-4am.timer)

When the script runs, prior to connecting to the remote node it plays a local audio file. In this case it was a rooster crowing and an announcement of the net that it is currently connecting to. (This has been running for about two or three months.) The script fired off as expected and the "cockadoodle doo" starts. But in the middle it pauses for like 15 or 20 seconds, tries to continue, then everything disconnects. I look over to my HT like a dog hearing a whistle. I grabbed the laptop tried to log into the shell, nothing. cockpit, won't open.
The node Is located in the camper in the driveway, connects to the house Wi-fi which is Starlink. I hop up and out to the camper to reboot the node. The red activity light on my shari pi was still running as if nothing was wrong. I pulled the power and restarted and everything's back to normal.

I did not check to see if there was any new Wi-fi access points listed. However, I ran a System Diagnostics (w/i Cockpit) I can supply this file ( was downloaded ) if it is requested.

Note, this node is already set up with extra journaling persistent logging for troubleshooting - if needed

73 TIm

Thanks Tim. I feel less like a dork now. I have added the asl-repo-switch to a set of maintenance items, with some logging added to easily spot a change in repository.

Someone replied to your post.

| KD6HOF
September 3 |

  • | - |

WA3WCO:

sudo asl-repo-switch

Just for giggles I ran the command "sudo asl-repo-switch" and got = trixie: main beta

Seems I am indeed on the beta. I did not ask for this and not sure how it happened. (guessing it happened about the time my MOTD got overwritten during last "normal" update(?) I'm not complaining, I just thought I should have been notified in some way of the latest update being pushed to me as a "beta" (extra banner when SSH opens?). Especially if there's problems that need to be reported.

Example: About an hour ago, 4AM, my node seemingly "froze" (I just happened to be awake to witness it)

I have a script that auto runs via Cocpit>Services>Timers to auto connect to various nodes running nets throughout the week (and spawns an "auto disconnect and remove" script). The first one of the day is labeled "Link: The Morning Brew Crew – 4am" (Path

/etc/systemd/system/asl-connect-45225-4am.timer)

When the script runs, prior to connecting to the remote node it plays a local audio file. In this case it was a rooster crowing and an announcement of the net that it is currently connecting to. (This has been running for about two or three months.) The script fired off as expected and the "cockadoodle doo" starts. But in the middle it pauses for like 15 or 20 seconds, tries to continue, then everything disconnects. I look over to my HT like a dog hearing a whistle. I grabbed the laptop tried to log into the shell, nothing. cockpit, won't open.
The node Is located in the camper in the driveway, connects to the house Wi-fi which is Starlink. I hop up and out to the camper to reboot the node. The red activity light on my shari pi was still running as if nothing was wrong. I pulled the power and restarted and everything's back to normal.

I did not check to see if there was any new Wi-fi access points listed. However, I ran a System Diagnostics (w/i Cockpit) I can supply this file ( was downloaded ) if it is requested.

Note, this node is already set up with extra journaling persistent logging for troubleshooting - if needed

73 TIm

···

On Thursday, September 3, 2026 at 08:35:11 AM CDT, Ham Radio with Tim noreply@community.allstarlink.org wrote:


Visit Topic or reply to this email to respond.

To unsubscribe from these emails, click here.

Update:

I was perusing the logs this morning and it Jogged my memory when I saw:

So, the previous night just after 6:00 PM I reset my Nighthawk WiFi router that the SHARI node connects to. I do this Maybe once a month.

I am thinking that the node went offline and never reconnected like it normally does. I would have not noticed any problem because I did not SSH to it that night and there was no scheduled nets...

I guess I may follow instructions to roll back that (fallback) feature...

73 Tim

LOL, Don't worry Murphy is still around the corner and you may feel like a dork again soon ( or later.)

Since they changed the fall back feature to "optional" I'm going to go ahead and push forward with the next updates that are queued up, there's something like 30 of them waiting for me.

Also been noticing constant log entries every minute: