This is an odd one. I may just need some help debugging iptables at the module layer, since none of my debug log entries in the rules seem to get processed. But anyway, here is the background.

I followed this guide on setting up hostapd:

http://forum.doozan.com/read.php?2,6300

I have the same TP-LINK adapter, so I thought it a good guide to follow. It worked well, and I have my adapter listening in AP mode, issuing IP addresses using dnsmasq. However, any device that connects to it, has no routing to the external network (internet) because there are no firewall rules for wlan0 yet. So everything is implicitly dropped and logged. This I can see coming out in the firewall debug log.

However, the moment I add a rule for wlan0, even a simple accept rule on the INPUT chain (-A INPUT -i wlan0 -j ACCEPT), all routing through my ppp0 interface stops working. By that, I mean, anything connected to eth0 can't establish a connection to the internet, to resolve hostnames or even ping an address. If I remove the rule for wlan0 from the INPUT chain, everything starts working again.

I have never seen anything like this go so wrong with netfilter before, so any help appreciated.

Hi,

I think you should check through the doc again and specially the network part. If all the interfaces are configured correctly and they are coming up at the boot time as they should.

Have you activated routing/ip forwarding in your device? You can do this by typing on your prompt:

# echo "1" > /proc/sys/net/ipv4/ip_forward

Also try to activate NAT:

# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

You also need to have a default route. Can you post the output of "route -n" before and after adding the rules?

Regards

I meant to follow this up last night, but it was late by the time I got everything working (1 am ZZZZzzzz). IP forwarding is and has been setup for long time, as are the masquerade rules for eth0 and eth2, hence why everything works and addresses are being masqueraded correctly. The issue here is that, if I simply add a rule to the firewall for wlan0, masquerading stops working for all the other interfaces. Forwarding works fine, hence why I can establish connections between wlan0 and eth0 connected devices. It's masquerading on the external interface (eth2) that seems to stop. For example, I can ping google.com and make outbound connections directly from the NAS drive, but if I try it on a machine connected through eth0, nothing... This is a definite sign of masquerade rules not working.

I don't know what the underlying issue is exactly, but it seemed to be resolved by bridging wlan0 with a phony interface eth4, that I created in the interfaces file.

iface eth4 inet manual
iface wlan0 inet manual
iface br0 inet static
bridge_ports eth4 wlan0
address ...

I then configured hostapd to setup the bridge interface on startup.

So when the system boots, eth4 is not available (because it's fake), so brctl doesn't create the bridge interface. I then have udev hooks that detect when the USB wlan0 driver is loaded (ath9k) and it runs a script to start hostapd. This seems to be a much more reliable way than doing silly sleeps (mentioned in the guide) or having hostapd started through init. At the point hostapd starts, it sets up the bridge interface and br0 comes up with it's static IP address. At that point, I can then connect to the system via this port, so I know this is working. Thus, adding the same rule to iptables that I added for wlan0, except specifying interface br0, does not break existing masquerading rules. Viola!

There is clearly something wrong here, no?

I am running the latest 3.2 kernel with a patch to fix T() macro definition and calls in arc/arm/include/asm/assembler.h. I back ported this from 3.5.5 myself, given someone didn't think that people using ARM architecture would wan't a 3.2 kernel? Tut!

I now have a new issue, which is that the ath9k_htc driver causes a kernel crash. Well that is my suspicion, given the last entry in the syslog was a mode change notification from ath9k at 2 am this morning. Next message is at 7 am when I woke up and heard the hardware watchdog beeping like an alarm clock, before I reset it.

Anyway, thanks for your help. More to the point, why is masquerading failing when referencing wlan0 directly, as opposed to indirectly through a bridge driver?

I think I know what may have been happening. The forwarding was working previously by pure chance, but essentially, there were two interfaces on the system both on the same subnet. This was not deliberate, but was fine given they were both on the same physical interface. Originally, these would have been on different subnets, to provide routing for both subnets through the same port. However, some time ago, I merged the two subnets when I obtained a new router and configured it on the subnet I wanted. I must have forgotten to update the aliased interface, given there were no other side effects. But with the changes I made recently, I have lost a USB gigabit ethernet adapter and switch the onboard controller to be the external interface. Switching the config for the interface, since renaming the interface through udev had undesired results. Now you might start to see where things have gone awry. I left the aliased interface config line, since it was right at the bottom of the interfaces file, now aliased against the original interface, now the external interface. So as soon as wlan0 came up and a filter rule was added something was getting confused about what port to send the reply out on and ended up picking the wrong one. Unfortunately, it meant physical network traffic from the NAS was being sent out over wifi and wifi traffic being sent out on the physical port. This would explain the lack of messages from iptables, because disabling the DROP on wlan0 packets allowed free flow of packets on any of the two interfaces. Fortunately, I was able to see this going on, because the management port was configured on it's own subnet, connected to the laptop I was using.

Here is my interpretation of what the routing table would have looked like:
I think next time, I'll remember not to stay up so late!

Good that you have sorted out the issue! Yes, it happens to all tech guys I guess. Sometime the mistake is too simple to notice.