I love OpenWRT, but it doesn’t forward multicast packets between the WiFi (wlan0) and LAN (br-lan). DLNA discovery uses multicast

I tried a few solutions like igmpproxy and udpxy but neither worked.

Avahi to the rescue

Avahi-daemon does this for us. There isn’t much documentation online, but I found it worked out of the box for me. These were the commands I used and I was immediately able to see my DLNA servers (on the LAN side) on my Wireless devices.

# opkg update
# opkg install avahi-daemon
# /etc/init.d/avahi-daemon enable
# /etc/init.d/avahi-daemon start

Finally, disable multicast snooping (from this ticket)

# echo "0" > /sys/devices/virtual/net/br-lan/bridge/multicast_snooping

(And add that line to /etc/rc.local to survive rebooting)

All working now!

I was recently stumped with an rsync using ssh command that has been running for a year from my cron suddenly stop working. Here was the error:

Permission denied, please try again.
Permission denied, please try again.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: unexplained error (code 255) at io.c(601) [Receiver=3.0.8]

The rsync runs an ssh with a set of keys that needs no password. So it should automatically login to the remote server and start the rsync. And that’s how it was working and working fine.

I’d ad changed my ssh config on both servers so I knew that had to be the issue, but what had me stumped is that it worked fine when I ran the rsync manually from the command line!

Turns out, thanks to reading a handy post by chmac on the Fedora Forum, that my ssh-agent for my interactive session was taking over and providing the keys the server needed. However, when run via cron, the agent wasn’t present, so gave a permission denied error.

It was easy to verify. As soon as I removed the ‘SSH_AUTH_SOCK’ variable from my shell, the rsync/ssh no longer worked without a password.

Which pointed me to the actual problem – in modifying my ssh config a few days earlier, I’d removed the public key from authorized_keys2 on the server, so my ssh was no longer able to automatically connect. Re-adding the public key fixed the problem!

20 May, 2011  |  Written by  |  under Uncategorized

I had a problem with my Mac Mini that it wouldn’t connect to my AirPlay device. All other devices (iTunes on my PC, Laptop, and iPhone) worked fine.

Only on my Mac Mini, it finds the AirPort device, but when I tried to connect, it said “Connecting To” for a few seconds then went back to my computer speakers.

Turns out the problem was easy to fix. I got the idea from an apple thread. Disable IPv6.

      Open System Preferences
      Open Network pane
      Choose your active network device (I chose Ethernet)
      Click the Advanced button
      Go to the TCP/IP tab
      Set the “Configure IPv6″ field to Off.
      Click “OK”
      Click “Apply”
      Let iTunes connect to your Airtunes speakers

So, if your iTunes says ‘Connecting To’ but doesn’t connect to your AirPlay device, disable IPv6 in the network settings and see if that fixes things.

10 Apr, 2011  |  Written by  |  under Uncategorized

I’ve been using the wonderful OpenVPN for ages to securely connect my work network to my home network. This also had the advantage in that I could setup a VPN into my internal network when I was away from home and work.

While it’s a nice system, it was very complicated to setup and I always had issues setting up the routing between the two locations. Once we closed the office location, I didn’t bother with it again because I had no need.

I always wanted to have a VPN to my servers located in the US, and have them linking to each other securely.

OpenVPN has a spoke layout, so all communication would need to route through the main server. Not an option for me when I pay for all traffic to and from my mail server (the only Australian server with a large pipe).

Enter Tinc

Tinc solves all these problems. It is a cloud VPN allowing each node to communicate with any other node directly. And it’s dead simple to configure, to boot. Now after just a few hours, I have a VPN between my home network, the network at my old house, the two US servers, and my Australian mail server.

And it’s wonderful! I’ve always been annoyed that I haven’t been able to SCP files from my US servers to my development server inside my home network (I always had to go the other way because of NAT). Now I can!

Setup of Tinc

Here are my setup steps:

In /etc/netname/tinc.conf:
Name = host1
ConnectTo = host2

In /etc/netname/tinc-up
ifconfig $INTERFACE 192.168.XX.1 netmask

# Generate keypairs for host
tincd -n netname -K

# Create file for this host. Prepend to /etc/netname/hosts/host1
Address = host1.full.domain.com
Subnet = 192.168.XX.0/24

Start tincd as a service, and you’re all done!

netname is a unique identifier for this VPN. Tinc allows multiple virtual networks, and separates each configuration through a different netname.

I’m using 192.168.XX.0/24 as the virtual networks, one subnet per machine/internal network. The subnet line in hosts tells other clients connecting to this computer which address to add a route for.

