dCore Import Debian Packages to Mountable SCE extensions > General dCore Talk

Wifi.sh quirk?

(1/3) > >>

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

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: ---sudo ifconfig wlp2so down
--- End code ---
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.

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.

Found the solution!

Just boot with the following parameter:

--- Code: ---net.ifnames=0
--- End code ---

Doing that, ifconfig and iwconfig show up as the older normal name, like wlan0

Apparently, this is due to some updates I caught here:

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.


[0] Message Index

[#] Next page

Go to full version