1.8b Development

I've been running a Atheros AR5007EG/AR2425 based wireless b/g card successfully as an AP on 1.8.1b550. All running good: (not using radius, just PSK)

Dec 3 22:07:49    hostapd: wlan0: STA 10:a9:16:49:78:0c IEEE 802.11: associated
Dec 3 22:07:49    hostapd: wlan0: STA 10:a9:16:49:78:0c RADIUS: starting accounting session 529E55EA-00000000
Dec 3 22:07:49    hostapd: wlan0: STA 10:a9:16:49:78:0c WPA: pairwise key handshake completed (RSN)

However, when i enable Captive portal on the WLAN interface, my test client can't connect get past being associated (repeat this log forever or until I manually disconnect the client from trying to connect):

hostapd: wlan0: STA 10:a9:16:49:78:0c IEEE 802.11: associated
hostapd: wlan0: STA 10:a9:16:49:78:0c IEEE 802.11: deauthenticated due to local deauth request
hostapd: wlan0: STA 10:a9:16:49:78:0c IEEE 802.11: deassociated

I'm out of my depth here, but looks like a bug of some sort as wireless works flawlessly without the captive portal enabled.

Try putting the m0n0wall IP address in the allowed IP addresses.  It may be improperly filtering DHCP.  Not a lot of us actually use wireless directly in the router.  Real stand alone APs are much better.  (And higher speed)

[status.php #ipfw show]

Well, it can't get past obtaining an IP address, (as soon as it's associated, it gets bumped) so i'm not sure if that would help but i tried it anyway and there was no change.

This is only thing I can spot; under status.php #ipfw show:

01102   19    1509 deny ip from any to any layer2 not mac-type 0x0800

during trying to get a wifi client connect, these numbers (19, 1509) increment. I'm guessing either packets/bytes handled by this rule.

the only thing i can get from it is it's denying something in layer 2 that's not IPv4 (0x0800).

If i turn captive portal on another interface (e.g. a wired one) and plug in a wired client, everything works and the same line shows:

01102    0       0 deny ip from any to any layer2 not mac-type 0x0800

and the final breadcrumb if someone can work this out: if i turn off captive portal, connect the wireless client, turn on captive portal, then try and browse the web, i'm presented with the captive portal login screen and everything works... until the client disconnects. to me, it seems that deny rule is at least partly responsible.

[mac-type 0x0806,0x8035]

I know it's bad form to reply to your own reply, but I figured this might warrant it.

With the help of pfSense to compare it to, i set up essentially the same configuration. I then found it too has a status.php page, which produced the following

ipfw -x mywifi show

65291    0       0 allow pfsync from any to any
65292    0       0 allow carp from any to any
65301   67    1876 allow ip from any to any layer2 mac-type 0x0806,0x8035 (ARP and RARP)
65302   72    8392 allow ip from any to any layer2 mac-type 0x888e,0x88c7(802.1X  - Port-based network access control and 802.11i - Pre-Authentication) ****
65303    0       0 allow ip from any to any layer2 mac-type 0x8863,0x8864 (PPP over Ethernet Discovery Stage/PPP over Ethernet Session Stage)
65307    8      48 deny ip from any to any layer2 not mac-type 0x0800,0x86dd (IPv4 and IPv6)
65310  362   37048 allow ip from any to { 255.255.255.255 or 192.168.2.1 } in
65311  848  206432 allow ip from { 255.255.255.255 or 192.168.2.1 } to any out
65312    0       0 allow icmp from { 255.255.255.255 or 192.168.2.1 } to any out icmptypes 0
65313    0       0 allow icmp from any to { 255.255.255.255 or 192.168.2.1 } in icmptypes 8
65314    0       0 pipe tablearg ip from table(3) to any in
65315    0       0 pipe tablearg ip from any to table(4) in
65316    0       0 pipe tablearg ip from table(3) to any out
65317    0       0 pipe tablearg ip from any to table(4) out
65318 2697  744017 pipe tablearg ip from table(1) to any in
65319 2118 1166996 pipe tablearg ip from any to table(2) out
65532   62    7353 fwd 127.0.0.1,8000 tcp from any to any dst-port 80 in
65533   52    5883 allow tcp from any to any out
65534  126    7724 deny ip from any to any
65535    0       0 allow ip from any to any
         

***Note: this (counter?) increases during WiFi client joining, followed shortly after the one above increases (for ARP/ RARP) which i assume is some arp traffic once the link is up.

Contrast this to m0n0wall:

01000 5512 520710 skipto 50000 ip from any to any not layer2 not via wlan0
01001 3643 381954 allow ip from any to any layer2 not via wlan0
01002    1     96 skipto 50000 ip6 from any to any not layer2
01100    0      0 allow ip from any to any layer2 mac-type 0x0806 (ARP)
01101    0      0 allow ip from any to any layer2 mac-type 0x86dd (IPv6)
01102   15   1206 deny ip from any to any layer2 not mac-type 0x0800 (IPv4)
01103    0      0 skipto 20000 ip from any to any layer2
01200    0      0 allow udp from any 68 to 255.255.255.255 dst-port 67 in
01201    0      0 allow udp from any 68 to 192.168.2.1 dst-port 67 in
01202    0      0 allow udp from 192.168.2.1 67 to any dst-port 68 out
01203    0      0 allow icmp from 192.168.2.1 to any out icmptypes 8
01204    0      0 allow icmp from any to 192.168.2.1 in icmptypes 0
01300    0      0 allow udp from any to 192.168.2.1 dst-port 53 in
01301    0      0 allow udp from 192.168.2.1 53 to any out
01302    0      0 allow tcp from any to 192.168.2.1 dst-port 8000 in
01303    0      0 allow tcp from 192.168.2.1 8000 to any out
19902    0      0 fwd 127.0.0.1,8000 tcp from any to any dst-port 80 in
19903    0      0 allow tcp from any 80 to any out
19904    0      0 deny ip from any to any
29900    0      0 allow ip from any to any layer2
65535 5513 520806 allow ip from any to any

m0n0wall is a little more restrictive and says permit ARP and IPv6 and block any other frames not based on IPv4 type.
I suspect if i can insert the a permit mac type 0x88c7 for 802.11i, it will work.

Any pointers on how i can do that? Busy day. Felt like someone spoonfeeding

monowall.ip/exec.php:

ipfw add 01099 allow ip from any to any layer2 mac-type 0x88c7

Added, verified in ipfw show - then the test. No change. I then tried the other, 0x888e

ipfw add 01098 allow ip from any to any layer2 mac-type 0x888e

Bingo 

ipfw show:
....
01098    4    474 allow ip from any to any layer2 mac-type 0x888e
01099    0      0 allow ip from any to any layer2 mac-type 0x88c7
....

Shows some counters increased and WiFi connected.

So, how do I verify:

1) Why wasn't 802.11i / 0x88c7 needed? I thought that was the silver bullet.
2) Any chance to have this mac type added as permitted in the ipfw ruleset when captive portal is used?

How do i go about making the case for getting the mac-type 0x888e added to the captive portal ipfw rules? I've been running for about 12 days now and it's working wonderfully.

Really wish to just keep using the integrated wirelsss card in hostap mode as it's working well.

Hi,

Browsing the sources, I found a statement that already adds a pass rule for the 0x888e mac-type. The rule seems to be enabled if the configuration has a 'wpaaccess' entry under the 'captiveportal' entry.
I wasn't able to spot a check-box that would enable that in the GUI though.
So try edit your XML configuration file by hand: add a <wpaaccess/> node under the <captiveportal> node.
Hope it'll help.

Note: I don't have a wireless interface on my box neither have I the captive portal service configured, so I did not test it before posting.

Pierre

Thank you Pierre, you were right on the money

Testing shows manually adding <wpaacess/> to the captive portal configu adds the required mac-type:

Code:

01000 367 389682 skipto 50000 ip from any to any not layer2 not via wlan0
01001 380 389494 allow ip from any to any layer2 not via wlan0
01002   3    228 skipto 50000 ip6 from any to any not layer2
01100   2     56 allow ip from any to any layer2 mac-type 0x0806
01100   4    474 allow ip from any to any layer2 mac-type 0x888e
01101   6    384 allow ip from any to any layer2 mac-type 0x86dd
01102   1      6 deny ip from any to any layer2 not mac-type 0x0800

i do see that what i assume is the rule number, seems duplicated. does that matter?

Hi,

Short answer: No.
Rules may share a same rule number. It may be used to delete many rules at once for instance.

Beside, maybe we should add a check box in the captive portal settings page to enable the "WPA access" feature.

Pierre

Hi Piper,

I just saw that Manuel has made a commit adding the required mac-type rules for WPA access in the captive portal configuration.
The <wpaaccess/> node trick isn't needed anymore.

Pierre

Awesome, thanks for the notification. Hoping 1.8 is released out of beta soon  

Hah. Bugger me.

Downloaded the 1.8.1b561 build, reconfigured a few things because im making a new build and figured i would use the latest beta to test, and then just *now* 1.8 has been released