Tiny Core Linux
Tiny Core Extensions => TCE Talk => Topic started by: mcdudeabides on October 28, 2013, 01:25:45 AM
-
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.
-
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?
-
It is an open access point.
-
No password, nothing to save.
-
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?
-
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)
AndroidAP auaa2880 WPA
What would happen if you made a wifi.db file with this content:
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
-
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:
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.
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.
-
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.
-
Topic moved from piCore 5.0alpha6 topic as it is not related to piCore but wifi.tcz
-
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.
#=== 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.
#=== 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.
#=== 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?
-
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.
-
Providing a patch ('diff original modified') would be easier digestible ;)
-
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:-)
-
Let's see if this helps.
Output of diff:
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??)
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.
-
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".
-
Thanks. In the future, all that is needed is the diff output - no options.
I take it that the first code snippet is acceptable for use for our current purposes?
-
I won't be able to assess or test till the weekend when I will have access to both equip and open access points.
-
Yes. The mods work for an open wifi used with the -a option.
However, when not using the -a option such open wifi items are repeatedly added to wifi.db.
Such is not the case with protected wifi items. This will need to be corrected.
-
Thanks for your review and findings. In the use case I am pursuing, the user is presented with a script that prompts for a number of setup options. For the option that provides wireless setup, the wifi.db is deleted before wifi.sh is invoked (thus preventing the windup). The bootup logic is then modified to start with "wifi.sh -a".
I understand the need to have open access points behave the same as protected. I believe that can be accomplished. It will also give me the opportunity to exercise the DIFF and PATCH advice you gave me:-)
I'll look at it later tonight when I return home.
-
I've included the dbfile lookup logic to prevent the wifi.db duplicates you indicated. Hopefully I have followed the correct process for the patch this time. I'll include both in attachment and inline code form.
--- /usr/local/bin/wifi.sh
+++ /home/tc/wifi.sh
@@ -95,11 +95,15 @@
function associate(t,d,s,p,c) {
print p > ptmp
+ keyphrase=" key restricted "
+ if ( p == "" ) { keyphrase = "" }
+ selchannel=" channel "
+ if ( c == "" ) { selchannel = "" }
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 {
- system("iwconfig " d " essid " s " key restricted " p " channel " c)
+ system("iwconfig " d " essid " s keyphrase p selchannel c)
}
for (try=1; try<20; try++) {
printf(".")
@@ -227,10 +231,10 @@
} while (selection < 1 || selection > i)
if ( offset == 1 && selection != "q") {
sid_display = sid[selection]
+ password = ""
+ newitem=""
gsub(" ","\\ ",sid[selection])
if ( enc[selection] == "on" ) {
- password = ""
- newitem=""
while ( getline dbitem < dbfile > 0 ) {
split(dbitem,field,"\t")
if (sid[selection] == field[1] ) {
@@ -250,7 +254,16 @@
associate(type[selection],wifi,sid[selection],password,chan[selection])
} else {
- system("iwconfig " wifi " essid " sid[selection] " channel " chan[selection])
+ newitem=1
+ while ( getline dbitem < dbfile > 0 ) {
+ split(dbitem,field,"\t")
+ if (sid[selection] == field[1] ) {
+ newitem=""
+ break
+ }
+ }
+ close(dbfile)
+ associate(type[selection],wifi,sid[selection],password,chan[selection])
}
if ( mode == "prompt" ) {
#Choose automatic or manual setting IP adresses
-
Patch easily applied. Thanks! Looks good but will field test before final acceptance.
-
Hi Robert, did you find time to evaluate the patch and is it so good that it be can be accepted?
I have used it few days and don't find any problems.
Steen
-
Yes! A OK. Only waiting for attribtion info, as I wish to give credit where due.
-
Yes! A OK. Only waiting for attribtion info, as I wish to give credit where due.
My name is Randy McEuen. Houston, TX. Is there any more that I need provide?
-
Updated wifi.tcz posted to 4.x and 5.x repos as well as the dCore x86 import directory.
Randy's mods adds open access wifi items to the database and therefore allows auto connect to an open wifi when in pole position.
-
Hello members, I also would like to propose a change tot he wifi.sh script.
Problem: On my raspberry Pi, the IP address lease is not always obtained fast enough. After a several tries, the wifi.sh script gives up. This is probably caused by not enough performance on the Pi, or my network and/or routers is busy/slow.
Proposal: The wifi.sh script uses the -n option for the udhcpc command. I would like to introduce a option for the wifi.sh script which causes it to use the udhscpc command without the -n option. This will force the udhcpc command to indefinitely try to obtain a lease.
This might be strange and unwanted for some applications, but my Raspberry Pi is used headless with only a WiFi connection. Without the wifi connection the Raspberry is useless anyway, so "keep trying" is better then "stop trying".
I've made some changes to the script, I've introduced a -w option. The "w" stands for wait, as in "wait until lease is obtained".
This is the first version, and I've allready some tests on it. It seems to be working but I want to do more testing.
Tell me your opinion on this change, please:
--- /tmp/tcloop/wifi/usr/local/bin/wifi.sh
+++ wifi_new.sh
@@ -11,6 +11,7 @@
echo " Default select AP from menu and request IP via DHCP."
echo " -a Auto connect to first wifi.db entry via DHCP."
echo " -p Select AP from menu and prompt for IP configuration type."
+ echo " -w Wait indefinitely until lease is obtained"
echo " -? Displays this help message."
exit 0
}
@@ -25,15 +26,17 @@
DB=/home/"$TCUSER"/wifi.db
PTMP=/tmp/wpa.$$
-while getopts ap? OPTION
+while getopts apw? OPTION
do
case ${OPTION} in
a) MODE=auto ;;
p) MODE=prompt ;;
+ w) OBTAINLEASE=wait ;;
*) help ;;
esac
done
[ -n "$MODE" ] || MODE=menu
+[ -n "$OBTAINLEASE" ] || OBTAINLEASE=try
unset WIFI && CNT=0
until [ -n "$WIFI" ]
@@ -72,7 +75,7 @@
iwlist "$WIFI" scanning
[ "$?" == 0 ] && break
sleep 1
-done ) | awk -v wifi="$WIFI" -v dbfile="$DB" -v mode="$MODE" -v ptmp="$PTMP" '
+done ) | awk -v wifi="$WIFI" -v dbfile="$DB" -v mode="$MODE" -v obtainlease="$OBTAINLEASE" -v ptmp="$PTMP" '
BEGIN {
RS="\n"
FS=":"
@@ -186,13 +189,20 @@
if ($2 ~ /WPA/ ) type[i]="WPA"
}
END {
+ if ( obtainlease == "try" ) {
+ lease = "-n "
+ print("Set to try a few times to obtain a lease." )
+ } else if ( obtainlease == "wait" ) {
+ lease = ""
+ print("Set to try indefinitely until lease is obtained." )
+ }
if ( mode == "auto" ) {
print("Attempting auto connection with " autoconnect)
for (i in sid) {
gsub(" ","\\ ",sid[i])
if (autoconnect == sid[i] ) {
associate(type[i],wifi,sid[i],mypass,chan[i])
- system( "udhcpc -n -i " wifi " 2>/dev/null" )
+ system( "udhcpc " lease "-i " wifi " 2>/dev/null" )
exit
}
}
@@ -274,14 +284,14 @@
setipaddresses(wifi)
}
else {
- results = system( "udhcpc -n -i " wifi " 2>/dev/null")
+ results = system( "udhcpc " lease "-i " wifi " 2>/dev/null")
if ( results == 0 )
if ( newitem == 1 )
printf("%s\t%s\t%s\n", sid[selection] ,password, type[selection] ) >> dbfile
}
}
else {
- results = system( "udhcpc -n -i " wifi " 2>/dev/null")
+ results = system( "udhcpc " lease " -i " wifi " 2>/dev/null")
if ( results == 0 )
if ( newitem == 1 )
printf("%s\t%s\t%s\n", sid[selection] ,password, type[selection] ) >> dbfile
-
Hi Gerrelt
( I've tried to mimic the difference report as used by mcdudeabides, a "-" means line deleted, a "+" means line added)
Don't do this manually, that's what the diff command is for:
diff Original_File Modified_File > diff.txtThat will list just the differences and save them to a file called diff.txt.
-
Ah thanx! I used the diff command and updated my post.
-
I've did some more testing yesterday evening, and everything seems to work fine.
I added this line to the bootlocal.sh:
/<patch to wifi script>/wifi_new.sh -a -w
And it connected after every reboot or power off -> power on.
-
Hello everybody,
I've made another (small) change to the script I want to propose.
Problem: When connected to a wifi router, the name displayed in the DHCP client list is "unknown". This makes it more difficult to discover the tinycore device amongst the other devices.
Solution: Adding the "-x hostname:<hostname>" option to the udhcpc command. With the "hostname" command the current set hostname is retrieved, and that is used as the hostname for the wifi DHCP client.
If, for some strange reason, the hostname cannot be determined, it will default to "Tinycore".
The difference report (compared to the current wifi.sh, so it also contains my previous change request):
--- /tmp/tcloop/wifi/usr/local/bin/wifi.sh
+++ wifi_new.sh
@@ -11,6 +11,7 @@
echo " Default select AP from menu and request IP via DHCP."
echo " -a Auto connect to first wifi.db entry via DHCP."
echo " -p Select AP from menu and prompt for IP configuration type."
+ echo " -w Wait indefinitely until lease is obtained"
echo " -? Displays this help message."
exit 0
}
@@ -25,16 +26,22 @@
DB=/home/"$TCUSER"/wifi.db
PTMP=/tmp/wpa.$$
-while getopts ap? OPTION
+while getopts apw? OPTION
do
+
case ${OPTION} in
a) MODE=auto ;;
p) MODE=prompt ;;
+ w) OBTAINLEASE=wait ;;
*) help ;;
esac
done
[ -n "$MODE" ] || MODE=menu
+[ -n "$OBTAINLEASE" ] || OBTAINLEASE=try
+CURRENTHOSTNAME=$(hostname -s)
+[ -n "$CURRENTHOSTNAME" ] || CURRENTHOSTNAME=Tinycore
+
unset WIFI && CNT=0
until [ -n "$WIFI" ]
do
@@ -72,7 +79,7 @@
iwlist "$WIFI" scanning
[ "$?" == 0 ] && break
sleep 1
-done ) | awk -v wifi="$WIFI" -v dbfile="$DB" -v mode="$MODE" -v ptmp="$PTMP" '
+done ) | awk -v wifi="$WIFI" -v dbfile="$DB" -v mode="$MODE" -v obtainlease="$OBTAINLEASE" -v currenthostname=$CURRENTHOSTNAME -v ptmp="$PTMP" '
BEGIN {
RS="\n"
FS=":"
@@ -186,13 +193,20 @@
if ($2 ~ /WPA/ ) type[i]="WPA"
}
END {
+ if ( obtainlease == "try" ) {
+ lease = "-n "
+ print("Set to try a few times to obtain a lease." )
+ } else if ( obtainlease == "wait" ) {
+ lease = ""
+ print("Set to try indefinitely until lease is obtained." )
+ }
if ( mode == "auto" ) {
print("Attempting auto connection with " autoconnect)
for (i in sid) {
gsub(" ","\\ ",sid[i])
if (autoconnect == sid[i] ) {
associate(type[i],wifi,sid[i],mypass,chan[i])
- system( "udhcpc -n -i " wifi " 2>/dev/null" )
+ system( "udhcpc " lease "-i " wifi " -x hostname:" currenthostname " 2>/dev/null" )
exit
}
}
@@ -274,14 +288,14 @@
setipaddresses(wifi)
}
else {
- results = system( "udhcpc -n -i " wifi " 2>/dev/null")
+ results = system( "udhcpc " lease "-i " wifi " -x hostname:" currenthostname " 2>/dev/null")
if ( results == 0 )
if ( newitem == 1 )
printf("%s\t%s\t%s\n", sid[selection] ,password, type[selection] ) >> dbfile
}
}
else {
- results = system( "udhcpc -n -i " wifi " 2>/dev/null")
+ results = system( "udhcpc " lease "-i " wifi " -x hostname:" currenthostname " 2>/dev/null")
if ( results == 0 )
if ( newitem == 1 )
printf("%s\t%s\t%s\n", sid[selection] ,password, type[selection] ) >> dbfile
-
Problem: When connected to a wifi router, the name displayed in the DHCP client list is "unknown".
That may depend on the router in question, mostly the name is constructed from client MAC in such case.
-
I am using a TP-Link router, and it displays Client name, mac address and ip address. But the Client name is set to unknown, if the hostname is not specified with the udhcpc command.
-
Gerrelt's patch accepted. Updated wifi.tcz posted to 4.x and 5.x repos as well as the dCore x86 and armv7 import directories.
-
piCore repos updated
-
Thanks guys!
I've update my wifi.tcz and everything is running good. I've tested it on three different wifi adapters.
One word of warning for people that want to use the -w option in a headless situation: When you add the command "wifi.sh -a -w" to bootlocal, do it after starting openssh or dropbear. When added before starting ssh, then if anything goes wrong with the wifi connection (wrong password or something), ssh will not be started. This means you cannot access your machine by plugging in a wired network. You will have to attach a keyboard and monitor to correct the situation.
So add it after starting ssh.
While typing this I realised this could probably also be solved by add ing a "&" to the end of the wifi start command. This will start it in the background, and return to the bootlocal script immediately. But I haven't tested that.
Greetings,
Gerrelt.
-
Hello everybody,
I've got a proposal for a change to the wifi.tcz.
Problem:
I've encountered some problems with some WiFi adapters. Running wifi.sh produced only a partial access point list, and/or wouldn't automatically connect.
I traced the problem down to the adapter not being entirely ready scanning, but it does return an empty or partial list.
The problem is that in the wifi.sh script the "iwlist "$WIFI" scanning" command is executed too soon after "ifconfig "$WIFI" up".
At the moment of scanning, the network might be up, but the wifi adapter is not entirely started up yet. This results in a partial AP list. The adapter needs a little more time to complete the scan for AP points.
The automatic connect fails because of this reason too. Most of the times, it can not find the set accespoint name in the partial AP list.
Solution:
The "solution" is to wait a little before before executing the iwlist command. This solved the problem for some adapters, but not for all.
Apparently some adapters automatically start scanning after the "ifconfig "$WIFI" up" command, to prepare for the iwlist command.
But other adapters don't do this, and start the first scan when the "iwlist "$WIFI" scanning" is executed.
So, the solution is twofold:
- add a dummy iwlist scanning command right after ifconfig up, for starting the first scan.
- move the "sleep 1" from line 85 to line 83. Now it will sleep 1 second before each iwlist scanning try. This will give the WiFi adapter some time for scanning.
The drawback is that connecting to a wifi network takes one second longer, the benefit is that it makes the wifi connection much more reliable.
I've tested it on several WiFi adapters on piCore 6.0rc1, and piCore 6.0. Also user sbp tested this solution (only the sleep mod) on piCore 6.1alpha2.
And it seems to work great.
The difference report:
--- /tmp/tcloop/wifi/usr/local/bin/wifi.sh
+++ /home/tc/wifi.sh
@@ -78,11 +78,15 @@
echo "Standby for scan of available networks..."
ifconfig "$WIFI" up 2>/dev/null
+# do a dummy ap scan to start up the wifi adapter
+iwlist "$WIFI" scanning >/dev/null
(for i in `seq 5`
do
+ # sleep 1 sec to give the wifi adapter some time to complete scanning
+ sleep 1
+ # do actual scan
iwlist "$WIFI" scanning
[ "$?" == 0 ] && break
- sleep 1
done ) | awk -v wifi="$WIFI" -v dbfile="$DB" -v mode="$MODE" -v obtainlease="$OBTAINLEASE" -v currenthostname=$CURRENTHOSTNAME -v ptmp="$PTMP" '
BEGIN {
RS="\n"
Greetings,
Gerrelt.
-
Hi Gerrelt
thanks for the fix, it is OK for me. I will apply and update wifi.tcz
Béla
-
Hi Béla,
Great! Thanks. :)
Greetings,
Gerrelt.
-
Hi guys,
This issue only cropped up in piCore v6.1alpha2. Up till then connection to the wireless network worked 100% of the time.
I have noticed (in the past) that the first "scan" usually didn't show all the wireless networks but the main wireless networks always appeared. The second and subsequent scans usually showed one or two more networks but the extra networks were of marginal strength and never the ones I wanted to connect too.
What changed?
regards
Greg
-
What changed?
Only the kernel.
Az én iPad készülékemről küldve a Tapatalk segítségével
-
What changed?
Hi Greg,
I think this problem has become more visible because of the improved performance of piCore. Because it's faster, the wifi adapter now has less time to do a full AP scan. Which results in a empty or partial list.
Greetings,
Gerrelt.