Network Connections – Technical Intercourse

Linux WiFi on HP Pavillion AIO

I bought a HP24 B110D all-in-one desktop PC from HP. I decided to run Ubuntu MATE LTS 16.04 on it. It’s a pretty nice machine and nearly everything works right out of the box, with Linux. Unfortunately, one thing that randomly failed regularly, was the WiFi connection. The kernel module would crash rather spectacularly.

After some investigation, I attempted various fixes that didn’t work. I tried to turn of 802.11n, which resulted in the WiFi connection running a little longer before it crashed spectacularly. I also tried to install the latest firmware for the driver from Intel, which didn’t have any discernible affect on the system.

In the end, the actual fix needed was to disable the HP WMI driver. So, all I had to do was to add in the appropriate blacklist to modprobe.
blacklist hp-wmi

That did the trick and now my desktop works like a charm.

NAT64/DNS64 on OpenWRT

The latest stable release of OpenWRT – Barrier Break – makes it a simple matter to add NAT64 and DNS64 capabilities to the router. This is particularly useful if one wishes to run an IPv6 only internal LAN network while dealing with the IPv4 + IPv6 world of the Internet.

DNS64

DNS64 provides a faux AAAA record for any existing A record. The easiest tool to use for this is TOTD, which is no longer in development but is found in the main OpenWRT repositories.

So, install TOTD and configure it.

# opkg update
# opkg install totd
# vi /etc/totd.conf

The totd.conf file should contain the following:

; substitute with your upstream DNS
forwarder 8.8.8.8 port 53
forwarder 8.8.4.4 port 53
; modify your OpenWRT ULA prefix here
prefix fd63:fab9:6ccf:64::
; this port is used later
port 5353

Enable and start TOTD, and check the logs for any errors:

# /etc/init.d/totd enable
# /etc/init.d/totd start
# logread

Finally, configure the built-in DNSMASQ to use TOTD as its upstream. Just remember to use 127.0.0.1#5353 as the upstream server. Note the use of a hash (#) symbol.

You should be able to verify that it works by querying AAAA records for pure IPv4 names. You should see that a fake IPv6 address be returned with your TOTD specified prefix.

# ping6 ipv4.google.com

You won’t be able to actually ping it over IPv6 yet at this point, until your NAT64 is setup correctly.

NAT64

NAT64 provides an IPv6 to IPv4 NAT mechanism which will actually transfer the IPv6 packets by converting them into IPv4 packets and back. The tool to do this is TAYGA and is also available in the OpenWRT repositories.

First, install TAYGA.

# opkg update
# opkg install tayga

Next, edit /etc/config/network and add a new interface.

config interface nat64
 option proto tayga
 option ifname 'tayga-nat64'
 option ipv4_addr 192.168.64.1
 option prefix fd63:fab9:6ccf:64::/96
 option dynamic_pool 192.168.64.0/24
 option accept_ra 0
 option send_rs 0

Next, edit /etc/config/firewall and add it to the LAN zone.

config zone
 option name 'lan'
 option input 'ACCEPT'
 option output 'ACCEPT'
 option forward 'ACCEPT'
 option network 'lan nat64'

Enable and start TAGYA, and check the logs for errors.

# /etc/init.d/network restart
# /etc/init.d/firewall restart
# logread

You should now be able to ping any IPv4 server using IPv6.

# ping6 ipv4.google.com

Voila!

LTSP Client with HPLIP

I had a problem hanging a HP printer off an LTSP client. This printer – M1132 – requires a proprietary plugin.

First, I tried to setup the printer using USB-IP. This obviously worked. The LTSP server was successfully fooled into thinking that the printer was connected to the local USB port. However, this method was troublesome as USB-IP needs to be manually connected each time the client was rebooted.

Then, I tried the recommended way to do it by editing lts.conf to enable jetpipe and saned. Unfortunately, while both the daemons started up, it was not possible to neither print nor scan from the client. When I ran hp-setup from the LTSP server, it failed to even detect a network printer. While sane was able to detect the scanner, it too failed to scan.

Next, I tried to run hp-setup from within the LTSP chroot but that was not possible either as lsusb failed to return anything inside the chroot. Therefore, the HP software is unable to install the plugin nor configure the CUPS queue.

Finally, the way that I got things to work was to manually install the plugin and setup CUPS. This involves running hp-plugin from within the LTSP chroot. Then, I installed the PPD and configured both the cupsd.conf and printer.conf manually. Then, all I had to do was add a network connected IPP printer on the LTSP server and point it to the client.

Voila, both scanning and printing now works with the printer hanging off the client.

PS: In order to prevent CUPS from running on any of the other clients, I made CUPS listen to the specific IP address assigned to that specific client.

HD Video Streaming on LTSP

Our office uses a LTSP setup for workstations. On a lark, I decided to measure how well it worked with streaming video.

As can be seen from the screenshot of nmon running and measuring the network bandwidth, the maximum peak transfer is 120MBps which translates to about 1Gbps. This is the amount of bandwidth taken when streaming a Youtube video on full-screen.

At this bandwidth, the video is perfectly watchable with no noticable lag or refresh rate problems. However, if we merely watch the video in cinema mode, the bandwidth requirement drops to about half. If we watch it in the normal mode, the bandwidth reduces by another half.

So, to watch smooth Youtube videos on LTSP, we will need about 250Mbps network bandwidth. On a 100Mbps network bandwidth, video was choppy even at the standard Youtube video size. There were noticeable frame rate problems.

This also means that we will need high amounts of bandwidth at the LTSP server end to provide smooth videos to a number of workstations via a gigabit switch. Therefore, it is advisable for the LTSP server to have multiple nics in a bonded configuration.

NAT64 and DNS64

I have been investigating options for moving my network to a pure IPv6 stack. The main issue here is ensuring that there is still connectivity to the IPv4 Internet after the move. The best options that I have found that support this configuration is the NAT64/DNS64 stack.

Setting this up was a bit of a head-ache as the documentation was lacking for Tayga on Linux as a NAT64 router. That said, I had to follow the example strictly and I was able to replicate things on my OpenWRT 12.09 router.

Setting up the DNS64 settings was much easier and things worked after that. I was able to ping and connect to the IPv4 world on my pure IPv6 network. Unfortunately, I had trouble connecting to the IPv6 Internet instead. Thing is that my Internet connection is still pure IPv4.

So, I’m now investigating the possibility of running a DNS server that will not forward AAAA record lookups but things do not look good. There doesn’t seem to be any DNS server built with that feature. Looks like I’m going to have to roll my own.

I might have to look at the feasibility of modifying the TOTD source, once I can find it though.

Experimenting with CORS

As a follow up to yesterday’s post on CORS, I did some simple experiments to test it out to see if it’ll work specifically by using JQuery primitives. It was easy as pie to make it work. The following little experiment demonstrates the feasibility of using CORS to use the browser as a middle-man.

I just wrote a simple cors.php script and fired it up from the browser.

If the Access-Control-Allow-Origin: * header is removed, then the console log will show the following error:
XMLHttpRequest cannot load http://127.0.0.1/cors.php. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost' is therefore not allowed access.

However, once it is in there, the console log shows the expected output, which is essentially the data payload being transmitted. My only concern now is the size of the data blob that can be transmitted via this method using JQuery. I gather that there should be a limit on the size of such a transmission.

Also, there is a concern on security. So, I will need to figure out a mechanism to protect the communications between the parties. There are many other Access-Control-Allow headers that can be returned such as those listed here.

This will require more research.

PS: According to this site, JQuery does not support CORS on IE. So that’s a browser limitation that I’ll have to keep in mind.