Wifi.sh quirk?

[PDP-8]

I think I caught some sort of loop weirdness in the wifi.sh script ...

Symptom:
Bring up a wireless acesss point for the first time and supply the WRONG wpa password.  Fat fingered mistake.   Wont connect of course.

Wait a little bit for the device/resource to not be busy and try again.  But this time supply the CORRECT password.

It still won't connect, even with the right password.  (don't trust me, try this yourself.

The only thing that will cure that is to ugh, reboot and it will now accept the correct password.

Supplementary info:
my wireless device as seen in ifconfig is wlp2so

Noticed another loop of sorts that it can't get out of:

Let's say you provide the right password straight off the bat and connect.  But now you issue another wifi.sh to perform a disconnect and scan.  So you disconnect and Quit instead of scanning.

Later, you bring up wifi.sh again, but instead of scanning, it says it is already connected, even though you chose to disconnect and quit earlier.

Sure, I can bring it down manually with

Code: [Select]

sudo ifconfig wlp2so down but wondering why wifi.sh isn't doing that when I tell it to disconnect and quit.

I'm looking at the awesome script at /usr/local/bin/wifi.sh and am wondering if busybox or something else is garbling my wlp2so device and confusing things?

[Jason W]

Do you see this same behavior in regular Core?  I see the wifi.sh in Core and dCore are the same but for one simple change I made when exiting the terminal at the end.  It doesn't exit the terminal window if no wifi devices are found but the terminal window stays open with the message of no devices found and press enter to exit. 

I am not familiar with the wifi.sh script and I don't have wireless hardware myself.  If this is something that affects Core and dCore as the script for them is the same, a solution to this issue would be a fix for both.

[PDP-8]

On TinyCorePlus there is no weird behavior if you accidentally enter the wrong password and try it again.  Either from the shell or from the iconized wbar trigger.

BUT, maybe this has something to do with it:  once wireless has been established, an ifconfig or iwconfig will identify the card as wlan0.

However, with dCorePlus (on both stretch and stretch64), that is identified as
wlp2S0 - not the wlan0 I was used to seeing.

So maybe the wifi.sh script is ok, but for some reason something is not translating wlp2s0 (on my machine at least) to a generic wlan0 ?

Or, think of it as a feature, not a bug!  Enter the wrong password, and unless you know the real remedy, even the right password won't work. 

[Jason W]

Thanks for the reporting results between Core and dCore.  The issue is apparently dCore specific, and I will work towards a solution.

[PDP-8]

Found the solution!

Just boot with the following parameter:

Code: [Select]

net.ifnames=0
Doing that, ifconfig and iwconfig show up as the older normal name, like wlan0

Apparently, this is due to some updates I caught here:
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

Wifi.sh acts perfectly now.  Thing is, that article brings up some good points, and if I really knew my shell scripting, maybe wifi.sh could use some sprucing with udev/systemd type stuff.  I'll whip that out tonight!  (Yeah right.) 

Making the soft link to /dev/null as a quickie didn't seem to work as that file already existed, so I hit the system up front on the boot prompt line and bingo.

[Jason W]

Thank you PDP-8 for your testing and feedback.  I will look into the udev files to perhaps see that wlan0 is used for the first wireless interface instead of other names. 

[PDP-8]

Note that I modified the original message to make the boot parameter a plural with an "s":

Code: [Select]

net.ifnames=0

[Jason W]

I have been reading up on the predictable device names thing, and at least for now I like the idea about using net.ifnames=0 as a default boot parameter rather than editing udev files.  I like to create extra data files or use starting scripts to modify existing ones when that is the only way.  The boot code is simpler and more reliable as file contents in packages can change with new versions and can make package startup scripts or data.tar.gz incorrect with an update in the Debian repo.

[PDP-8]

Well, this got me thinking - always dangerous.

Politics aside, I wonder if not using wifi.sh at all and using a more systemd/udev aware network manager would be the way to go with dCore and the debian/ubuntu repos.

Or, perhaps tracking a more classic distribution, like Devuan would reduce the dev workload and be more suitable for busybox init, wifi.sh etc etc.  Apparently the "ascii" / aka stretch version of Devuan is close to being declared stable.  I'm here for testing if that seems interesting.

Don't get me wrong - it may seem like I'm just trying to grab all the low-hanging fruit with dCore, but it's only because I find that TinyCore and dCore complement each other perfectly.  Alike, yet different.   I can't keep my hands off either one!

[Jason W]

wifi.sh is good for including in dCorePlus or as available in the wireless extension, it is small and allows folks to get on the network.  Just like in standard Tinycore.  wifi.sh fits into the Tinycore/dCore concept as the default small way to get online with wireless. 

[PDP-8]

I agree completely.

This also put my mind to rest:

Code: [Select]

sudo stat /proc/1/exe
Carry on!