wifi.tcz

[mcdudeabides]

Unsure if this question belongs here.  Mods feel free to move if appropriate.

I'm using the piCore V5a6 in default image.  I use tce to download and install the wifi tools.  Using the wifi.sh script, my wifi adapter is recognized and a list of access point are presented for my selection.  I can select an AP and the script will correctly connect me.

My understanding is that the wifi.sh script should create the wifi.db file in the user home directory (/home/tc/wifi.db) with the selections made by wifi.sh to allow persistence of the wifi selections over reboots (the -a option).  However it appears that the wifi.db is not being written.  I can look in the home directory and I can sudo find / -iname wifi.db with no results. 

Is my understanding incorrect?  Is there another place that wifi.db might exist?  Thanks in advance for your assistance.

[bmarkus]

Unsure if this question belongs here.  Mods feel free to move if appropriate.

I'm using the piCore V5a6 in default image.  I use tce to download and install the wifi tools.  Using the wifi.sh script, my wifi adapter is recognized and a list of access point are presented for my selection.  I can select an AP and the script will correctly connect me.

My understanding is that the wifi.sh script should create the wifi.db file in the user home directory (/home/tc/wifi.db) with the selections made by wifi.sh to allow persistence of the wifi selections over reboots (the -a option).  However it appears that the wifi.db is not being written.  I can look in the home directory and I can sudo find / -iname wifi.db with no results. 

Is my understanding incorrect?  Is there another place that wifi.db might exist?  Thanks in advance for your assistance.

It is correct, wifi.db is created in /home/tc containing ESSID, password and type.

Are you connecting to a WPA protected AP or an open one?

[mcdudeabides]

It is an open access point.

[bmarkus]

No password, nothing to save.

[mcdudeabides]

Agreed.  But also does not save the SSID.  So when using -a option after reboot, there is no reconnect to previously chosen AP. 

It would be possible to use "sudo iwconfig wlan0 essid MyAPName" and then associate the adapter in the bootup as a single case solution.  But If the objective is to leverage wifi.sh as a universal approach to wifi setup, it seems that even the open APs should be preserved in the wifi.db file.

Or is there is preferred approach other than wifi.sh?

[sbp]

Hi Randy

I agree that this could be the root for some of the problems of getting piCore to auto-connect to a non protected wifi network.
It would be nice if the wifi script would allow for saving enough info, so that "wifi.sh -a" could auto-connect to such a network after a reboot.

The content of my wifi.db is something like this:
(essid                password        protection)

Code: [Select]

AndroidAP auaa2880 WPA

What would happen if you made a wifi.db file with this content:

Code: [Select]

your essid
Then make a backup (sudo filetool.sh -b)
and after a reboot
sudo wifi.sh -a

Will it then connect to your open AP?

Steen

[mcdudeabides]

Hi Randy

I agree that this could be the root for some of the problems of getting piCore to auto-connect to a non protected wifi network.
It would be nice if the wifi script would allow for saving enough info, so that "wifi.sh -a" could auto-connect to such a network after a reboot.

I have a lot of streaming media and finicky extenders.  I have intentionally set my wireless network for open unencrypted operation.  While most likely not the majority use case, I would imagine that many others with high streaming loads might have made similar choices.  And given the natural appeal of piCorePlayer to that population, I can understand the static over the wifi setup.

What would happen if you made a wifi.db file with this content:

Code: [Select]

your essid
Then make a backup (sudo filetool.sh -b)
and after a reboot
sudo wifi.sh -a

Will it then connect to your open AP?

Steen

I did try to spoof the wifi.db by "echo McHouse > /home/tc/wifi.db".  While it did preserve the settings and attempt to reconnect to McHouse after a reboot, the wifi.sh logic forces a "key restricted" option to the iwconfig command.  It seems that the logic to associate adapters only considers WPA and then everything else gets "key restricted".  The snippet of wifi.sh logic from line 96 is below.

Code: [Select]

