Nagios Core - Error: Could not stat() command file '/usr/local/nagios/var/rw/nagios.cmd'!

 Setting up a new Nagios Core installation and I ran across the following error message:

Error: Could not stat() command file '/usr/local/nagios/var/rw/nagios.cmd'!

If you search for this error, you'll find a lot of posts saying to set SELinux to Permissive or Disabled. This (and many other SELinux issues) is easily solved while leaving SELinux Enforcing. First, verify that SELinux is the culprit: 

tail -f -n 0 /var/log/audit/audit.log

Could pipe to "grep denied" if you wanted. Do whatever you did to get the error again, and you should see some new lines come in like this:

type=AVC msg=audit(1609875518.415:72426): avc:  denied  { getattr } for  pid=951704 comm="cmd.cgi" path="/usr/local/nagios/var/rw/nagios.cmd" dev="dm-0" ino=68793599 scontext=system_u:system_r:httpd_sys_script_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=fifo_file permissive=0

What you need to do is use audit2allow to build policy to instead allow the denied action. So copy the single offending line of audit.log and run the following:

# echo "<replace-with-the-denied-error-message>" | audit2allow -M <some-name>

So mine looked like:

# echo "type=AVC msg=audit(1609875518.415:72426): avc:  denied  { getattr } for  pid=951704 comm="cmd.cgi" path="/usr/local/nagios/var/rw/nagios.cmd" dev="dm-0" ino=68793599 scontext=system_u:system_r:httpd_sys_script_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=fifo_file permissive=0" | audit2allow -M nagios_1

Then load the new policy:

# semodule -i nagios_1.pp

Wait a few seconds and the new policy will be in effect. Tail your audit.log and try the action again. Second time around I got a new error in the web-gui:

Error: Could not open command file '/usr/local/nagios/var/rw/nagios.cmd' for update! 

If you get another "avc denied" message take that and pipe it to audit2allow and load the new policy. Rinse/repeat until you stop getting denied messages and the action you were trying works. For the Nagios Core command I needed to do this 3 times total, but end result should be a working application and SELinux still enabled.

# echo <2nd-denied-log> | audit2allow -M nagios_2

# semodule -i nagios_2.pp

# echo <3rd-denied-log> | audit2allow -M nagios_3 

# semodule -i nagios_3.pp

Intel RST - Newest AHCI/RAID Driver by CPU Generation

Official support for various Intel chipsets gets deprecated after some period of time. Here is the most current version officially supported by each generation:

CPU Gen	CPU Arch	SATA Controller	RST Version	RST Date
1st	Westmere/Arrandale	Intel 5 Series/3400	12.9.0.1001	12/12/2013
2nd	Sandy Bridge	Intel 6 Series/C200	12.9.0.1001	12/12/2013
3rd	Ivy Bridge	Intel 7 Series/C216	13.0.0.1098	2/5/2014
4th	Haswell	Intel 8 Series/C220	14.8.16.1063	4/16/2017
5th	Broadwell	Intel 9 Series	14.8.16.1063	4/16/2017
6th	Skylake	Intel 100 Series/C230	16.5.1.1030	7/19/2018
7th	Kaby Lake	Intel 200 Series	16.5.1.1030	7/19/2018
8th	Coffee Lake	Intel 300 Series	16.5.1.1030	7/19/2018

This was derived from the iaAHCIC.inf file with each x64 release. Pretty certain if you put a 2nd gen (Sandy Bridge) CPU in a supported 3rd gen (Ivy Bridge) motherboard you would use the corresponding 3rd gen driver.

Please comment if you find any different information.

Intel WiDi on 2nd Gen Intel Core CPU

Spent some time over the holidays with some relatives. After marveling that I could use miracast to display a video from my phone on their TV, they requested I set up their laptop to do the same.

Figured it would be a pretty simple request - I was wrong. The laptop in question contained a 2nd gen Intel Core i5 CPU, so although not the latest and greatest, still very adequate for their email/web-browsing use.

I was pretty certain this system supported WiDi, but wanted to verify things before proceeding. Let's take a look at the updated system requirements for Intel WiDi:
http://www.intel.com/content/www/us/en/support/emerging-technologies/000014932.html

According to this document, Intel only supports 4th Gen Intel core and newer chips with Windows 10. That's fine - software support falls off for older hardware fairly often. Luckily, the laptop was still running 7 and the .

I went to start pulling down the software only to find this fine page from Intel's website:
http://www.intel.com/content/www/us/en/support/emerging-technologies/000021693.html

Here's the icing on the cake:

"August 15, 2016 – Intel WiDi software downloads have been removed."

That's pretty lame and smells like forced obsolescence. Stopping development is one thing, removing existing packages that might be needed by customers is another.

So editorial opinions outside here's the system components and what it took to get it working.