Note how the netmask shows a /16 address, whereas we’re using /24 for each network? That’s so that one route can be used to route into the VPN and tinc will work out the details of which node to send it to. And the beauty is that I can have another interface for the local network with the same IP address. It just needs a separate netmask – 192.168.XX.0/24.

The ConnectTo line tells which other hosts this hosts will directly connect to. If this host doesn’t connect directly, say to host3, tinc will find a route through other hosts that DO connect to host3. Add as many ConnectTo lines as you need.

In Tinc, all points need to have a copy of the hosts/host1 file for all hosts, but that’s simply kept in by placing all files in that directory under version control – git being my tool of choice.

I run my own local DNS server for DNS caching, and handling the local DHCP domains.

As my main firewall/router doesn’t move around (and thus doesn’t need to change it’s DNS), I prefer to hard code my /etc/resolv.conf file to add my local domains and DNS server. However, Fedora overwrites the /etc/resolv.conf file whenever the network boots.

Found an easy fix to this today. Add the following line to every ifcfg-* file in /etc/sysconfig/network-scripts


The PEERDNS line causes the dhclient script to not find the DNS server for that network link and add it to resolv.conf, so it leaves the file alone.

Here’s my resolv.conf:

search home
; Local machine's nameserver
; Telstra's nameservers in case mine is down

20 Mar, 2011  |  Written by  |  under Uncategorized

Well, I’ve recently switched from a cable modem (in bridge mode) to an ADSL modem (also in bridge mode).

Placing the modem in bridge mode gives me lots of advantages because my Linux router computer becomes the computer that has the external IP address. That allows me to easily create servers (http, opendns, vpn) on my router and view all network traffic into and out from my internet connection.

It adds some headaches too – mostly having to set firewall rules (I use the excellent FireHol).

The cable modem was great because it gave me a DHCP server that I connected to, the IP it gave me was the world-viewable IP and any traffic I sent out that interface went to the Internet.

The ADSL modem is a little different. I need to set and keep a PPPoE connection alive and ppp0 is where all traffic is sent.

Not a big deal, except with Fedora 14, I couldn’t get the ppp0 network to startup on boot. I installed rp-pppoe (yum install rp-pppoe) and set it up with pppoe-setup. Nice and simple. However on a reboot the network didn’t come up. It started when I issued pppoe-start, but I didn’t want to do it manually. Searching the logs I saw:

NetworkManager[2171]: ifcfg-rh: error: Unknown connection type 'xDSL'

Looks like Network Manager doesn’t like the older-style ifcfg-ppp0 file created by pppoe-setup, so ignores the file.

The simplest method to fix this seems to be disabling Fedora’s Network Manager. That will also give me an advantage in stopping the box from reloading it’s network settings whenever I change the ifcfg- files (which usually ends up making the box un-accessible remotely to me as I have a habit of saving while part way through editing).

To remove Network Manager and instead use the older Network service to start the network:

yum remove NetworkManager
service network start
chkconfig network on

After a reboot to test, ppp0 (and the other interfaces) came up fine. Beauty!

1 Mar, 2011  |  Written by  |  under Uncategorized

I’ve had a few goes at getting dynamic dns name resolution working on my DHCP home network, but could never get it right.

I realised today I really should have it working to make my life much easier with the move to IPv6 shortly, and to get Synergy working with my new computer setup.

A quick search found this excellent page giving the full steps to enable Dynamic DNS with DHCP. Easy to follow instructions and using it I got it all working very quickly.

The only change I had to make was to remove the domain name after ddns-domain-name in dhcpd.conf (thanks Jeffery Forman). Otherwise it gave an error. Works fine without the domain name though.

My Steps

$ dnssec-keygen -a hmac-md5 -b 128 -n USER dhcpupdate
$ cat Kdhcpupdate*.key

edit /etc/named.conf

ddns-update-style interim;
update-static-leases on;

key dhcpupdate {
algorithm hmac-md5;
# example:
# secret “N8Hk2RUFO84bEVl3uGTD2A==”;
zone “home” {
type master;
file “master/db-home”
allow-update { key dhcpupdate; };

zone “0.168.192.in-addr.arpa” {
type master;
file “master/db-home_rev”;
allow-update { key dhcpupdate; };

And editing /etc/dhcp/dhcpd.conf

key dhcpupdate {
algorithm hmac-md5
secret N8Hk2RUFO84bEVl3uGTD2A==;

zone 0.168.192.in-addr.arpa {
primary dns.home;
key dhcpupdate;

zone home {
primary dns;
key dhcpupdater;

subnet netmask {
option domain-name “home”;