My thoughts on Slackware, life and everything

Month: March 2011 (Page 1 of 2)

Wireless Ethernet Bridge

This weekend, I setup a Wireless Ethernet Bridge.

What the heck, I hear you say! I’d better explain why I did this, and what it actually means.

I have a wireless network in the house that extends to a large part of the rooms. Unfortunately we have thick walls and ceilings with a lot of steel-reenforced concrete, and this causes less-than-ideal wireless reception in parts of the house. The thick concrete walls do not invite drilling a lot of holes for CAT5 cables. I had to think of something else that minimized the drilling of holes and still gave me a network that covers all of the house.

I have been using a WRT54GL (its selling point being that it can easily be flashed with alternative Linux based firmware) until now. This gave me a wireless speed of 54 Mbit/sec (802.11g) maximum. I have flashed this router with an alternative firmware, tomato, which really helped me getting my Internet router stable and feature-rich while at the same time I was able to raise the transmission power a bit… but not enough.

Linksys WRT54GL

So what I did was to buy a new wireless dual-band router with 802.11n speeds (300 Mbit/sec) which gives the existing wireless LAN a boost. This new router had to be capable of running tomato firmware too (because I am fond of it) and the dual-band gave me a way to leverage the old WRT54GL without killing the speeds of the larger wireless LAN: a dual-band router basically has two wireless access points built-in. I found the Cisco/Linksys E3000EW at a very interesting price (it is being followed up by a new device, the E4200). It also has an USB port (for connecting a hard drive or a printer) and I found that the tomatousb firmware (a successful mod of the tomato firmware) fully supports this device.

Cisco/Linksys E3000-EW

The E3000EW was switched on and two minutes later, the poor bugger was running tomato firmware! A firmware upgrade through HTTP upload using the standard Linksys firmware worked flawlessly.

Now the first task was to copy the configuration of the old WRT54GL to the new E3000EW. That was not too hard. AlsoI setup the two internal access points with two different ESSIDS of course. Then I quickly swapped the two (after “cloning” the WAN MAC address so that I would not have to go through my ISP’s provisioning setup again) and I had freed the WRT54GL for re-configuration into a Wireless Ethernet Bridge.

What was my plan? To position the WRT54GL in the house, nearby the area where wireless signals were weak because of the steel and concrete. Its position would be where I do have a good wireless connectivity. From that point on, I would run CAT5 cable from the WRT54GL to the computers that needed to be connected. This would mean, much less cable and much less drilling.

Actually, that was the final plan, which I implemented. Originally I wanted to create a distributed wireless network using WDS, which is a technique (supported by the tomato firmware) to connect multiple wireless access points. However, when I started reading about these techniques, it turned out that WDS effectively cuts your wireless network speeds in half with every “hop” that you create in your network. And I was not prepared for lower speeds… even though the advantage would be that I did not have to run new CAT5 cables. Access points with WDS still accept client connections, so all I would have to do was put the second AP in a location where it gave good coverage to the computers that suffered from problematic wireless reception.

The thing with Wireless Ethernet Bridging (WET) is this: the second Access Point, deployed to connect to the “master” and create the bridge, dedicates its wireless link to that bridged connection. It will no longer accept connections from wireless clients. It means that the computers need to connect to it using conventional cable!

It was a matter of weighing the pros and the cons. I decided on creating the bridge and using cables, because that would keep the maximum network speed acceptible.

So the old WRT54GL was reconfigured (using a network cable of course, you can not do this wirelessly). And it works surprisingly well! I am writing this article while my laptop is connected to this device using a cable and the traffic is bridged across the air. So, whoopee!

There are a few gotcha’s that I ran into, before I finally found out what it takes to successfully create a wireless bridge.

  • The “master” router (the E3000EW in this case) needs to be configured as a Wireless Access Point – that is the default, so I could leave that one alone.
  • The secondary router (the WRT54GL) needs to be configured, not as a gateway but as a router (in the tomato’s Advanced > Routing menu) or else your traffic is not going to reach the “master” router at the other end of the bridge.
  • The wireless security must be set to “WPA Personal”, with AES encryption (in the tomato’s Basic > Network menu). I had left this setting to “WPA/WPA2 Personal” at first, using AES for ecryption (this was what I used when the WRT54GL was still my Internet router), and it would refuse to connect to the wireless master. If you look more closely to the dropdown menu for the security settings, you’ll see that the tomato warns that WPA is the only accepted choice…
  • The WRT54GL can function as a wireless bridge without having an IP address assigned to it. However, you lose the ability to make a HTTP connection to the administrative interface – and someday that will prove to be very inconvenient. So I gave the router an unused IP address from my LAN address range.

