Cisco RV160 RFI fix

Cisco RV160 RFI-problems [fixed]

Being an amateur radio operator (or HAM-radio operator) I need to use electronic devices with as low radio emissions as possible in order to keep a low noise level on the shortwave bands (or HF-bands). I found out that my Cisco RV160 router was one of the major sources of radio noise (RFI or Radio Frequency Interference) in my home. It turned out it was easily fixed as the culprit was not the router in itself, but it’s power supply.

The router runs on 12 volts DC (original power supply rated up to 1,5A) which is often available in the ham schack already. So in that case, get rid of the original power supply and hook up the router to your 12 volts DC supply in the shack. In my case, the router was located in another part of the house so I just replaced the power supply with another, transformer based power supply. In my case, a Mascot 6823, rated for 12 volts DC, 1A (intermittently up to 1,3A). Even though not the same amp rating as the original, it seems to be sufficient.

Toshiba laptop green blinking LED light

A Toshiba laptop I encountered recently was deemed “possibly dead”. It would not boot and screen was just black.

A blinking green LED was present, meaning the battery is discharged. Further investigation revealed that the power supply electric cord had fallen out of the socket.

Plugging it in again turned the blinking green LED to solid orange, meaning the laptop was charging and just pushing the power button made it boot up normally.

Sometimes the problems are too simple 🙂

Samsung SL-M3375FD scan to email and SMB stopped working

Samsung multi function laser printer SL-M3375FD could suddenly not send email (scan to email) and SMB shares stopped working. Logging in to the printer web interface, using the test function for the SMTP settings just resulted in “failed” when it tried to authenticate to the email server.

Recently the email server’s SSL-certificate was updated because it was about to expire and about this time the scan to email stopped working.

The solution was simply to update the printer firmware. It was running a firmware from 2014 but updating to the latest one download here solved the problem both concerning email and SMB shares.

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:

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.


  • 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=”” id=”vlc”>
<embed type=”application/x-vlc-plugin” pluginspage=”” 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/ 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 with the IP-address of your local network which you found out above):

ping -t -l 1024

and in Linux you run:

ping -s 1024


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.