DHCP overriding my STATIC IP on wireless using Frisbee

[npierce]

Oh dear. I'm sorry to hear that things didn't go well.

First, here is how to find the original file:

I set up PUPPY as a hard drive installation . . .

If by that you mean what is commonly called a "full install", you will need to mount your Puppy CD or .iso file, then mount the Puppy .sfs file that is on that. You will then find the file in the mounted .sfs file at /etc/init.d/frisbee.

If you have what is commonly called a "frugal install", you don't need to mount anything, and can find the file at /initrd/pup_ro2/etc/init.d/frisbee.

By the way, which of those installation types do you have, and what version of Puppy?

. . . I made a backup of /etc/frisbee and NOT /etc/init.d/frisbee!! . . .

I'm assuming that you didn't also overwrite your original /etc/frisbee/ directory, which obviously would be troublesome.

. . . It changed my ordering: eth0 is now the wireless and eth1 is the hardwire! Weird. . . .

What my modification does (or is supposed to do )is simply cause the script to wait for wpa_supplicant to finish scanning for wireless signals before starting dhcpcd. I would not have expected that it would cause a switch from eth1 to eth0. But nothing surprises me anymore, especially when it involves a change in timing.

But if the wireless is now eth0, and your dhcpcd.conf file hasn't changed, this would explain why it isn't working for you now. Two things:

1. The following line causes dhcpcd to ignore eth0:

Code: Select all

denyinterfaces lo,wmaster0,pan0,ppp0,eth0

2. Both of the stanzas that define the configuration for your interfaces specify eth1, since they both contain this line:

Code: Select all

interface eth1

But perhaps you have already made those adjustments.

By the way, I am assuming that the SSID of your interface is really "EducateMe", as stated in your dhcpcd.conf file. Correct?

If you would like to persue this, try making the appropriate modifications to dhcpcd.conf (either manually or by using the frisbee GUI). And if you don't meet with success, please post your updated /etc/frisbee/dhcpcd.conf file.

If you would just like to get back to where you were, let me know if restoring your original frisbee initialization script does that.

[dlopeman]

Thanks for hanging in there!!

OK... let's see. I removed the /etc/init.d/frisbee... now after rebooting looks like eth1 and eth0 switched BACK around! nice.

I did not copy OVER /etc/frisbee, it now looks exactly like it did... and I made that change to dhcp.conf to remove eth0.

I have Puppy Precise... installed to "hard disk" [which is actually a CF card converted to PATA - a frugal-man's Solid State HD ] It's a picture frame so I wanted as few moving parts as possible.

Welp... as it stands, I don't have the cdrom drive installed and will have to pull the frame off the wall and stuff... I'll try to get some time to do that later on... otherwise, if the frame reboots I'll have to enable networking again manually (there's a keyboard and mouse hanging out of it now!) Too bad I didn't post my /etc/init.d/frisbee file here, too!

[dlopeman]

where does puppy show it's exact version?

Linux PictureFrame 3.9.11 #1 SMP Sat Jul 27 19:40:54 GMT-8 2013 i686 i686 i386 GNU/Linux

was looking for /etc/puppy-release or something like that...

[dlopeman]

poking around... I found this version of frisbee:

http://www.murga-linux.com/puppy/viewto ... &start=255
frisbee-1.2-alpha-20130905.pet
maybe I can try installing that pet?

[npierce]

Code: Select all

cat /etc/DISTRO_SPECS | grep -E "DISTRO_NAME|DISTRO_VERSION"

You can also find the frisbee initialization script in the .pet package in the Puppy "noarch" repository.

To see which frisbee package your Puppy came with, try this:

Code: Select all

grep frisbee /root/.packages/woof-installed-packages

You can then find that same package in the repository at: http://distro.ibiblio.org/puppylinux/pe ... es-noarch/

You can choose to let petget install the .pet file, which will require that you configure your network connection again. Or you can download the .pet to your /tmp/ directory and extract the etc/init.d/frisbee file from the pet with tar, like so (substituting the name of your .pet file, if different):

Code: Select all

