GUI frontend is ready. Now, it is time for users to discover deep bugs that only show their heads when the user number increases.
A popup window has been provided to display detailed information about any available wifi hotspots. This simplified the design and implementation of the GUI. Hopefully, users find it useful. On 21/08/2015, Edward Bartolo <edb...@gmail.com> wrote: > I think, I can also upload the Lazarus code of the frontend. I am > using the application, and for those who love the principle of "Keep > it simple stuptid", it is a nice simple application which is run on > request. It is also controlled by the user, instead of automatically > making decisions behind the scenes. > > Automation will definitely take more time to do, but for the KISS > lovers, the application can be provided as is, with a version number > of 0.1 or something similar. > > When the C backend is hardened enough, it will be time for upload to > git.devuan.org. > > Cheers, and may DEVUAN be enjoyed by anyone wanting software freedom. > > Edward > > On 21/08/2015, Edward Bartolo <edb...@gmail.com> wrote: >> At long last, the backend runs without the frontend having for it to >> finish as I wished. This got rid of frontend hangs. >> >> >> >> On 21/08/2015, Steve Litt <sl...@troubleshooters.com> wrote: >>> On Fri, 21 Aug 2015 06:47:13 +0100 >>> Edward Bartolo <edb...@gmail.com> wrote: >>> >>>> Parsing headaches: >>>> >>>> I have this chunk of data retrieved from the backend which I need to >>>> parse *reliably*. The goal is to read the SSID and the corresponsing >>>> signal strength. >>>> >>>> How should I proceed. This part of code will be done from within >>>> Lazarus. Please, be informed that Lazarus generated GUI uses GTK* as a >>>> base. The executable can is also statically built which means an >>>> increased portability. Executables are about 3 MB. In the past I have >>>> written such applications that dwarf what I am doing and still the >>>> size is small. >>>> >>>> Here is what I want to parse: >>>> >>>> root@edbarx-pc:/home/edbarx# iwlist wlan0 scan | grep -B 4 ESSID >>>> >>>> <<<<<<<<< >>>> Channel:1 >>>> Frequency:2.412 GHz (Channel 1) >>>> Quality=70/70 Signal level=-34 dBm >>>> Encryption key:on >>>> ESSID:"EB-TP-LNK67" >>>> -- >>>> Channel:6 >>>> Frequency:2.437 GHz (Channel 6) >>>> Quality=24/70 Signal level=-86 dBm >>>> Encryption key:on >>>> ESSID:"TNCAPA0332D" >>>> -- >>>> Channel:11 >>>> Frequency:2.462 GHz (Channel 11) >>>> Quality=30/70 Signal level=-80 dBm >>>> Encryption key:on >>>> ESSID:"Home WiFi" >>>> >>>>>>>>>>>>>>> >>> >>> :-) >>> >>> Hi Edward, >>> >>> At this point you're a lot more knowledgeable on this situation than I, >>> but I'll give you an opinion. If this problem were any more complex, >>> I'd suggest spawning awk, but it looks to me like as long as you can >>> get these lines into Lazarus, I think you're golden. >>> >>> Please refer to http://dpaste.com/0FZE769 ... >>> >>> First thing: By using grep -B, you're throwing away some information >>> you need: Specifically, encryption type. I'd recommend you pull *all* >>> the output from iwscan $device scanning into a Turbo Pascal (you know >>> what I mean) file linked into your Lazarus program, >>> except "^\s+IE: Unknown". >>> >>> It's pretty easy to parse: >>> >>> * Throw away anything beginning with "^\s*IE: Unknown" >>> * Throw away ^$device\s+Scan completed >>> * Every ^\s*Cell \d starts a new record, record the cell number >>> >>> Every line is one of the following: >>> >>> 1. ^$device\s+Scan Completed >>> 2. ^\s+Cell >>> 3. ^\s+IE: Unknown >>> 4. ^\s+\S.*: >>> 5. ^\s+\S.*= >>> 6. Everything else >>> >>> #3 can be avoided by having your original command be the following: >>> >>> root@edbarx-pc:/home/edbarx# iwlist wlan0 scan | grep -v "^\s+IE: >>> Unknown:" >>> >>> #4 are the key/value pairs comprising most of what you need >>> >>> #6 are all additional information appended to the #4 item preceding >>> them. So you need a somewhat stateful algorithm. You may or may not >>> need a Group Cipher, Pairwise Ciphers, and/or Authentication Suites. If >>> you don't need those three things, I think you can throw away all #6. >>> >>> #2 separates records >>> #5 is the signal quality/level line. Give it its own subroutine. >>> #1 gets thrown out >>> >>> Anyway, you definitely need to capture the encryption type, and by >>> using your grep -B4 ESSID you're throwing that away. NetworkManager and >>> Wicd both show encryption type on the ESSID list, and when I use >>> either of this, I want to know which ones are WPA as opposed to >>> (eeeuuu) WEP and which are (be very careful) unencrypted. >>> >>> HTH, >>> >>> Steve >>> >>> Steve Litt >>> August 2015 featured book: Troubleshooting: Just the Facts >>> http://www.troubleshooters.com/tjust >>> _______________________________________________ >>> Dng mailing list >>> Dng@lists.dyne.org >>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng >>> >> > _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng