Networking

Windows 10 Spurious Wake – Check Your NIC Power Settings!

Published by on May 29, 2017 | 1 Response
Really? REALLY?

I put my Windows 10 desktop to sleep last night and laid down in bed to engage my own “sleep mode”. Five minutes later, with a frantic rush of cooling fans, my PC woke itself back up. I gave the cheerful login screen the middle finger, shut it down, and made a mental note to troubleshoot in the morning.

There’s tons of forum threads and blog posts on Google about spurious wakeups. My old Windows 7 laptop used to wake itself up for the sole purpose of going into hibernation if it had been left in sleep mode for longer than six hours on battery. My Windows 8.1 tablet…still does whatever the heck it’s doing to drain the battery. And my Windows 10 laptop has occasionally woken itself to do updates.

But the cause of my desktop waking up was none of these. Instead, Event Viewer shows me this:

Really? REALLY?

 

To verify, I put my computer to sleep while pinging it with arping from a Linux box. Interestingly, even in the brief time it was asleep, arping continued to receive responses. A few seconds later, the machine boot up again.

This can probably be fixed from the BIOS/UEFI. However, another quick fix is to open the NIC settings in Device Manager and either uncheck “Allow this device to wake the computer” or, if you still want Wake On LAN capabilities, check “Only allow a magic packet to wake the computer”. Apparently, by default, the computer can be woken by any packet that is directed to the NIC. In a noisy LAN environment, this is unacceptable.

Check the circled box if you want to keep WOL; uncheck the box above if you don’t want it to wake your computer, ever.

 

Note that I still haven’t figured out root cause–what sent the traffic in the first place–but that can come later.

 

 

OpenWRT on a “locked down” TP-Link WR1043ND v3 wireless router

Published by on July 7, 2016 | 4 Responses

It turns out that the brouhaha over certain manufacturers’ reactions to the FCC ruling to prevent 3rd-party software from taking wireless routers out of their approved emissions range is valid. I bought a TP-Link WR1043ND v3 router to compliment the existing v2 router I bought several years ago. I have a point-to-point setup with OpenWRT on both ends. It turns out that TP Link has indeed started locking down their routers to prevent third-party firmware installations. (I had hoped that buying the older V3 would get around this, but apparently not so.) Setting up OpenWRT is now a little bit (but not much) more difficult than it was on these routers.

Fortunately, it seems that TP-Link has only locked down the web interface to prevent third-party firmware installation and downgrading factory firmware. You’ll get an error 18005 if you try this. TFTP still works. In the end, the steps to flash were the following, based on the information at the OpenWRT wiki. You’ll need a Linux machine with DNSMasq installed.

  1. Download the factory OpenWRT trunk image for the WR1043ND v3. Currently as of July 7, 2016: https://downloads.openwrt.org/snapshots/trunk/ar71xx/generic/openwrt-ar71xx-generic-tl-wr1043nd-v3-squashfs-factory.bin
  2. Rename the OpenWRT file to wr1043v3_tp_recovery.bin
  3. Move the file to /tmp
  4. Set your NIC’s address to 192.168.0.66 and hook up the router, but don’t power it on yet.
  5. Use DNSMasq as a quick tftp server with the following command: dnsmasq -d –enable-tftp –tftp-root=/tmp
  6. In another terminal window, use tcpdump to view traffic on your NIC.
  7. Hold down the router’s reset button and power it on.
  8. Hold the reset button until tcpdump shows the file transfer.
  9. Wait 5 minutes

The OpenWRT build doesn’t have the web GUI installed. Fortunately, that’s easy to fix:

  1. Use SSH to log into root@192.168.1.1
  2. Hook the router’s WAN port to a LAN switch (to give it Internet access)
  3. Run opkg update && opkg install luci on the router
  4. Run reboot on the router
  5. Visit 192.168.1.1 and enjoy

HughesNet Troubleshooting

Published by on July 27, 2015 | Leave a response