cd /tmp
pet2tgz frisbee-1.1-20130415-modified.pet
tar -xzf frisbee-1.1-20130415-modified.tar.gz frisbee-1.1-20130415-modified/etc/init.d/frisbee

(Note that that is only three lines of code, although it may look like more in your browser if your window is small.)

You will then find the file at /tmp/frisbee-1.1-20130415-modified/etc/init.d/frisbee

[npierce]

frisbee-1.2-alpha-20130905.pet
maybe I can try installing that pet?

That might work fine for you. But using the original is probably a better idea. You would probably agree that it's best not to make too many changes at once when troubleshooting. You could certainly try that version later, once things are working again.

[npierce]

dlopeman,

I am wondering if you saw my earlier (Dec-19 11:47 UTC-4) post which suggested how to restore your /etc/init.d/frisbee file by downloading your original frisbee .pet file. That would save you from the need to "pull the frame off the wall and stuff..." to install a CDROM drive.

Or perhaps you have it working well enough that you don't want to mess with it at the moment.

[rerwin]

I discovered this thread just now.

For the record, I am the current person responsible for the version of frisbee now in precise pup and any other recent woof-based pups. I assume you are working with frisbee-1.1. The "1.2-alpha" is an experiment of adding 3G wireless and DSL modem support to frisbee. The only reason to try that version is to test its 3G part, which is based on the pgprs technique. It adds nothing to the broadband wireless code.

It will take me awhile to digest what has been discussed here. But I would like to add whatever fixes we come up with to an updated frisbee (1.1.1?) eventually. Note that although I am comfortable with the internals of frisbee, I am learning as I go and respect and depend on npierce's knowledge of how the wireless stuff works.

The thread where you got "1.2" is where development is discussed. But we can continue working out this issue in the current thread.
Richard

[npierce]

Richard,

I am happy to know that you are interested in seeing this problem fixed and releasing an updated version of frisbee when that happens. Had dlopeman and I found and verified a solution, I would have been lobbying you to include it in a future release. Since we didn't get that far, I didn't contact you, but am now grateful to have your help.

I assume you are working with frisbee-1.1.

Yes. I've been working with the frisbee that came with Precise 5.7.1, since that is my best guess at what dlopeman is using. dlopeman is using Precise but hasn't yet reported the version, although it uses kernel 3.9.11, which is consistent with Precise 5.7.1, and not consistent with Precise 5.6, which has kernel 3.2.44. (I don't have Precise 5.7, so can't rule that out.) Anyway, you'd know better than I, but I think that all Precise Puppies since last May probably use frisbee-1.1-20130415-modified.pet (but I've not verified that).


I didn't offer much of an explanation about my proposed patch since I was waiting to do so until after it had been tested and found to be useful. And that has yet to happen -- possibly because my code is bad, or possibly because there were other issues with dlopeman's system.

But since a couple of weeks have passed without any progress, and since I am already starting to forget the details of this issue, perhaps it would be a good idea to do a brain-dump here before I totally forget, in case doing so would help you to find a fix for this problem.

First, a couple of definitions. Since there are two files named "frisbee", I'll refer to the script used to configure the network connections (/usr/local/bin/frisbee) as the configuration script, and the script used to initialize the network connections (/etc/init.d/frisbee) as the initialization script.


In the course of this thread, two symptoms have been noticed. I believe both are related to a timing problem within the frisbee initialization script which sometimes starts dhcpcd too soon after starting wpa_supplicant. On my hardware, my patch eliminated both symptoms, but failed to work for dlopeman.

Both of these symptoms happen when a static address is specified in the dhcpcd configuration file, and both result in dhcpcd broadcasting for a DHCP leased address instead of using the desired static address. Both happen only when wpa_supplicant and dhcpcd are started when the frisbee initialization script is started, as happens at boot time. The symptoms do not appear when wpa_supplicant is already running, as is the case when the user edits a profile using the frisbee configuration script, which restarts dhcpcd.

Symptom 1:

dhcpcd initially uses the static address found in its configuration file (192.168.1.76 in dlopeman's example), but later broadcasts for a lease and changes the address to the address offered (192.168.1.120 in dlopeman's example), as shown in this excerpt from dlopeman's log file:

Code: Select all

Dec  2 19:49:49 PictureFrame daemon.info dhcpcd[3111]: eth1: carrier acquired
Dec  2 19:49:49 PictureFrame daemon.debug dhcpcd[3111]: eth1: using hwaddr 00:12:f0:1c:dd:d2
Dec  2 19:49:49 PictureFrame daemon.debug dhcpcd[3111]: eth1: executing `/lib/dhcpcd/dhcpcd-run-hooks', reason CARRIER
Dec  2 19:49:49 PictureFrame daemon.info dhcpcd[3111]: eth1: using static address 192.168.1.76
Dec  2 19:49:49 PictureFrame daemon.debug dhcpcd[3111]: eth1: adding IP address 192.168.1.76/24
Dec  2 19:49:49 PictureFrame daemon.debug dhcpcd[3111]: eth1: adding route to 192.168.1.0/24
Dec  2 19:49:49 PictureFrame daemon.debug dhcpcd[3111]: eth1: adding default route via 192.168.1.1
Dec  2 19:49:49 PictureFrame daemon.debug dhcpcd[3111]: eth1: executing `/lib/dhcpcd/dhcpcd-run-hooks', reason STATIC
Dec  2 19:49:51 PictureFrame daemon.info dhcpcd[3111]: eth1: broadcasting for a lease
Dec  2 19:49:51 PictureFrame daemon.debug dhcpcd[3111]: eth1: sending DISCOVER (xid 0x4e5a85d4), next in 3.27 seconds
Dec  2 19:49:53 PictureFrame daemon.info dhcpcd[3111]: eth1: offered 192.168.1.120 from 192.168.1.1
Dec  2 19:49:53 PictureFrame daemon.debug dhcpcd[3111]: eth1: sending REQUEST (xid 0x4e5a85d4), next in 3.91 seconds
Dec  2 19:49:53 PictureFrame daemon.info dhcpcd[3111]: eth1: acknowledged 192.168.1.120 from 192.168.1.1
Dec  2 19:49:53 PictureFrame daemon.info dhcpcd[3111]: eth1: using static address 192.168.1.120
Dec  2 19:49:53 PictureFrame daemon.debug dhcpcd[3111]: eth1: adding IP address 192.168.1.120/24
Dec  2 19:49:53 PictureFrame daemon.debug dhcpcd[3111]: eth1: deleting IP address 192.168.1.76/24 

Originally I didn't have this symptom on my hardware, but later was able to figure out how to modify my dhcpcd configuration file to make this symptom appear.

Symptom 2:

When reading /etc/frisbee/dhcpcd.conf, dhcpcd doesn't recognise that the current SSID matches the SSID named on the ssid line, so ignores the configuration information on the lines that follow it, including the static ip_address line. So the desired static address is never used at all, and dhcpcd broadcasts for a lease.

This is the symptom I first ran into when stating to investigate this issue. dlopeman didn't run into this symptom, since a later stanza in dlopeman's dhcpcd.conf file matched on the interface line, so used the static ip_address line in that stanza.


Here is what I think is happening:

The frisbee initialization script starts wpa_supplicant then calls wpa_cli to send the scan command to wpa_supplicant. Immediately after doing those things, it starts dhcpcd. It's my belief that wpa_supplicant hasn't finished its scan when dhcpcd starts, and so dhcpcd doesn't find a valid SSID to match against the entries in its configuration file.

This is not a problem when the user uses the frisbee configuration script to edit a profile and dhcpcd is restarted. That's because wpa_supplicant is already running at that time, and has finished its scan.

At least that is what I suspect is happening: I've not conducted any practical experiments to prove my theory.

But I do know that when I modified the frisbee initialization script to wait for wpa_supplicant to finish its scan, symptom #2 went away. And after I learned how to reproduce symptom #1, the modified script also caused that symptom to go away as well. This was on my system. dlopeman's system was not so happy.