function associate(t,d,s,p,c) {
        print p > ptmp
        if (t == "WPA") {
                system("wpa_passphrase " s " < " ptmp " > /etc/wpa_supplicant.co
                system("wpa_supplicant -i " d " -c /etc/wpa_supplicant.conf -B >
        } else {
                system("iwconfig " d " essid " s " key restricted " p " channel
        }

While d will register wlan0 and s will register McHouse, the "key restricted" will be invoked even if there is no password p. 

Is it permitted to offer alternatives to the existing scripts?  Specifically the wifi.sh script?
@bmarkus - my apologies if this is taking the intention of this thread OT. 

[Rich]

Hi mcdudeabides

Is it permitted to offer alternatives to the existing scripts?  Specifically the wifi.sh script?

Yes it is. I suggest you start a new thread under  TCE Talk. State what the problem is and what behavior you are looking
for. If you have a possible solution you wish to offer, be sure to enclose it in code tags to make it easy to copy.

[bmarkus]

Topic moved from piCore 5.0alpha6 topic as it is not related to piCore but wifi.tcz

[mcdudeabides]

Hello members.  I would like to propose a change to the wifi.sh script included in the wifi.tcz package. 

Problem:  I would like to leverage the wifi.sh script to allow setup across all wifi network types in preparation for running a headless application.  Currently the wifi.sh script will allow an initial scan and selection of an open wifi network.  However, the information is not retained across reboots and prevents using the wifi.sh -a approach as a universal norm.

Proposal:  I think there are 3 relatively minor changes that would allow for persistence of open wifi networks without interfering with the current logic for all other network types.

Change 1. Beginning at line 229.  Reposition password and newitem variable to allow them usage in the ELSE case of the encryption selection.

Code: [Select]

#=== Begin proposed change 1A
                password = ""
                newitem=""
#=== End proposed change 1A
                gsub(" ","\\ ",sid[selection])
                if ( enc[selection] == "on" ) {
#=== Begin proposed change 1B
#                       password = ""
#                       newitem=""
#=== End proposed change 1B

Change 2.  Beginning at line 252.  Utilize the ASSOCIATE function so that the -a option will find a former SSID and that a newly scanned SSID will be saved in wifi.db file.

Code: [Select]

#=== Begin proposed change 2
#                       system("iwconfig " wifi " essid " sid[selection] " channel " chan[selection])
                        newitem=1
                        associate(type[selection],wifi,sid[selection],password,chan[selection])
#=== End proposed change 2

Change 3.  Beginning at line 98.  Modify the ASSOCIATE function to allow open, unencrypted (no password) access points to show in scans, be saved in wifi.db and persist with -a option.

Code: [Select]

#=== Begin proposed change 3A
        keyphrase=" key restricted "
        if ( p == "" ) { keyphrase = "" }
        selchannel=" channel "
        if ( c == "" ) { selchannel = "" }
#=== End proposed change 3A
        if (t == "WPA") {
                system("wpa_passphrase " s " < " ptmp " > /etc/wpa_supplicant.conf")
                system("wpa_supplicant -i " d " -c /etc/wpa_supplicant.conf -B >/dev/null 2>&1")
        } else {
#=== Begin proposed change 3B
#               system("iwconfig " d " essid " s " key restricted " p " channel " c)
                system("iwconfig " d " essid " s keyphrase p selchannel c)
#=== End proposed change 3B

I had quick successful tests on an open and a WPA access point.  The full script is attached (renamed mifi.sh to prevent local interference).  If this is acceptable, what is the correct path forward to approve changes?

[Rich]

Hi mcdudeabides

If this is acceptable, what is the correct path forward to approve changes?

Wait for roberts (the scripts author) to read this thread and give his thoughts on your proposal.

[tinypoodle]

Providing a patch ('diff original modified') would be easier digestible

[mcdudeabides]

Forgive me. I'm a little rusty. My last time with Unix was BSD days. I'll see what I can do when I get home tonight:-)

[mcdudeabides]

Let's see if this helps.

Output of diff:

Code: [Select]

97a98,101
>         keyphrase=" key restricted "
>         if ( p == "" ) { keyphrase = "" }
>       selchannel=" channel "
>       if ( c == "" ) { selchannel = "" }
102c106
<               system("iwconfig " d " essid " s " key restricted " p " channel " c)
---
>                 system("iwconfig " d " essid " s keyphrase p selchannel c)
229a234,235
>                 password = ""
>                 newitem=""
232,233d237
<                       password = ""
<                       newitem=""
253c257,258
<                       system("iwconfig " wifi " essid " sid[selection] " channel " chan[selection])
---
>                         newitem=1
>                         associate(type[selection],wifi,sid[selection],password,chan[selection])

And output with -e (I'm very rusty - assuming this is what feeds to patch??)

Code: [Select]

253c
                        newitem=1
                        associate(type[selection],wifi,sid[selection],password,chan[selection])
.
232,233d
229a
                password = ""
                newitem=""
.
102c
                system("iwconfig " d " essid " s keyphrase p selchannel c)
.
97a
        keyphrase=" key restricted "
        if ( p == "" ) { keyphrase = "" }
        selchannel=" channel "
        if ( c == "" ) { selchannel = "" }
.

Please forgive and educate me if this in not the proper approach.

[tinypoodle]

I think with some other implementations of 'diff' you might need some extra parameter like "-u" to get a proper unified diff patch, however with busybox no such would be needed.
You most certainly shouldn't use "-e".