It has been nearly six years with a netbook and five since I last wrote about
wifi roaming from the bus to stay on irc without a costly celluar link during the daily commute. Since then, some readers have asked me to share my refinements to the method in a followup post. So here it is.
The software
On the server:
- openssh-server
- screen
- irssi
On the client:
- screen
- wpasupplicant
- isc-dhcp-client
- openssh-client
- openbox
- sudo & gksudo (optional)
- urxvt
- wavemon (optional)
- three shell scripts (provided below)
Putting it together: on the client
Make sure if you have a wireless manager installed (such as NetworkManager) it is configured to skip your wireless interface, disabled entirely, or if possible, removed. Set up
/etc/wpa_supplicant/wpa_supplicant.conf and
/etc/network/interfaces for roaming, as per the instructions in
/usr/share/doc/wpasupplicant/README.modes.gz. Don t forget to add yourself to the
netdev group if you are not in it already.
In
/etc/wpa_supplicant/wpa_supplicant.conf, list common names of open networks. Normally the catch-all network that associates with any essid, i.e. the first stanza below, works well. However, occasionally the strongest signal is neither one of the common networks nor an easily accessible network (e.g. web portals), so having a list of common open networks helps to quickly select from among those instead. The more you travel, the more of these will discover and add. Just use
reconfigure from
wpa_cli to reload your edited list each time you add a new one.
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
network=
key_mgmt=NONE
network=
ssid="default"
key_mgmt=NONE
network=
ssid="linksys"
key_mgmt=NONE
...
Since you ll be using
ssh repeatedly to connect and it has to be fast, make sure your server is set up to accept your key and use
ssh-add so that you only have to enter your ssh key password once.
You can tweak
isc-dhcp-client to make connections faster. In
/etc/dhcp/dhclient.conf, use:
backoff-cutoff 1;
initial-interval 1;
Here are a few scripts I wrote to facilitate quick roaming from one open AP to another and reconnect to
irssi running in
screen, to break a connection and try the next one, and to recover from occasional lockups (more about that later).
~/bin/screen_reconnect
This is a script to reconnect continuously via ssh to a screen session:
#!/bin/sh
reset
while ! ssh -t 10.9.8.7 'screen -UDr' 2>/dev/null ; do echo -n "." ; sleep .1 ; done
Just substitute the IP of your own server here. Using an IP instead of domain name makes the connection faster because a DNS lookup is not required.
~/bin/wifi_reassociate
This script closes any open
ssh sessions and informs
wpa_supplicant to attempt to connect again.
#/bin/sh
/sbin/wpa_cli rea
killall ssh >/dev/null 2>&1
~/bin/wifi_killall
This optional, somewhat ugly script addresses an issue I hope you never have. On my ASUS Eee PC 1001PX, occasionally scanning stops. When this happens, and I have never figured out why, apparently ACPI events are blocked. At this point wifi becomes unusable and ACPI sleep is inhibited. By trial and error I found that if you bring down the interface, kill all network-related processes, and bring it up again, ACPI events are unblocked and wifi is usable once more (and any pending request to sleep will finally happen). The script requires
sudo, and to use the
openbox key binding,
gksudo.
#/bin/sh
sudo ifdown wlan0
# in case any of these are hung
sudo killall dhclient3
sudo killall wpa_cli
sudo killall wpa_action
sudo killall wpa_supplicant
# in case any of these are *really* hung
sleep 1
sudo killall -9 dhclient3
sudo killall -9 wpa_cli
sudo killall -9 wpa_action
sudo killall -9 wpa_supplicant
sudo dhclient -r
sudo ifup wlan0
Openbox
Since certain actions need to be performed repeatedly and quickly, it is useful to have hotkeys bound in your window manager to the scripts. In
~/.config/openbox/rc.xml, key bindings for
<alt>-r to reassociate and
<alt>-d to disconnect a hung connection would look like:
<keyboard>
<!-- My keybindings -->
<keybind key="A-R">
<action name="Execute">
<execute>/home/synrg/bin/wifi_reassociate</execute>
</action>
</keybind>
<keybind key="A-D">
<action name="Execute">
<execute>gksudo /home/synrg/bin/wifi_killall</execute>
</action>
</keybind>
</keyboard>
Putting it together: on the server
There is very little to do here. Just start
screen, and start
irssi in screen. Running
screen on the client as well as the server means you should either bind the
screen meta keys to a different key sequence on each system, or else learn to press meta twice to pass through meta to the server
screen as needed. I use the latter approach. Alternatively, you could use a tabbed terminal on the client, or separate terminals per client process instead of
screen. This is a matter of personal taste.
Ready to roam
Here is a typical setup for roaming on the bus:
In a terminal (I use
urxvt), first
ssh-add, then start
screen with these three processes running in separate virtual terminals:
- /sbin/wpa_cli
- screen_reconnect
- wavemon (optional)
March of the dots
Most of the commute, just enjoy watching the dots march by, waiting for a new connection. If you estimate a connection is unusable, press
<alt>-r to reassociate immediately, giving the next network a chance. If the connection is already firmly established, this might not work on the first try. If the dots don t resume immediately, wait a bit and press it again. This might take a few tries.
Changing selected networks on the fly
Use
wpa_cli when you need to do some fine-tuning of network selections on the fly. While normally you can just watch the march of the dots until a connection is acquired, sometimes you can improve your chances of connecting to a good network by manually controlling the selected candidate networks here.
For example, by watching the speed of the bus relative to known good APs, you can predict which networks are more likely to succeed. Rather than connect to any arbitrary network, you might select a specific one by id, and then later when it goes out of range, revert to the original configuration, e.g.
> select_network 5
...
> reconfigure
You can use tab-completion in
wpa_cli to type these commands quickly or else just abbreviate the commands.
Another common scenario is when you pass through a business area with many captive portal hotspots. These rarely make good choices because they either require a password not known to you or else you can t click through I agree in time before the bus moves on. In this case, you might just disable the catch-all stanza and let the common open network stanzas you listed ( default , linksys , etc.) do the work:
> disable_network 1
Become a type ahead wizard
While running, a continuous stream of periods fills the screen, which provides you with a highly visible cue that no available APs are in range. When the movement stops, you know a connection is being attempted.
While waiting to connect, you can type ahead any comments you want to make in the current irssi window (taking care to remember which one you are in!) While having periods interspersed in what you type may be disorienting at first, you get used to it.
There is a point when a connection is first established and ssh is accepting input, but anything you type can no longer be seen while you re typing. Depending on whether the connection was completely successful or not, what you type now may or may not finally be sent. For best results, only type ahead before the dots stop moving.
Eventually you can become skilled enough at this to type ahead a comment in one channel, switch channels with
/win # and continue typing ahead in the new channel, all buffered until the next few seconds (or even fraction of a second) of connection time.
Fine-tune antenna direction with wavemon
When the bus has come to a standstill, you may find
wavemon useful to pull in a weak signal. Because
wavemon has continuously updated signal level and link quality bars, you can use it to fine-tune the antenna position. Just turn your laptop until the bars are at their maximum.
Captive portals
I have not figured out how to do any automation for this, so it really is a crapshoot, as it is likely the bus has moved on by the time you ve managed to manually navigate the login through a captive portal. But in rush hour, you may have the luxury of time to connect to these as you pass them. I have recently learned about the
CoovaFX Firefox plugin which automates logins to captive portals. I m going to give it a try to see if it helps. Update: I can t recommend this plugin, as it is not compatible with Iceweasel >= 23.0. Also, the standard it is based on,
WISPr, appears to have an uncertain future. That, coupled with the fact that the plugin appears to not be open source means I m still looking for alternatives.
Summary
If all of this sounds a bit nuts to you, well, it probably is. But after half a decade enjoying free access to irc from the bus, it all seems perfectly natural to me! If you try this method and like it, please let me know in the comments. Likewise, if you have any improvements to the process or scripts, please share them!
Debian LTS - impressions and thoughts from my first month involvement
About LTS - we want feedback and more companies supporting it financially
Squeeze LTS, and even more Debian LTS, is a pretty young project, started in May 2014, so it's still a bit unclear where exactly we'll be going 
One purpose of this post is to spread some information about the initiative and invite you to tell us what you think about it or what your needs are.
LTS stands for "Long Term Support" and the goal of the project is to extend the security support for Squeeze (aka the current oldstable distribution) by two years. If it weren't for Squeeze LTS, the security support for it would have been stopped in May 2014 (=one year after the release of the current stable distribution), which for many is a too short timespan after it's release in February 2011. It's an experiment, we hope that there will be a similar Wheezy LTS initiative in future, but the future is unwritten and things will change based on our experiences and your needs.
If you have feedback on the direction LTS should take (or anything else LTS related), please comment on the lts mailing list. For immediate feedback there is also the #debian-lts IRC channel.
Another quite pragmatic way to express your needs is to read more about how to financially contribute to LTS and then doing exactly that - and unsurprisingly we are prioritizing the updates based on the needs expressed from our paying customers.
My LTS work in July 2014
So, "somehow" I started working for money on Debian LTS in July, which means there were 10h I got paid, and probably another 10h where I did LTS related work unpaid. I used those to release four updates for squeeze-lts (linux-2.6, file, munin and reportbug) fixing 22 CVEs in total.
The unpaid work was mostly spent on unsuccessfully working on security updates and on adding support for LTS to the security team tracker, which I improved but couldn't fully address and which I haven't properly shared / committed yet... but at least I have a local instance of the tracker now, which - for LTS - is more useful than the .debian.org one. Hopefully during DebConf14 we'll manage to fix the tracker for good.
Without success I've looked at libtasn1-3 (where the first fixes applied easily but then the code had changed too much from what was in squeeze compared to the available patches that I gave up) and libxstream-java (which is at version 1.3, while patches exist for upstream branches 1.4 and 2.x, but those need newer java to build and maybe if I'll spend two more hours I'll can get it build and then I'll have to find a useful test case, which looked quite difficult on a brief look.. so maybe I give up on libxstream-java too.... OTOH, if you use it and can do some testing, please do tell me.
Working on all these updates turned out to be more team work than expected and a lot of work involving code (which I did expect), and often code which I'd normally not look at... similarily with tools: one has to deal with tools one doesnt like, eg I had to install cdbs... 
And then there is another thing: as already mentioned, the people working paid hours for this, are prioritizing their work based on customer requests. So we did two updates (python-scipy and file), which are not fixed in wheezy yet. I think this is unfortunate and while I could probably prepare the wheezy DSA for file, I don't really want to join the Security Team... or maybe I want/should join the Security Team and be a seldomly active member (eg fixing file in wheezy now....)
A note related to this: out of those 37 uploads done until today, 16 were done by those two people being paid, while the other 21 uploads were done by 10 volunteers (or at least not paid by Debian LTS). It will be interesting to see how this statistics evolves over time.
Last, but not least, there is also this can of worms (aka: the discussion) about paying people to work on Debian... I do agree it's work we didnt find volunteers for and I also see how the (financial side of the) setup is done outside of Debian (and well too, btw!), but... then we also use Debian ressources like buildds, the archive itself and official mailing lists. Also I'm currently biased in this discussion, as I directly (and happily) profit from it. I'm mentioning this here, because I believe it's important we discuss this and come to both good and practical conclusions. FWIW, we have also discussed this on the list, feel free to search the archives for it.
To bring this post to an end: for those attending DebConf14 (directly or thanks to some ninjas), there will be an event about LTS in Portland, though I'm not sure yet what I will have to talk about what hasn't been already covered here 
I've somehow managed to break firefox:
I recently bought a new Lenovo X1 Carbon. It is the new second-generation, type 20A7 laptop, based on 
After quite a few hours of work, I finally switched completely to DNSSEC. Both client-side in my notebook, and in my personal tincho.org domain.
The client-side was pretty easy, although something broke in 
Wow. 3G delta. I haven t booted this laptop for a while I think I m finally ready to make the move from gnome2 to gnome3. There are bits that still annoy me, but I think it s off to a good start. Upgrading perl from 5.10 to 5.14.
There are several friends and family I want to be able to call with free software. The only way I could make it accessible to them was to burn 
WebRTC has been in the most recent stable releases of 
Users have 
Problem description: One of my customers had a problem with their 
TIP 1: Visiting $JENKINS_SERVER/label/$label/ provides a list of slaves that provide that given $label (as well as list of projects that use $label in their configuration), like:
This is what we can use to gradually upgrade from the old Iceweasel version to the new one by keeping a given set of slaves at the old Iceweasel version while we re upgrading other nodes to the new Iceweasel version (same for the selenium-server version which we want to also control). We can include the version number of the Iceweasel and selenium-server packages inside the labels we announce through the swarm slaves, with something like:
Whereas the development selenium job can point to the slaves providing Iceweasel v24, so it will be executed on slave selenium-client1 here:
This setup allowed us to work on the selenium Ruby tests while not conflicting with any production build pipeline. By the time I m writing about this setup we ve already finished the migration to support Iceweasel v24 and the infrastructure is ready for further Iceweasel and selenium-server upgrades.
So it may sound normal to receive compressed response for CSS/JS file
from Apache2 but what I faced is completely different behavior, here I
saw not just body of response but also header are getting compressed
and send to browser and browser was unable to interpret the response
there by leading page rendered without CSS and JS.
That was long story short, so let me explain in detail the case and
what I found out.
I have 
So you can see no response header in the above image but there is a
response and below how is response content visible on firebug.
Still weird part was when using wget/curl directly to get the CSS I
was getting correct reply and the file, which is puzzling.
So I went ahead opened the CSS url directly using browser and saved
the resulting file. When I used file command on it, output
suggested the saved file in gzip compressed!. I went ahead
uncompressed it and opened the file and inside it I found response
header and the response body! So what just happened? Did apache some
how manage to compress entire respone not just response body?
The more puzzling question was why did it work when I was using
mod_proxy_uwsgi and failed when I switched to mod_uwsgi. I had no
clue at this point why this behavior is coming up.
So response is still gziped but this time only response body was
gziped and Content-Encoding field was set properly which makes browser
to properly uncompress the response body and use it.
So it seems like there is a difference between mod_uwsgi and
mod_proxy_uwsgi implementation. mod_uwsgi was sending the response
along with response headers which was compressed by mod_deflate there
by rendering browser helpless to interpret the response. But
mod_proxy_uwsgi seems to be only sending the response content without
response body and this content was later compressed by mod_deflate and
proper response headers were set by apache before sending it to
browser.
So now whose fault is this? Is it the bug in mod_uwsgi or, mod_deflate
not being able to exclude response headers from compression? I've no
clue! If you have a clue and you want to share it with me, please
consider writing to me over email. My details are available in
Wanna-build, wanna-build, which packages spent most time on armel buildd's since beginning of 2013? 
[update 2] And, of course, after finishing the update process... I got a new version of Iceweasel. Restarted it, and everything is back to normal :-
).
Missing