Why didn't it work on dlopeman's system? I don't know, but I do know that I am using a less than ideal test to determine when the scan is complete. I am waiting for a status line that says "wpa_state=COMPLETED". Doing that may not be reliable, since I've found no documentation that guarantees that that exact line is always issued, nor have I dug into the source code to verify that that is the case. Perhaps different hardware and a different wireless driver will cause a different message to be issued. Perhaps not.

Or, it could well be that there were other issues with dlopeman's system. If so, my patch might work once the other issues, if any, are dealt with. dlopeman reported that after using my modified script and then removing it, "It changed my ordering: eth0 is now the wireless and eth1 is the hardwire!" That would clearly be a problem if the system was configured to use eth1 for wireless. Did my modification change the order? It seems unlikely, but I wouldn't want to rule it out without more testing.


As can be seen in my patch below, the code waits a maximum of 33 seconds for wpa_supplicant to complete its work. On my hardware the wait only lasts between two and three seconds.

Code: Select all

@@ -56,6 +58,15 @@
 
 	grep -q '^wireless_enabled=1' /etc/frisbee/frisbee.conf \
 	 && start-wpa&
+        #Wait for wpa scan to completes.  npierce, 20131215
+        COUNT=33
+        while [ $(( COUNT-- )) -gt 0 ] \
+         && ( ! wpa_cli -i $INTERFACE status 2> /dev/null \
+             | grep "wpa_state=COMPLETED" > /dev/null )
+        do
+         sleep 1
+        done
+        [ $COUNT -lt 0 ] && echo "frisbee: wpa scan failed to complete"
 fi
 start-dhcp&
 fi

Richard, have you seen either of these symptoms yourself? I am wondering if, like many timing issues, the problem happens with some hardware and not other hardware. It would be good if more folks could test this out.

Anyway, I hope this post has added light, not confusion to the discussion.

Norm

[rerwin]

npierce,
Thank you very much for investigating this problem and pointing me to the area to fix. I agree that the sequence of starting wpa_supplicant and then dhcpcd needs to be synchronous. I will have to look into ways to determine when wpa_supplicant is ready (whatever that means). But feel free to continue pursuing that, because it may be awhile.

Could you gather some evidence for me, so I can see how things happen in both successful and unsuccessful cases? I want to see what wpa_supplicant logs versus dhcpcd's log. I suppose you can simply run with and without your fix.

In both cases, please obtain a pdiag file, but use frisbee's diagnostic window to initiate pdiag. When it asks permission to include sensitive information, please allow it to do so. Then send me the files in a PM, so as to avoid publishing passwords or keys. (I have updated pdiag in lucid pup 5.2.8.6 to hide those values, but have not yet submitted the fix to the woof-CE group for other puppies.)
Richard

[npierce]

Richard,

The other day I rebooted into Precise 5.7.1 and started to capture the pdiag*.tar.gz files that you requested for both the unmodified frisbee from Precise 5.7.1 and the version with my patch. But I ran into some confusion.

You said you were specifically interested in the dhcpcd.log and wpa_supplicant.log files. The problem was that the pdiag*.tar.gz files that were created had no dhcpcd.log, and only an empty wpa_supplicant.log.

Wondering what I was doing wrong, I looked into the matter and found a couple of unexpected things:

1. wpa_supplicant.log

Using wpa_supplicant v0.7.3 (that comes with Precise 5.7.1), I am unable to redirect stdout to a file using the following line:

Code: Select all

setsid wpa_supplicant -B -d -Dwext -iwlan0 -c/etc/frisbee/wpa_supplicant.conf > /tmp/wpa_supplicant.log

(Surprisingly I can redirect it to another tty, just not a file.)

On my hardware, the above line is the command sent by the start-wpa function in /usr/local/frisbee/func after it evaluates this line:

Code: Select all

setsid wpa_supplicant -B -d -Dwext -i$INTERFACE -c$WPACFGFILE > /tmp/wpa_supplicant.log

To redirect output to a file I needed to use wpa_supplicant's -f option, like so:

Code: Select all

setsid wpa_supplicant -B -d -Dwext -iwlan0 -c/etc/frisbee/wpa_supplicant.conf -f/tmp/wpa_supplicant.log

