Latest iLO2 firmware for HP Proliant DL380 Gen 5

When looking for the latest iLO2 firmware for HP Proliant DL380 Gen 5 on the HPE website I found version 2.27 dated in 2015. To resolve browser issues with modern browsers I wanted to find a later firmware.

On this site you will find an exellent collection of all the latest iLO firmwares: https://pingtool.org/latest-hp-ilo-firmwares/

The latest listed iLO2 firmware is 2.33 dated march 2018 (when writing this post). The download links leads to HP sites so it should be legitimate. However, when unpacking the archive and investigating the Readme-file, only Gen 6 servers where listed.

HP Proliant iLO2 firmware

HP Proliant iLO2 firmware

It turns out the firmware works fine on my DL380 Gen 5 iLO2. Upgrade had to be done through Microsoft Internet Explorer 11, otherwise when trying to upgrade through other browsers I got the error message “iLO 2 firmware update has not started.” described here. The simple solution was to upgrade through MSIE 11.

Disclaimer: I can’t garantuee this will work for you or not get you in trouble with your system using the above procedure. It is just a description of what worked for me.

 

What Supermicro motherboard model does my server have?

When getting the latest IPMI firmware for your Supermicro server, you need to know what model of the motherboard your server has. Often the server lives in a datacenter somewhere and you don’t want to go there, take down the server, pull it out of the rack and investigate it. If you are running Linux on it, you can simply check the dmesg log for “Supermicro”.

grep Supermicro /var/log/dmesg

Supermicro motherboard model

Supermicro motherboard model

HP Procurve MSM422 / MAP-625 clients flow the dhcp server [solved]

A client was using the HP Procurve MSM422 / MAP-625 MultiService Access Point (wifi). It was being used in a rather crowded wifi environment and the problem was the wifi clients keept reconnecting and renegotioating so often that the DHCP server was overflowed, sometimes with DHCP requests every few seconds. They had been struggling with the problem for a couple of months and the focus was aimed at the DHCP requests.

It turned out that the problem was not in the DHCP negotiation at all, but was caused by the wireless clients that keept losing connection and each time when they reconnected a DHCP request was sent.

The client was misinformed, that 5 GHz band was prohibited in the country where it was set up (which is acutally not). So both radios (radio 1 and 2) where set to 2,4 GHz where radio 1 was set to 802.11n/b/g and radio 2 with 802.11b/g.

Furthermore, for radio 2 the value of the Antenna gain was set to the maximum which is 29 dBi in an attempt to boost the maximum power out of the system. However, this field works the opposite. In order to be regulatory compliant and not emit more than the allowed power, this field informs the system that it is connected to an antenna with 29 dBi gain, so to not emit illegal levels of power (output power + antenna gain), the system will reduce the actual output power (i.e. the power input to the antenna) by 29 dBi. But the system was using the internal antennas which, I guess, has more or less no antenna gain. This caused the system to actually emit -29 dBi, i.e. a very weak wifi signal.

The low power output made it hard for the wifi clients to “hear” the access point, which caused them constantly to lose connection and when reconnecting, they were sending a DHCP request, hogging down the DHCP server.

Solution:

  • Radio 1 was configured to use the 5 GHz band. This band is much less crowded than the 2,4 GHz band and the bandwidth is better, so when a client has the possibility, it is preferred if it can use the 5 GHz band.
  • Radio 2 was configured to use Internal Antenna with 0 dBi antenna gain.

Settings used when the problem was solved like this (click on the image to enhance it):

HP Procurve MSM422 MAP-625

HP Procurve MSM422 MAP-625

bigclivedotcom Youtube channel

bigclivedotcom is a Youtube channel operated by Clive from Isle of Man. He dissects and investigates all kinds of electronics stuff, mostly ordered from questionable eBay sources. If you are into electronics this is a really enjoyable channel.

Vivotek PT7137 rtsp stream to webpage using VLC plugin

One way of getting the video from Vivotek PT7137 to a webpage is by using the VLC plugin and connect the rtsp stream.

