wifi.tcz

[maro]

Today I embarked on a kind of "tire kicking" exercise of this new extension. So far I've been using a "home grown" little script to do essentially the same, but I never found the time to enhance it well enough to cater for more then just my own set of hardware and potential wireless access points. So it would be good if I could "retire" mine and use the community one.

From my own testing so far with a few different notebooks and a few different devices (e.g. built-in, PC-Card, or USB) I'm aware how variable the responses of such devices can be. So I did not expect that the very first run of the 'wifi.sh' script would go without a hitch. Now, for this first attempt I used what is probably my most "benign" system (i.e. a Lenovo T60 with built-in Intel 'iwl3945' adapter). Luckily I'm already aware which firmware extension (i.e. 'firmware-iwlwifi.tcz') I'll require. So after installation of those two extensions plus their dependencies (via tce-load -wi firmware-iwlwifi wifi) I was pleasantly surprised about a new icon in the 'wbar'. Even more so when I clicked it and in the 'xterm' appeared indeed a list of the wireless networks in my neighborhood. After entering my WPA2 passphrase (in clear text !!) the script managed to connect successfully to my WiFi router. So all up a surprisingly positive experience for such a "hot off the press" script.


A few thoughts now have come up. Let me state first off that I understand that this script should not become a "competitor" to 'wicd' or 'networkmanager' in terms of supported features (which would make it equally bloated), but some of these might be worth some future development effort:

• (1) I'm not sure whether entering a password in clear text is such a good idea. Most GUIs allow to show or hide such entry, which then requires a radio button. That is OTOH not really easy to do in a text based interface. So I'm not too strongly opposed against the current solution.
• (2) What I consider a bit too weak a solution is the fact that the passphrase appears in clear text in '~/wifi.db' as well as '/etc/wpa_supplicant.conf'. I strongly believe that there is a reason why only hashed values appear in the likes of '/etc/shadow' etc. I'd therefore like to suggest to only store the hashed value in both of these two files.
• (3) One not so pleasant observation was the fact that multiple 'wpa_supplicant' processes are allowed to run for the same interface at the same time. This then lead to a frequent tear-down and re-connect to the AP running at about every 10 seconds. One can imagine that the throughput wasn't great plus all those unwanted extra entries in the logs of the route and the client. To get into this situation one could simply re-run 'wifi.sh'. Whilst it could be considered a user error I can envisage more complex scenarios, e.g. after some period of activity the user turns off the WiFi via the "kill switch" only to re-enable it (via 'wifi.sh') some time later (but still in the same session). As the initial process is still running the second one is then getting into a "fight" with the first one. So it needs to be ensured that for the same interface no other 'wpa_supplicant' process is running before the current one gets started.
  BTW, the same applies to the 'udhcpc' process, and as before I think a 'killall udhcpc' is not a good idea as there could be multiple interfaces on a system using said process.
• (4) It might be an idea to list all available networks in descending signal strength (i.e. 'Quality') so that the strongest network (which often tends to be ones own) shows up tops.
• (5) Another "beatification" idea for this selection list would be to put a marker (e.g. '(*)' or '(known)') against those ESSID for which an entry is already in the 'wifi.db'.
• (6) And still on the subject of this all important ESSID list: I've noticed that on occasion my own WiFi router did not show up in that list. That is rather surprising as the distance during those test was not even 1.5 meters (ca. 5 feet). Therefore it might be better to include a '(r)escan' option into the selection.

I'm happy to come up with a patches for each of these suggestions. But as something might already be "brewing" back at HQ it would be good to know on which one I should focus my effort (provided these suggestions make sense not just to myself).

[roberts]

So it would be good if I could "retire" mine and use the community one.

Interesting that you call it a "community one". Comes across as projecting difficulty with acknowledging the author.

I wrote this script to be the extreme opposite of wicd. The Team saw this script at the same time as the community when I released it as part of the starter pack network.gz.

It is a shame that you did not try the script's initially intended purpose. That is so say, you might know which wifi/firmware extensions that you need, but a new user to Tiny Core may not.

For that very purpose I have introduced starter packs. The two installation starter packs I include my custom installation GUI programs. But  the network starter pack did not have any such tool. And wicd is just way to bloated! So I wrote wifi.sh. Thereby using only the network starter pack, a new user might have initial success connecting their wifi. 

After seeing my wifi.sh in the network starter pack, a team member asked me to make it into a proper extension.

Since the team has seen my script, there has been internal discussions about enhancements. I will consider such for the next version. And, no, thanks, I do not need help enhancing my program. Your suggestions are duly noted.

[Rich]

Hi roberts

So it would be good if I could "retire" mine and use the community one.

Interesting that you call it a "community one". Comes across as projecting difficulty with acknowledging the author.

I can see how you could read it that way, however, when I first read it I took it to mean he was looking
to replace a personal script with an official Tinycore script. Sometimes meanings get lost in translation
or in how a person expresses them self. While I saw no ill intent, only maro can clear that up one way
or the other.

[maro]

I believe I might already be on the record with the statement that English is not my first language. So even though I now live in an English speaking country I still struggle sometimes with some expressions. I guess I won't be able to shake off 35+ years living in a non-English environment (plus I really hated to learn it at school, so it was my worst school subject by far).

That said, I apologize if my wording was taken as anything different to the meaning of "official" (i.e. created by the Core team). The thought to question Robert's authorship would have never crossed my mind.

[hiro]

As an extension you could also include a dependency file, right?
What's the reason for using two config files? Easier backup? Or because wpa_supplicant.conf is too complicated? Sorry if this question may seem a bit dumb

[maro]

What's the reason for using two config files? Easier backup? Or because wpa_supplicant.conf is too complicated? Sorry if this question may seem a bit dumb

The two files have different functions:

• '/etc/wpa_supplicant.conf' is a runtime configuration file (for a single interface),
• '~/wifi.db' is a (very simplistic) "database" holding the passphrases of previously used wireless access points.

The former should be generated freshly every time before an interface attaches to an AP, the latter should be kept for the next time around (hence it is located in the home directory which is included in the backup and should therefore "survive" the next reboot).

Come to think of it (and as an add-on to the OP):

• (7) For the (further) future it would be good if 'wifi'sh' would be able to support multiple wireless interfaces. This then would obviously require potentially multiple 'wpa_supplicant.conf' files, which would require an appropriate renaming of them. Whilst multiple wireless interfaces in a single system might not be the norm (I can have up to three different ones in one notebook, albeit I've only used such a configuration for test purposes), it costs nothing to include the interface name in the configuration file name.

[hiro]

> '/etc/wpa_supplicant.conf' is a runtime configuration file (for a single interface),
No.

[roberts]

it is as deployed in my script!

[gerald_clark]

I use wep, and "wifi.sh auto" it does not work for me.
It sets the ESSID on eth0 to the wrong value ( not the one in wifi.db ).
If I run it a second time, it finds the ESSID and sets it correctly and finds the access point, but it still does not get a dhcp address.
If I runit a third time, an IP address is assigned.

I am awk rusty, and the intemittant results make it difficult for me to troubleshoot.