Well....progress in the 'reconnect' department. Running just 'swifer reconnect' or the service file now results in a permanent swifer process running...which I _think_ is a good thing.
But...now it won't connect to the open network...only to the WPA hotspot on my phone
Can you check the output from the following while in that condition:
cat /proc/$(pgrep swifer | sed 's/\n//')/cmdline`
18:18:22 $ sudo swifer reconnect 18:18:33 $ cat /proc/$(pgrep swifer | sed 's/\n//')/cmdline swiferreconnect18:18:36 $ cat /proc/$(pgrep swifer | sed 's/\n//')/cmdline swiferreconnect18:18:38 $ cat /proc/$(pgrep swifer | sed 's/\n//')/cmdline swiferre18:18:47 $ cat /proc/$(pgrep swifer | sed 's/\n//')/cmdline swiferre18:18:50 $
Not sure if it's a terminal glitch or if the cmdline is actually getting cutoff....
Thats one big piece of good news, and one piece of odd news.
It's not being cutoff - two letters of any of the parameters are sufficient to unambiguously specify them (any, auto, reconnect), so when swifer spawns another instance of itself it just uses two letters "re".
I'm not sure why there are no spaces or newlines though, that seems odd. It'd probably be cleaner to get the PID (from pgrep) then cat the appropriate file: eg cat /proc/####/cmdline.
In any case, this is one good step in the right direction. Two other relevant tests would be to try `swifer any reconnect` to see if it will then connect to the open network (when the phone's is not available). If it does, then I'd check whether your open network has actually been added to /etc/swifer.conf. It should get added to that file if/when you use `swifer add` and connect to it.
Last edited by Trilby (2013-03-25 01:30:32)
Just in case you might find it useful or interesting, Dr. Freitag has been messing around with bash scripts to do some of these same things:
http://true-random.com/homepage/project … index.html
I've used that with some success although it is picky about the output of iwconfig (and yes, I'm aware that iwconfig is being deprecated). I've found it doesn't work with some of my adapters.
To your earlier pondering about how to test for connectivity vice signal strength, he fires off connection attempts to determine if the network is up. He does two DNS queries and two GETs to verify that he has connectivity to the Internet and not just connected to the AP or a dead-end portal. Not saying that is elegant or effective but that's his solution.
There are also options for automatically getting past splash pages and captive portals on free wifi connections:
http://www.linux-magazine.es/issue/72/0 … rlLM72.pdf
I haven't quite figured out how to hook all that stuff together yet....
Thanks, but that's all basically like my idea to spawn a ping processes. It would work - but it'd be an ugly resource hog.
Sorry...didn't have time to test the past couple of days. Still can't get it connected to an unsecured network (different one this time). Relevant journalctl entries starting after running 'sudo swifer'. No output from command line. dhcpcd runs for a short time and then times out. Updated to current git. Netcfg hooks up fine to the same network. I made sure the wpa_supplicant instance from netcfg was killed and there were no stale entries in /var/lib/dhcpcd prior to running swifer.
-- Logs begin at Wed 2013-01-16 21:02:13 PST, end at Thu 2013-03-28 20:18:02 PDT. -- Mar 28 20:16:53 scotty sudo: pam_unix(sudo:session): session closed for user root Mar 28 20:16:53 scotty dhcpcd: version 5.6.7 starting Mar 28 20:16:53 scotty dhcpcd: wlan0: configured as a router, not a host Mar 28 20:16:53 scotty dhcpcd: wlan0: waiting for carrier Mar 28 20:17:23 scotty dhcpcd: timed out
Hmm, that's odd.
On an open network, swifer just does the equivalent of the following commands:
ip link set wlan0 up iwconfig wlan0 essid "youressid" dhcpcd wlan0
Do these manual steps work to connect to that network?
Hey...not sure if you noticed yet, but I added a comment to the github issues page about the failure to start swifer exit code (2).
And to answer your (very old) previous post...yes manual setup on an open network works just fine here. I'll test swifer again as soon as I can get it running!
Again, I apologize for the very delayed responses on this!
D'oh! Um, ok...got the right interface name now. However, it still won't connect to this open network using 'auto'.
~ $ sudo swifer auto reconnect ~ $ echo $? 0 ~ $ cat /etc/swifer.conf INTERFACE = wlp2s0 COBPUBLIC ~ $ iw dev wlp2s0 info Interface wlp2s0 ifindex 2 wdev 0x1 addr c4:85:08:08:6d:6c ssid COBPUBLIC type managed wiphy 0 channel 4 (2427 MHz), width: 20 MHz (no HT), center1: 2427 MHz ~ $ pgrep dh ~ $ sudo dhcpcd dhcpcd: version 6.0.5 starting dhcpcd: wlp2s0: soliciting an IPv6 router dhcpcd: wlp2s0: rebinding lease of 172.17.5.123 dhcpcd: wlp2s0: leased 172.17.5.123 for 7200 seconds dhcpcd: wlp2s0: adding host route to 172.17.5.123 via 127.0.0.1 dhcpcd: wlp2s0: adding route to 172.17.4.0/23 dhcpcd: wlp2s0: adding default route via 172.17.5.1 dhcpcd: forked to background, child pid 30641 ~ $ sudo pkill dhcpcd ~ $ sudo ip link set dev wlp2s0 down ~ $ sudo swifer auto [swifer] no suitable networks found.
It appears that dhcpcd isn't getting started for some reason with the 'auto' setting.
'Any' seems to work with this network, however. If I select 'add' and the network already exists in /etc/swifer.conf, it will be added again.
Let me know what else I can try out.
I suspect one of two things is at issue here, and both are fixed in the last git push;
1) It looks like your /etc/swifer.conf does not have a [NETWORKS] line. If one modifies that file before it is created by swifer, they'd have to add the [NETWORKS] line at the bottom themselves. This is a foolishly fragile way to do things though, so I've included a swifer.conf in the package that will be installed. It has some comments that should help. This was poor design on my part resulting from the fact that swifer.conf wasn't originally meant to be user-edited, but as some options were added (DHCP and INTERFACE settings) it came to be edited by users.
2) PEBKAC at my keyboard and chair: there was a typo in POST_UP in the code that read swifer.conf.
I suspect the second may have caused your original problems with using PRE/POST_UP, then the exit 2 problems came from INTERFACE defaulting to wlan0, now most recently #1 lead to your manually edited swifer.conf lacking a [NETWORKS] line.
Sorry this took so long to give a saner design, but as I haven't used the PRE/POST up settings myself, I haven't had occasion to run into those issues - and so on the flip side, many thanks for reporting the problems.
I hope the latest push fixes things up, but let me know either way.
Last edited by Trilby (2013-09-12 15:50:56)
I updated and adjusted my /etc/swifer.conf and now 'swifer add', 'swifer auto' and 'swifer' work fine. However, when I run 'swifer auto reconnect' either by itself or via the .service file, dhcpd appears to start and stop every few seconds (looking at htop), making the connection unusable. Still haven't testing the PRE/POST up settings yet...wanted to get regular connections sorted first
Last edited by firecat53 (2013-09-12 19:22:28)
Thanks, I tried it out and saw the same thing. It was due to a typo in a format string for reading from /proc/net/wireless to get the current status. It should be fixed with the very last push.
That works now. Another issue: I have two wifi networks in our house - firecat4153 and firecat4153a. If I'm connected to firecat4153a with 'swifer auto reconnect' and I want to switch to firecat4153 with 'swifer add' (firecat4153 hasn't been added to /usr/share/swifer yet), it doesn't ask for the passphrase, try to connect or add the new network to /usr/share/swifer or /etc/swifer.conf . Even if I kill 'swifer auto reconnect' and 'dhcpcd', it still won't add the new network.
So if I'm connected at home, suspend my laptop, go to the library, and then resume my laptop and want to connect to their wifi (assuming I haven't before), do I need to kill both 'swifer auto reconnect' and 'dhcpcd' and then re-run 'swifer add', or can I just run 'swifer add' and have it add and switch to the new network, then go back to doing its 'swifer auto reconnect' thing without any further intervention?
edit: It seems to be something to do with the similar name, because it will prompt for the passphrase if I try to connect to another network...just not that one. Which brings up another minor issue: I was just testing out connecting to neighbor's wifi and because I don't know the passphrase, swifer would just sit there for a long time and never time out. Shouldn't it time out if you make a mistake and either exit or let you try again?
Last edited by firecat53 (2013-09-12 20:45:30)
You're exactly right about the similar names. I have what is usually a good habit of using strncmp() rather than strcmp(), however I neglected the downside that it will give a false positive for a match when the known network is the same as the new network just with a postfix.
I just changed this to a strcmp function which should work properly.
1. This update seems to have broken the 'auto' function. 'swifer add' and 'swifer' still work, but 'auto' or 'auto reconnect' will not establish the connection.
2. If 'swifer' is run and an already added network is selected, it will delete the existing profile from /usr/share/swifer.
3. Is 'swifer add' supposed to be able to work (i.e. to add a new network in a new location) when 'swifer auto reconnect' is already running?
4. Seems to fail when there is a space in the ssid (wouldn't connect to 'kcls.org Wireless')
Last edited by firecat53 (2013-09-13 03:05:31)