Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Sat 30 Aug 2014, 12:52
All times are UTC - 4
 Forum index » House Training » Users ( For the regulars )
DHCP overriding my STATIC IP on wireless using Frisbee
Moderators: Flash, Ian, JohnMurga
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
Page 2 of 3 Posts_count   Goto page: Previous 1, 2, 3 Next
Author Message
dlopeman

Joined: 04 Dec 2013
Posts: 17

PostPosted: Wed 18 Dec 2013, 18:01    Post_subject:  

OH COOL! Lemme give that a whirl and let you know. I had almost given up and was just gonna mess with it some other day.
Back to top
View user's profile Send_private_message 
dlopeman

Joined: 04 Dec 2013
Posts: 17

PostPosted: Wed 18 Dec 2013, 18:11    Post_subject:  

Yeah... so like 25 years of LINUX experience and I still screw up!! I made a backup of /etc/frisbee and NOT /etc/init.d/frisbee!! Doh! I'm committed to you update!!! Smile

Rebooting now...
Back to top
View user's profile Send_private_message 
dlopeman

Joined: 04 Dec 2013
Posts: 17

PostPosted: Wed 18 Dec 2013, 18:36    Post_subject:  

So that did not work and now I cannot get the Wireless card to even start. I tried removing /etc/init.d/frisbee and rebooting.

Once I get it back on the network I'll post the messages log snippet.
Back to top
View user's profile Send_private_message 
dlopeman

Joined: 04 Dec 2013
Posts: 17

PostPosted: Wed 18 Dec 2013, 19:11    Post_subject:  

OK... I got it back using DHCP again... here the ODD part! It changed my ordering: eth0 is now the wireless and eth1 is the hardwire! Weird.

The other thing is that the wireless card was just flat out turned OFF. I had to pull up the GUI and unclick and reclick the Enable Wireless. It's been that way now for the last 4 reboots... me no likey... it sees the card, though:
Code:

Dec 18 19:03:58 PictureFrame user.info kernel: [   14.545262] ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, 1.2.2kmq
Dec 18 19:03:58 PictureFrame user.info kernel: [   14.545269] ipw2200: Copyright(c) 2003-2006 Intel Corporation



And then it just does this a WHOLE bunch, taking it a while to finally bring up XWindows.

Code:

Dec 18 19:04:06 PictureFrame daemon.info dhcpcd[3241]: version 5.6.4 starting
Dec 18 19:04:06 PictureFrame daemon.warn dhcpcd[3241]: all: configured as a router, not a host
Dec 18 19:04:06 PictureFrame daemon.debug dhcpcd[3241]: forking to background
Dec 18 19:04:06 PictureFrame daemon.info dhcpcd[3241]: forked to background, child pid 3245
Dec 18 19:04:06 PictureFrame daemon.debug dhcpcd[3245]: eth1: using hwaddr 00:11:43:5d:9d:d1
Dec 18 19:04:06 PictureFrame daemon.debug dhcpcd[3245]: eth1: executing `/lib/dhcpcd/dhcpcd-run-hooks', reason PREINIT
Dec 18 19:04:06 PictureFrame daemon.debug dhcpcd[3245]: eth1: executing `/lib/dhcpcd/dhcpcd-run-hooks', reason NOCARRIER
Dec 18 19:04:06 PictureFrame auth.info sshd[3269]: Server listening on 0.0.0.0 port 22.
Dec 18 19:04:09 PictureFrame daemon.info dhcpcd[3245]: eth1: waiting for carrier
Dec 18 19:07:25 PictureFrame daemon.info dhcpcd[5352]: sending commands to master dhcpcd process
Dec 18 19:07:25 PictureFrame daemon.info dhcpcd[3245]: control command: dhcpcd -k eth0
Dec 18 19:07:25 PictureFrame daemon.info dhcpcd[5355]: sending signal 1 to pid 3245
Dec 18 19:07:25 PictureFrame daemon.info dhcpcd[3245]: received SIGHUP, releasing
Dec 18 19:07:25 PictureFrame daemon.info dhcpcd[3245]: eth1: removing interface
Dec 18 19:07:25 PictureFrame daemon.debug dhcpcd[3245]: eth1: executing `/lib/dhcpcd/dhcpcd-run-hooks', reason STOP
Dec 18 19:07:25 PictureFrame daemon.info dhcpcd[5355]: waiting for pid 3245 to exit
Dec 18 19:07:25 PictureFrame daemon.info dhcpcd[5378]: version 5.6.4 starting
Dec 18 19:07:25 PictureFrame daemon.warn dhcpcd[5378]: all: configured as a router, not a host
Dec 18 19:07:25 PictureFrame daemon.debug dhcpcd[5378]: forking to background


Now that I got DHCP back... I'm going to try rebooting again to at least see if I can make sure the wireless stays ON.
Back to top
View user's profile Send_private_message 
dlopeman

Joined: 04 Dec 2013
Posts: 17

PostPosted: Wed 18 Dec 2013, 20:31    Post_subject:  

wow... that doesn't even work now. Welp! Any changes you wanna make to that boot file? Smile

and... does anyone have or now where the default frisbee boot file is? Or how to reset everthing?

and don't think I'm not grateful for your time... I am... it's not always easy supporting remote stuff you know nothing about! Smile
Back to top
View user's profile Send_private_message 
npierce

Joined: 28 Dec 2009
Posts: 858

PostPosted: Thu 19 Dec 2013, 08:57    Post_subject:  

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

First, here is how to find the original file:

dlopeman wrote:
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?


dlopeman wrote:
. . . 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.


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

What my modification does (or is supposed to do Smile )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:
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:
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.
Back to top
View user's profile Send_private_message 
dlopeman

Joined: 04 Dec 2013
Posts: 17

PostPosted: Thu 19 Dec 2013, 10:48    Post_subject:  

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 Smile ] 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!
Back to top
View user's profile Send_private_message 
dlopeman

Joined: 04 Dec 2013
Posts: 17

PostPosted: Thu 19 Dec 2013, 10:49    Post_subject:  

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...
Back to top
View user's profile Send_private_message 
dlopeman

Joined: 04 Dec 2013
Posts: 17

PostPosted: Thu 19 Dec 2013, 11:03    Post_subject:  

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

http://www.murga-linux.com/puppy/viewtopic.php?t=64472&start=255
frisbee-1.2-alpha-20130905.pet
maybe I can try installing that pet?
Back to top
View user's profile Send_private_message 
npierce

Joined: 28 Dec 2009
Posts: 858

PostPosted: Thu 19 Dec 2013, 11:47    Post_subject:  

Code:
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:
grep frisbee /root/.packages/woof-installed-packages

You can then find that same package in the repository at: http://distro.ibiblio.org/puppylinux/pet_packages-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:
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
Back to top
View user's profile Send_private_message 
npierce

Joined: 28 Dec 2009
Posts: 858

PostPosted: Thu 19 Dec 2013, 11:58    Post_subject:  

dlopeman wrote:
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.
Back to top
View user's profile Send_private_message 
npierce

Joined: 28 Dec 2009
Posts: 858

PostPosted: Sat 28 Dec 2013, 11:20    Post_subject:  

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.
Back to top
View user's profile Send_private_message 
rerwin


Joined: 24 Aug 2005
Posts: 1513
Location: Maine, USA

PostPosted: Thu 02 Jan 2014, 12:01    Post_subject: Responsibility for maintenance of frisbee-1.x  

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
Back to top
View user's profile Send_private_message 
npierce

Joined: 28 Dec 2009
Posts: 858

PostPosted: Sat 04 Jan 2014, 09:49    Post_subject:  

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.

rerwin wrote:
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:
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:
@@ -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
Back to top
View user's profile Send_private_message 
rerwin


Joined: 24 Aug 2005
Posts: 1513
Location: Maine, USA

PostPosted: Mon 06 Jan 2014, 22:23    Post_subject:  

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
Back to top
View user's profile Send_private_message 
Display_posts:   Sort by:   
Page 2 of 3 Posts_count   Goto page: Previous 1, 2, 3 Next
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
 Forum index » House Training » Users ( For the regulars )
Jump to:  

Rules_post_cannot
Rules_reply_cannot
Rules_edit_cannot
Rules_delete_cannot
Rules_vote_cannot
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1228s ][ Queries: 12 (0.0045s) ][ GZIP on ]