Update: After about a week, HughesNet pushed out a potential fix to my specific modem. Although I don’t know exactly what bits got flipped, the problem is now solved, and the fix will be pushed out to other subscribers’ modems in the future. Thank you, HughesNet!

Old post:

This post is for the benefit of HughesNet tech support/engineering personnel. These are my troubleshooting notes.

Large (>1MB) downloads have been failing for me on certain URLs, although smaller downloads fail as well. HTTPS fails more than HTTP. This has been happening for at least a month. Other users are reporting the same issue.

Files that usually fail to download:

https://pypi.python.org/packages/source/D/Django/Django-1.8.3.tar.gz#md5=31760322115c3ae51fbd8ac85c9ac428

https://rubygems.org/downloads/nokogiri-1.6.6.2.gem

A third, that occasionally produces the problem, is an HTTP download:

http://nl.archive.ubuntu.com/ubuntu/dists/vivid/universe/source/Sources.bz2

Occasionally, GitHub repos will fail to fetch for the same reason. This is particularly annoying because Git offers no way to resume a partially-fetched repository.

This Git repo is known to do so when cloned using HTTPS or using the Git protocol:

https://github.com/otwcode/otwarchive

Troubleshooting steps taken:

  1. Disable/Enable Web Acceleration (no change in HTTPS downloads, didn’t test HTTP download with Web Acceleration yet).
  2. Several modem reboots (soft reboots from the control panel and hard reboots by pulling the plug from the wall and waiting several minutes).
  3. Several router reboots (soft reboots from the control panel and hard reboots by pulling the plug from the wall and waiting several minutes).
  4. Router bypass (connecting a laptop directly to the modem).
  5. Cable swaps (replacing modem LAN cable with a known good one).

Problematic operating systems and browsers:

  • Windows 7 (IE 11, Firefox, Chrome)
  • Windows 8.1 (IE 11, Firefox, Chrome)
  • Ubuntu Linux 14.04 (Firefox, wget)
  • Ubuntu Linux 12.04 (wget)
  • SuSE Linux 12.3 (wget, and yeah yeah, I know, 12.3 isn’t getting security updates anymore…)

Other information:

IPv4 and IPv6 connections are both susceptible to failure.

A number of people on the HughesNet support forum have also reported issues with these files. A number of them are on the HughesNet’s AMA IP gateway. Another is on the Tuscon, Arizona gateway. The HughesNet Community support thread is here.

The HTTPS downloads fail whether Web Acceleration is enabled or not.

Packet Captures (Wireshark format):

http://nl.archive.ubuntu.com/ubuntu/dists/vivid/universe/source/Sources.bz2 over IPv6:

Client side: https://jacksontech.net/sourcesbz2.failed.client.pcapng

Server side: https://jacksontech.net/sourcesbz2.failed.server.pcapng

Random thoughts:

HughesNet alters TCP packets mid-flight. :( You can see this in the packet captures above. Something between my client and the server has taken upon itself to act as a TCP endpoint. Not nice.

Goodbye, Old Router

Published by on July 18, 2015 | Leave a response

I retired my old router a few days ago. (I might’ve cried.) For the past few years my router has been a computer powered by a 900MHz Celeron CPU (512MB RAM, 2x gigabit PCI-X NIC, 2x 100MBit NIC). And it worked great. It used a Compact Flash card as its hard drive via a CF->IDE adapter and could push 300MBit/s across any two interfaces; it used CentOS 6 and packages like dnsmasq to provide various services on the network: dhcp/dhcp6, dns, ntp, etc. I had built the router as a project to learn about Linux and networking, and I had chosen that old computer because it had a serial port for a 28.8k modem.

The problem was, it used a lot of electricity for what it did; my Kill-A-Watt meter reported about 45W idle and 65W when under full load, compared to 5W-10W for modern routers. So I found a Cisco-Linksys WRT160Nv3 router for $5 at a thrift store and slapped OpenWRT on it.

The WRT160Nv3 is at least mostly supported by OpenWRT; I built my own custom image for it as I did for the RouterBoard RB411 awhile back. I’m not confident that the BCM4716B0 Wireless N radio is fully supported; there are several drivers for Broadcom chipsets and since I only needed G speeds (for a guest network), I selected the open-source b43 wireless firmware instead of the proprietary Broadcom wireless driver, out of principle. The Broadcom driver likely supports N speeds. There is a third driver (brcm80211) but I didn’t test it; you might have more luck than I did. You can switch between all of these drivers in the OpenWRT menuconfig system.

I also added some goodies to the image: iftop, tcpdump, and LuCI, the OpenWRT web UI, because it has totally spoiled me rotten. Adding them to the image instead of as modules saves space, which is important because this router has only 4MB flash. I shaved off space by disabling kernel debug symbols and removing a few other things, including opkg and ppp support.

Flashing was a minor challenge because the bootloader’s handling of TFTP flashing is broken. (This makes bricking a little easier, so be careful!) If flashing the OpenWRT from the stock web UI doesn’t work, flashing DD-WRT onto the device and then flashing OpenWRT via DD-WRT’s UI will.

After installing, I set up each port on its own VLAN, one for each subnet, and configured each one so the device would be a drop-in replacement for the Celeron box. It took a day or so of tweaking but I’m finally happy with the configuration. I even have a spare port to spin up whenever I want, although currently it’s disabled.

So how well does it work?

The wireless connection is stable; I can push 16-20Mbit/s through it without issues, which is decent for Wireless G. The device can push about 50-60Mbit/s tops between interfaces before its little 300MHz CPU gets saturated. Considering that my Internet connection is 10Mbit/s max, and the things the other ports are connected to top out about 40-50Mbit/s, it works out. For the price and the amount of electricity the device uses, I couldn’t be happier.

There’s two caveats.

One: whoever designed the case probably didn’t take a course on thermodynamics. There are actual vents, which is nice (two of my older routers have nothing more than tiny slots), but they’re around the edge of this plastic dome that collects heat at the top. Ooops! Wishing I had my Dremel tool still. It hasn’t overheated yet, but just in case I raised it up on two mechanical pencils to allow more airflow.

Two: it’s silent. That’s usually a good thing, except the Celeron router wasn’t; it had a single moving part (the power supply fan) that made a comforting whisper 24/7. I’ve had that sound in my ear for the past 4 years whenever I sleep. Now I have to get used to barking dogs and the garbage truck going past at 3AM–or find something else to make an equivalently soft noise. Preferably a something that doesn’t draw 45W power constantly!

 

Galileo temperature sensor code now on Github

Published by on July 10, 2015 | Leave a response

I cleaned up the Python source code for the Intel Galileo temperature sensor I blogged about earlier this summer, and pushed the source up to my GitHub account. The code is very brute-force and make-do (it was written in a very short period of time during a very crazy semester and hasn’t been touched since) but I think it will be more useful online than sitting on my drives.

The temperature sensor is a TMP36 analog temperature sensor. I followed the directions at Adafruit to assemble a circuit and hook it up to my Galileo Board 2. I used the same circuit diagram as shown–the Galileo Board series and the Arduino shown are electronically compatible–although I added a 0.1uf capacitor between VCC and GND as suggested by a commenter at SparkFun and the TMP36 datasheet to cut down on noise. (No, I’m not sure this is necessary, but the capacitor was cheap and the resulting measurements seemed accurate within a degree or so. Maybe I should take some EEE classes next semester to find out what it’s actually doing?)

The daemon itself is written in Python 2 and runs under Yocto Linux (the Intel-provided full-sized Linux SD card image for the Galileo Board 2). A LSB script does a little configuration in /proc to give access to the analog input pins and then starts the daemon. The daemon listens on port 8080 for HTTP requests and serves up temperature data for the past 15 minutes, the past hour, the past day, and the past week, returning the data as a JSON feed that can be graphed by a library like MetricsGraphics.

Instructions for setting up the daemon are on the GitHub page. You’ll need the Galileo SD Card Image to install Yocto Linux. The newest version, 1.0.4 at the time of writing, is much smaller than the version I have. You made need to go to the old downloads page and download version 1.0.3 if the newest version does not have Python available.

In case you missed it, the feeds from the project can be seen in graph form here.

Galileo Board Temperature Sensor

Published by on June 17, 2015 | Leave a response

My independent study project turned into a full-blown research project last semester. The project involves benchmarking lots of physical and virtual machines, which means the project involves generating lots and lots of heat. My equipment is in a room that has no air conditioning on evenings and weekends. I knew it got hot in there over the weekend, but I wanted to know: just how hot did it get?

So, using the Intel Galileo Board 2 I won at IDF2014, I cobbled together a smart temperature sensor. It uses a TMP36 analog temperature sensor wired to the Galileo’s Arduino-compatible analog input pins. With the Yocto Linux image on an SD card, a little Python daemon, and some /proc filesystem flags tweaked to control the Galileo’s onboard analog-to-digital converter, I can scrape data from the temperature sensor and make it available as JSON feeds, which were then read in by another script to be processed into a HTML report. It’s a little kludgy, but it works.

You can find the actual (current) feeds of the equipment room here. A glance at the week graph shows the pattern of air conditioning availability.

I’ll release the source code and write up step-by-step instructions soon.

 

Fun With Routers, part 2 – Netgear WNR1000v2 VC + OpenWRT

Published by on March 28, 2015 | 3 Responses

Garage sales. Garage sales are awesome. I picked up a Netgear WNR1000v2 VC router at a garage sale for $5 last year. That’s a bargain, until you realize that this router should’ve retailed for $5. The stock firmware is terribad and limited. A JavaScript bug prevents WPS from being disabled unless you visit the administration page using Internet Explorer. It doesn’t help that some of these units were modified by Comcast to only accept certain firmware updates, and then passed out like candy to clueless Internet subscribers who needed a troublesome device to scream at daily. (As if dealing with Comcast wasn’t bad enough already.)

Enough ranting. Here’s the cool part: OpenWRT didn’t support it at the time. No, wait, that’s not the cool part. The cool part is, I accidentally got a custom build of OpenWRT onto the thing after investing in a USB TTL serial adapter and flailing around with OpenWRT’s source code. Wait, that’s still not the cool part.

I don’t remember how I got it working. It was towards the end of last semester, and last semester was two forevers ago in computer years. I posted on the OpenWRT forum but didn’t get any response, and I didn’t know enough about OpenWRT’s internals to submit a patch, so I slapped my hackish build onto the device and immediately forgot about it.

But! A hardworking developer who goes by the handle SaltwaterC took the time to figure out this pesky little device and made some nice builds and patches. That’s the cool part. Thanks, SaltwaterC!

If you have one of these, don’t throw it out! They actually work great with OpenWRT, especially if you can rescue one from the bargain bin at your local thrift store.

MicroTik Routerboard 411 + OpenWRT: Update

Published by on October 31, 2014 | Leave a response

The ailing Routerboard 411 in one of my previous posts has been sitting in a plastic tub under my bed awaiting replacement capacitors, a sudden level-up in my soldering ability, and a dramatic increase in my level of confidence in not destroying things by jabbing at them with a giant heating element. I still have none of the three; however, one of my friends donated his time and effort and replaced the four dead capacitors for me. (Thanks, Will! I owe you a gift card.)

Now that the capacitors have been replaced, I’ve put OpenWRT on the device for good. The instructions here are dubious. I did things the manual way according to this blog post, starting from the point after I had booted into OpenWRT’s ramdisk image as detailed in my previous post about this router.

(more…)

Fun with routers, part 1: MicroTik Routerboard 411 + OpenWRT

Published by on July 11, 2014 | 1 Response
Routerboard running OpenWRT Attitude Adjustment

My father uses a WISP for his Internet access. His equipment malfunctioned recently and a technician came out to examine the antenna. He discovered that the circuitry inside it had failed; instead of throwing it away, he offered it to me.

Meet the MicroTik Routerboard 411.

(more…)