Resolved

hardware:
alix2c1 = 3 LAN / 1 miniPCI / LX700
Wistron CM9 Atheros 802.11a/b/g miniPCI wireless card
32 MB CF-Card

m0n0wall version 1.3b8

Interfaces:
LAN, WAN, LAN2 and WiFi.

If I bridge the LAN2 to LAN and set up the correct firewall rule, the PC on LAN and LAN2 can access eachother, and both the LAN and LAN2 can access the internet and m0n0wall via webGUI.

If I bridge the WiFi to LAN and set up the same firewall rule, the PC on LAN and WiFi can access eachother, but only the LAN can access the internet and m0n0wall via webGUI. The WiFi PC's can't ping the m0n0wall or access the internet, but it can access the shared-folders on the PC's on the LAN side.

If I don't bridge the WiFi and set it to ex. 192.168.2.1/24 the PC's on WiFi can access the internet and the m0n0wall via webGUI.

I have the same problem. Spent 6hrs yesterday trying to get this sorted, looking at all the documentation/forums I could google.

Setup:
alix2c1 = 3LAN / 1 miniPCI / LX700
Wistron DCMA81 miniPCI card (Atheros)
m0n0wall v1.3b8 on 128MB CF-Card

Symptoms:
When bridging LAN+WLAN (vr0+ath0) computers on the WLAN cannot access the internet or firewall, despite allow all rules on the WLAN iface.
Strangely enough, computers on WLAN can access LAN fine (have not tried other way).
Even stranger, a Wireshark on a WLAN client shows m0n0wall's replies to requests (and these show up in firewall tables) but the client seems to reject the replies. It's as if the WLAN clients are rejecting all packets coming from m0n0wall, except for the initial DHCP packets. I haven't looked at detail at the Wireshark output yet but I suspect it may have something to do with incorrect MAC addresses (disagreeing with WLAN client's ARP table).

Additional info:
Available on request. I'll post the Wireshark output, ARP tables, and netstat output this evening (if I have time).

PS. It'd be nice to know if somebody knowledgeable is watching this thread.

I'm having this problem with 1.3b7 and 1.3b8, and I think I found the cause.  The IP checksum of almost every packet M0n0wall sends out on the WLAN is incorrect (and in fact exactly 0), so while the packets arrive back at the host on the WLAN, the packets are then ignored.  The only exception seems to be the DHCP packets, which have correct checksums.  So the host on the WLAN connects to the network via DHCP successfully and then can talk to the LAN, the M0n0 box, and upstream to the Internet but ignores every IP packet coming from the M0n0 box, which includes traffic generated both on the M0n0box and anywhere on the WAN.  IP packets generated by LAN hosts (or indeed, by hosts on any subnet behind them) come directly to the WLAN host and are well-formed, so connectivity with those hosts is fine.

If you use M0n0wall's GUI to ping a WLAN host, these packets also have incorrect IP checksums (of 0).  Pings to LAN hosts are fine.

I confirmed the bad checksums on b8 only.  On b7, I had identical connectivity problem but I didn't actually look at the checksums till after trying an upgrade to b8.

A related fact is that the M0n0 box responds to ARP broadcasts by WLAN hosts with the MAC of the wireless interface, but all frames from M0n0 are tagged with a source of the MAC of the LAN interface.  I don't know enough about networking, but it seemed to me a potential problem if the ARP table didn't confirm the hardware/IP source tags of frames that are supposed to be coming from the local subnet.    I tried setting M0n0wall's WLAN interface to have a spoofed MAC matching the LAN interface, but that seemed just to confuse M0n0wall (couldn't connect a host on the WLAN at all).  Then I tried putting a static ARP entry in the WLAN host pointing to M0n0's LAN interface.  Then the incoming frames did match the ARP table, but "ping" still refused to recognize the packets as legitimate replies.  This is when I noticed the checksum problem, and now I think that's the only problem.  But I mention the ARP table discrepancy as background that may be relevant.

Jan 14 15:30:15 m0n0 kernel: ath0: <Atheros 5212> mem 0xe0080000-0xe008ffff irq 9 at device 12.0 on pci0
Jan 14 15:30:15 m0n0 kernel: ath0: Ethernet address: 00:80:48:7e:13:60
Jan 14 15:30:15 m0n0 kernel: ath0: mac 7.8 phy 4.5 radio 5.6

vr0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
   options=b<RXCSUM,TXCSUM,VLAN_MTU>
   inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255
   ether 00:0d:b9:12:67:b0
   media: Ethernet autoselect (100baseTX <full-duplex>)
   status: active
vr1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
   options=b<RXCSUM,TXCSUM,VLAN_MTU>
   inet <PUBLIC IP ADDRESS CENSORED> netmask 0xfffffc00 broadcast 255.255.255.255
   ether 00:0d:b9:12:67:b1
   media: Ethernet autoselect (100baseTX <full-duplex>)
   status: active
ath0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
   ether 00:80:48:7e:13:60
   media: IEEE 802.11 Wireless Ethernet autoselect mode 11g <hostap>
   status: associated
   ssid LairOfRosco channel 1 bssid 00:80:48:7e:13:60
   authmode WPA privacy MIXED deftxkey 2 AES-CCM 2:128-bit
   AES-CCM 3:128-bit txpowmax 36 bmiss 7 protmode CTS burst dtimperiod 1
   bintval 100
enc0: flags=41<UP,RUNNING> mtu 1536
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
   inet 127.0.0.1 netmask 0xff000000

Thank you, msswift, for your detailed analysis! Off the top of my head, I'd say that something related to the bridge code in the kernel gets confused when an interface in a bridge group supports hardware TX checksumming (which vrX does). You could try running the following commands via exec.php to disable hardware checksumming, just to see if it makes a difference:

/sbin/ifconfig vr0 -rxcsum -txcsum
/sbin/ifconfig vr1 -rxcsum -txcsum

Wow! Great responses! I'll check them both out and report the outcome.

Turning off checksumming on the LAN interface (vr0 in my case) resolves the problem.  Thank you!  No need to turn it off on the WAN as well.  And the ARP stuff I mentioned isn't relevant: M0n0 still advertises the MAC of the WLAN interface on the WLAN and still sends out all frames it generates with the different source-MAC of the LAN interface, but it doesn't seem to matter (to a WinXP client on the WLAN anyway).

Is there an easy way to preserve the actions of the ifconfig command over a reboot?

Is there a better way to monitor CPU load than exec.php and uptime?

I think CPU bottlenecking throughput is the only disadvantage of this workaround.  I'm lucky enough to have a blistering fast cable connection, but I have no idea if peaks of 20MB/s are going to get squeezed by my M0n0 box's Geode LX800.  Not bridging (putting WLAN on separate subnet) doesn't have this potential drawback, but some may find the extra overhead of maintaining rules for both LAN and WLAN annoying.  My issue with routing is mainly that I have never been able to get Samba to do cross-subnet browsing like it should.

Running the:

/sbin/ifconfig vr0 -rxcsum -txcsum
/sbin/ifconfig vr1 -rxcsum -txcsum

worked for me to

Thx

Fix in 1.3b9. Thanks for the good work!