Remember, when you setup a bridge, you are extending your network transparently. A network bridge passes network packets back and forth without dividing the network in two segments. Computers in the LAN will be unaware of the bridged connection – it does not show up in a traceroute. There is another solution for my problem that I have not gone deeper into, and that is to setup the WRT54GL as a “wireless client”. This creates a new network segment though… which requires that you run a DHCP server on the WRT54GL for the wired client computers that you connect to the device.

And yet another option is to install the “dd-wrt” firmware and configure the WRT54GL as a Wireless Repeater which allows you to connect your computers wirelessly to the device… but dd-wrt is not nearly as userfriendly as tomato. Pick your choice.

This is the network diagram I ended up with (courtesy of oldspeak where I also obtained the final piece of the puzzle):

Wireless Ethernet Bridge

And what about powerline / homeplug, you ask?

I have considered that, and sometime ago, when my wireless conneciton problems became aggravating, I even wanted to buy a set of 200 Mbit Devolo mini adapters. They would give me 100 Mbit effective network speeds, but I still would have to buy a second wireless access point if I wanted to extend my wireless LAN, or else I would have had to use conventional cable. That made me decide to pick the geeky solution.

Eric

Slackware has the answer to all

… perhaps even to the Ultimate Question of Life, the Universe, and Everything.

Just kidding of course. From today’s ChangeLog.txt for Slackware “current“:

?Sun Mar 27 08:28:47 UTC 2011
There have been quite a few changes so we will have one more release
candidate:  Slackware 13.37 RC 3.14159265358979323846264338327950288419716.
Very close now!  But we'll likely hold out for 2.6.37.6.

Well there you have it. The answer you all have been looking for, all that time! 😉

The list of changes is again pretty long. It shows that “declaring a Release Candidate” has a good reason. People ask from time to time, why these release candidates? Thy are nothing similar to what the bigger distros use in their progression towards a stable release. Things like “feature freeze” and “show stopper bugs” are used in Slackware development too, but you won’t see those mentioned in the ChangeLog. They are not relating one-to-one to any of the Release Candidates. Instead, the first call of a Slackware Release Candidate causes many people to try and install Slackware-current for the first time in a development cycle. Not many people are anxious to use a development release, especially since all of us keep repeating “when you are running -current, we expect that you know what you are doing, and that you are able to fix a suddenly broken system by yourself (with the help of the community)“. The Release Candidates are a sign of stability for those people. And we need all of you to help with the final stage of development! All these new people testing the pre-release result in many bugs found and forgotten features requested, and this causes a surge in the stabilization process which makes Slackware the rock solid distro we all know.

Multilib fans (slackware64), pay attention!

A new kernel again (2.6.37.5) and as the ChangeLog.txt says, there will likely be one more before the final release of Slackware 13.37. This means, you get a recompiled multilib version of glibc from me – and there will be another recompile if we see yet another kernel update.

Grab the updated multilib glibc packages from the usual locations:

Enjoy! Eric

New libreoffice, vlc packages for your Slackware

Yummy food for your hungry Slackware boxen!

* VLC 1.1.8 available

Another minor release in the 1.1 series, version 1.1.8 saw the light yesterday. Bugfixes and updates for the translations are its main features, but several small enhancements were made to the codec modules.

New encoders for dirac video (now using the schroedinger implementation) and webm /vp8 were added but to be honest, I have not looked at those since I rarely encode audio or video. Feedback welcome of course!

Noteworthy is the fact that VideoLAN celebrated its 10th birthday of going open source this february – the software was initially developed as a french student project under a closed-source license. Hilarious promotional video there… typical french humour?

Get the Slackware packages here (built on Slackware 13.1, will work on later versions too):

The “US restrictions” are ludricous crap, but there you go… otherwise I would not be able to host the packages on the slackware.com server. Of course, mp3 and aac decoding is not a problem at all.

And for you KDE 4.6 users, remember having this problem with the “Media > Open” file browser dialog box taking 30 seconds to appear, that issue has been resolved. The fix was applied on the KDE side (it was gone with KDE 4.6.1) but I thought I’d mention it here regardless because it was a nuisance. See https://bugs.kde.org/show_bug.cgi?id=260719 for a nice discussion between KDE and VLC developers. Interesting to read on https://bugs.launchpad.net/kubuntu-ppa/+bug/708527 is, that while we do not have this bug anymore in Slackware’s KDE 4.6.1 (well, my own KDE 4.6.1 for Slackware 13.37 to be precise), it appears that Kubuntu’s KDE 4.6.1 still suffers from it…