• Intel Core i5-2430M
• Intel Centrino Wireless-N 1030
• Windows 7 x64

GPU Drivers
First upgraded the GPU drivers (HD Graphics 3000). Grabbed the current release:
https://downloadcenter.intel.com/download/24971/

Intel File Version: 15.28.24.64.4229
Device Manager Reported Driver Date: 5/26/2015
Device Manager Reported Driver Version: 9.17.10.4229

Wireless Drivers
Next, upgraded the Intel PROSet wireless drivers. For whatever reason - searching for the drivers for this card on Intel's site results in only Bluetooth drivers as of this post... I finally found a matrix of OS/Wireless-Card/Newest-Driver which is worth it's weight in gold:
http://www.intel.com/content/www/us/en/support/network-and-i-o/wireless-networking/000005559.html

It pointed me to Intel PROSet ver 18.40.4:
https://downloadcenter.intel.com/download/26094

You need to make sure "Intel My WiFi Technology" is installed as part of the PROSet drivers. I was never offered the option when upgrading the existing drivers - had to use the procedure here (Use the modify option from Control Panel -> Programs and Features -> Intel PROSet Wireless, click the checkbox for Intel My Wifi Technology):
http://www.intel.com/content/www/us/en/support/network-and-i-o/wireless-networking/000005738.html

Intel File Version: 18.40.4
Device Manager Reported Driver Date: 4/30/2015
Device Manager Reported Driver Version: 15.11.0.9

WiDi Client
Last came the Windows 7 WiDi client. This was the real guessing game. Intel doesn't host it anymore - so good luck with 3rd party sites. The newest release I found (6.0.60.0) only supports 4th gen and newer CPUs. The installer will give an error message telling you what components aren't compatible to aid your guessing.

Finally found version 4.2.24.0 which worked. Google "intel wireless display 4.2.24.0" or the like to find it on sites like Softpedia, OEM support sites, etc. For whatever reason - the prior 4.2.19.0 release failed in install for me.

***EDIT*** Found a release of 4.2.24.0 direct from Intel:
https://downloadcenter.intel.com/download/23428/

Upon writing this, I see a release of version 4.2.29.0 (only on 3rd party sites) that would likely work as well - at least it looks legit. I'll try to upgrade if I get my hands on the system again. It also looks like there can be some weird upgrade bugs if you have an old version of the client installed, so it's likely best to perform an uninstall first.

4.2.24.0/4.2.29.0 are the newest WiDi clients I can find for 2nd/3rd gen CPUs. Please let me know if you find newer.

Conclusion
Using the above software packages I was able to cast the laptop's screen to the Smart TV without issue.

Overall Intel's driver site leaves something to be desired. When I couldn't find the WiFi driver (only bluetooth) I did try the Intel Driver Update Utility only to be met with the same results. Hopefully this is a quickly corrected bug.

The removal of the WiDi software from Intel's site is pretty poor form though. I guarantee this will be a trend that continues as many users hold onto systems longer.

There's a good chance that the same will work for 3rd Generation Intel Core CPUs (with their respective GPU driver of course).

Mushkin ECO3 120GB Review (MKNSSDE3120GB)

The OS drive for my HTPC is ancient. It's an over 13 year old IDE Western Digital 80GB HDD (WD800JB to be exact). Connected to an AMD E-350 board (the one from this post) via an IDE to SATA bridge, it was a quick and dirty solution while I looked for a permanent drive. With the system usually resuming from sleep and 8GB of memory, files need by the OS were usually cached where they could be quickly retrieved.

I've definitely got my money's worth from that HDD purchase, and since the system is usually used for streaming, I haven't really needed anything faster or larger. The only real complaint is the noticeable sound of the older drive's motor and seeking heads.

Since cheap TLC based SSDs are now available for just over $30, I figured I'd take the plunge. Also since reviews for the lower end TLC drives are a lot less common, I'll try to correct that.

I settled on the Mushkin ECO3 120GB. The price was right and the specs were competitive for this segment. Yes I could have doubled the storage for $20 more, or moved to an MLC based drive, but price was king here. I'm replacing a working solution for an already low-power system.

The actual drive is of solid metal construction - it actually has some significant weight to it. Not more so then your average HDD, but definitely more then some of the plastic-enclosed SSDs with small PCBs. Looking at the screw locations on doing my best to peak through the mounting holes shows what appears to be a full size PCB. For warranty reasons I did not dissemble the drive (yet).

The SATA and power connector use the actual drive PCB for the connector, there's no soldered on connector. I’d imagine this was done to cut costs, and seems functional, but may cause issues with frequent connect/disconnect cycles. Likely not an issue.

I could not find any published flash memory endurance numbers (TBW).

From what I can find online, the details are:
Controller: Silicon Motion SM2256
DRAM Cache: 128MB
NAND Flash: TLC (Possibly SandDisk)

