Wireless works fine… until I turn on security!?

  • System:  pfSense v2.0 Release

    Situation:  I've added a wireless kit to my box, enabled the interface, configured for 802.11g, set an SSID, and left it wide open.  I have multiple clients that can connect to it just fine.  I set a firewall rule to allow any2any just to make things simple.

    However, if I turn on any type of security for the wireless none of my clients can connect anymore (one linux and one windows vista).  Here are the settings I made on the wireless interface:

    Mode: AP
    SSID: Test
    802.11g Only: Unchecked
    Allow intra-BSS: checked
    Enable WME: checked
    Hide SSID: unchecked
    WEP: unchecked
    WPA: checked
    PSK Key: testing123
    WPA Mode: WPA2
    Key Man: Pre Shared Key
    Auth: Open System Auth
    WPA Pair: AES

    All other settings are pretty much default.  Those are the only changes I make and all of the sudden the clients can connect (they CAN see it just fine) and they key the error that the key is wrong, even though it isn't and I've double-checked.

    (NOTE:  I have the wireless interface bridged to OPT1 & LAN set to BRIDGE0) but in open mode that was working just fine so I don't believe the bridge has anything to do with it.

    Anybody have any suggestions of what might be causing this?

  • Sounds like an Atheros driver bug I heard about recently that affects a couple different chipsets. Couldn't replicate it with any of the 7 Atheros cards I have, but it's definitely an issue with some of them. No work around at this time, probably no option but to wait until we have 2.1 builds on FreeBSD 9 (likely by the end of the year).

  • Uh oh, that's not good news at all!  :'(

    Any ideas on how I can test specifically to see if this card is in fact subject to the aforementioned bug?  Are there any logs I can produce or tests I can perform to ensure this is the problem?

    Update:  I wanted to give more specifics as to what I'm using.  I'm using a DCMA-82 250mW mini PCI Card if that helps.  I'm pretty sure this is a really standard card that has been around for awhile and I'm not sure why it would stop working now in the latest revision?

  • The DMCA-82 is what I use in my production AP actually, with WPA2, with 0 issues so that shouldn't be affected. What hardware are you putting it in?

  • I'm using a Netgate m1n1wall 2D3/2D13 Alix board (http://store.netgate.com/Netgate-m1n1wall-2D3-2D13-Blue-P217C61.aspx).

  • @cmb:

    The DMCA-82 is what I use in my production AP actually, with WPA2, with 0 issues so that shouldn't be affected.

    There might be different chipset revisions or even different chipsets involved. It seems fairly common practice among the bigger WiFi device suppliers to change chipsets (even chipset manufacturers) without changing a device model name and number.


    Any ideas on how I can test specifically to see if this card is in fact subject to the aforementioned bug?

    I don't know the details of the referenced bug but it would probably be useful if you provided the output of the pfSense shell command pciconf -l -v to facilitate comparison of chipset in your device with others known to work.

  • dmesg says the following:

    ath0: <atheros 5413="">mem 0xe00c0000-0xe00cffff irq 9 at device 12.0 on pci0
    ath0: [ITHREAD]
    ath0: AR5413 mac 10.5 RF5413 phy 6.1</atheros>

  • The dmesg snippet is useful, the pciconf output will be even more useful because it will include a revision number. Your chipset might have a different revision number than a working chipset.

  • $ pciconf -l
    hostb0@pci0:0:1:0: class=0x060000 card=0x20801022 chip=0x20801022 rev=0x33 hdr=0x00
    none0@pci0:0:1:2: class=0x101000 card=0x20821022 chip=0x20821022 rev=0x00 hdr=0x00
    vr0@pci0:0:9:0: class=0x020000 card=0x01061106 chip=0x30531106 rev=0x96 hdr=0x00
    vr1@pci0:0:10:0: class=0x020000 card=0x01061106 chip=0x30531106 rev=0x96 hdr=0x00
    vr2@pci0:0:11:0: class=0x020000 card=0x01061106 chip=0x30531106 rev=0x96 hdr=0x00
    ath0@pci0:0:12:0: class=0x020000 card=0x1600185f chip=0x001b168c rev=0x01 hdr=0x00
    isab0@pci0:0:15:0: class=0x060100 card=0x20901022 chip=0x20901022 rev=0x03 hdr=0x00
    atapci0@pci0:0:15:2: class=0x010180 card=0x209a1022 chip=0x209a1022 rev=0x01 hdr=0x00
    ohci0@pci0:0:15:4: class=0x0c0310 card=0x20941022 chip=0x20941022 rev=0x02 hdr=0x00
    ehci0@pci0:0:15:5: class=0x0c0320 card=0x20951022 chip=0x20951022 rev=0x02 hdr=0x00

  • That's exactly the same card I have. Again, what hardware is it in?

  • @cmb:

    Again, what hardware is it in?

    Do you need more information than:

    I'm using a Netgate m1n1wall 2D3/2D13 Alix board (http://store.netgate.com/Netgate-m1n1wall-2D3-2D13-Blue-P217C61.aspx).

  • Thanks I missed that post. I'll try putting mine in an ALIX in a bit.

  • Any luck?  I'm eager to know how screwed up I am.  pfSense has been so rock solid that I just have to assume that it's me that is the problem.  :P

    I patiently await your update.  Thanks for helping out on this!

  • I'm at a loss. I went through all my Atheros cards including the DCMA-82, on an ALIX, and had no issues with any of them. Jim @ Netgate gave me the idea that maybe it was related to the glxsb crypto accelerator on the ALIX so I made sure to try with that both on and off, and no diff either way, both ways work for me.

    The only thing I can think of is somehow the hardware has changed in newer stock, the wireless gear I have is all 3-6 years old, though it should be identical since it's the same model and identifies itself the same. Netgate is going to test on new stock to compare.

  • Is there anything else I can do to help troubleshoot this?  Should I pull the card out and provide any info off of it for you?  I'd really like to help get this working, not for just myself, but for everybody.  Anything I can do to help just let me know.

  • Not yet, but I'll definitely be in touch if Netgate can't replicate it either.

  • I have good news.  No, scratch that, I have GREAT news!  ;D

    I upgraded to the newly released 2.0.1 this morning and guess what.. the wireless works properly now!  There was no mention in the blog post regarding the new release of wireless fixes of this type but whatever the team did fixed my problem!

    All clients can now connect to wpa/wpa2 secured networks (I have the WPA mode and WPA Pairwise each set to BOTH) and it's working great now.  Thanks pfSense & FreeBSD teams!

  • Hmm… well, that's great news, but I have no idea how that could have changed. Weird, the OS didn't change at all, nothing related to wireless changed either. Glad to hear it though!

  • Just to clarify, I also have changed nothing other than updating to the new version as I was awaiting a response.  ::)  Thanks for your help through all of this!  Now back to my other forum post about bridging it now (fingers crossed): http://forum.pfsense.org/index.php/topic,43799.0.html

  • I have completed my bridging pfSense blog post.  It has a decent section that talks about configuring wireless in general.  If anyone is interested they can see it here:  http://blog.qcsitter.com/BSDay/index.php?/archives/2-Bridging-the-pfSense-2.x-wireless-divide.html

Log in to reply