However, in current version of Chrome the VLC plugin is no longer supported. Instead it is suggested to use HTML5 to embed video, but rtsp is not supported in Chrome so it is kind of a dead end there for the moment. This solution works in for example Firefox.

In the webpage where you would like to add the stream:

<object classid=”clsid:9BE31822-FDAD-461B-AD51-BE1D1C159921″ codebase=”http://download.videolan.org/pub/videolan/vlc/last/win32/axvlc.cab” id=”vlc”>
</object>
<embed type=”application/x-vlc-plugin” pluginspage=”http://www.videolan.org” autoplay=”yes” loop=”no” width=”600″ height=”340″ target=”rtsp://USERNAME:PASSWORD@IPADDRESS:554/live.sdp” />

Replace USERNAME, PASSWORD and IPADRESS with real values for your Vivotek PT7137 camera. It might be a good idea to create an account in the Vivotek PT7137 to use from the web as the username and password will be visible for anyone who inspects the webpage source code. That said, putting the root user account and password here would be considered stupid 🙂

Tip for Joomla users: If you include this code in a Joomla site, include {emailcloak=off} before the above, because the @-sign will trig Joomla email cloaking beliving it is an email address.

QNAP TS-420 web interface not accessible over SSL

After a reboot the web interface on a QNAP TS-420 NAS was not accessible over SSL. A nmap showed the NAS was not listening on the SSL port and it was configured to force SSL connections over the standard 443 SSL-port. So trying to access it over the non-SSL port just directed me to https://<ip-address of the nas> where there was no response.

To be able to access the web interface over the non-SSL port 8080 i had to ssh into the NAS using the admin account, then I issued the following commands:

/sbin/setcfg SYSTEM "Force SSL" 0
/etc/init.d/thttpd.sh restart

After this it was possible to access the NAS web interface over the non-SSL port, i. e. http://<ip-address of the nas>:8080

 

Improving wifi in a crowded wifi environment

This is a litle trick I use when I travel and hook up to a wifi network in a crowded wifi environment. Sometimes the network performance over wifi is really bad and the problem is that it can be caused by heavy traffic (like file sharing) on another wifi network sharing the same channel as yours. I have experienced this especially when travelling to big cities like Paris, Amsterdam and so on. First of all, it is recommended that you disable 802.11n wifi mode which works terribly bad in crowded environments. See this article for Windows and this for Linux (Ubuntu).

 

Crowded wifi environment (Wifi Analyzer for Android)

Crowded wifi environment (Wifi Analyzer for Android)

The problem with the wifi technology is that networks in the neighbourhood is sharing the same channels. In the 2,4 GHz band there are only 11-14 channels availible (depending on your region) and those channels overlap. That means if your network is on channel 1 you will get interference with traffic on channels 1, 2 and 3. Another problem with wifi is that is has no means of evenly dividing the capacity (like timeslots), so it is kind “the one shouting highest gets the most bandwidth”. And when someone already is using a lot of bandwidth (like file sharing) it is very hard for other users to obtain a part of the bandwidth. Even if it is the neighbours wifi which you can’t access but it shares the wifi channel.

A countermeasure to improve the situation is to constantly use some bandwidth forcing the heavy users to pull back a bit. Before transmitting, each node in the network listens in the air if the channel is free, so by using a little bit of bandwidth even if idle you don’t give the other node the same possibilty to hog the entire capacity.

First of all, find out the IP address of your local network default gateway. In WIndows you run a command prompt (cmd) and type the command ipconfig. In Linux you can use netstat -rn.

To constantly use up a small portion of the bandwidth I use the ping comand. Ping normally sends very small packets (56 bytes), but to get this to work we need a bit larger packets (but not to large, then we will hog the entire capacity). 1024 bytes is good.

In Windows you run the command (replace 192.168.0.1 with the IP-address of your local network which you found out above):

ping -t -l 1024 192.168.0.1

and in Linux you run:

ping -s 1024 192.168.0.1

 

ping with 1024 bytes

ping with 1024 bytes

Voila! Now my wifi connection gets a lot more stable because I force the other wifi nodes to pull pack a bit since I constantly make them aware of my presence.

 

Disable 802.11n on Compaq 6910p with iwl4965 in Ubuntu

I’ve found out that the 802.11n high speed wifi / wlan mode (300 Mbps theoretically) tends to cause more harm than good, i.e. the performance in many, especially crowded, wifi environments will be really poor and it is a better option to turn it off.

My Compaq 6910p laptop comes with an Intel Wireless WiFi Link 4965AGN chipset. The 802.11n mode can be disabled making it fall back to only use 802.11a/b/g modes casuing the connection to be much more stable and often the overall bandwidth will be better.

To check if your chipset is running with 802.11n enabled, enter the command:

sudo iwconfig wlan0

The output will look something like this:

wlan0     IEEE 802.11abgn  ESSID:"XXXXXX"
          Mode:Managed  Frequency:2.462 GHz  Access Point: 00:0C:F6:82:90:28
          Bit Rate=14.4 Mb/s   Tx-Power=15 dBm
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=51/70  Signal level=-59 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:66  Invalid misc:36   Missed beacon:0

If the first line says 802.11abgn your chipset has 802.11n activated.

To disable 802.11n mode do the following:

sudo modprobe -r iwl4965
sudo modprobe iwl4965 11n_disable=1

This will disable 802.11n until next reboot. Now check again with sudo iwconfig wlan0 and the output should display the first line without the “n” after 802.11, like this:

wlan0     IEEE 802.11abg  ESSID:”XXXXXX”
          Mode:Managed  Frequency:2.462 GHz  Access Point: 00:0C:F6:82:90:28
          Bit Rate=54 Mb/s   Tx-Power=15 dBm
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=46/70  Signal level=-64 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:7  Invalid misc:485   Missed beacon:0

If you want to make this change permanent, i.e. always disable 802.11n, do the following:

sudo echo "options iwl4965 11n_disable=1" >> /etc/modprobe.d/iwl4965.conf

After rebooting, verify using sudo iwconfig wlan0 that 802.11n is not enabled.

 

Samsung Ultrabook series 5 loses wifi connection intermittently

On a rather new Samsung Ultrabook series 5 we had intermittent / sporadic connection problems on some wifi networks. The status for the network shifts forth and back between ok and “No internet access”. This doesn’t happen on all wifi networks. It seems the problem is the 802.11n mode, especially in a crowded wifi environment.

The solution (or workaround) is to disable the 802.11n mode in the wifi driver for the Intel(R) Centrino(R) Advanced-N 6235 chipset. This gives a lower bandwidth connection but on the other hand, a stable connection.

  1. Go to the Control panel
  2. Open Network connections (search for it if you have troble to find it)
  3. Right click on your wifi connection and select Properties
  4. Click Configure in the upper part of the box (my screenshot is danish, so it is the button labeled “Konfigurer…”)

    Intel Centrino Advanced N-6235

    Intel Centrino Advanced N-6235

  5. Click on the Advanced tab
  6. Find the 802.11n mode status configuration parameter and select to set it inactive (off)
  7. Click Save / OK in the bottom

 

 

[Solved] Samsung Galaxy Note II (GT-7105) + Plantronics Voyager Legend bluetooth headset poor audio quality

I recently bought a Plantronics Voyager Legend headset to use with my Samsung Galaxy Note II phone. It worked fine for a day or two, then I started to experience poor sound quality. Especially the person I was talking to had real trouble hearing me. Restarting bluetooth in the Samsung or restarting the Plantronics headset did not help. But restarting the Samsung Galaxy Note II resolved the problem momentarily – after a day or two the problem returned.

Before returning the headset to the dealer I decided to have a look at Plantronics website and found out there are a firmware update procedure availible on their website. To get the update software running on my Windows 8 PC I had to run the installer as administrator. When returning to the update window in the browser (yes, the update procedure is done all in the browser), I found my headset was running firmware version 44 and an update would update it to version 93.

After updating the firmware all quality issues where gone. 

To update the Plantronics headset visit http://www.plantronics.com/us/support/myheadset/updater/