There is no dashboard or other software available from Mushkin.

Formatted capacity is 111 GB (120,031,539,200 bytes)

Crystal Disk Info shows a good number of SMART attributes. Firmware version is 01126A.

My drive reported a temp of 11C for the duration of all tests. With ambient being around 21C, either the temp sensor is faulty in my unit, or multiple software tools can't read the temp correctly.

Tests were performed on an AMD 970 chipset (SB950 southbridge with SATA3 6Gb/s ports). A newer platform could have marginally better performance figures.

First order of business is determining the size of the "SLC" cache. Most cheap TLC drives utilize a subset of their TLC flash and write to it at a rate of 1 bit/cell (versus the normal 3 bit/cell) for a performance speed-up. It's assumed that later when things are idle, the SSD will move this data to TLC memory. Writing a lot of data to an empty drive that has been idle for a bit is hopefully a decent method of determining this, but there's some things going on auto-magically behind the scenes - so it's still an estimate.

HD Tune shows the delta in write speed between this SLC cache and the regular TLC memory. The cache appears to be around 2.4 GB in size. The first 2.4 GB is written at what looks to be just over 300 MB/s, peaking at 377 MB/s. Once this is exhausted, write speed will vary between about 53 MB/s and 75 MB/s (averaging closer to 75, with dips to 53).

Text output from CDM w/ IOPS

Sequential Read (Q= 32,T= 1) :   553.452 MB/s

Sequential Write (Q= 32,T= 1) :   451.892 MB/s

Random Read 4KiB (Q= 32,T= 1) :   277.322 MB/s [ 67705.6 IOPS]

Random Write 4KiB (Q= 32,T= 1) :   241.179 MB/s [ 58881.6 IOPS]

Sequential Read (T= 1) :   471.884 MB/s

Sequential Write (T= 1) :   408.721 MB/s

Random Read 4KiB (Q= 1,T= 1) :    24.943 MB/s [  6089.6 IOPS]

Random Write 4KiB (Q= 1,T= 1) :    51.998 MB/s [ 12694.8 IOPS]

Overall I think this drive will meet my use case well. The only time I expect to overflow the SLC cache would be during OS install, some major software install, or the like. Even then, the source of this data has to be taken into consideration. Short of another SSD, this system won't ever see data throughput of 400+ MB/s outside of benchmarking. It also appears that the TLC write speed (after the SLC cache has been saturated) is still faster then the old HDD's best-case-scenario transfer rate. When you add in access time that's an order of magnitude faster, silent operation, and reduced power usage, it becomes clear that it was the right time to do this upgrade.

Dell "FOR DELL INTERNAL USE" Password Protected Software

I have a Dell Inspiron 3147 which has an interesting item listed in the "Downloads and Drivers" section of the Dell support page:

INSPIRON 3147/3148/3152/3153/3157/3158 G-SENSOR CALIBRATION TOOL(FOR DELL INTERNAL USE)

This package provides Dell G-sensor calibration internally and is supported on Inspiron 3147/3148 that is running the following Operating Systems: Windows 8.1(64bit).

Link: http://www.dell.com/support/home/us/en/19/Drivers/DriversDetails?driverId=1MGNJ

So what's actually interesting is that this software is provided publicly and is contained in a password protected zip file.