* LibreOffice 3.3.2 … wow that was fast!

The LibreOffice development really shows the power of collaboration. Little over a month after their previous “micro release” 3.3.1, here we have 3.3.2 already. It shows plainly that LibreOffice is diverging fast from its origin OpenOffice.org. How is that possible? Well, the most obvious reason is the growth in numbers of developers. What was impossible while SUN and later Oracle held the reigns, is now showing its worth: people are contributing code, and with more people starting to dig at the deeper levels of code, this momentum of development will only accelerate.

Specific highlights for the 3.3.2 release are the code cleanups: german-only comments have been replaced and no longer used code has been removed. If the schedule is not slipping we’ll see the big release 3.4.0 in May. This is supposedly the release that is going to make the large step away from OpenOffice.org.

I created some Slackware packages for you (built on Slackware 13.1, works on Slackware 13.37 too). Using the new LibreOffice menu icons instead of the old OpenOffice seagull logos, its looking prettier even! I added a dictionary to the italian language pack, but other than that I did not diverge from the way I built the previous 3.3.1 packages.

One word about the dictionaries (which I included for en-GB, en-US, es, fr, it, nl language packs): they are installed as “shared dictionaries” i.e. they will show up in your extension manager as locked and unchangeable. You can still install your own dictionary on top of that, if you find one that is more advanced or better suited to your work. This personal version will be installed into your ~/.ooo3 user directory and will have preference over the shared version.

Get packages here:

Enjoy!  And tell me if you like these packages (or if you see room for improvement).

Eric

Slackware 13.37 Release Candidate 2

We have progressed to the second release candidate for the upcoming release of Slackware stable (version 13.37 no less). There is probably not going to be a lot of other updates before final release; the TODO list should be quite short now. The only one to know for sure is Pat Volkerding… I am only speculating of course.

Noticable is that the Slackware -current’s kernel has again been updated – this time to 2.6.37.4. And again, as part of a Slackware kernel update, the glibc packages were rebuilt against the new kernel’s header files.

If you have enhanced your 64bit Slackware-current with multilib capabilities, you can upgrade to the new multilib glibc packages that I compiled for you.

Get the glibc packages for your multilib Slackware64-current at http://slackware.com/~alien/multilib/current/ as usual (or visit my mirror at http://taper.alienbase.nl/mirrors/people/alien/multilib/current/).

I also updated the content of the slackware64-compat32 directory. In there you will find a copy of all the packages which are created by running the massconvert32.sh script. Install these packages on top of your multilib Slackware64-current in order to make your computer fully support 32bit applications (or use “upgradepkg –install-new” if you already installed a previous set of these packages).

No idea what I have been talking about?

If you want to know about 64bit Slackware Linux (which is a pure 64bit OS) and how to “upgrade” to a multilib system (supporting 32bit as well as 64bit applications), you should definitelty read http://alien.slackbook.org/dokuwiki/doku.php?id=slackware:multilib

Eric

KDE 4.6.1 add-on for Slackware 13.37 RC1

Yes folks… we have a release candidate for the next stable version of Slackware. Its version mumber is going to be “13.37” as could be expected… it was too tempting not to be used, after we had “12.34567890” for a little while during an earlier development cycle…

And to accompany this event, I have also made available a new set of KDE packages. It’s KDE 4.6.1 and the packages have been built on Slackware 13.37-RC1.

KDE Software Compilation 4.6.1 sources were released a few days ago. It is the first “stabilization update” in the 4.6 series which will see steady updates until July 2011. I had to wait with my upload & announcement until the 13.37-RC1 appeared; there were some last-minute changes to the raptor/rasqal/redland packages in slackware-current because soprano would no longer compile. Be sure to upgrade to Slackware 13.37-RC1 or newer before using these KDE packages!

KDE 4.6.1 for Slackware (32bit as well as 64bit releases) can be found in my ktown repository already, http://alien.slackbook.org/ktown/4.6.1/ and soon on its mirrors (http://taper.alienbase.nl/mirrors/alien-kde/4.6.1/ and http://repo.ukdw.ac.id/alien-kde/4.6.1/ both of which have rsync access as well).

You are encouraged to (re-)visit my older post, because most of what I said for KDE 4.6.0 – about the upgrade from Slackware’s own KDE 4.5.5 – still holds true. Of course, the packages come with a detailed README which shows step-by-step what you have to do in order to upgrade to KDE 4.6.1.

Enjoy! Eric

« Older posts

© 2024 Alien Pastures

Theme by Anders NorenUp ↑