So in order to generate wpa_supplicant.log, I made that change to the appropriate two lines in this block of /usr/local/frisbee/func:

Code: Select all

	if grep -q '^wpa_log_mode=1' /etc/frisbee/frisbee.conf ; then
		setsid wpa_supplicant -B -d -Dwext -i$INTERFACE -c$WPACFGFILE -f/tmp/wpa_supplicant.log
	else
		setsid wpa_supplicant -B -Dwext -i$INTERFACE -c$WPACFGFILE -f/tmp/wpa_supplicant.log
	fi

Does frisbee generate a wpa_supplicant.log for you without that change? If so, are you using a different version of wpa_supplicant?

2. dhcpcd.log

Clicking the Generate Diagnostic Data in frisbee doesn't actually generate a dhcpcd.log file. Apparently that file is only generated when the user chooses the Network Interfaces tab and then clicks View DHCP Log. If the log file has already been generated, it will be grabbed by clicking Generate Diagnostic Data, but the log is only as recent as the last time the user clicked View DHCP Log, which could've been at the time of the last blue moon. This can be a bit confusing.

So in order to generate a current dhcpcd.log for you, I will click View DHCP Log just prior to clicking Generate Diagnostic Data. Of course, since that log file is just stuff extracted from /var/log/messages, dhcpcd.log is a bit redundant, since /var/log/messages is also included in the tar ball, but I'll include it for convenience.


I'll be sending you four pdiag*.tar.gz files:

1. Generated after clicking Save Profile, with my patch
2. Generated after stopping and starting /etc/init.d/frisbee, with my patch
3. Generated after clicking Save Profile, no patch
4. Generated after stopping and starting /etc/init.d/frisbee, no patch


So that you know what steps were taken before the files were created, here is my general procedure:

1. Boot Precise 5.7.1 with: "puppy pfix=ram".
2. Overwrite /etc/init.d/frisbee with my patched version.
3. Edit /usr/local/frisbee/func to use -f option when starting wpa_supplicant, as described above.
4. Start frisbee configuration script.
5. Click Diagnostics button.
6. Tick Enable Debug Logging check box.
7. Close "Wireless Diagnostic Tools" window.
8. Select access point from table.
9. Click Connect button.
10. Enter key and key type.
11. Wait for connection to be established.
12. Click Manage Saved Networks button.
13. Enter static ip address, subnet mask, gateway, DNS server.
14. Click Save Profile button.
15. Wait for connection to be established.
16. Click OK button under "Profile updated" message.
17. Close "Manage Saved Network Profiles" window.
18. Click Network Interfaces tab.
19. Click View DHCP Log button.
20. Close "DHCP Log" window.
21. Click Wireless Networks tab.
22. Click Diagnostics button.
23. Click Generate Diagnostic Data button.
24. Enter name.
25. Click No to not exclude WPA files.
26. Click OK to close "Pdialog Diagnostic Information Capture" window.
27. Close "Wireless Diagnostic Tools" window.
28. Click Exit button.
29. Enter these two commands:

    Code: Select all

    /etc/init.d/frisbee stop
    /etc/init.d/frisbee start

30. Wait for connection to be established.
31. Start frisbee configuration script.
32. Click Network Interfaces tab.
33. Click View DHCP Log button.
34. Close "DHCP Log" window.
35. Click Wireless Networks tab.
36. Click Diagnostics button.
37. Click Generate Diagnostic Data button.
38. Enter name.
39. Click No to not exclude WPA files.
40. Click OK to close "Pdialog Diagnostic Information Capture" window.
41. Close "Wireless Diagnostic Tools" window.
42. Click Exit button.

Repeat above but omit overwriting /etc/init.d/frisbee.


