Tag Archives: 1-wire

OpenWRT Successes and Failures

I’ve been a big fan of the OpenWRT project for a while now. I love the idea of taking an inexpensive single-purpose device with low power needs and turning it into a flexible platform that can fill multiple roles. I’ve been using it on a few Linksys WRT54GL routers for a while now with great results, even if the plain old “Wireless Access Point” function I’ve given them is fairly bland.

Sooner or later, that may change. A few months ago, I bought a couple Asus WL-520gU units to act as a platform for more OpenWRT experimentation. They’re quite similar to the WRT54GLs in their specifications, but they have one added feature that I highly desire – a USB port. The now-ubiquitous feature of modern computers is still fairly absent from devices compatible with OpenWRT.

I have two primary use cases in mind for these units and their USB ports. The first is for use in my home monitoring and automation setup, which uses 1-wire devices inside and outside of the house to monitor the environment and manipulate various things, such as electricity fed to power outlets or HVAC controls. These 1-wire devices are controlled by a computer, and the 1-wire network connects to the computer using USB. In this setup, I could connect back into the main IP network by using the WL-520gU’s wireless in client mode, or it connect to the network using ethernet and function as an access point while also doing 1-wire control things.

The second use case is to make the device into a wireless router (gasp!) that connects to a cell phone using its USB tethering function and provides the 3G internet to the devices connected through it, either via the wifi or ethernet ports. This would serve as an easily transportable and totally mobile internet connection that could be used while travelling. This would also have the secondary benefit of providing emergency internet access to our overly-complicated home network setup, which uses routing protocols and separate virtual machines to handle routing duties for separate internet connections (of which we have two). With the ‘magic’ of the routing protocols, I could simply plug the tethered router into the appropriate VLAN on our network and its routes to the internet would be exposed to the rest of our network, providing access if our cable and DSL services are down.

I’ve been largely successful with the first goal. OpenWRT’s backfire branch has support for 1-wire USB host devices and the OWFS interface layer that I use to access the 1-wire network. It took me a while to find the right version of OpenWRT to use, but I think I’ve got a stable setup. I’m cooking up my own firmware images so I can customize what goes in the ROM image so I don’t have to install things later. I’ve had a “stripped down” version of OpenWRT running the owserver utility for a month or so, and it’s been stable so far. I only documented its setup process loosely, but I’ll likely reimage the device at some point, and I’ll take better notes at that point.

The wireless tethering goal has been more elusive. While getting it to function has been pretty easy, making it stable has not. There seems to be a bug in the kernel that’s affecting the USB RNDIS functionality in my situation, and it causes simple things like a stream of pings to cause a kernel oops or panic. This is obviously not a good thing. I tried a new build last night, and for a while, I thought i had achieved a breakthrough. The tether functioned for a good 20 minutes without issue, with pings going the whole time. After a reboot of the WL-520, things did not go as well. The kernel problems started showing up:

[  180.832000] ------------[ cut here ]------------
[  180.836000] WARNING: at net/sched/sch_generic.c:255 0x801da888()
[  180.840000] NETDEV WATCHDOG: usb0 (rndis_host): transmit queue 0 timed out
[  180.844000] Modules linked in: rndis_host cdc_ether usbnet ohci_hcd nf_nat_irc nf_conntrack_irc nf_nat_ftp nf_conntrack_ftp ipt_MASQUERADE iptable_nat nf_nat xt_conntrack xt_CT xt_NOTRACK iptable_raw xt_state nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack pppoe pppox ipt_REJECT xt_TCPMSS ipt_LOG xt_comment xt_multiport xt_mac xt_limit iptable_mangle iptable_filter ip_tables xt_tcpudp x_tables ppp_async ppp_generic slhc b43legacy(O) b43(O) mac80211(O) usbcore usb_common nls_base crc_ccitt cfg80211(O) compat(O) ssb_hcd bcma_hcd arc4 aes_generic crypto_algapi switch_robo(O) switch_core(O) diag(O)
[  180.892000] Call Trace:[] 0x802676b0
[  180.896000] [] 0x802676b0
[  180.900000] [] 0x8001bc18
[  180.904000] [] 0x801da888
[  180.904000] [] 0x8001bccc
[  180.908000] [] 0x80015ecc
[  180.912000] [] 0x801da888
[  180.916000] [] 0x801da6a4
[  180.920000] [] 0x80028484
[  180.920000] [] 0x80051660
[  180.924000] [] 0x801bfc04
[  180.928000] [] 0x80022940
[  180.932000] [] 0x80054e18
[  180.932000] [] 0x80022ba8
[  180.936000] [] 0x800022b0
[  180.940000] [] 0x80005984
[  180.944000] [] 0x80005ba0
[  180.948000] [] 0x80016c58
[  180.948000] [] 0x800075fc
[  180.952000] [] 0x80005bc0
[  180.956000] [] 0x802cd908
[  180.960000] [] 0x802cd0dc
[  180.960000]
[  180.964000] ---[ end trace 7e575b276bcf3f69 ]---

I’m using the bleeding-edge branch of OpenWRT (currently at r31439) in the hopes that the kernel fixes will miraculously show up sometime soon. They haven’t at this point, so I’ll have to submit a bug report.