For CAT5/6 use T568B wiring

This is also one that I constantly keep forgetting: What is the best way of wiring my UTP/STP CAT5 / CAT5E / CAT6 cables. Apparently I was always using the T568B scheme, but every time I attach a new connector or socket I search the Internet, trying to find which is better T568A or T568B :).

From what I understand from my searches, it doesn't matter which one you choose, as long as you use it consistently. Some sites indicate that T568A is more suitable for homes and T568B for offices, but I have not found a solid reason for that. Furthermore, as this MeOnTech on YouTube shows, (almost?) all factory punched cables are T568B. (Which can also perfectly work in a T568A socket ;))

OpenWRT on Cisco Linksys E2000 and back to stock firmware

The goal of my effort was to create two separate WLAN SSID's that linked to two different VLAN's on the Linksys E2000. I did not get it working at that time and reverted back to the original firmware. This article describes my painful (took me a lot of time to find things out) journey.

Background

I replaced my Linksys / Cisco E2000 by a TP-Link TL-WA901ND, because I wasn't really satisfied with the coverage of the Linksys / Cisco E2000 and I wanted to have a separate SSID for guest Wifi access in my house. The TP-Link supports multiple SSID's and VLANning out of the box.



For devices that still are in their warranty period, I prefer to stay with stock firmware as long as it still does what I'd like it to do (hmmm, the clock is way off and I still can't find the NTP settings...).

I still have a purpose for the E2000, as I would like to have some better coverage in the attic. The stock firmware however does not support VLAN's. I also had problems configuring it so that it behaved as 'just' an Access Point. I was able to configure it as an access point, but that immediately disabled access to the interface. If I wanted to change the config, I had to reset it and configure it all over again. I never found out what caused it. That's why I wanted to play around with OpenWRT

 

 'Flashing' the Cisco Linksys E2000 with OpenWRT

To install OpenWRT on the E2000, I, of course, read the OpenWRT wiki page on the Linksys E2000. And the page on the WRT320N v2.0, as it was based on the same hardware according to the wiki. And the page on flashing using the TFTP server in the bootloader. But nothing worked.

As a last resort, I tried to upload the firmware using the standard 'Update Firmware' functionality of the stock Cisco firmware as is described on the OpenWRT Linksys WRT320N/E2000 page (huh, another page?). Much to my surprise, this worked. I uploaded openwrt-e2000_v1-squashfs.bin. Unfortunately, I didn't not create this blogposting right away, but I think I got it from here.

After that, you can telnet to 192.168.1.1, set a root password and replace telnet with SSH, see first login. You can use the normal reset procedure (press & hold the reset button for ~5 s) to revert the config to the start state (if the management interface becomes unreachable for instance).

 

Configuring OpenWRT

Multiple SSIDs and 802.11n are not supported by the b43 driver

The Linksys E2000 V1 is powered by a Broadcom BCM4716 System on a Chip. According to Linux Wireless drivers (b43) page, it is a BCMA SoC. This leaves you with two drivers for the E2000, either the default b43 driver or the brcmsmac driver. I wasn't able to install the brcmsmac driver, using opkg on Chaos Calmer (Bleeding Edge, r42687), due to problems in dependencies (because the packages are updated frequently and expect a newer kernel). I haven't put much effort in that, as I haven't seen any positive results when someone got it installed (see here and here). The problems with the b43 driver are:

1. I wasn't able to get 802.11n working, only 802.11g. That's of course quite a dealbreaker.

2. I wasn't able to get multiple SSIDs in the air. If I configured multiple SSIDs, either the second one in the config file showed up, or no SSID showed up at all (probably depending on the OpenWRT version)

 

Bricking and Unbricking

When I was initially done with installing and configuring the trunk version. I wanted to install a stable version, as I wasn't planning on flashing the device daily to patch any security problems.

I downloaded Attitude Adjustment, checked the integrity and flashed it, using sysupgrade:

wget http://downloads.openwrt.org/attitude_adjustment/12.09/brcm47xx/generic/openwrt-brcm47xx-squashfs.trx

