Hardware

My previous post about my Huawei B593 4G-router has become quite popular, so I thought to tell more about my setup.

What I'd really need is a network bridge, so that my Linux-box would be the one getting a dynamically changing public IP via DHCP. Understandably it simply cannot be done with a mobile router. In UMTS-network, the mobile terminal will negotiate a data connection and get the IP-address associated with the connection. There literally is no chance for my router to do that via B593. Using an USB-based mobile terminal such a feat could be achieved, for example my Huawei E160 gets an IP-address directly to the Linux. No 4G LTE, though. So, I'll be sticking with my B593 for a while. See an example of a transfer speed measurement @ Ookla Speedtest.net. Not, bad huh?

I also did investigate if the box would be based on Linux. Huawei has some GPL-components in the firmware, but they don't release BusyBox nor Dropbear source. It is possible, that they are using something of their own make or simply don't have a prompt or are not using Linux at all. The reason I'd like to see them is that both BusyBox and Dropbear SSHd are very typically used in Linux-based hardware.

Doing a port-scan from LAN-side to B593 reveals, that it has something there:

Not shown: 995 closed ports
PORT    STATE    SERVICE
22/tcp  filtered ssh
23/tcp  filtered telnet
80/tcp  open     http
443/tcp open     https
631/tcp filtered ipp
MAC Address: F8:3D:FF:F8:3D:FF (Huawei Technologies Co.)

... but since all the nice stuff (SSH and telnet) are filtered, I don't know if there are actually any services listening to those ports.

To repeat: to my understanding, a bridging firmware cannot be done. However, something very similar can be achieved, it has a DMZ-setting. See:

It says "You can configure a computer as the DMZ host that is exposed to the Internet so that unlimited services and exchanges are provided between the host and Internet, for example, online games and meetings." in the page. That is pretty much same as bridge.

I had to test if it really would work. I took a hping-utility for crafting raw IP-packets and ran:

hping -c 1 -n <-da-IP-address-here> -e "AAAA" -0 --ipproto 41

That sent a single (-c 1) raw IP-packet (-0) and stamped the outgoing packet a IPv6-encapsulation protocol (--ipproto 41). If the Huawei would have a simple UDP & TDP forwarding, such a packet would never pass trough.

On my Linux it said:

16:15:50.115851 IP sending.host.com > receiving.host.net: [|ip6]
16:15:50.115920 IP receiving.host.net > sending.host.com: ICMP host receiving.host.net unreachable - admin prohibited, length 32

Goddamn! It works! The packet properly passes trough.

My conclusion is that the DMZ-function is actually usable. Apparently there is no need for SSH-prompt -based configuration tweaking. It would always be nice, though. All Linux-nerds like me simply love to go to the prompt and type cat /proc/version and cat /proc/cpuinfo and boast about their hacking abilities to anybody who cares (not) to listen.

I had a glitch with my DD-WRT -setup as it failed to pass-trough native IPv6-traffic on my own network. It took me a while to understand why only IPv4-traffic was getting trough it, but I managed to get it working. Here is my setup:

It is pretty trivial, the internet connection goes trough firewall and a router. Behind the router, there is my wired Ethernet and wireless connection to mobile devices. I had no issues with wired devices, IPv6 was working fine, so I guessed my WLAN-setup was flawed.

A closer inspection revealed, that my DD-WRT was configured to use IPv6 Stateless address autoconfiguration. This is part of IPv6-specification and a closer inspection of the traffic reveals, that autoconfiguration is done with couple of specially crafted ICMPv6-packets. I bumped into Mr. Matt Brown's blog, which pointed me to the RFC 4862 which defines the protocol. It states that there exists two kinds of nodes:

• router - a node that forwards IP packets not explicitly addressed to itself
• host - any node that is not a router

Then it struck me:
My WLAN access-point is considered a router, altough it is a bridge by definition, but for the sake of IPv6 autoconfiguration it is a router. As it came out, the autoconfiguration packages are using link-local addresses from address-space of fe80::/64, which by definition won't survive a hop over a router. (Which in my mind I didn't have, it was a WLAN bridge!)

The plan was to:

1. disable the autoconfiguration from the WLAN access-point and manually define a static IPv6-address
2. use a static default route from the WLAN access-point and confirm that it has proper IPv6-connectivity
3. run router advertisement daemon (RADVD) to advertise the WLAN access-point as a proper router for any wireless clients
4. make sure, that any incoming traffic from the mobile clients is properly routed to the real IPv6-router, and confirm that traffic flows both ways

This was actually very easy to do into DD-WRT. After disabling and enabling the wireless interface on my Windows 8, I finally got a default route:

PS C:\Windows\system32> netsh interface ipv6 show route

Publish  Type      Met  Prefix                    Idx  Gateway/Interface Name
-------  --------  ---  ------------------------  ---  ------------------------
No       Manual    256  ::/0                       18  fe80::c2c1:c0ff:c2c1:c0ff

This was nice! Everything simply started working. What I'm still looking for are ways of getting the default route without disable/enable for the interface. Both, on Linux and Windows.

QNAP released their version 4 firmware. Its GUI has iPad-look and feel and is a major improvement overall. It has all the existing features (actually I don't know of any new interesting things), but the management interface has been completely re-written. It responds much faster and is really nice to use. Actually the version 3 GUI was very, very slow to log-in or respond to a click. It looks like this:

The only thing I noticed that didn't work was date/time settings. It chose a GMT-12 time zone for some reason. It does work in the background, I'm using Europe/Helsinki TZ and it shows EEST correctly on SSH-connection:

[~] # date
Wed Aug 14 13:24:52 EEST 2013

Also, I noticed that daylight savings time -setting displays the correct TZ.

To fix the NTP-client I did following:

# /sbin/setcfg NTP "Server1 IP" -my-IP-here-

# /etc/init.d/ntpd.sh stop
# /etc/init.d/ntpd.sh start

This does not reflect the change to the GUI.

Anyway, I'm looking forward to see the next firmware to fix those issues.

I got one of Linksys wireless access points. The original idea was to install Linux into it with DD-WRT, but the operation failed miserably due the fact, that there are actually two kinds of E4200 APs. Guess who has the "wrong" kind. That would be my 3rd Linksys wireless access-point. I love their products due to extensive Linux-support and very high quality hardware. Now it looks like, this one didn't turn out like I planned.

Anyway, the thingie had a very old firmware and I thought that it would be a good idea to upload the newest factory firmware into it. That failed immediately, all I got was a "Image File Is Incorrect" error message. The message was spat out from the GUI almost immediately, so I decided to debug it. Here is the code I found:

var len = F.file.value.length;
var ext = new Array('.','i','m','g');
if (F.file.value == '') {
    alert(fwupgrade.upgradefile);
    return false;
}
var IMAGE = F.file.value.toLowerCase();
for (i=0; i < 4; i++) {
    if (ext[i] != IMAGE.charAt(len-4+i)){
        alert(hupgrade.wrimage);
        return false;
    }
}

Nice! The manufacturer designated file of FW_E4200_2.1.39.145204.SSA hardly matches the required .img file extension. Also on the code side: is the way of checking for the file extension completely braindead, or is it just me? Guess what would happen, if the filename would contain less than 4 characters.

It was safe to rename the file and upload the firmware. It didn't brick the thing. There seems to be plenty of people having the same issue. The unit seems to have interesting ports open, nobody knows why. Here are the port scan results:

Starting Nmap 6.25 ( http://nmap.org ) at 2013-08-07 13:47 EEST
Nmap scan report for 192.168.1.1
Host is up (0.0017s latency).
Not shown: 992 closed ports
PORT      STATE    SERVICE
53/tcp    open     domain
80/tcp    open     http
139/tcp   open     netbios-ssn
443/tcp   filtered https
445/tcp   open     microsoft-ds
8083/tcp  open     us-srv
49152/tcp open     unknown
49153/tcp open     unknown
MAC Address: 58:6D:8F:GG:2G:3G (Cisco-Linksys)

Nmap done: 1 IP address (1 host up) scanned in 1.32 seconds

There is a project to get Linux running on Marvell-chipsets also, but the site seems to be down. So, I'm linking the WikiDevi page instead: http://wikidevi.com/wiki/Linksys_E4200_v2
Hopefully that pans out and there will be support for DD-WRT some day.

5 am this morning I woke, because a thing was beeping somewhere. The sound was quite annoying, so I had to investigate. My NAS-box chose to go into error state during regular backup schedule and inform me with this audible alarm, that hard drive was full. Bullshit! I said.

In the front-panel there was a flashing message "Error message volume full". However, the hard drive was far from being full. With the text, I googled into this article about QNAP HDD full. The clue about Network Recycle Bin was helpful. The system information really said, that all of the available hard drive capacity was taken. Majority of the stuff I had there was files in the Network Recycle Bin.

The fix was easy: I reduced the file retention time into half of the previous and clicked "Empty". The box chewed the drives for a couple of minutes and new stats were much better. Also the annoying beep ended.

Falling back to sleep at 5:30 was another thing. No could do. Unfortunately.