Hardware - 8

This is something I've wanted to do for a long time. Ever since I got my B593. Jevgenij has been hacking his B593 and dropped me a comment that he found command /bin/lteat from his box. Obviously I had to SSH into mine to confirm this:

# ssh admin@192.168.1.1 /bin/sh
admin@192.168.1.1's password:
-------------------------------
-----Welcome to ATP Cli------
-------------------------------
ATP>shell

BusyBox vv1.9.1 (2013-07-25 14:10:15 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

# ls -l /bin/lteat
-rwxrwxrwx    1 0        0           34604 /bin/lteat

... and oh yes! Such a command is there. It is an interactive AT-command shell!

Warning!
Running these AT-commands will mess up with your box. The modem does not like to be messed up and my box didn't connect to internet after doing this. There is a simple fix to just reboot the router.

Let's explore some possibilities.

Manufacturer information

Running the AT-command shell:

# lteat
AT>

This is something that worked already in the 80s modems. The classic modem information:

AT>ati
Manufacturer: Huawei Technologies Co., Ltd.
Model: EM920
Revision: 11.433.61.00.07
IMEI: 868031008680310
+GCAP: +CGSM,+DS,+ES
OK

The 15-digit IMEI is broken into two pieces. First 8 numbers are the Type Allocation Code (or TAC). The second part is the 7 number unique id of my unit. That's why I'm not revealing it here.

If we punch the TAC into a http://www.nobbi.com/tacquery.php it will yield a result of:
86803100
Manufacturer = Huawei
Model = B593
Hints = LTE/UMTS Router

Which is not very surprising. That is something we already know.

Telco information

Let's see what we can get from my telco. I found a nice reference List of AT commands to be very helpful. Running command:

AT>AT+COPS=3,2
AT+COPS=3,2
OK
AT>AT+COPS?
AT+COPS?
+COPS: 0,2,"24405",2
OK

The 24405 is my PLMN code (note: this can be found from web GUI's diagnostics wireless status also). According to article Mobile country code, it breaks down to two parts:
Mobile Country Code = MCC = 244
Mobile Network Code = MNC = 05

According to the table:
MCC = 244 = Finland
MNC = 05 = Elisa

Again, something that I already know.

Location information

To dig a bit deeper ... Every cell tower has unique code. I found information about that from a discussion forum with topic Huawei USB LTE Modem, E3276 K5150 E398 (Modems). The forum says that:

AT+CREG?
+CREG: 2,1, YYYY, XXXXX, 2
OK

Y = LAC
X = Cell ID
Added: Note that both are in hex so need to convert it

Let's try that one out:

AT>AT+CREG=2
AT+CREG=2
OK
AT>AT+CREG?
AT+CREG?
+CREG: 2,1, 620C, 123ABC, 2
OK

Now we have:
LAC = 620C (hex) = 25100 (decimal)
Cell ID = 123ABC (hex) = 1194684 (decimal)

Again, I'm not going to reveal my exact location here! The cell-ID published here is something I made up.

I tested all the gathered information of:
MCC = 244
MNC = 05
LAC = 25100
cell-ID = 1194684
in OpenCellID's search engine, but they don't seem to have my coordinates in it. Maybe I should add them. Your's may very well be there.

According to Wikipedia article, there are a number of databases for cell-IDs, but most of them are commercial and I don't have a license to use them. In general they simply have exact GPS-coordinates of cell towers and they can be used to get a rough estimate of your location.

Signal quality

The last one I did was to get exact signal quality. A B593 has 5 bars in it, which is accurate enough for most users. The hardware has the quality info in much more detailed level. The AT-command list says:

Signal quality

Command: AT+CSQ
Response: +CSQ: <rssi>,<ber>

Let's try that out:

Query for the ranges:
AT>AT+CSQ=?
AT+CSQ=?
+CSQ: (0-31,99),(0-7,99)
OK

Query for the signal quality:
AT>AT+CSQ
AT+CSQ
+CREG: 1, 620C, 123AC1, 2
AT+CSQ
+CSQ: 23,99
OK

Whoa! It also returned a LAC and another cell-ID. The cell-ID is pretty close to the original one, but not exactly the same. Anyway, the Received signal strength indication (RSSI) is 23 and Bit Error Rate (BER) is 99.

By Googling I found out following information about RSSI:
RSSI (dBm) = RSRP + 10*log10(RB) + | RSRQ | + other noice, temperature noice etc.

You may also see the RSSI vs RSRP: A Brief LTE Signal Strength Primer for details about the signal math.

To put all the logarithms and four-letter-acronyms into layman terms. This table was published in the discussion forum in Finnish by user with nickname timtomi. Signal levels are from poor to excellent:

The BER is typically 99 which means that none could be measured. In general there shouldn't be any errors in the transmission, so 99 is likely what you'll get also.

This is a HOWTO instruction for replacing a spinning platter hard drive with a modern faster solid-state drive. Since Compaq 615 has Windows 7 Home Premium OEM installed, I'll blog about the Windows Activation in more detail on my next post.

This kind of Compaq laptop is quite generic PC. Majority of this information applies to almost any laptops I've disassembled. It's about the location of the drive, location and number of screws, but the information in general covers the operation of replacing a drive with another one.

I started this project with checking for Manuals for Compaq 615 Notebook PC @ HP. The good stuff is at PDF-document with title Compaq 615 Notebook PC and Compaq 610 Notebook PC - Maintenance and Service Guide.

It will contain all the information a service technician would need to successfully operate on this kind of hardware. On page 4-8 it has the hard drive replacement procedure documented.

Anyway, this is something I've done a lot. I briefly checked out the location of the drive and the screws that needed un-screwing. Here is a pic from the flipside of the laptop:

Those two screws hold a HDD-cover in place. The screws even have a HDD-symbol next to them. Un-screw both of them with a small Phillips head screwdriver:

Remove the HDD-cover by pulling up from the side you removed the screws from. The drive is visible:

The drive is held in place by a single Phillips head screw. Remove that too. Pull up from the drive screw bracket and the drive will slide left and reveal a standard S-ATA -connector:

Now you have the drive completely detached from the laptop. The actual hard drive is connected to a metal cradle with 4 Phillips head screws. Un-screw them:

As you can see, the screws are really small. The screws are quite tight, see the blue substance in the screws. It is threadlocker and its purpose is to make sure a screw is tightly attached. If you don't have the proper sized screwdriver, you will destroy the notches of these screws making removal really difficult. This is the only part of disassembly, where I needed to apply some force just to make sure that the screwdriver wouldn't slip.

The next step is to attach the new SSD-drive to the cradle:

Think really carefully which way the drive needs to be attached to the cradle. There are four possible options, but only one of them will yield success. You will see quite soon the position the cradle needs to be in the laptop. The hard part is to figure out which way the drive needs to be to succesfully connect to the S-ATA -connector of the laptop.

When the hard part is done, all you need to do is slide the cradle back to S-ATA connector and secure the screw holding the cradle at place. Then put the HDD-cover back and secure the two screws for the cover.

All this will take around 10 minutes on experienced hands. If this is your first laptop maintenance work, reserve a hour. Nothing here requires much force to be applied. If you are applying much force, you're doing something wrong.

Good luck on your project!

Jevgenij dropped me a comment about new firmware. It is from Telia Sweden and you can get it from here http://www.telia.se/privat/support/mobiltbredband/uppdaterausbmodemorouter#huaweib593formac=&tabMenu_0=huaweib593formac The direct download link is https://www.telia.se/dms/mgnl-ext-dms/www-telia-se-ui/installation-files/se_telia_r-m-h-s.tar/se_telia_r-m-h-s.tar.bz2 The firmware seems to have nice features, SMS and even to force for 2G-operation. He highly recommends this one. This looks very promising, perhaps I'll try this myself.

I upgraded my B593 with this one and can confirm that it works well. GUI-languages are: Svenska, Suomi, Pусский, Norsk, Dansk, Eesti, Lietuviu and Latviešu. No setup wizard. Has external antenna support. No VoIP. No DDNS. Mode selector has 5 options: auto, auto 3G/4g, 2G only, 3G only and 4G only. SMS in/out. No DLNA. So it is little bit light on features, but is fully exploitable and SP102!

The file will contain a SP102 for u-12. Altough The Exploit does not work, it seems to have a nice bug in it. When you're FTPing into it, it will open also SSH-port! Whaat!

Warning:
SSH passwords are reset to something the telco set. However, USB/FTP-hack will work and you can get the /var/sshusers.cfg and look at the plaintext password from there.

John do, a reader of this blog made a serious break-trough! Via SSH on B593 prompt, he found the flashtest-command. Before this I had no knowledge about such command, but see what I can do with this new information:

# flashtest
Usage: flashtest {info|read|write|erase|export|load} {addr} {len} [data]
Format:
flashtest    help
flashtest    info
flashtest    read      addr    len
flashtest    write     addr    len    {data}
flashtest    erase     addr    len
flashtest    export    addr    len

Well ... the info sound interesting. Let's see:

# flashtest info
 flash  block  size  :  0x40000 (256k Bytes)
  flash  block  num   :  0x40 (64 Blocks)
  flash  total  size  :  0x1000000 (16M Bytes)
  flash  partation  info :
  ---------------------------------------------------------------
  Name                  Address                    Usage
 ---------------------------------------------------------------
  Boot                  0x0---0x40000            Bootloader
  Image             0x40000---0xA40000           Main  image
  Image            0xA40000---0xE00000           Subject  image
  Curcfg           0xE00000---0xE40000           Curcent  config
  Faccfg           0xE40000---0xE80000           Factury  config
  Tmpcfg           0xE80000---0xF00000           Temp  config
  Fixcfg           0xF00000---0xF40000           Fixed  config
  Logcfg           0xF40000---0xF80000           Log  config
  TR069            0xF80000---0xFC0000           TR069  cert
  Nvram            0xFC0000---0xFFFFFF           Nvram

Current config! Really!? (Mis-typed as Curcent config). The run-time -only /var/curcfg.xml's real storage has eluded me this far. Let's explore that further:

# flashtest export 0xE00000 65536
Read data: addr = 0xe00000, len = 0x10000 ...
Begin write to file
Export done

What did it do? Where it wrote to? Some poking around reveals:

# cd /tmp/
# ls -l
----------    1 0        0           65536 flashinfo.bin

Oh yes! The next thing is to get my hands on to the file. In the B593 firmware's Busybox there is only a limited set of tools.

Let's use the USB/FTP-hack for transferring the file. The idea is to plug an USB-stick into B593. Any FAT32-formatted stick will do, it is totally irrelevant if there are files or not. Early firmwares are known to have a flaw in them. You can mount the entire filesystem into FTP-server and transfer file to/from the box. Setup goes like this:

Make sure you have the FTP-server running, add a user to the new mount and set the directory as ../.. It is really important to do that! That effectively breaks out of /mnt/usb2_1 into /. See this pic:

I added user with name test. Now let's see if the FTP-connection works from an external machine:

# ftp 192.168.1.1
Connected to 192.168.1.1 (192.168.1.1).
220 bftpd %v at 192.168.1.1 ready.
Name (192.168.1.1:user): test
331 Password please.
Password:
230 User logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> cd /tmp
250 OK
ftp> dir
227 Entering Passive Mode (192,168,1,1,166,124)
150 BINARY data connection established.
----------   1 0        0        65536 May 21 19:26 flashinfo.bin
226 Directory list has been submitted.
ftp>

Oh yes! The extracted NVRAM-binary is there. Let's download it:

ftp> get flashinfo.bin
local: flashinfo.bin remote: flashinfo.bin
227 Entering Passive Mode (192,168,1,1,144,190)
150 BINARY data connection established.
226 File transmission successful.
65536 bytes received in 0.06 secs (1092.41 Kbytes/sec)

A brief analysis of the file reveals:

# hexdump -C flashinfo.bin | head -3
00000000  3e 00 64 fe 3c 3f 78 6d  6c 20 76 65 72 73 69 6f  |>.d.<?xml versio|
00000010  6e 3d 22 31 2e 30 22 20  3f 3e 0a 3c 49 6e 74 65  |n="1.0" ?>.<Inte|
00000020  72 6e 65 74 47 61 74 65  77 61 79 44 65 76 69 63  |rnetGatewayDevic|

# hexdump -C flashinfo.bin | tail -5
000064f0  65 77 61 79 44 65 76 69  63 65 43 6f 6e 66 69 67  |ewayDeviceConfig|
00006500  3e 0a 00 ff ff ff ff ff  ff ff ff ff ff ff ff ff  |>...............|
00006510  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00010000

The first 4 bytes of 3e 00 64 fe are bit of a mystery. I don't know what the 3e 00 is for, but the 64 fe is obvious! It is the length of the XML-file following the header bytes. I can confirm that the entire /var/curcfg.xml is there. Unchanged. Intact!

My next move is to try altering the curcfg.xml and write it back. There is a chance of locking myself out of my own B593, so ... I need to be really careful with this. If everything works as I expect, my next move is to write tools for allowing people to access their devices as they want to.

I'd like to extend my gratitude to Mr. John do. This really is ground-breaking stuff allowing us to new lengths with Huawei B593 hacking. Thank you, sir!

This is something that has been bugging me since November. In my post about different models, I stated that I have a u-12 (and still do). Last year I did setup a s-22 to a friend and got to see that it is pretty much the same. However, "pretty much the same" is not exactly the same.

The s-22 is a newer model and it has been well established, that it has a TDD 2600 MHz added into it. All the FDD frequencies are exactly the same than in u-12.

In the comments of my post, a user suggested that s-22 differs from u-12 by having only one USB-connector. At the time I was unable to find proof of that, all the pictures I could found of alleged s-22 units had no difference for a u-12 unit.

Now the situation has changed. In my ventures of the wonderful Internet I found an article What's the difference between HUAWEI B593s-22 and B593u-12? and it has a picture of both units side by side in it. Nice! But which one is which?

Just to make sure that s-22 is in the left and u-12 is in the right, I'll post a fresh picture of my own u-12 unit:

Also to close the case I also found a vendor page with a nice picture of s-22 in it, see HUAWEI B593s-22 4G LTE CPE [B593s-22]. It has a picture of the unit in the page, and their s-22 looks exactly the same than the left unit in the picture, and exactly NOT the same than my u-12. Apparently s-22 does not have a power switch, it lacks the side USB-connector and SIM-card -slot has been changed into a tray. Lot of differences to spot, actually.

So I'm confident that s-22 is very much re-designed both in hardware and firmware. The hardware side is surely changed because of the new(ish) 4G TDD radio interface. And while Huawei engineers were at it, they changed also the firmware in number of ways, one of them being to resist hacking attempts better than their 1st gen version did. This is also a well established fact, s-22 firmware has a completely different structure than u-12 firmware.

Now me and everybody else should be able to identify the units by a simple visual inspection.

I got a comment from John, he told me that a telco in Germany called Telekom has SP104 firmware out for B593 u-12. They seem to call it Speedport LTE II. The download link to the firmware is http://hilfe.telekom.de/dlp/eki/downloads/Speedport/Speedport%20LTE%20II/Firmware_Speedport_LTE_II_V100R001C748SP104.zip

The UI has English language, so it should be usable for us non-German speaking users too.

As usual, I did download and extract the firmware and all looks ok to me. Also as usual, I didn't test it. If you do, please comment how it went.

Update 21th May 2014:
Today John told me that, Telekom released a security update SP105 firmware. There is little information what the fix is, but you can get the lates from this link http://www.telekom.de/dlp/eki/downloads/Speedport/Speedport%20LTE%20II/Firmware_Speeport_LTE_II_B593u-12_V100R001C748SP105.zip

I got a comment about the firmware version numbers. How can you tell which one is a newer and which one is older? Well ... Huawei really does make this one difficult. I'm guessing all this has to do with the fact that any regular user should be insulated from the fact that his/hers hardware is manufactured by Huawei. Your beloved telco should be their face and you should be doing business with them and only them. Screw that! This is 2014 and the age of social networking in the Internet. Openness is the only real way to go.

Here is what I gatehered for B593 u-12. This is a list of firwares from oldest to newest:

This is for B593 s-22:

Just to be clear:
I don't know any of this to be factually correct, nor I can back any of this up from an "official" source. Feel free to correct me or suggest any other interpretation.

Update 18th May 2014:
Bilbo dropped me a comment with a link into https://app.box.com/s/0uim7fp7j4dzet2bpmhp. It provides more details about version numbering scheme Huawei uses. I did update the table headers with this new information.

My home Linux box is always on and to make sure it stays on I have an uninterruptible power supply for it. APC is very well supported in Linux by open-source apcupsd. Pretty much all other UPSes are supported by NUT, but for some strange reason APC has a separate project.

Update 20th May 2018: There is a new post about APC UPS batteries here.

Couple days ago the UPS started to beep. My house had electricity and there was no apparent fault. Except that I got an e-mail from apcupsd "UPS battery needs changing NOW". Aow crap! The batteries had reached their end of life. I confirmed the status with apcaccess and got status of:
STATUS : ONLINE REPLACEBATT NOBATT

Every 12 hours, the UPS releases a burst of beeps and I find that very annoying. It was time to go shopping for new batteries. Luckily my unit uses Replacement Battery Cartridge #7, which is popular and generally well available and the price ~200 € isn't too bad. The next thing is to get the old ones out and new ones in. APC user's manual says that battery pack is hot-swappable, so it should be an easy thing to do. Apparently the first thing to do is remove the front cover:

It has nice holes on the sides. I guess the idea is to put your fingers into them an pull hard.

When the front cover is loose, a ribbon-cable and a metal cover is revaled.

There are two phillips-head screws to hold the metal cover in place:

When the metal cover is removed, the battery pack is visible:

There is a plastic tab at the bottom. I guess it is there, so that batteries can be pulled out. Now that the metal cover is removed, the batteries are not attached to anything:

The final thing to do is to disconnect the battery pack:

Now the UPS keeps beeping a lot. It is annoyed by the fact, that it cannot find a battery. Since I don't have any original APC software on my computer I found out that the audible beep can be silenced. First make sure that the apcupsd is not running:
systemctl stop apcupsd.service

Now the apctest can be used to change any of the UPS-parameters:

Current alarm setting: ENABLED
Press...
 E to Enable alarms
 D to Disable alarms
 Q to Quit with no changes
Your choice: Select function: d

New alarm setting: DISABLED

Now there is the blissful silence. It is much nicer to operate with the new battery pack.

Obviously the idea is to reverse the instruction. Connect the new battery, slide it in and tighten the screws and attach the front cover back.

I guess, the new battery should last at least 3 years before I'll be getting a completely new UPS. There simply is no point in running a really old UPS with brand new batteries. I guess the UPS technology will still evolve so that a new tech is required after half a decade.

An active contributor for this blog, Mr. nos_com71 was kind enough to notify me about a firmware he found. It is from Polkomtel, a Polish telco. You can download the package from this link @ Norton Zone cloud. I had issues with the download, but using a different browser on another machine solved it for me.

I didn't install the firmware into my s-12, but as usual, I extracted it and confirmed its contents and version of V100R001C69SP103, which is quite new. In the Bjørn Grønli's spreadsheet the newest one he found is a SP102, but this Polish one seems to be a notch newer.

If any of you test this one out, please tell us about it.

I got a comment from Mr. nos_com71 about 3 Italy's firmware for u-12.

The download link is to Mediafire, which definitely is not my favorite place to pick up something I'd like to run on any of my computers. But if you think you can handle it, go for https://www.mediafire.com/?jut00ju7uov988z to get it.

Little bit of FMK:ing revealed, that 3 Italy is using a classic V100R001C12SP104 (see the article about 3 Denmark's firmware with exactly the same version). The important thing is, that he pointed out that the SSH passwords are stored unencrypted in /var/sshusers.cfg. This is exactly like my version does.

So, those people who are able to use the exploit, are able to know what the SSH-passwords are. A command like
B593cmd.pl "cat /var/sshusers.cfg" will give you immediate answer and a regular
ssh admin@-the-IP-here- /bin/sh will do the rest. As I previously stated, the thing is, you need to know the admin password to the web-console and old enough firmware to have the exploit in it to be table to any of that.

Couple of my users were complaining, that their SSH-connection dies when idling for a while. The client does not notice, that server is gone. It cannot regain communications and dies only after a transmission is attempted, failed and timed out.

My initial reaction was, that a firewall disconnects any "non-used" TCP-connections. The non-used may or may not be true, but the firewall thinks that and since it can make the decision, it disconnects the socket. There is one catch: if the TCP-socket is truly disconnected, both the server and the client should notice that and properly end the SSH-session. In this case they don't. For those readers not familiar with the details of TCP/IP see the state transition diagram and think half-closed connection as being ESTABLISHED, but unable to move into FIN_WAIT_1 because firewall is blocking all communications.

Googling got me to read a discussion thread @ Cisco's support forums titled SSH connections through asa hanging. There Mr. Julio Carvaja asks the original poster a question: "Can you check the Timeout configuration on your firewall and also the MPF setup. What's the Idle time you have configured for a TCP session?" So I did the same. I went to the box and on IOS CLI ran the classic show running-config, which contained the timeout values:

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02

From that I deduce that any TCP-connection is dropped after one hour of idling. It is moved into half-closed state after 10 minutes of idle. The 10 minutes is in the time range of my user complaints. One hour is not. So essentially Cisco ASA renders the TCP-connection unusable and unable to continue transmitting data.

In the discussion forum there is suggestion to either prolong the timeout or enable SSH keepalive. I found the way of defining a policy for SSH in the ASA. There is an article titled ASA 8.3 and Later: Set SSH/Telnet/HTTP Connection Timeout using MPF Configuration Example, which describes the procedure in detail.

However, I choose not to do that, but employ keepalive-packets on my OpenSSHd. I studied my default configuration at /etc/ssh/sshd_config and deduced that keepalive is not in use. In the man-page of sshd_config(5) I can find 3 essentially required configuration directives:

• TCPKeepAlive: The master switch to enable/disable the mechanism.
• This is on by default, but this alone does not dicatate if the keepalive will be used or not
  
• ClientAliveInterval: The interval [in seconds] at how often a keepalive packet is being transmitted
• As default, this is 0 seconds, meaning that no packets will be sent.
  
• ClientAliveCountMax: The number of packets that a client did not respond to before declaring the connection dead
• As default this is 3. Still, no packets are sent ever, thus a client is never declared M.I.A. based on this criteria.
  

So to fix the failing SSH-session problem, the only thing I changed was to set a client alive interval. Since after 10 minutes of idling (600 seconds), the Cisco ASA will mess up the connection, I chose half of that, 300 seconds.

After restarting the sshd, opening a connection and idling for 5 minutes while snooping the transmission with Wireshark, I found out that my SSH server and client exchanged data after ever 300 seconds. The best thing about the fix is that it works! It solves the problem and SSH-connection stays functional after long period of idling.

Yesterday I was mighty pissed about Oracle's Java breaking my stuff. Then it occurred to me: I shouldn't be using self-signed certificates in the first place! See my post about Certificate Authority setup: Doing it right with OpenSSL, where I wrote "My personal recommendation is to never use self-signed certificates for anything". And there I was! Darn.

I figured, that there must be a way of stop the stupidity and install an own certificate to the network appliance. Then I bumped into ASA 8.x: Renew and Install the SSL Certificate with ASDM, a PDF-document from Cisco instructing how to achieve that. Nice! Exactly what I needed.

This is how to do it. Log into ASDM and go to Configuration -> Device Management -> Certificate Management -> Identify Certificates. It looks like this:

There you can find Add-button:

You should add a new identify certificate. I used the Default-RSA-Key, but Cisco's own documentation says to generate a new one. In case SSH-keys need to be regenerated, the SSL-certificate won't work anymore. In my case I can simply recreate the certificate also, so it is not an issue to me. After you click Add Certificate:

You will get a dialog to save the Certificate Signing Request (CSR) into a local drive to be sent to a Certification Authority (CA) to be processed.

After your CSR has gone trough and you have your certificate in PEM-format go back to ASDM and select Install this time. You will get a dialog:

Upload or copy/paste the PEM certificate there and click Install Certificate. After that you'll have an identity:

Now the next thing to do is to start using the newly created identity. In Configuration -> Device Management -> Advanced -> SSL Settings there is an option to choose an identity to use when ASDM is being accessed via HTTPS or ASDM-IDM.

To get better results from Qualsys SSL Labs server test I did following changes:

• SSL-version is set to TLS V1 Only, that is TLS 1.0 only. 1.1 nor 1.2 is not available.
• For encryption I'm only using:
• 112-bit 3DES-SHA1
• 128-bit RC4-SHA1
• 128-bit RC4-MD5
• The AES-encryptions for 128-bit or 256-bit failed on my box for some reason. If you have them, please use those! The chosen 3 crypto algos provide reasonable security, but the AES-ones are better.
  

After an Apply the new certificate is in use. You can verify that via a web browser from HTTPS-interface or go to Control Panel's Java security settings and remove the self-signed certificate from secure site certificates -list. The ASDM-login will work again.

This one really made me laugh. The entire situation was like from T-2: "Skynet begins to learn at a geometric rate. It becomes self-aware at 2:14 a.m."

I was trying to see the remote console of one of my servers:

It said: "Could not create token for this session. Max session limit might have reached". This was yet another reminder that Asus iKVM isn't the sharpest tool in the box, it generally responds slowly and sometimes it does weird things. Thanks to Java, it wasn't easy to get the console application running, it said a number of things, including a complaint:

... but after sorting out a number of Java issues it spat out an error-message with XML-content of:

<jnlp spec="1.0+" codebase="http://192.168.1.11/Java">
    <information>
        <title>JViewer</title>
        <vendor>American Megatrends, Inc.</vendor>
        <description kind="one-line">JViewer Console Redirection Application</description>
        <description kind="tooltip">JViewer Console Redirection Application</description>
        <description kind="short"> JViewer enables a user to view the video display of managed
            server via KVM. It also enables the user to redirect his local keyboard, mouse for
            managing the server remotely. </description>
    </information>

...
    <resources>
        <j2se version="1.5+"/>
        <jar href="release/JViewer.jar"/>
    </resources>
    <application-desc>
        <argument>192.168.1.11</argument>
        <argument>7578</argument>
        <argument>
            <html>
                <head>
                    <title>Document Error: Page not found</title>
                </head>
                <body>
                    <h2>Access Error: Page not found</h2>
                    <p>Could not create token for this session. Max session limit might have reached
                    </p>
                </body>
            </html>
        </argument>
    </application-desc>
</jnlp>

I found out somebody who had the same issue at Asus' discussion forums article [Problem]iKVM Remote Control Console w/ Java exception error. There was a suggestion to unplug the power cord. In my case the server is couple hundred kilometers away in a secure data center where I certainly do not have any access. Sure, I could write the support and ask them to do that but ... I'm pretty sure there has to be a way to reset the BMC remotely.

Then I remembered something I did a while ago with ipmitool on Linux-shell. Running:

# ipmitool bmc help
MC Commands:
  reset <warm|cold>
  guid
  info

There is a reset-command in the list. Google led me to an article "Restarting an IBM BMC without restarting the server itself". I wasn't sure what would happen. My first guess was that it would do the same thing as typing "google" into a Google search - the entire world would implode to a singularity. So it is very important not to that. But I really needed the remote console. I was willing to try:

# ipmitool bmc reset cold
Sent cold reset command to MC

Nothing serious happened immediately. The Linux was responsive and world didn't come to an end. After a minute or so, ipmitool bmc info -command yielded a response! The IPMI was back on-line. A logon to web-console:

Yep. I had my console back.

I sure hope that all remote console manufacturers would stop using Java for their apps. It is such a bitch to get a Java application working on after 1.7.0_51 was released. See: "Java 7u51 will not accept JNLP with self-signed certificate?" about other people complaining about that. Anyway, all ended well and I didn't have to drive to the server to do some maintenance.

I needed a new rack-server to fit in a standard 19" telco-rack. Your average rack-mounted server is 60 to 100 cm long. A rack-server may be really thin. 1U (4,5 cm) or less, but really long. Then again, your average telco rack is not long enough for a long server, they may be 40 to 50 cm and not all of them have brackets for mounting the back. My requirement of mounting a server into a telco-rack hugely limits the options to choose a server from. One final requirement I had was that the server must have IPMI 2.0, because that would guarantee KVM over IP.

But after a longish search I found one. The bad news was, that it was a Supermicro, a SuperServer 5015A-EHF-D525 to be exact. Supermicro's track-record on failing IPMI-security is known, see an earlier blog post about it. Anyway, I got a vendor from UK who would order one. They didn't have them in stock and such small rack-servers are quite inexpensive, but don't sell like hotcakes. Who would be crazy enough to want one? I am, so put an order in with the Boston Ltd. It didn't take them many weeks and I got my server delivered.

Here are the pics from front and back:

In the front there is couple of LEDs, power and reset buttons. In the back there are couple of USB 2.0 -ports and two RJ-45 for 100 Mbit/s Ethernet. It is possible to run IPMI on a shared Ethernet-port or a dedicated one. In my setup I didn't want to have the extra cable and went for a shared setup. The port announces itself as two different MAC-addresses and effectively gets two different DHCP-addresses. One for IPMI and one for the operating system.

This is what it looks inside:

Notice how the Intel SSD -drive is not attached properly yet at the time of taking the pic. The motherboard is really small. The only fan is in the PSU, no other ones are required as the Intel Atom CPU does not produce too much heat and the GPU isn't much of a rocket. The tiny box is almost empty, even with a 2.5" SSD in it.

In the BIOS I found that there is a lot of watchdogging to do, there are two of them:

I don't know what the BIOS watchdog is good for as it keeps triggering if turned on. For the IPMI's watchdog there is a Linux-daemon.

Anyway, except the small size and 32-bit Atom CPU there is nothing special in it. 10 years ago such a server would have been a state-of-the-art box, but on today's standards its just a small low-power unit.

On the positive side, IPMI's web console has a setting for IP Access Control. I tested it and it seems to work. It closes all the ports for everybody else. Since the raw rules are not available for inspection, there still may be couple of network blocks which are allowed. These days you cannot help being suspicious.

This is a special box. If you happen to need a silent low-power server, then go with a 5015A-EHF-D525.