sysupgrade -v /tmp/openwrt-brcm47xx-squashfs.trx

Unfortunately, after that flash, the device wasn't reachable anymore over ethernet. I tried to reset it and even performed the 30-30-30 reset which should only work on dd-wrt (?). That didn't help. Also, trying to flash the firmware using tftp still did not work.

The only way to unbrick it, was to open the E2000, solder wires to the connections for the serial port and connect that to a TTL to USB cable to get console access. A lot of information for this (such as the pin layout for serial port) is in this thread on the dd-wrt forum.

As this was my first attempt to solder something to a PCB and it worked, I guess it doesn't require much precision (as you can see). I used an Ada Fruit USB to Serial TTL cable (PL2303TA chipset).

With that console access, I found out that my ethernet ports were not functioning at all. I wasn't able to find out what was the cause of this. The WLAN was functioning however (but since I reset it, the default config was to disable WLAN). I could turn on the WLAN and, using Linux on my laptop, use netcat to send the trunk version of OpenWRT to the E2000. Once that succeeded, I could successfully flash the trunk version and it worked again!

I am still wondering what I could've done if I had no wireless, but only the console. I found all kinds of methods, but they basically used z-, y-, or xmodem or kermit to transfer files using the console. But the default OpenWRT image does not have these tools installed (at least, I didn't find them).

The console also allowed me to see why the tftp flashing wasn't working. Apparently, if I timed it right (it was kinda precise, it only worked for me when I had the cable inserted in the port 2 (coincidence?) and started the Windows TFTP client at the same time as a I turned the device on)  the E2000 received the firmware, but it rejected it. I tried it with a couple of versions, including the default Linksys firmware, but also trailed and non-trailed builds of OpenWRT: I couldn't get it to work.

Conclusion

Finally, I reflashed the original firmware. There was a new version, that at least got rid of the bug that I was experiencing which caused me to not be able to login anymore after I had configured it.


I followed the steps on the OpenWRT wiki page on 'uninstalling': I downloaded the latest firmware from the Linksys site and cut of the header as indicated:

dd bs=32 skip=1 if=original.bin of=original.trx

I used sysupgrade to flash the E2000 to the stock firmware.

Adding non-indexed folders on Windows shares to a Windows Library

I've traded in my Windows Server 2012 domain for a FreeNAS server. One of the many advantages is that you can disable Offline Files completely. Unfortunately, you need Offline Files for being able to add shares as folders in your Windows 7/8 libraries. If you just add a shared folder to your library, you will get the error:

This network location can't be included because it's not indexed.

Apparently, you can't choose to do the indexing on your Windows 7/8 system and that's that.
It took me some time to come up with a good solution, but the guys and girls at My Digital Life have put up a workaround. See the lower half of this page.
Here are the steps:

1. Create a dummy folder with any name. You can use the same name with the network folder name.
2. Add and include the dummy folder into the Library.
3. Delete the dummy folder (it won’t be removed from the Library).
4. Open an elevated Command Prompt window (Run as Administrator), and use the following command to make a symbolic link which links the dummy folder to the network location:
   
   mklink /d "\full\path\to\dummy\folder" "\\full\path\to\remote\folder"
   
   Change the "\full\path\to\dummy\folder" and "\\full\path\to\remote\folder" to actual full path to the folders.
5. Visit the Library, and the contents from the non-indexed remote location linked via symbolic link is now appearing inside the Library.

If you want to remove the link, because you want to update it, for instance, just use rmdir "link"

Bootstrap of CMake fails on (n)curses

When I try to bootstrap CMake (regardless of parameters for as far as I can see) it fails with the following error:

CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
CURSES_CURSES_H_PATH
   used as include directory in directory /usr/src/cmake-2.8.6/Source/CursesDialog/form
   used as include directory in directory /usr/src/cmake-2.8.6/Source

Although it can find libcurses...

-- Looking for wsyncup in /usr/lib/libcurses.so
-- Looking for wsyncup in /usr/lib/libcurses.so - found