(Just want to take a moment and say - the average user of this system does not need this software, I have no idea what it actually does. It's likely there so support can have customers acquire and run it when their issue meets a specific set of criteria. Also, if you break something because you ran it, that's your fault not Dell's.)

Anyways, I dumped the hashes and fed them into John the Ripper (community enhanced "Jumbo" release has support for zip file).

$ ./john ~/encrypted/gsensor.hashes 
Using default input encoding: UTF-8
Loaded 1 password hash (PKZIP [32/64])
Will run 4 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
0g 0:06:41:48  3/3 0g/s 18284Kp/s 18284Kc/s 18284KC/s hrrlek0e
0g 0:07:29:56  3/3 0g/s 18130Kp/s 18130Kc/s 18130KC/s sumspy752*..sumskres9a
0g 0:09:38:53  3/3 0g/s 17980Kp/s 17980Kc/s 17980KC/s 1823adors4..1823adysac
0g 0:12:22:09  3/3 0g/s 17700Kp/s 17700Kc/s 17700KC/s 10932sho1*..10932spyon
0g 0:12:40:15  3/3 0g/s 17654Kp/s 17654Kc/s 17654KC/s 03433750458..03434741048
0g 0:13:21:40  3/3 0g/s 17532Kp/s 17532Kc/s 17532KC/s tutiairayes..tutiaimurla
0g 0:14:12:37  3/3 0g/s 17421Kp/s 17421Kc/s 17421KC/s lemrodm118..lemras061a
0g 0:15:01:52  3/3 0g/s 17302Kp/s 17302Kc/s 17302KC/s julk4tu00..julk46mb3
0g 1:05:22:06  3/3 0g/s 18348Kp/s 18348Kc/s 18348KC/s hg,bsp14s..hg,bh kuz
0g 1:08:09:16  3/3 0g/s 18343Kp/s 18343Kc/s 18343KC/s syarcr2ab..syarf0r61
0g 1:08:40:48  3/3 0g/s 18324Kp/s 18324Kc/s 18324KC/s zzjy@sk..zz42OF5
0g 1:13:25:46  3/3 0g/s 18142Kp/s 18142Kc/s 18142KC/s lk2hv''92..lk2hv/rs5
breakfix         (gsensor.zip)
1g 3:08:27:17 DONE 3/3 (2016-02-28 11:35) 0.000003g/s 18723Kp/s 18723Kc/s 18723KC/s bree3xyh..breal5fs
Use the "--show" option to display all of the cracked passwords reliably
Session completed
$

I assumed it would be something easy/simple that support could give an end-user over the phone, but still let JTR run with the default charset just in case. Leaving it to run over the weekend - the password is:

breakfix

Kind of a let-down. My Google-fu couldn't find any other software that had similar strings in Dell's support portal. Please comment if you find others. Also interesting that I can't find any examples of this password anywhere.

Curious if this is a one-time deal, or a common password used across multiple packages to keep the average user from accidentally running something.

I will add that the zip file contains some screenshots of the software running as well as a PDF instructions:

The 2nd pic shows what appears to be a snazzy Sensors Self Test Utility (SST).

Remove Leading Zeros from IP Address

I was working on some automation where I'd need to translate an IP address that was always represented as 3 digits per octet - like 001.002.003.004 instead of 1.2.3.4.

Since I didn't want to reinvent the wheel I went to Google and to my surprise found no examples that worked well - some would only remove 1 leading zero.

So, after some testing and code borrowing, here are two solutions:

Using sed:
sed -r 's/^0*([0-9]+)\.0*([0-9]+)\.0*([0-9]+)\.0*([0-9]+)$/\1.\2.\3.\4/'

Using awk:
awk -F'[.]' '{w=$1+0; x=$2+0; y=$3+0; z=$4+0; print w"."x"."y"."z}'

POC:
$ echo 001.002.003.004 | sed -r 's/^0*([0-9]+)\.0*([0-9]+)\.0*([0-9]+)\.0*([0-9]+)$/\1.\2.\3.\4/'
1.2.3.4
$ echo 001.002.003.004 | awk -F'[.]' '{w=$1+0; x=$2+0; y=$3+0; z=$4+0; print w"."x"."y"."z}'
1.2.3.4

Level 3 DNS Hijacking - 4.2.2.2 and others

I posted about Verizon's DNS servers and how some of them perform DNS hijacking for domains which don't resolve. While troubleshooting a problem today I found out to my surprise that Level 3's DNS severs do the same thing, one of which has some notoriety.

Level 3 DNS Servers:
4.2.2.1
4.2.2.2
4.2.2.3
4.2.2.4
4.2.2.5
4.2.2.6

The odd ones (.1, .3, .5) will correctly reply with NXDOMAIN for FQDNs which don't exist. The even ones (.2, .4, .6) will instead resolve to two "SearchGuide" IPs:

~]$ dig @4.2.2.2 domain-i-just-made-up.fake +short
198.105.244.11
198.105.254.11

Any hosts that may have been configured to use these Level 3 DNS servers will have some interesting outgoing connections when trying to connect to internal hosts that aren't externally resolvable. Hopefully this will save a few minutes when investigated unusual connections to 198.105.244.11 or 198.105.254.11.

Offline Dell PowerEdge Firmware Updates Using the LifeCycle Controller

Dell's FTP servers they host firmware updates on aren't the best - especially when being accessed from the Dell USC Lifecycle Controller. Usually things work fine, but every now and again things go south and you end up seeing a screen like this:

"A network error occurred while trying to connect to the FTP server. Check your network connections, cables, settings, and configuration..."

...or sometimes like this:

"The update packages that you selected to install failed during download or installation. Retry the operation or provide an alternate repository."

Both results can make your day sour fast if you scheduled downtime or are working in a maintenance window. The second error above gives the suggestion to "...provide an alternate repository" and the menu used when launching the the Platform Update has the options of using a Local Drive. I never gave this much thought until I needed to do some updates outside of the OS and couldn't connect to Dell's FTP server. Enter Dell Repository Manager.