Don't be confused by the fact that the connection will first be made to a leased ip address when I click the Connect button, even though I want to use a static address. That's not the bug we are discussing in this thread. (That's more of a design flaw than a bug: I am unable to manage a profile and configure it to use a static address until the profile has been created; and I am unable to create a profile except by clicking the Connect button which automatically connects using a leased address, if available. So the cart is before the horse.)

The problem discussed in this thread happens after I restart the frisbee initialization script. With the unmodified script, a leased address is used, as indicated in the fourth pdiag*.tar.gz by these lines in pdiag-201401092052/network/dhcpcd.log:

Code: Select all

Jan  9 20:50:42 puppypc30828 daemon.debug dhcpcd[25625]: wlan0: using hwaddr 00:13:02:3d:a2:fe
Jan  9 20:50:42 puppypc30828 daemon.debug dhcpcd[25625]: wlan0: executing `/lib/dhcpcd/dhcpcd-run-hooks', reason PREINIT
Jan  9 20:50:42 puppypc30828 daemon.debug dhcpcd[25625]: wlan0: executing `/lib/dhcpcd/dhcpcd-run-hooks', reason CARRIER
Jan  9 20:50:43 puppypc30828 daemon.info dhcpcd[25625]: wlan0: broadcasting for a lease
Jan  9 20:50:43 puppypc30828 daemon.debug dhcpcd[25625]: wlan0: sending DISCOVER (xid 0x329d5c44), next in 4.64 seconds
Jan  9 20:50:43 puppypc30828 daemon.info dhcpcd[25625]: eth0: waiting for carrier
Jan  9 20:50:43 puppypc30828 daemon.info dhcpcd[25625]: wlan0: offered 192.168.1.21 from 192.168.1.1
Jan  9 20:50:43 puppypc30828 daemon.debug dhcpcd[25625]: wlan0: sending REQUEST (xid 0x329d5c44), next in 4.56 seconds
Jan  9 20:50:43 puppypc30828 daemon.info dhcpcd[25625]: wlan0: acknowledged 192.168.1.21 from 192.168.1.1
Jan  9 20:50:43 puppypc30828 daemon.info dhcpcd[25625]: wlan0: checking for 192.168.1.21
Jan  9 20:50:43 puppypc30828 daemon.debug dhcpcd[25625]: wlan0: sending ARP probe (1 of 3), next in 1.19 seconds
Jan  9 20:50:44 puppypc30828 daemon.debug dhcpcd[25625]: wlan0: sending ARP probe (2 of 3), next in 1.68 seconds
Jan  9 20:50:45 puppypc30828 daemon.debug dhcpcd[25625]: wlan0: sending ARP probe (3 of 3), next in 2.00 seconds
Jan  9 20:50:47 puppypc30828 daemon.info dhcpcd[25625]: wlan0: leased 192.168.1.21 for 86400 seconds
Jan  9 20:50:47 puppypc30828 daemon.debug dhcpcd[25625]: wlan0: renew in 43200 seconds, rebind in 75600 seconds
Jan  9 20:50:47 puppypc30828 daemon.debug dhcpcd[25625]: wlan0: adding IP address 192.168.1.21/24
Jan  9 20:50:47 puppypc30828 daemon.debug dhcpcd[25625]: wlan0: adding route to 192.168.1.0/24
Jan  9 20:50:47 puppypc30828 daemon.debug dhcpcd[25625]: wlan0: adding default route via 192.168.1.1

With my patched version, the desired static address is used, as indicated in the second pdiag*.tar.gz by these lines in pdiag-201401091813/network/dhcpcd.log:

Code: Select all

Jan  9 18:11:56 puppypc3672 daemon.debug dhcpcd[26819]: wlan0: using hwaddr 00:13:02:3d:a2:fe
Jan  9 18:11:56 puppypc3672 daemon.debug dhcpcd[26819]: wlan0: executing `/lib/dhcpcd/dhcpcd-run-hooks', reason PREINIT
Jan  9 18:11:56 puppypc3672 daemon.debug dhcpcd[26819]: wlan0: executing `/lib/dhcpcd/dhcpcd-run-hooks', reason CARRIER
Jan  9 18:11:56 puppypc3672 daemon.info dhcpcd[26819]: wlan0: using static address 192.168.1.4
Jan  9 18:11:56 puppypc3672 daemon.debug dhcpcd[26819]: wlan0: adding IP address 192.168.1.4/24
Jan  9 18:11:56 puppypc3672 daemon.debug dhcpcd[26819]: wlan0: adding route to 192.168.1.0/24
Jan  9 18:11:56 puppypc3672 daemon.debug dhcpcd[26819]: wlan0: adding default route via 192.168.1.1

Do you have this problem when using a static IP address? If so, does my patch work for you?

OK, now I'll go send you a PM with the four files. I hope this is helpful to you.

Norm

[npierce]

I had a chance to look at this some more.

. . . I am using a less than ideal test to determine when the scan is complete. I am waiting for a status line that says "wpa_state=COMPLETED". Doing that may not be reliable, since I've found no documentation that guarantees that that exact line is always issued, nor have I dug into the source code to verify that that is the case. Perhaps different hardware and a different wireless driver will cause a different message to be issued. Perhaps not.

I feel better about this test now. While I'm not sure if it is bullet-proof, I did dig into the source code and verified that it is always issued when a connection is made, and the text does not vary for different drivers. (See the wpa_supplicant_state_txt() function defined in wpa_supplicant-0.7.3/wpa_supplicant/wpa_supplicant.c in the source code, which can be found at http://archive.ubuntu.com/ubuntu/pool/m ... rig.tar.gz).

I previously misunderstood the meaning of the "COMPLETED" status. Since that status appears after the scan is completed, I assumed that it indicated that the scan was completed. But since it really means that the association and authentication (if any) of the connection has been completed, the "COMPLETED" status will never appear unless a connection has been made. So in the case where no connection has been completed, like on the first boot of a new Puppy, my test waited the full 33 seconds for a "COMPLETED" status that never came. This means that my code added an unnecessary delay to the frisbee configuration script the first time it was run.

So I've modified my code to also stop waiting if it sees a status line that says "wpa_state=INACTIVE", which is the status after the scan is complete when no connection has been made.

Both the "COMPLETED" and the "INACTIVE" state are documented in the source code:

Code: Select all

        /**
         * WPA_INACTIVE - Inactive state (wpa_supplicant disabled)
         *
         * This state is entered if there are no enabled networks in the
         * configuration. wpa_supplicant is not trying to associate with a new
         * network and external interaction (e.g., ctrl_iface call to add or
         * enable a network) is needed to start association.
         */
        WPA_INACTIVE,

Code: Select all

        /**
         * WPA_COMPLETED - All authentication completed
         *
         * This state is entered when the full authentication process is
         * completed. In case of WPA2, this happens when the 4-Way Handshake is
         * successfully completed. With WPA, this state is entered after the
         * Group Key Handshake; with IEEE 802.1X (non-WPA) connection is
         * completed after dynamic keys are received (or if not used, after
         * the EAP authentication has been completed). With static WEP keys and
         * plaintext connections, this state is entered when an association
         * has been completed.
         *
         * This state indicates that the supplicant has completed its
         * processing for the association phase and that data connection is
         * fully configured.
         */
        WPA_COMPLETED

Also, I have removed the ampersand from the call to the start-wpa function so that it is run in the foreground and the script will wait for the function to complete. It makes no sense to try to talk to wpa_supplicant until it has been started, and experimentation has show that the first attempt to do so was simply failing to connect to wpa_supplicant. Now no attempt is made until after it has started.


I will attach my revised version to my earlier (2013-Dec-17) post, where it will replace my initial version. I welcome feedback from anyone volunteering to try this out. While I am most interested to know if it solves the problem with static addressing, I also need to know if it causes any new problems for static or DHCP addressing. And if it causes no problems, feel free to report that as well -- I need to see some reports before recommending that this fix be included in new Puppies. Thanks.

[HoerMirAuf]

Thanks a lot for your fix!

I solved my static IP Problem on Precise-5.7.1

[npierce]

You're welcome. Thanks for trying out the fix. It is always good to know that my fixes actually work for people other than me before I recommend that they be added to future Puppies. So feedback like yours is very helpful.

[ahoppin]

This patch is working nicely for me on frugal Retro Precise 5.7.1, EEE PC 901. Well done!

If you're using Frisbee and Retro Precise 5.7.1, you may want to also view this thread:

http://murga-linux.com/puppy/viewtopic.php?p=838802