The problem seems to lie in the fact that my curses.h header file is in /usr/include/ncursesw instead of in /usr/include. It would seem that CMake needs curses to build and cannot use ncurses... Strangely, I've compiled ncurses conform Linux From Scratch and which places the headers in that subfolder (ncursesw). Compiling non-wide versions didn't work either, as the headers are placed in /usr/include/ncurses.  CMake is part of Beyond Linux From Scratch, but I don't see any workarounds there, so I'm puzzled why BLFS doesn't encounter the same problems...

I've come up with a workaround that works for my situation, but I don't know if this is a good solution or will cause problems in the future...

sed -i "s#FIND_FILE(CURSES_HAVE_CURSES_H curses.h )#FIND_FILE(CURSES_HAVE_CURSES_H curses.h HINTS /usr/include/ncursesw )#" Modules/FindCurses.cmake
sed -i "s#FIND_PATH(CURSES_CURSES_H_PATH curses.h )#FIND_PATH(CURSES_CURSES_H_PATH curses.h HINTS /usr/include/ncursesw )#" Modules/FindCurses.cmake

I've hinted the FindCurses script to look for curses.h in the /usr/include/ncursesw folder.

Test "samba3.blackbox.smbclient_s3.crypt" in samba 3.6.0 fails

I got the following two errors from one of the tests in the Samba 3.6.0 test suite:

UNEXPECTED(failure): samba3.blackbox.smbclient_s3.crypt (s3dc).writing into a read-only directory fails
REASON: _StringException: _StringException: CLI_FORCE_INTERACTIVE=yes /usr/src/samba-3.6.0/source3/bin/smbclient -U% //LOCALS3DC2/ro-tmp -I 127.0.0.2 --configfile=/usr/src/samba-3.6.0/source3/st/client/client.conf -e

UNEXPECTED(failure): samba3.blackbox.smbclient_s3.crypt (s3dc).Reading a owner-only file fails
REASON: _StringException: _StringException: CLI_FORCE_INTERACTIVE=yes /usr/src/samba-3.6.0/source3/bin/smbclient -U% //LOCALS3DC2/ro-tmp -I 127.0.0.2 --configfile=/usr/src/samba-3.6.0/source3/st/client/client.conf -e

The solution to these errors is to run the test suite as a non-root user (which is always a good idea). Unfortunately, since I use automated scripts to compile, test and configure packages (wrote them myself), it is difficult to switch users half way (you need root for installing). My solution was to su to a non-root user just for these tests and let him own the entire source tree, so that there are no access problems.

Error in testing binutils-2.21

When compiling a new version of binutils (version 2.21), I encountered the following error during the 'make check':

Running /usr/src/binutils-2.21/ld/testsuite/ld-plugin/plugin.exp ...
FAIL: plugin claimfile lost symbol

I couldn't find much about the cause of this error, but I did find a patch that fixed this error for me:

http://sourceware.org/ml/binutils-cvs/2010-11/msg00048.html

PPP+PAM Windows VPN Error 734: The PPP link control protocol was terminated

Today I was battling with "Error 734: The PPP link control protocol was terminated" that the Windows 7 VPN client was giving me. Although the fixes suggested in this forum post will probable help most people, it didn't help me (as usual).

Apparently, in my case, this was caused by having the "login" setting in your /etc/ppp/options.xl2tpd and using an improper PAM-configuration.

From what I understand is that when you enter the correct password that is in chap.secrets, it will pass that authentication step, but it could fail on PAM authentication (as was the case with my configuration). So removing the "login" option will take care of this error, but will also disable PAM-support.

Currently I'm working on how to avoid having passwords in the chap.secrets file (but only in LDAP that is accessible via PAM). Filling in "" as the secret does not seem to work... According to an Oracle (?) article CHAP cannot be used in combination with PAM, since the password isn't sent accross the link, the server cannot create the MD5 hash that is requested by the client (based on a kind of challenge). But if LDAP could generate that hash... (Yeah, I know, LDAP is a database, not an authentication server)