Since some time, those crappy Fritz!Box devices do not support WDS anymore, but rather a proprietary solution created by AVM. Now what happens if you have devices in another room that need/want wired access (like TVs, Playstations) or if you want to extend the range of your network? Buying another Fritz!Box is not very cost efficient – What I did was to buy a cheap TP-Link TL-WR841N (can be bought for 18 euros) and installed OpenWRT on it. Here’s how I configured it to act as a WiFi bridge.
Basic overview: You configure OpenWRT into station mode (that is, as a WiFi client) and use relayd to relay between the WiFi network and your local network. You also need igmpproxy to proxy multicast packages between those networks, other UPnP stuff won’t work.
I did this on the recent Barrier Braker RC2. It should work on older versions as well, but I cannot promise it (I did not get igmpproxy to work in Attitude Adjustment, but that was probably my fault).
Note: I don’t know if it works with IPv6, I only use IPv4.
You might want to re-start (or start) services after the steps, or reboot the router afterwards.
Configuring WiFi connection to the FRITZ!Box
Add to: /etc/config/network
config interface 'wwan' option proto 'dhcp'
(you can use any other name you want instead of wwan, and a static IP. This will be your uplink to the Fritz!Box)
Replace wifi-iface in: /etc/config/wireless:
config wifi-iface option device 'radio0' option mode 'sta' option ssid 'FRITZ!Box 7270' option encryption 'psk2' option key 'PASSWORD' option network 'wwan'
(adjust values as needed for your network)
Setting up the pseudo-bridge
wwan to the list of networks in the
lan zone in the firewall. Then add a forward rule for the lan network (not sure if needed). Afterwards, configure a new
stabridge network and disable the built-in DHCP server.
Diff for /etc/config/firewall
@@ -10,2 +10,3 @@ config zone list network 'lan' + list network 'wwan' option input 'ACCEPT' @@ -28,2 +29,7 @@ config forwarding +# Not sure if actually needed +config forwarding + option src 'lan' + option dest 'lan' + config rule
Add to /etc/config/network
config interface 'stabridge' option proto 'relay' option network 'lan wwan' option ipaddr '192.168.178.26'
(Replace 192.168.178.26 with the IP address your OpenWRT router was given by the Fritz!Box on wlan0)
Also make sure to ignore dhcp on the lan interface, as the DHCP server of the FRITZ!Box will be used:
Diff for /etc/config/dhcp
@@ -24,2 +24,3 @@ config dhcp 'lan' option ra 'server' + option ignore '1'
Proxying multicast packages
For proxying multicast packages, we need to install igmpproxy and configure it:
Add to: /etc/config/firewall
# Configuration for igmpproxy config rule option src lan option proto igmp option target ACCEPT config rule option src lan option proto udp option dest lan option target ACCEPT
(OpenWRT wiki gives a different 2nd rule now, but this is the one I currently use)
Replace /etc/config/igmpproxy with:
config igmpproxy option quickleave 1 config phyint option network wwan option direction upstream list altnet 192.168.178.0/24 config phyint option network lan option direction downstream list altnet 192.168.178.0/24
(Assuming Fritz!Box uses the
Don’t forget to enable the igmpproxy script:
# /etc/init.d/igmpproxy enable
Optional: Repeat the WiFi signal
If you want to repeat your WiFi signal, all you need to do is add a second
wifi-iface to your
config wifi-iface option device 'radio0' option mode 'ap' option network 'lan' option encryption 'psk2+tkip+ccmp' option key 'PASSWORD' option ssid 'YourForwardingSSID'
If I was connected via WiFi to the OpenWRT AP and switch to the FRITZ!Box AP, I cannot connect to the OpenWRT router for some time.
The igmpproxy tool writes to the log about changing routes.
I’ll try to get the FRITZ!Box replaced by something that runs OpenWRT as well, and then use OpenWRT’s WDS support for repeating; because the FRITZ!Box 7270v2 is largely crap – loading a page in its web frontend takes 5 (idle) – 20 seconds (1 download), and it’s WiFi speed is limited to about 20 Mbit/s in WiFi-n mode (2.4 GHz (or 5 GHz, does not matter), 40 MHz channel). It seems the 7270 has a really slow CPU.
Today, I decided to set my X230 back to UEFI-only boot, after having changed that for a bios upgrade recently (to fix a resume bug). I then choose to save the settings and received several error messages telling me that the system ran out of resources (probably storage space for UEFI variables).
I rebooted my machine, and saw no logo appearing. Just something like an underscore on a text console. The system appears to boot normally otherwise, and once the i915 module is loaded (and we’re switching away from UEFI’s Graphical Output Protocol [GOP]) the screen works correctly.
So it seems the GOP broke.
What should I do next?
Today I made an important change to the python-apt code: It is now native Python 3 code (but also works under Python 2). The previous versions all run 2to3 during the build process to create a Python 3 version. This is no longer needed, as the code is now identical.
As part of that change, python-apt now only supports Python 2.7, Python 3.3, and newer. I’m using some features only present in 3.3 like Python2 unicode literal syntax in order to keep the code simple.
Here’s how I did it:
I took the Python 2 code and ran 2to3 -f print -x future on it. This turned every print statement in a call to the print function. I then went ahead and added a “from __future__ import print_function” to the top of each module. This was the first commit.
For the second commit, I ran 2to3 -p -x future to convert the remaining stuff to Python 3, and then undid some changes (like unicode literals) and fixed the rest of the changes to work under both Python 2 and 3. Sometimes I added a top-level code like:
if sys.version_info_major >= 3: unicode = str
So I could use unicode in the code for the Python 2 cases.
I used various backported modules like io and stuff only available in Python 2.7, so dropped support for Python 2.6.
I released python-apt 0.9. This completely removes support for the old API from the code base (it was disabled for the entirety of 0.8 in Debian, and in Ubuntu since saucy). Highlights:
- Cleanup: Complete removal of old-api support code
- Bug fix: Various coverty bug fixes by Michael Vogt
- Bug fix: Correctly handles multi-arch dependencies in apt.debfile, so packagekit and gdebi can now install local multi-arch packages correctly
- Bug fix: A segmentation fault has been fixed. When releasing the value of the policy attribute of an apt_pkg.Cache object, its destructor deleted the pkgPolicy, but that was managed by a CacheFile from APT, causing it to be deleted twice.
- Bug fix: Tests do not depend on the contents of /tmp anymore
- Bug fix: All examples and old tests have been updated to the current python-apt API
- Feature: Paths can now be specified using ‘bytes’ objects instead of ‘str’ in Python 3.
- Ubuntu-specific: Meta-data for Ubuntu 14.04 — although with a typo (‘thar’ instead of ‘tahr’), but that is fixed in git
This week, a few hours after Lenovo announced the X240, I bought an X230. Normally, the X230 model I bought comes with a Core i5-3320M CPU, 4GB RAM, 500GB HDD. My model was a special set including a second 4GB RAM stick and a 128 GB mSATA Plextor SSD. It came without Windows; and the ThinkVantage button is black instead of blue and has no label.
I put a fresh installation of unstable on it and tweaked it to save more power when on battery (enabled RC6++, and enabled autosuspend and other powertop suggestions with a script in /etc/pm/power.d); and configured hdparm.conf to put my hard disk into standby after 5 seconds (it’s only used for big data anyway, so most of the time it is unused). It now consumes 5W in idle with minimum brightness, and 8-10W with brightness 13 of 15. Consumption when surfing is 10 – 15 watts. Booting from grub to gdm is fast, I did not measure it, but it probably took about 5 seconds.
The IPS screen looks really good. Much much much better than the screen in my 2010 Edge 15 (I reviewed that one in 2010). It seems a bit more glossy than that one, but still matte. Keyboard is good as well. The touch pad is crap however. All hardware seems to work.
Comparison to the X240 for others who think about buying one of them: The X240 is lighter and thinner (it’s an Ultrabook) and has an optional FullHD 12.5 inch screen. It also offers a much larger touchpad and palm rest. But compared to the X230, the X240 lacks many things: No dedicated buttons for the trackpoint (you need to use the click-pad), it’s limited at 8GB RAM, uses a slower low-voltage Haswell CPU, and it uses the new M.2 connector (probably supporting only the shortest cards) instead of mini-PCIe, so it’s not really possible to add an additional SSD currently; as M.2 SSDs do not seem to be available yet. I also do not know whether the X240 offers ThinkLight or LEDs for hard drive activity and similar.
The script apt-show-versions is developed by another Debian Developer called Christoph Martin in Perl. Recently, it turned out that apt-show-versions is too slow for some users; so I decided to rewrite his program using APT’s C++ API. I expect this to be part of a future APT release, rendering the original apt-show-versions obsolete.
The rewrite is sadly not 100% backwards compatible to the original version; as some option names had to be renamed due to our command-line parser not supporting option names like -nh, and some other options were dropped because they are hard to support (like –status-file and –lists-dir) with our command-line parsing. I also decided not to keep the the -p and -r options, but use the standard APT command-line conventions insteads.
For now, it also cannot show you the distribution names you have specified in your sources.list file, but will always display codenames instead; if available. I hope to fix this in Jessie by extending APT’s cache format a bit.
On the performance side, this program now takes about 0.09s compared to the 1.40 seconds needed by apt-show-versions. The times are taken with all data in caches.
The current version can be found in a git repository, a link to gitweb is:
Please also note that support for –allversions is not 100% implemented yet, but it should work for most uses.
Now, go testing and report back!
Writing recursive descent parsers is easy, especially in Python (just like everything is easy in Python). But Python defines a low limit on the number of recursive calls that can be made, and recursive descent parsers are prone to exceed this limit.
We should thus write our parser without real recursion. Fortunately, Python offers us a way out: Coroutines, introduced in Python 2.5 as per PEP 342. Using coroutines and a simple trampoline function, we can convert every mutually recursive set of functions into a set of coroutines that require constant stack space.
Let’s say our parser looks like this (tokens being an iterator over characters):
def parse(tokens): token = next(tokens) if token.isalnum(): return token elif token == '(': result = parse(tokens) if next(tokens) != ')': raise ... return result else: raise ...
We now apply the following transformations:
return X => yield (X)
parse() => (yield parse())
That is, we yield the value we want to return, and we yield a generator whenever we want to call (using a yield expression). Our rewritten parser reads:
def parse(tokens): token = next(tokens) if token.isalnum(): yield token elif token == '(': result = yield parse(tokens) if next(tokens) != ')': raise ... return result else: raise ...
We obviously cannot call that generator like the previous function. What we need to introduce is a trampoline. A trampoline is a function that manages that yielded generators, calls them, and passes their result upwards. It looks like this:
def trampoline(generator): """Execute the generator using trampolining. """ queue = collections.deque() def schedule(coroutine, stack=(), value=None): def resume(): if 0: global prev now = stack_len(stack) if now < prev: print("Length", now) prev = -1 elif prev != -1: prev = now result = coroutine.send(value) if isinstance(result, types.GeneratorType): # Normal call schedule(result, (coroutine, stack)) elif isinstance(result, Tail): # Tail call (if you want to) schedule(result.value, stack) elif stack: # Return to parent schedule(stack, stack, result) else: # Final Return return result queue.append(resume) schedule(generator) result = None while queue: func = queue.popleft() result = func() return result
This function is based on the code in PEP 342, the difference being that
- we do not correctly propagate exceptions through the stack, but directly unwind to the caller of the parser (we don’t handle exceptions inside our parser generators anyway)
- the code actually compiles (code in PEP used ‘value = coroutine.send(value)’ which does not work)
- the code returns a value (code in PEP was missing a return in schedule)
- we don’t use a class, and allow only one function to be scheduled at once (yes, we could get rid of the queue)
- we allow tail calls [where Tail = namedtuple(“Tail”, ["result"])] to save some more memory.
For a more generic version of that, you might want to re-add exception passing, but the exceptions will then have long tracebacks, so I’m not sure how well they will work if you have deep recursion.
Now, the advantage of that is that our parser now requires constant stack space, because the actual real stack is stored in the heap using tuples which are used like singly-linked lists in scheme here. So, the only recursion limit is available memory.
A disadvantage of that transformation is that the code will run slightly slower for small inputs that could be handled using a normally recursive parser.