Vodafone firmware for B593u-12
Saturday, November 16. 2013
I was looking for a firmware for s-22 and bumped into Vodafone's firmware. It seems to be in use at least in Vodafone Germany. The download location for the firmware version V100R001C35SP061 is at http://vve.su/vvesu/files/misc/B593/.
Just to be clear, the 3.dk's version for u-12 is V100R001C26SP054. Another thing: I didn't test the new version, currently my router runs just fine. If you do, please drop me a comment. The version number and router compatibility information comes from extracted firmware header it says (in hexdump -C):
# hexdump -C Vodafone_fmk/image_parts/header.img | head
00000000 48 44 52 30 00 10 9b 00 04 da 6f d2 00 00 01 00 |HDR0......o.....|
00000010 1c 01 00 00 d4 14 16 00 00 00 00 00 42 35 39 33 |............B593|
00000020 2d 55 31 32 00 00 00 00 00 00 00 00 56 31 30 30 |-U12........V100|
00000030 52 30 30 33 43 30 33 42 30 30 38 00 00 00 00 00 |R003C03B008.....|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 56 31 30 30 |............V100|
00000050 52 30 30 31 43 33 35 53 50 30 36 31 00 00 00 00 |R001C35SP061....|
00000060 00 00 00 00 00 00 00 00 00 00 00 00 56 65 72 2e |............Ver.|
00000070 42 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |B...............|
00000080 00 00 00 00 00 00 00 00 00 00 00 00 31 31 2e 33 |............11.3|
00000090 33 35 2e 33 33 2e 30 30 2e 30 30 30 00 00 00 00 |35.33.00.000....|
This is the the obligatory warning: if you have a s-22 DON'T update with this firmware. If you don't know which version you have: DON'T update with this firmware. Nobody want's to brick the router, right? It is expensive and all.
Huawei B593 different models
Sunday, November 10. 2013
Just to clarify: My exact mode of Huawei 4G router is CPE B593u-12.
So my previous writings about 3's firmware and Saunalahti's firmware are specific to that exact model. According to 4G LTE mall website following models exist:
- B593u-12: FDD 800/900/1800/2100/2600MHz
- B593s-22: TDD 2600 FDD 800/900/1800/2100/2600MHz (Speed to 150Mbps)
- B593s-82: TDD 2300/2600MHz
- B593s-58: TDD 1900/2300/2600MHz
- B593s-58b: TDD 1900/2300MHz
- B593u-91: TDD 2300/2600MHz
- B593u: LTE FDD 850/900/1800/1900/2600 MHz
- B593s: Band 42 (3400-3600MHz)
- B593u-513
- B593s-42
- B593u-501
- B593u-41
- B593s-601
In Finland the most common models are the two first ones: u-12 and s-22.
There are number of discussions for getting a new firmware (they even copy/paste stuff from my blog without crediting me as the author), but please carefully find out the exact model before upgrading. If you manage to inject an incorrect firmware, it will most likely brick your thing. I didn't try that and don't plan to.
What's funny is that Huawei does not publicly have a B593 in their product portfolio, apparently their only sales/support channel is via their client Telcos and they don't publish anything except the GPL-code required by GPL v2 license.
Huawei B593 firmware from 3 Denmark
Thursday, September 5. 2013
Sorin was kind enough to comment my article about Telia's firmware. He found a firmware from 3 Denmark for B593. Naturally I had to try that as soon as I could.
My previous articles about B593 are:
- Telia firmware not having SMS-functionality in it, Saunalahti firmware link
- DMZ-setting
- Dropping to 2G EDGE occasionally
The download link for 3's firmware is: http://www.3.dk/Privat/Kundeservice/Hjaelp-til-mobilt-bredbaand/Routere/Huawei-B593/#Firmware_opgradering
You will find a .zip-file, which will contain the firmware file with name hi3g_r+m+h+s.tar.bz2 in it. The file is dated 20th Nov 2012. After the firmware upgrade, a software version of V100R001C26SP054 will be installed:
The previously used Saunalahti firmware has software version of V100R001C260SP055, so the difference is C26 SP054 vs. C260 SP055. It is a known fact that telcos get a firmware modification kit from Huawei and can enable/disable features and add their own skins (see previous posts).
For all of us not fluent in Danish, there is a language selection in the login-screen. Beware: after the upgrade was done, I didn't have any connectivity. See:
The lack of connectivity was for the reason, that during update the APN-settings were set for 3 Denmark. Naturally they didn't work for me. This firmware has the VoIP-functionality enabled, thus, there is need for 2 separate APNs. Finnish telco's don't have the VoIP, so I cannot test that. But that does make the APN-setting -screen quirky. You cannot edit/delete an APN which is in use, either as data connection or VoIP-connection. There is no visual feedback about that, so I had to investigate the setting screen -logic for a while.
I did confirm that SMS-send/receive functionality is there and works. No issues on my tests. Also I confirmed my DMZ-forwarding, it still works as expected.
One fact that Sorin mentioned in his comment was, that he experienced lot of dropped connections with Saunalahti-firmware. His experience is that this firmware is more robust.
I'll update here if something surprising appears.
Huawei B593 4G-router dropping to 2G EDGE
Monday, September 2. 2013
My 4G-router drops to 2G EDGE after running couple of weeks. It's a really weird thing, since it does not do it always. Also the total on-line time is really weird. I hardly think that the on-line time can be 9 years or so.
I could not find any other remedy to fix this, but to reboot. After that it does a scan for connections and finds 4G/3G/2G and chooses the fastest one like it should do.
This is just a nuisance. I'd expect the box to be a little bit more robust.
The on-line time calculator -thing is a really weird one. It seems to jump 200 days during 8 hours when it feels like doing it. Apparently the entire calculator is busted.
Using the DMZ-setting of Huawei B593
Thursday, August 29. 2013
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.
IPv6 through WLAN access-point
Wednesday, August 21. 2013
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:
- disable the autoconfiguration from the WLAN access-point and manually define a static IPv6-address
- use a static default route from the WLAN access-point and confirm that it has proper IPv6-connectivity
- run router advertisement daemon (RADVD) to advertise the WLAN access-point as a proper router for any wireless clients
- 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 Turbo NAS firmware version 4
Wednesday, August 14. 2013
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.
Running Linksys E4200 access point
Thursday, August 8. 2013
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.
QNAP Turbo NAS "Error message volume full"
Monday, August 5. 2013
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.
Un-boxing Leap Motion
Tuesday, July 30. 2013
A FedEx guy dropped my Leap Motion while I was on holidays. Today I managed to un-box it.
Here are the pics:
On the end of the thing, there is an USB-3 connector. Inside the box is a shorter cable and a longer cable, with length of 1,5 meters. The spec says USB-2 will do it on your computer.
Here are the videos:
What can this be used for? I dunno (yet).
Security: IPMI / BMC backdoors
Friday, June 14. 2013
I got a new Supermicro server. Pretty much the next day there was a writing about computer security. The article is in Finnish, and it contains interviews from
- Stonesoft, the Finnish firewall / intrusion detection company bought by McAfee / Intel
- F-Secure, the Finnish virus detection company
- CERT-FI, the Finnish national computer security incident response team
- SSH, the Finnish security company
It contains allegations from USA about Chinese Huawei using their hardware for spying American companies. There is also allegation that Supermicro had intentionally left specific IP-addresses open in their Base Management Controller. I didn't find a single trace about that, however, there is a security warning by SEC Consult about Barracuda-products having something similar what they describe in the article.
Taiwanese Supermicro is not totally innocent. I found that they had/have a flaw in their documentation. They failed to mention that their IPMI implementation has two admin-accounts. That is pretty rare when it comes to networked appliance. Typically one admin-account will do fine for most of us. Intentional or a honest mistake? Nobody knows. And those who do, won't tell.
Otherwise, I found two separate issues about remote management security issues. First one is about using a non-standard chiper to encrypt the IPMI-traffic. It simply lets you pass without encryption or authentication. Nice!
The second one is from almighty Bruce Schneier. It describes findings about general lack of security in those very critical systems used to manage the servers. Consumer products are safe, they don't have BMC / IPMI -chips in them.
I have one Asus ASMB4 and one Hewlett Packard iLO 2 on-line at the time of writing. The Asus BMC doesn't survive two weeks in the wild Internet. There is an unknown flaw to shoot it out of the Net somehow. That's why I put a firewall appliance in front of it. The HP iLO 2 seems to survive in the wild, however it has a very sluggish response time and absolutely requires a firewall also. It seems to be a target for lots of incoming traffic. Those BMC-boards are tiny both in physical size and computing capabilities, it doesn't take much to overload them.
Playstation 3 failing to load updates
Friday, May 24. 2013
Something really weird happened. My Playstation 3 refused to load updates. I retried at least 50 times, but it failed to load measly 24 MiB update from Sony.
A quick Google-search reveals, that plenty of people are suffering from this problem.
In my case the fix was to change wired connection into wireless. I have no idea what the difference is, but for some reason it did the trick.
Getting the updates into PS3 is rather complex as observed from the network traffic. An update is a HTTP-request and the load is split into 4 parallel loads. Example:
GET /tppkg/np/NPEB00874/NPEB00874_T8/0bbab4e7b137739f/EP4350-NPEB00874_00-NETFLIXRIGEL01EU-A0104-V0100-PE.pkg?product=0085&downloadId=be00b7cc&q=2058b9eb8ab5f2492012c6c5b5a73320d1bde7f004d5cb6734fa2ebf322b971e&serverIpAddr=87.248.207.254&downloadType=fm HTTP/1.1
Host: b0.ww.np.dl.playstation.net
Range: bytes=6126400-12252799
I don't understand why they do that. Obviously there is some sort of bug in the 4.41 firmware.
Update 4th July 2013:
Problem still exists in 4.46 firmware. I had major trouble updating, since my PS3 didn't get 100% of the firmware. The error message reads: "An error occurred during the download operation. A connection to the server cannot be established (80710723)".
Windows 7 not staying in sleep-mode
Thursday, April 18. 2013
My gaming-PC is couple years old and one day it didn't want to sleep anymore. Which is pretty weird. It has been working ok since I built it, but now something really weird happened. I Googled a couple of articles with keywords "windows 7 random wake from sleep" to confirm that it's not just my breaking down hardware, but a real issue.
Normally I don't shut down my PC, I just let it sleep when not being used. It is pretty modern piece of hardware and does not consume very much electricity during sleep. It also "boots" from the sleep pretty fast on a mouse or keyboard click. My initial fix was to reboot it and shut it down, and even turn off the power supply power to make sure it stays down. No matter what I tried, it just keeps popping up after random period of time. It could be 15 minutes or couple or hours.
Mr. Jack Ukleja found the actual reason for this behaviour. He has an execellent article in his blog. It appears that network adapter's Wake on pattern caused this. He also describes a way to see why Windows was woken last time. In my case Windows power configuration somehow gets it wrong. When I do a:
powercfg -lastwake
from command line, it gives me:
Wake History Count - 1
Wake History [0]
Wake Source Count - 1
Wake Source [0]
Type: Device
Instance Path: PCI\VEN_8086&DEV_1503&SUBSYS_849C1043&REV_05\3&11583659&0&C8
Friendly Name:
Description: Intel(R) 82579V Gigabit Network Connection
Manufacturer: Intel
... which most certainly is not the case here. I tapped a mouse button to wake this up.
Anyway, in his case he had a Realtek Gigabit Ethernet NIC and fixed the issue by disabling Wake on pattern from NIC's advanced settings. Even though I have an Intel Gigabit NIC, I had to try the same. It helped. I don't know if it is a factor, that in my PC there are two NICs and the another one is a Realtek Gigabit NIC. Anyway, now my PC is back in order. It stays sleep when I put it to sleep the way it is supposed to do.
Shop alarm gate tag dissected
Tuesday, March 26. 2013
Everybody who has ever been to a store has seen those electronic gates which are meant to keep shoplifters from stealing stuff. Normal shoplifters use some kind of countermeasures and are actually not bothered by the gates, only honest people get to suffer from them. Typically the gate triggers the alarm by accident when shop personnel simply forgot to remove the tag, or sometimes a rolled wire of some sorts will resemble a coil so that the gate thinks that my recently bought extension cord and/or Ethernet cable is an anti-theft tag. The other not-so-typical scenario is that, there is a tag attached to thing that you bought, but the gate does NOT trigger the alarm. Well, this time that's what happened.
I'm at home and realize, that there is a tag attached. It looks ugly and annoying and should be removed. Since I've always wanted to know how do they remove them in the shop, I took my trustworthy Dremel and started cutting.
Here are the pics:
It looks that there are 4 lightly magnetic ball bearings inside a small cavity made out of plastic and steel. The steely part of the cave is also magnetic so that it attracts the ball bearings to stay on that side. Then there is the part they remove in the store, it is a metallic stud which really doesn't move a lot when pulled. If a lot of force is applied to the stud, the four ball bearings are tightening to the direction of the pull, so that is it impossible (or very very hard) to actually succeed in removing the stud from the tag. In the store (you see them next to the cash register) they have a powerful magnet which is applied to the plastic side of the tag. When the tag is placed on top of the magnet, it pulls the ball bearings down (with the help of gravity), making the stud move away. A removed stud slips back to the tag very easily without magnets or anything, the ball bearings just move out of the way.
The tag is fully covered with plastic and most of it is a coil for the gate. Normal tags don't have sharp edges or brownish dust from dremeling. This one does, since I literally cut it half. The white plastic part in the 2nd pic is typically covered with the black plastic. Also the stud in the pics 3 and 4 is bit longer, since it is not cut short with a power tool.
Next question typically is: How to remove them next time without cutting/breaking the tag? My answer is that I don't know. My tag is busted anyway, but next time I have one that is not busted, I'll try applying some sort of magnet and hitting the tag to the direction of the magned. Eventually, it boils down to the magnetic force, so a powerful one is recommended. I don't know if I have one that has enough pull in it, but I'll sure try. Another thing that comes into mind is to keep twisting the stud while pulling, it should make the ball bearings roll and stay loose enough.
New laptop: Lenovo T430u
Monday, February 18. 2013
I ended up gotting a new laptop. Since my weapon of choice has been Thinkpad for ages, I got me a new Lenovo. The T-series has existed for ages. Even IBM made them during 90s. The T-series laptops are a bit pricey, but they are meant for working. Couple of years ago a colleague said "and they look like tools, too!".
Here is the link to Lenovo-page.
Since this is an ultrabook (whatever that actually means). It is quite light and only 22 mm thick, as you would expect there is no DVD-drive and only 2 USB-ports. They are USB3, but still, only two of them. Everything in this reminds me of Apple laptops, with the difference that there is a latch at the bottom of the machine. You can open the bottom very easily and all of the parts are easily accessible. It is easy to notice the philosophical difference in design and the ease of manufacturing with Lenovo and Apple. This one was designed by the same people, who actually build and fix them.
The really exciting part is that the state-of-the-art Ivy Bridge CPU/chipset/graphics -combo runs really, really fast. The difference to my previous laptop is a huge. To speed up things even more, I changed the 128 MiB Samsung SSD into 240 MiB Intel SpeedDaemon 520-series. I'm getting Windows Performance index of 4,9 with the weakest link being GPU and specifically desktop graphics. i5 CPU gets 6,9, memory gets 5,9 and SSD gets maximum reading of 7,9. All of these are really good numbers for a 1,7 GHz machine!
Typical usage scenario for a business laptop is to use it in docking station at the office. I got the Lenovo USB3-dock, but still I wouldn't call this a traditional docking station. To "dock" the laptop, you just connect USB3-cable and charger. The dock has quite a many USB3-ports, two DV-i ports and a 1Gbit/s Ethernet connector, all of which I require when docked.
But I'll stamp this with my seal-of-approval. T430u is definitely one to get!