I'm not going to walk through the steps since they are well documented on Dell's site, but this should be all you need (for : Lifecycle Controller with Dell Repository Manager

This document outlines how to create a local USB or ISO repository that you can then use to perform these updates offline. You could even have it output to a directory on an FTP server accessible by all your servers.

I always assumed that tools like these weren't that useful unless I was managing hundreds of servers, but it turns out they're great even if you need to update just one.

Verizon FiOS Regional DNS Servers

Verizon provides their FiOS customers with 2 regional DNS servers via DHCP that are geographically close to their install location. The default address given out is a ".12" address which utilizes DNS Hijacking to serve you ads from Verizon. Each region has a corresponding ".14  DNS server which does not hijack DNS. Changing to this ".14" address is the method Verizon utilizes for allowing customers to opt-out of their "DNS Assistance".

I couldn't find a complete list of these online, so with a little digging I put this together.

Regional DNS Servers, opt-in/opt-out are listed below. There are many other valid Verizon DNS servers, but these are the ones given out to customers via DHCP. If you are aware of any additional DNS servers given out via DHCP to FiOS customers, please let me know in the comments.

Boston, MA:
nsbost01.verizon.net - 71.243.0.12
nsbost02.verizon.net - 71.243.0.14

New York, NY:
nsnyny01.verizon.net - 68.237.161.12
nsnyny02.verizon.net - 68.237.161.14

Newark, NJ:
nsnwrk01.verizon.net - 71.250.0.12
nsnwrk02.verizon.net - 71.250.0.14

Philadelphia, PA:
nsphil01.verizon.net - 71.242.0.12
nsphil02.verizon.net - 71.242.0.14

Reston, VA:
nsrest01.verizon.net - 71.252.0.12
nsrest02.verizon.net - 71.252.0.14

Atlanta, GA:
nsatla01.verizon.net - 68.238.120.12
nsatla01.verizon.net - 68.238.120.14

Tampa, FL:
nstamp01.verizon.net - 68.238.112.12
nstamp02.verizon.net - 68.238.112.14

Dallas, TX:
nsdall01.verizon.net -  68.238.96.12
nsdall02.verizon.net -  68.238.96.14

Los Angeles, CA:
nslala01.verizon.net - 68.238.64.12
nslala02.verizon.net - 68.238.64.14

Seattle, WA:
nsseat01.verizon.net - 68.238.128.12
nsseat02.verizon.net - 68.238.128.14

(Added 5/5/2016)
Chicago, IL:
nschic01.verizon.net - 68.238.0.12
nschic02.verizon.net - 68.238.0.14

Use tcpdump to Filter and Merge Multiple pcap Files

The other day I had a couple dozen pcap files (each just under 1 GB in size) that I wanted to filter the traffic of one host out of. A couple different options come to mind - merge the pcap files together and then filter, or filter each pcap separately and then merge the results together. Both of these are pretty sloppy ways of doing this if you don't do it in one line:

# mergecap -w /dev/stdout file1.pcap file2.pcap file3.pcap | tcpdump -r - -w output.pcap host 192.168.1.10

mergecap reads the list of files at the end as input and writes them out to /dev/stdout, where tcpdump reads them in and writes the result to output.pcap after applying the filter (host 192.168.1.10).

Single Line Base64 Decoder

If you have a chunk of Base64 encoded data and want to decode it, the quickest method is usually to find some online decoder. If you're worried about the sensitivity of the data or don't have access to a web browser or even the Internet you'll want to decode it locally.

To do this you'll need perl (should be installed on most linux distros). Given any file containing only Base64 encoded text, ex:

$ file base64_file
base64_file: ASCII text, with CRLF line terminators
$

The following command will decode the text:
(NOTE - the file must contain ONLY Base64 encoded text - any existing decoded data will break the process)

$ perl -MMIME::Base64 -e 'print decode_base64(join("",<>))' < base64_file >output
$ file output
output: HTML document, ASCII text, with CRLF line terminators
$

If done correctly the output file should contain the decoded data.

Legacy tcpdump - "Packet size limited during capture"

Was doing some debugging the other day on a legacy system with an older version of tcpdump installed. When I imported to packets to Wireshark in order to better interpret the results - I saw the familiar message "Packet size limited during capture":

You never realize there's a problem with a packet capture until after you've finished and shipped it somewhere else for analysis

It's then I remembered that older versions of tcpdump default to a snaplen of 68 bytes. In order to correct this you need to manually specify a longer snaplen. From the manpage of tcpdump 3.9.4:

-s   Snarf snaplen bytes of data from each packet rather than the default of 68 (with SunOS's NIT, the minimum is actually 96).  68 bytes is adequate for IP, ICMP, TCP and UDP but may truncate protocol information from name server and NFS packets (see below).  Packets truncated because of a limited snapshot are indicated in the output with  ''[|proto]'', where proto is the name of the protocol level at which the truncation has occurred.  Note that taking larger snapshots both increases the amount of time it takes to process packets and, effectively, decreases the amount of packet buffering.  This may cause packets to be lost.  You should limit snaplen to the smallest number that will capture the protocol information you're interested in.  Setting snaplen to 0 means use the required length to catch whole packets.

So in order to capture the whole packet, you need to set a snaplen of 0 using the option "-s 0":

~]# tcpdump -i eth0 -n -s 0 host 192.168.1.1

This would capture traffic (-i eth0) on the eth0 interface, (-n) not converting host addresses to names, (-s 0) capturing the entire packet, (host 192.168.1.1) where the packet is to/from a host with the IP 192.168.1.1.

Single Line Web Server in Python

This is an old trick, but very useful for transferring files in a pinch - especially in cross platform situations. Also great if you need a simple web server for testing.

The commands are simple.

For Python 2.x: python -m SimpleHTTPServer

[user@fedora folder1]$ python -m SimpleHTTPServer
Serving HTTP on 0.0.0.0 port 8000 ...

For Python 3.x: python3 -m http.server

[user@fedora folder1]$ python3 -m http.server
Serving HTTP on 0.0.0.0 port 8000 ...

Both of these default to port 8000, but you can add a port number to the end of the line to specify something else if you like. The current directory is used as the root folder. If an index.html or index.htm file is present it will be served initially, otherwise the server will provide a directory listing. Just point your browser to the system:

http://<your-ip-address>:8000

Make sure your firewall/IP-tables are properly adjusted to allow the inbound connection.

The terminal will show a running Apache style access log of connections. CTRL + c to exit.

Performance is pretty good too:

Official documentation here:
https://docs.python.org/2/library/simplehttpserver.html
https://docs.python.org/3/library/http.server.html

Quick Decimal, Hex, Binary, Octal Conversion on Windows

Sometimes you just need a quick and dirty way to convert between number systems (decimal, hex, octal, binary). The built in Windows calculator will actually do this for you. Simply start the calculator and under "View" choose "Programmer".

This should switch to the Programmer calculator view. Set the mode to whatever number system you are converting from - it should default to Decimal, and enter the number.

From here you just select the number system you want to convert to.

The number auto updates to the new number system. Done, quick and easy.

Cooling Down an ITX Board by Replacing Junk Thermal Pads

About a year ago I picked up the Sapphire Pure Mini E-350. I subsequently put a system together around it on the cheap over the next 2-3 months as some good deals showed up. It's performed well enough for some light HTPC duties (Netflix, a little indie gaming, etc.), and has enough expansion options and flexibility to have some decent longevity.

Being a mini-ITX board, the cooling is nothing to really write home about - especially with its screaming 40mm CPU fan, but this really shouldn't matter since it has such a low power draw. Since I had recently toyed with the option of leaving it on 24x7 I decided it was time to double check just how bad the temps could get if left unchecked. So I started OpenHardwareMonitor, loaded up the CPU and GPU and let it sit for an hour. Upon coming back to check how things were, I was pretty shocked:

Looking at the temps:
Max CPU: 89.8° C
Max GPU: 90.0° C
Max Temp 1: 78.0° C (I'm assuming this is the FCH -Fusion Controller Hub, see why below)

Just a note that the CPU and GPU temps should always be almost identical considering both parts are on the same die.

After idling for a while temps dropped to around the current values in the screenshot above:
Idle CPU: 62.0° C
Idle GPU: 62.0° C
Idle Temp 1: 52.0 C

Not what I like to see for a product I'm thinking of holding onto for a while. Let's see what the problem is.

The two heatsinks on the board have to be for the APU (CPU and GPU), and FCH. The APU (AMD E-350) has a max TDP of 18 watts, and FCH (AMD A50M) of 5.9 watts. Fully loaded these will get pretty toasty. Time to void the warranty.

First, we pop off the APU heatsink. It's mounted well with 4 spring loaded screws from the back. It has a crappy thermal pad slapped on the bottom:

Notice how thick the material is where the APU made contact - not good for thermal conduction at all. Residue still on the APU, you can see how brittle the material is:

I removed the residue from the APU with isopropyl alcohol. Then, I scrapped it off the bottom of the heatsink with a small wooden skewer. The entire bottom is a rough finish of anodized aluminum. To do this right, the bottom should really be sanded and lapped to a nice finish, maybe a project for another day. At this point - lets check on the FCH:

Same story as before, looks like the pad was almost folded over too. I finished cleaning everything up - we're ready for some thermal paste:

I applied some Arctic Silver I had lying around - really almost anything would be better then the original stuff. Once everything was back together, I powered on and went strait to the BIOS to monitor temps before booting. Things looked good, so I let it boot and ran our test again:

What a huge difference:

Max CPU: 75.3° C        - Δ of 14.5° C
Max GPU: 75.0° C        - Δ of 15.0° C
Max Temp 1: 62.0° C    - Δ of 16.0° C

Idle CPU: 47.5° C          - Δ of 14.5° C
Idle GPU: 47.0° C          - Δ of 15.0° C
Idle Temp 1: 36.0° C      - Δ of 16.0° C

What a huge difference! I was kind of surprised that the temp delta was identical between load and idle, but this is likely due to the rough bottom of the heatsink. Things should only improve as Artic Silver takes several heating/cooling cycles to spread out and "flow" evenly.

Looking at improving things further, the APU heatsink is larger then the 40mm fan. I test fitted a 60mm fan and it would fit while hanging off on one side. This would provide increased airflow over a larger surface area, all while spinning at at a slower speed. I could have this fan hang over the passively cooled FCH heatsink, further improving tempts there.

The board does also support a 4-pin PWM fan on the CPU. This would be an additional option to quiet things down when idle.

I'll update in a few weeks once the thermal paste has cycled a bit.

Dell PowerEdge R610/R710 Firmware - "The updates you are trying to apply are not Dell-authorized updates"

The other day I was performing some much needed firmware updates on a Dell PowerEdge R610 using the built in UEFI GUI. This usually goes pretty smoothly, but this time I received the following message:

"The updates you are trying to apply are not Dell-authorized updates."

After searching around I finally came up with a solution. The firmware updates have the signing certificates checked by iDRAC and the Lifecycle Controller. Dell changed/expired their cert so it is no longer considered valid by the old firmware. To get the new certs to be considered valid the iDRAC and Lifecycle Controller need to be updated, but since they are considered invalid this can't be done from the UEFI GUI. The answer is to update from the iDRAC web GUI.

Quick note: I documented this after updating, so some screenshots and instructions may not be 100% exact, but should be close enough to get through. Also, if you FUBAR your server its on you. This worked for me, but verify that the files mentioned and process shown match your hardware.

On reboot enter the iDrac by hittering CTRL-E when prompted:

Now enable iDrac. Set "iDRAC6 LAN" to "On":

Under "LAN Parameters" scroll down to IPv4 Settings and set IPv4 to "Enabled" and set valid LAN parameters (static would likely be easiest):

Now would also be a good time to set your iDrac credentials to something you know. Set the password in "LAN User Configuration":

Save changes and exit.

The server will start to boot normally. Would be best to halt the boot process here as you'll just have to reboot again soon (Windows - F8, VMWare - CTRL+O, Linux - Arrow keys, etc).

Now you need to wait for the iDrac to start its networking services. This could happen in 30 secs, or maybe a few minutes. I usually just run a continuous ping of the IP I just set it to until I start seeing a response.

Log into the iDRAC web GUI - https://<IP-you-set-the-idrac-to> (root and whatever you set the password to)

Click the "iDRAC Settings" on the left then choose the "Update" tab at the top:

Download this file (Life Cycle Controller Repair): http://downloads.dell.com/FOLDER00502596M/1/BDF_1.5.5_BIN-12.usc

Click on the "Choose File" button and point it at the BDF_1.5.5_BIN-12.usc file. Click "Upload".

The file will be uploaded and after a few minutes it will prompt you if you want to update. Choose Yes. It should quickly come back saying the update has been applied successfully.

Download this file (iDRAC firmware updater): http://downloads.dell.com/FOLDER01270825M/1/iDRAC6_1.95_A00_FW_IMG.exe

This contains a .d6 file you need (firmimg.d6). I just extracted the file from the exe using 7zip.

Navigate back to the update page (I had to navigate to a different page first) and upload the .d6 file.

The file will be uploaded and after a few minutes (could take up to 20) again it will prompt you if you want to update. Choose Yes. Eventually it should come back saying the update has been applied successfully and the iDRAC will now restart.

You now have to wait for the iDRAC to restart. I just run a continuous ping again and wait to see a few timing out - this happens when iDRAC restarts. Once it starts responding it's successfully restarted.

Restart your server and enter the UEFI - "F10 = System Services"

Run your update again and it should now complete successfully (usually takes several reboots). When its done it will drop you at the main UEFI screen. I usually run the update one more time and it should show everything at the current version:

Reboot and disable iDRAC again unless you have appropriate security measures in place to protect it.

I was able to apply the same process to both R610 and R710 servers of the same generation. YMMV.

Credit to the original thread where I found this solution: http://en.community.dell.com/support-forums/servers/f/177/t/19475476.aspx

iPad 2 + iOS 7 = Weak WiFi Signal

A few weeks ago my SO upgraded her iPad 2 to iOS 7. No issues other then the the iPad would show an extremely weak WiFi signal throughout the house, where previously the signal was good. Other devices showed no problem in these locations so it was clearly the iPad that was at fault.

Went through all the recommended things: reset networking in iOS, changed channel on AP, tried a different AP, and still had the same problem.

I had recently picked up a dual band AP but hadn't gotten around to migrating over from the old one yet, so on a hunch a powered it on. Low and behold the 5 GHz SSID is immediately seen by the iPad, while the 2.4 GHz one is no where to be seen. This of course contradicts the usual observation that 2.4 GHz networks should have better coverage due to poor wall penetration by 5 GHz signals.

This at least provided a band-aid while I figured things out.

While looking around for more solutions I came across several forum posts stating setting their network to N-only had helped with little additional explanation. So on a whim I set my AP to N-only and with that change the iPad suddenly showed the network it previously couldn't find when it was more then a few feet from the AP.

Going through all the possible setting for the WiFi mode with the iPad in a single location:

Mode	Signal
802.11 b/g/n	None
802.11 b/g	None
802.11 g/n	2 Bars
802.11b	None
802.11g	None
802.11n	2 Bars

Tried this with a different brand AP and saw the same results. That's good enough evidence for me. There is clearly an issue with iOS 7 and how it handles mixed mode wireless standards - specifically non-N or modes including B. Since it isn't all iOS 7 devices there has to be some other factor - likely firmware loaded at run-time by iOS for the wireless chipset in the iPad.

Changing the setting fixes things while the iPad is home, but does little everywhere else since almost all routers/APs will be set to some mixed mode out of the box for maximum compatibility. 

I'm waiting for a fix Apple.

TRENDnet TEW-711BR Review

So I needed to get a router for my grandmother-in-law after finding out her PC was directly connected to her cable modem. She only has one device (her computer) which is only used for email and web browsing. She doesn't need wireless, but obviously needs something that can be set and forget. I went for a gamble and picked up a TRENDnet TEW-711BR, it was on sale at Newegg for $15.99 with free shipping and I had yet to have bad luck with TRENDnet products so far.

The router was held securely in the box in a cardboard tray. Almost everything it was shipped in was recyclable which is nice. Received hardware version 1.0R. Shipped with firmware version 1.00b31, updated and tested with 1.01b09.

For my testing I applied a "load" using iperf. Power measurements taken with a Kill-a-Watt. I used the web GUI to disable the WiFi radio.

Router Status	Power Usage
Idle (Wifi on)	1.6W
Load LAN-WAN (Wifi on)	2.0W
Load WLAN-WAN (Wifi on)	2.0W
Load WLAN-LAN and LAN-WAN (Wifi on)	2.2W
Idle (Wifi off)	1.1W
Load LAN-WAN (Wifi off)	1.6W

Routing

Iperf testing shows that this router is limited only by its 100 Mbps WAN port. Using two client and two server processes I was able to sustain just under symmetrical 100 Mbps speeds between LAN to WAN(~94.3 Mbps, just under 190 Mbps bi-directional). Refreshing Steam servers multiple times while playing Team Fortress 2 showed no impact and no issue with browsing on a different system. Ping times remained low throughout this as well. I measured the max simultaneous connections at 3973 - so this is likely around 4096 total connections. Overall this router offered impressive performance for its low-end price point.

Wireless

Wireless coverage is average for a low-cost, single-antenna device. Performance is acceptable - iperf testing showed real world throughput of around 38 Mbps at a distance of a few feet - Windows showed a connection speed of 130 Mbps. Separating myself by about 2 stories I had much poorer signal, but could still browse the web and stream video without issue. 40 MHz channel width testing was not possible due to the crowded 2.4 MHz spectrum in my location. Wireless performance was certainly acceptable.

GUI

The Web GUI is fast, simple, and intuitive. All the usual features found in modern routers are present. One very neat feature is the ability to capture packets from either the WAN and LAN interfaces. When you stop a capture, the packets can be downloaded in a standard Wireshark .pcap file. I'm not sure what the limit is as to how long you can capture for, but this was a pretty neat feature for such a cheap device. The normally common feature of a Guest wireless network was not present.

Other

Device is light, but has rubber feet to keep it sliding around. 5 year warranty is admirable, but I hope I never have to use it. Through all the testing/loading the max temperature reached was around 92F at the top of the enclosure measured by an infrared thermoeter (~77F ambient). Normal operating temp was much lower at around 80F. I never had to reboot or power-off the router during testing

Conclusion

Highly recommend for the light user or someone not needing the latest and greatest WiFi coverage. Fantastic bang-for-your-buck at the price point I paid. At a normal price of around $25 there are likely better options out there.

Intro

So after wrestling with the concept for a few months I've committed to finally starting a blog. I have obviously ended up using Blogger vs Wordpress after weighing the pros and cons. The future chance of simple monetizing is a plus along with some of the less Wordpress'y junk. I've also decided to use my real name since my end hope will be to (hopefully) build some professional credibility.

Primary focus of this will likely be all things technology with a focus on IT, InfoSec, engineering, hardware and anything else I find interesting.

Here we go.