Navigation

    Netgate Discussion Forum
    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search

    WireLess WAN - Infrastructure (BBS) mode? Wireless Client - 2.0 RC3

    Wireless
    5
    33
    37807
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • W
      wallabybob last edited by

      Good progress.

      @Bo:

      FritzBox: WAN - NAT - Wifi (192.168.0.1) + DHCP + DNS
      pfSense: WAN (192.168.178.2/24) + WANGW (192.168.178.1) - LAN (192.168.0.1/24) + DHCP

      I don't understand this information. For a start, having two subnets with the same address parameters hanging off two different machines is bad practice. At the very least its going to complicate your troubleshooting which you have already found complicated. Change the LAN subnet on pfSense to something unique on your network (it conflicts with the WiFi on FritzBox.)

      I thought you had WiFi between pfSense and Fritz so why aren't the addresses in the WiFi subnet?

      @Bo:

      Question is what NAT setting is needed in this case and do I need any specific rules to be defined?

      Now that you have your wireless link working I suggest you adopt the simplest configuration, get that working and then we can look at some optimisations.

      Change your pfSense WAN link IP address to DHCP. Then the default LAN firewall rules and NAT settings should allow access to internet. Check the pfSense WAN link has a correct IP address. From the pfSense console check you can ping an internet site (e.g. www.google.com) then check from one of your pfSense LAN clients.

      1 Reply Last reply Reply Quote 0
      • B
        Bo last edited by

        Sorry guys but the IP address of the internal FritsBox network was a slip of the pen! These are the correct settings:

        FritzBox: WAN - NAT - Wifi (192.168.178.1) + DHCP + DNS
        pfSense: WAN (192.168.178.2/24) + WANGW (192.168.178.1) - LAN (192.168.0.1/24) + DHCP

        However I tried the set the WAN port of the pfSense box to DHCP. The FritzBox! thinks that the IP address is set to 192.168.178.25 but the pfSense box does not get an IP address it is still 0.0.0.0 in this case.

        If I enter an fixed IP address I am not able to route any data from or behind the pfSense box to the FritzBox or further upstream.

        Could it be that I am just bumping into a bug and should I try to change back to pfSense 1.2.3?

        1 Reply Last reply Reply Quote 0
        • W
          wallabybob last edited by

          @Bo:

          Could it be that I am just bumping into a bug and should I try to change back to pfSense 1.2.3?

          You could be bumping into a software bug but I think its more likely to be a configuration "bug".

          Why did DHCP not work on the WAN interface? It could be helpful to have the dhclient output from the system log. Please post the output of the pfSense shell command clog /var/log/system.log | grep dhclient

          Why can't you route data from pfSense? Please post the output of the pfSense shell command netstat -r -n ; ping -c 4 192.168.178.1

          You can issue pfSense shell commands in a SSH session to the pfSense box or from the pfSense web GUI: Diagnostics -> Command Prompt and type the command in the Command box then click the Execute button.

          1 Reply Last reply Reply Quote 0
          • B
            Bo last edited by

            My FritzBox indicates that there is a connection and it provided an IP address to my pfsense box:

            	pfsenseboxname 	192.168.178.34	00:80:48:52:FF:3D	11 Mbit/s	WPA2 

            clog /var/log/system.log | grep dhclient
Jan  1 01:44:42 sargas dhclient: PREINIT
Jan  1 01:44:42 sargas dhclient[40488]: DHCPDISCOVER on ath0_wlan0 to 255.255.255.255 port 67 interval 2
Jan  1 01:44:43 sargas dhclient[40488]: DHCPDISCOVER on ath0_wlan0 to 255.255.255.255 port 67 interval 2
Jan  1 01:44:45 sargas dhclient[40488]: DHCPDISCOVER on ath0_wlan0 to 255.255.255.255 port 67 interval 4
Jan  1 01:44:49 sargas dhclient[40488]: DHCPDISCOVER on ath0_wlan0 to 255.255.255.255 port 67 interval 4
Jan  1 01:44:53 sargas dhclient[40488]: DHCPDISCOVER on ath0_wlan0 to 255.255.255.255 port 67 interval 4
Jan  1 01:44:57 sargas dhclient[40488]: DHCPDISCOVER on ath0_wlan0 to 255.255.255.255 port 67 interval 8
Jan  1 01:45:05 sargas dhclient[40488]: DHCPDISCOVER on ath0_wlan0 to 255.255.255.255 port 67 interval 10
Jan  1 01:45:15 sargas dhclient[40488]: DHCPDISCOVER on ath0_wlan0 to 255.255.255.255 port 67 interval 16
Jan  1 01:45:31 sargas dhclient[40488]: DHCPDISCOVER on ath0_wlan0 to 255.255.255.255 port 67 interval 10
Jan  1 01:45:41 sargas dhclient[40488]: No DHCPOFFERS received.
Jan  1 01:45:41 sargas dhclient[40488]: No working leases in persistent database - sleeping.
Jan  1 01:45:41 sargas dhclient: FAIL
Jan  1 01:45:42 sargas dhclient[3527]: DHCPDISCOVER on ath0_wlan0 to 255.255.255.255 port 67 interval 2
Jan  1 01:45:44 sargas dhclient[3527]: DHCPDISCOVER on ath0_wlan0 to 255.255.255.255 port 67 interval 4
Jan  1 01:45:48 sargas dhclient[3527]: DHCPDISCOVER on ath0_wlan0 to 255.255.255.255 port 67 interval 7
Jan  1 01:45:55 sargas dhclient[3527]: DHCPDISCOVER on ath0_wlan0 to 255.255.255.255 port 67 interval 10
Jan  1 01:46:05 sargas dhclient[3527]: DHCPDISCOVER on ath0_wlan0 to 255.255.255.255 port 67 interval 14
Jan  1 01:46:19 sargas dhclient[3527]: DHCPDISCOVER on ath0_wlan0 to 255.255.255.255 port 67 interval 17
Jan  1 01:46:36 sargas dhclient[3527]: DHCPDISCOVER on ath0_wlan0 to 255.255.255.255 port 67 interval 7
Jan  1 01:46:43 sargas dhclient[3527]: No DHCPOFFERS received.
Jan  1 01:46:43 sargas dhclient[3527]: No working leases in persistent database - sleeping.
Jan  1 01:46:43 sargas dhclient: FAIL

            netstat -r -n ; ping -c 4 192.168.178.1
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
0.0.0.0/8          link#9             U           0        0 ath0_w
127.0.0.1          link#6             UH          0      131    lo0
192.168.0.0/24     link#1             U           0     6782    vr0
192.168.0.1        link#1             UHS         0        0    lo0
192.168.3.100      link#2             UHS         0        0    lo0 =>
192.168.3.100/32   link#2             U           0        0    vr1

Internet6:
Destination                       Gateway                       Flags      Netif Expire
::1                               ::1                           UH          lo0
fe80::%vr0/64                     link#1                        U           vr0
fe80::20d:b9ff:fe17:9694%vr0      link#1                        UHS         lo0
fe80::%vr1/64                     link#2                        U           vr1
fe80::20d:b9ff:fe17:9695%vr1      link#2                        UHS         lo0
fe80::%lo0/64                     link#6                        U           lo0
fe80::1%lo0                       link#6                        UHS         lo0
fe80::%ath0_wlan0/64              link#9                        U      ath0_wla
fe80::280:48ff:fe52:ff3d%ath0_wlan0 link#9                        UHS         lo0
ff01:1::/32                       fe80::20d:b9ff:fe17:9694%vr0  U           vr0
ff01:2::/32                       fe80::20d:b9ff:fe17:9695%vr1  U           vr1
ff01:6::/32                       ::1                           U           lo0
ff01:9::/32                       fe80::280:48ff:fe52:ff3d%ath0_wlan0 U      ath0_wla
ff02::%vr0/32                     fe80::20d:b9ff:fe17:9694%vr0  U           vr0
ff02::%vr1/32                     fe80::20d:b9ff:fe17:9695%vr1  U           vr1
ff02::%lo0/32                     ::1                           U           lo0
ff02::%ath0_wlan0/32              fe80::280:48ff:fe52:ff3d%ath0_wlan0 U      ath0_wla
PING 192.168.178.1 (192.168.178.1): 56 data bytes

--- 192.168.178.1 ping statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss

            Does this help?

            1 Reply Last reply Reply Quote 0
            • W
              wallabybob last edited by

              @Bo:

              Does this help?

              YES in that it gives an explanation why you couldn't get data through your pfSense box: Despite issuing at least 15 DHCP requests the box didn't receive a recognisable answer to that request hence the WAN link (ath0_wlan0) doesn't have an IP address. (dhclient is the DHCP client program)

              Here's an example from one of my pfSense boxes (so you have an idea of a "good" DHCP request):

              Aug  6 08:48:42 pfsense2 dhclient[14231]: DHCPREQUEST on vr0 to 255.255.255.255 port 67
              Aug  6 08:48:42 pfsense2 dhclient[14231]: DHCPACK from 192.168.211.173
              Aug  6 08:48:42 pfsense2 dhclient: REBOOT
              Aug  6 08:48:42 pfsense2 dhclient: Starting add_new_address()
              Aug  6 08:48:42 pfsense2 dhclient: ifconfig vr0 inet 192.168.211.217 netmask 255.255.255.128 broadcast 192.168.211.255
              Aug  6 08:48:42 pfsense2 dhclient: New IP Address (vr0): 192.168.211.217
              Aug  6 08:48:42 pfsense2 dhclient: New Subnet Mask (vr0): 255.255.255.128
              Aug  6 08:48:42 pfsense2 dhclient: New Broadcast Address (vr0): 192.168.211.255
              Aug  6 08:48:42 pfsense2 dhclient: New Routers (vr0): 192.168.211.173
              Aug  6 08:48:42 pfsense2 dhclient: Adding new routes to interface: vr0
              Aug  6 08:48:42 pfsense2 dhclient: /sbin/route add default 192.168.211.173
              Aug  6 08:48:42 pfsense2 dhclient: Creating resolv.conf
              Aug  6 08:48:42 pfsense2 dhclient[14231]: bound to 192.168.211.217 – renewal in 3600 seconds.

              Next step is to try to figure out why pfSense doesn't seem to see a DHCP reply.
              Are any other computers (e.g. laptops) laced near your pfSense box able to associate with the Fritzbox and display an external web page (e.g. http://www.pfsense.org)?
              Does your pfSense see any response to its DHCP requests? Issue the pfSense shell command```
              tcpdump -i ath0_wlan0 -v -e -c 20

              1 Reply Last reply Reply Quote 0
              • B
                Bo last edited by

                Are any other computers (e.g. laptops) laced near your pfSense box able to associate with the Fritzbox and display an external web page (e.g. http://www.pfsense.org)?

                Yes, I am sitting next to my pfSense box and typing this stuff from my macbook which is connected over Wifi as a DHCP client to the FritzBox. So a connection is possible.

                Here is the tcpdump with the WAN interface as a DHCP client

                $ tcpdump -i ath0_wlan0 -v -e -c 20
08:22:29.017231 00:80:48:52:ff:3d (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 16, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:80:48:52:ff:3d (oui Unknown), length 300, xid 0x4f1cf11f, secs 60, Flags [none]
	  Client-Ethernet-Address 00:80:48:52:ff:3d (oui Unknown) [|bootp]
08:22:29.022922 bc:05:43:bc:85:91 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.34 tell 192.168.178.1, length 28
08:22:31.037531 00:80:48:52:ff:3d (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 16, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:80:48:52:ff:3d (oui Unknown), length 300, xid 0xe997d5b0, Flags [none]
	  Client-Ethernet-Address 00:80:48:52:ff:3d (oui Unknown) [|bootp]
08:22:31.043267 bc:05:43:bc:85:91 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.34 tell 192.168.178.1, length 28
08:22:32.047345 00:80:48:52:ff:3d (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 16, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:80:48:52:ff:3d (oui Unknown), length 300, xid 0xe997d5b0, secs 1, Flags [none]
	  Client-Ethernet-Address 00:80:48:52:ff:3d (oui Unknown) [|bootp]
08:22:32.052883 bc:05:43:bc:85:91 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.34 tell 192.168.178.1, length 28
08:22:33.057266 00:80:48:52:ff:3d (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 16, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:80:48:52:ff:3d (oui Unknown), length 300, xid 0xe997d5b0, secs 2, Flags [none]
	  Client-Ethernet-Address 00:80:48:52:ff:3d (oui Unknown) [|bootp]
08:22:33.062438 bc:05:43:bc:85:91 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.34 tell 192.168.178.1, length 28
08:22:35.077273 00:80:48:52:ff:3d (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 16, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:80:48:52:ff:3d (oui Unknown), length 300, xid 0xe997d5b0, secs 4, Flags [none]
	  Client-Ethernet-Address 00:80:48:52:ff:3d (oui Unknown) [|bootp]
08:22:35.082590 bc:05:43:bc:85:91 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.34 tell 192.168.178.1, length 28
08:22:36.962291 bc:05:43:bc:85:91 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.21 tell 192.168.178.1, length 28
08:22:37.958047 bc:05:43:bc:85:91 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.21 tell 192.168.178.1, length 28
08:22:38.107500 00:80:48:52:ff:3d (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 16, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:80:48:52:ff:3d (oui Unknown), length 300, xid 0xe997d5b0, secs 7, Flags [none]
	  Client-Ethernet-Address 00:80:48:52:ff:3d (oui Unknown) [|bootp]
08:22:38.112719 bc:05:43:bc:85:91 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.34 tell 192.168.178.1, length 28
08:22:38.953883 bc:05:43:bc:85:91 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.21 tell 192.168.178.1, length 28
08:22:40.487459 bc:05:43:bc:85:91 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.21 tell 192.168.178.1, length 28
08:22:41.137361 00:80:48:52:ff:3d (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 16, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:80:48:52:ff:3d (oui Unknown), length 300, xid 0xe997d5b0, secs 10, Flags [none]
	  Client-Ethernet-Address 00:80:48:52:ff:3d (oui Unknown) [|bootp]
08:22:41.142837 bc:05:43:bc:85:91 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.34 tell 192.168.178.1, length 28
08:22:41.483189 bc:05:43:bc:85:91 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.21 tell 192.168.178.1, length 28
08:22:42.478972 bc:05:43:bc:85:91 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.21 tell 192.168.178.1, length 28

                If I manually set the IP address of the WAN port to 192.168.178.2 I get the following response:

                $ tcpdump -i ath0_wlan0 -v -e -c 20
08:32:12.559473 bc:05:43:bc:85:91 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.21 tell 192.168.178.1, length 28
08:32:12.703830 00:80:48:52:ff:3d (oui Unknown) > bc:05:43:bc:85:91 (oui Unknown), ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 64, id 5907, offset 0, flags [none], proto ICMP (1), length 64)
    192.168.178.2 > 192.168.178.1: ICMP echo request, id 1637, seq 16640, length 44
08:32:12.824888 00:80:48:52:ff:3d (oui Unknown) > bc:05:43:bc:85:91 (oui Unknown), ethertype IPv4 (0x0800), length 87: (tos 0x0, ttl 64, id 756, offset 0, flags [none], proto UDP (17), length 73)
    192.168.178.2.29343 > 192.168.178.1.domain: 19761+ PTR? 21.178.168.192.in-addr.arpa. (45)
08:32:13.555228 bc:05:43:bc:85:91 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.21 tell 192.168.178.1, length 28
08:32:13.713782 00:80:48:52:ff:3d (oui Unknown) > bc:05:43:bc:85:91 (oui Unknown), ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 64, id 20205, offset 0, flags [none], proto ICMP (1), length 64)
    192.168.178.2 > 192.168.178.1: ICMP echo request, id 1637, seq 16896, length 44
08:32:13.718683 bc:05:43:bc:85:91 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.2 tell 192.168.178.1, length 28
08:32:13.718700 00:80:48:52:ff:3d (oui Unknown) > bc:05:43:bc:85:91 (oui Unknown), ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 192.168.178.2 is-at 00:80:48:52:ff:3d (oui Unknown), length 28
08:32:14.551061 bc:05:43:bc:85:91 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.21 tell 192.168.178.1, length 28
08:32:14.723817 00:80:48:52:ff:3d (oui Unknown) > bc:05:43:bc:85:91 (oui Unknown), ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 64, id 5842, offset 0, flags [none], proto ICMP (1), length 64)
    192.168.178.2 > 192.168.178.1: ICMP echo request, id 1637, seq 17152, length 44
08:32:15.733765 00:80:48:52:ff:3d (oui Unknown) > bc:05:43:bc:85:91 (oui Unknown), ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 64, id 2758, offset 0, flags [none], proto ICMP (1), length 64)
    192.168.178.2 > 192.168.178.1: ICMP echo request, id 1637, seq 17408, length 44
08:32:16.743796 00:80:48:52:ff:3d (oui Unknown) > bc:05:43:bc:85:91 (oui Unknown), ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 64, id 9343, offset 0, flags [none], proto ICMP (1), length 64)
    192.168.178.2 > 192.168.178.1: ICMP echo request, id 1637, seq 17664, length 44
08:32:17.753828 00:80:48:52:ff:3d (oui Unknown) > bc:05:43:bc:85:91 (oui Unknown), ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 64, id 9533, offset 0, flags [none], proto ICMP (1), length 64)
    192.168.178.2 > 192.168.178.1: ICMP echo request, id 1637, seq 17920, length 44
08:32:17.833762 00:80:48:52:ff:3d (oui Unknown) > bc:05:43:bc:85:91 (oui Unknown), ethertype IPv4 (0x0800), length 87: (tos 0x0, ttl 64, id 36741, offset 0, flags [none], proto UDP (17), length 73)
    192.168.178.2.29343 > 192.168.178.1.domain: 19761+ PTR? 21.178.168.192.in-addr.arpa. (45)
08:32:18.763838 00:80:48:52:ff:3d (oui Unknown) > bc:05:43:bc:85:91 (oui Unknown), ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 64, id 11085, offset 0, flags [none], proto ICMP (1), length 64)
    192.168.178.2 > 192.168.178.1: ICMP echo request, id 1637, seq 18176, length 44
08:32:19.773837 00:80:48:52:ff:3d (oui Unknown) > bc:05:43:bc:85:91 (oui Unknown), ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 64, id 51002, offset 0, flags [none], proto ICMP (1), length 64)
    192.168.178.2 > 192.168.178.1: ICMP echo request, id 1637, seq 18432, length 44
08:32:20.783819 00:80:48:52:ff:3d (oui Unknown) > bc:05:43:bc:85:91 (oui Unknown), ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 64, id 21743, offset 0, flags [none], proto ICMP (1), length 64)
    192.168.178.2 > 192.168.178.1: ICMP echo request, id 1637, seq 18688, length 44
08:32:21.794335 00:80:48:52:ff:3d (oui Unknown) > bc:05:43:bc:85:91 (oui Unknown), ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 64, id 42508, offset 0, flags [none], proto ICMP (1), length 64)
    192.168.178.2 > 192.168.178.1: ICMP echo request, id 1637, seq 18944, length 44
08:32:22.803892 00:80:48:52:ff:3d (oui Unknown) > bc:05:43:bc:85:91 (oui Unknown), ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 64, id 8272, offset 0, flags [none], proto ICMP (1), length 64)
    192.168.178.2 > 192.168.178.1: ICMP echo request, id 1637, seq 19200, length 44
08:32:23.813903 00:80:48:52:ff:3d (oui Unknown) > bc:05:43:bc:85:91 (oui Unknown), ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 64, id 60195, offset 0, flags [none], proto ICMP (1), length 64)
    192.168.178.2 > 192.168.178.1: ICMP echo request, id 1637, seq 19456, length 44
08:32:24.823887 00:80:48:52:ff:3d (oui Unknown) > bc:05:43:bc:85:91 (oui Unknown), ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 64, id 5455, offset 0, flags [none], proto ICMP (1), length 64)
    192.168.178.2 > 192.168.178.1: ICMP echo request, id 1637, seq 19712, length 44
                1 Reply Last reply Reply Quote 0
                • W
                  wallabybob last edited by

                  @Bo:

                  Yes, I am sitting next to my pfSense box and typing this stuff from my macbook which is connected over Wifi as a DHCP client to the FritzBox. So a connection is possible.

                  Thanks. Useful datapoint.

                  I've adjusted the spacing in the following trace and deleted some entries that don't seem relevant.
                  @Bo:

                  Here is the tcpdump with the WAN interface as a DHCP client

                  $ tcpdump -i ath0_wlan0 -v -e -c 20
08:22:29.017231 00:80:48:52:ff:3d (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 16, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:80:48:52:ff:3d (oui Unknown), length 300, xid 0x4f1cf11f, secs 60, Flags [none]
	  Client-Ethernet-Address 00:80:48:52:ff:3d (oui Unknown) [|bootp]

08:22:29.022922 bc:05:43:bc:85:91 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.34 tell 192.168.178.1, length 28

08:22:31.037531 00:80:48:52:ff:3d (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 16, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:80:48:52:ff:3d (oui Unknown), length 300, xid 0xe997d5b0, Flags [none]
	  Client-Ethernet-Address 00:80:48:52:ff:3d (oui Unknown) [|bootp]

08:22:31.043267 bc:05:43:bc:85:91 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.34 tell 192.168.178.1, length 28

08:22:32.047345 00:80:48:52:ff:3d (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 16, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:80:48:52:ff:3d (oui Unknown), length 300, xid 0xe997d5b0, secs 1, Flags [none]
	  Client-Ethernet-Address 00:80:48:52:ff:3d (oui Unknown) [|bootp]

08:22:32.052883 bc:05:43:bc:85:91 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.34 tell 192.168.178.1, length 28

08:22:33.057266 00:80:48:52:ff:3d (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 16, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:80:48:52:ff:3d (oui Unknown), length 300, xid 0xe997d5b0, secs 2, Flags [none]
	  Client-Ethernet-Address 00:80:48:52:ff:3d (oui Unknown) [|bootp]

08:22:33.062438 bc:05:43:bc:85:91 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.34 tell 192.168.178.1, length 28

08:22:35.077273 00:80:48:52:ff:3d (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 16, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:80:48:52:ff:3d (oui Unknown), length 300, xid 0xe997d5b0, secs 4, Flags [none]
	  Client-Ethernet-Address 00:80:48:52:ff:3d (oui Unknown) [|bootp]

08:22:35.082590 bc:05:43:bc:85:91 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.34 tell 192.168.178.1, length 28

08:22:38.107500 00:80:48:52:ff:3d (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 16, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:80:48:52:ff:3d (oui Unknown), length 300, xid 0xe997d5b0, secs 7, Flags [none]
	  Client-Ethernet-Address 00:80:48:52:ff:3d (oui Unknown) [|bootp]

08:22:38.112719 bc:05:43:bc:85:91 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.34 tell 192.168.178.1, length 28

08:22:41.137361 00:80:48:52:ff:3d (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 16, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:80:48:52:ff:3d (oui Unknown), length 300, xid 0xe997d5b0, secs 10, Flags [none]
	  Client-Ethernet-Address 00:80:48:52:ff:3d (oui Unknown) [|bootp]

08:22:41.142837 bc:05:43:bc:85:91 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.34 tell 192.168.178.1, length 28

                  The trace shows the DHCP requests from your pfSense. The Fritzbox doesn't appear to send a DHCP reply (maybe it did send a DHCP reply that got damaged and was discarded) but about 0.005 seconds later appears to send an ARP (Address Resolution Protocol) request asking the system with IP address 192.168.178.34 to reply to 192.168.178.1 (so 192.168.178.1 knows the MAC address of 192.168.178.34). Is bc:05:43:bc:85:91 the MAC address of the FritzBox WiFi interface?

                  The FritzBox appears to be ignoring the DHCP request (perhaps because it doesn't see it).  Does the FritzBox have some sort of packet tracing facility or DHCP logging that could be used to see if the DHCP request is arriving there?

                  As before I'll adjust the spacing and remove some entries that seem irrelevant.
                  @Bo:

                  If I manually set the IP address of the WAN port to 192.168.178.2 I get the following response:

                  $ tcpdump -i ath0_wlan0 -v -e -c 20
08:32:12.703830 00:80:48:52:ff:3d (oui Unknown) > bc:05:43:bc:85:91 (oui Unknown), ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 64, id 5907, offset 0, flags [none], proto ICMP (1), length 64)
    192.168.178.2 > 192.168.178.1: ICMP echo request, id 1637, seq 16640, length 44

08:32:12.824888 00:80:48:52:ff:3d (oui Unknown) > bc:05:43:bc:85:91 (oui Unknown), ethertype IPv4 (0x0800), length 87: (tos 0x0, ttl 64, id 756, offset 0, flags [none], proto UDP (17), length 73)
    192.168.178.2.29343 > 192.168.178.1.domain: 19761+ PTR? 21.178.168.192.in-addr.arpa. (45)

08:32:13.713782 00:80:48:52:ff:3d (oui Unknown) > bc:05:43:bc:85:91 (oui Unknown), ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 64, id 20205, offset 0, flags [none], proto ICMP (1), length 64)
    192.168.178.2 > 192.168.178.1: ICMP echo request, id 1637, seq 16896, length 44

08:32:13.718683 bc:05:43:bc:85:91 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.2 tell 192.168.178.1, length 28

08:32:13.718700 00:80:48:52:ff:3d (oui Unknown) > bc:05:43:bc:85:91 (oui Unknown), ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 192.168.178.2 is-at 00:80:48:52:ff:3d (oui Unknown), length 28

08:32:14.723817 00:80:48:52:ff:3d (oui Unknown) > bc:05:43:bc:85:91 (oui Unknown), ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 64, id 5842, offset 0, flags [none], proto ICMP (1), length 64)
    192.168.178.2 > 192.168.178.1: ICMP echo request, id 1637, seq 17152, length 44

08:32:15.733765 00:80:48:52:ff:3d (oui Unknown) > bc:05:43:bc:85:91 (oui Unknown), ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 64, id 2758, offset 0, flags [none], proto ICMP (1), length 64)
    192.168.178.2 > 192.168.178.1: ICMP echo request, id 1637, seq 17408, length 44

08:32:16.743796 00:80:48:52:ff:3d (oui Unknown) > bc:05:43:bc:85:91 (oui Unknown), ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 64, id 9343, offset 0, flags [none], proto ICMP (1), length 64)
    192.168.178.2 > 192.168.178.1: ICMP echo request, id 1637, seq 17664, length 44

08:32:17.753828 00:80:48:52:ff:3d (oui Unknown) > bc:05:43:bc:85:91 (oui Unknown), ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 64, id 9533, offset 0, flags [none], proto ICMP (1), length 64)
    192.168.178.2 > 192.168.178.1: ICMP echo request, id 1637, seq 17920, length 44

08:32:17.833762 00:80:48:52:ff:3d (oui Unknown) > bc:05:43:bc:85:91 (oui Unknown), ethertype IPv4 (0x0800), length 87: (tos 0x0, ttl 64, id 36741, offset 0, flags [none], proto UDP (17), length 73)
    192.168.178.2.29343 > 192.168.178.1.domain: 19761+ PTR? 21.178.168.192.in-addr.arpa. (45)

08:32:18.763838 00:80:48:52:ff:3d (oui Unknown) > bc:05:43:bc:85:91 (oui Unknown), ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 64, id 11085, offset 0, flags [none], proto ICMP (1), length 64)
    192.168.178.2 > 192.168.178.1: ICMP echo request, id 1637, seq 18176, length 44

08:32:19.773837 00:80:48:52:ff:3d (oui Unknown) > bc:05:43:bc:85:91 (oui Unknown), ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 64, id 51002, offset 0, flags [none], proto ICMP (1), length 64)
    192.168.178.2 > 192.168.178.1: ICMP echo request, id 1637, seq 18432, length 44

08:32:20.783819 00:80:48:52:ff:3d (oui Unknown) > bc:05:43:bc:85:91 (oui Unknown), ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 64, id 21743, offset 0, flags [none], proto ICMP (1), length 64)
    192.168.178.2 > 192.168.178.1: ICMP echo request, id 1637, seq 18688, length 44

08:32:21.794335 00:80:48:52:ff:3d (oui Unknown) > bc:05:43:bc:85:91 (oui Unknown), ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 64, id 42508, offset 0, flags [none], proto ICMP (1), length 64)
    192.168.178.2 > 192.168.178.1: ICMP echo request, id 1637, seq 18944, length 44

08:32:22.803892 00:80:48:52:ff:3d (oui Unknown) > bc:05:43:bc:85:91 (oui Unknown), ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 64, id 8272, offset 0, flags [none], proto ICMP (1), length 64)
    192.168.178.2 > 192.168.178.1: ICMP echo request, id 1637, seq 19200, length 44

08:32:23.813903 00:80:48:52:ff:3d (oui Unknown) > bc:05:43:bc:85:91 (oui Unknown), ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 64, id 60195, offset 0, flags [none], proto ICMP (1), length 64)
    192.168.178.2 > 192.168.178.1: ICMP echo request, id 1637, seq 19456, length 44

08:32:24.823887 00:80:48:52:ff:3d (oui Unknown) > bc:05:43:bc:85:91 (oui Unknown), ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 64, id 5455, offset 0, flags [none], proto ICMP (1), length 64)
    192.168.178.2 > 192.168.178.1: ICMP echo request, id 1637, seq 19712, length 44

                  The FritzBox is apparently ignoring ping (ICMP echo request) from your pfSense. Does the FritzBox have some sort of filter or firewall that could be causing it to ignore transmissions from your pfSense? Again, is there some sort of tracing facility or logging in the FritzBox that might provide some more clues about what is going on?

                  1 Reply Last reply Reply Quote 0
                  • B
                    Bo last edited by

                    Looking at the WLAN logfile of the FritzBox! it turns out that there is some kind of an authentication problem:

                    06.08.11	20:57:21	WLAN registration failed (2,4 GHz): Authorization failed. Name: sargas, MAC address: 00:80:48:52:FF:3D.

                    When I turn off the ecryption the pfSense box properly gets an IP address and the connection works!
                    Finally some progress, but of course one would need to turn on WPA2 again.

                    On my FritzBox I have choosen the option "WPA + WPA2" other options are "TKIP (WPA)" and "WPA2 (CCMP)"
                    I am not completely sure how to configure my pfSense box.

                    When I choose the options:
                    WPA: Enable WPA
                    PSK: "MySecretKey"
                    WPA Mode: Both
                    WPA Key Management Mode: Pre Shared Key
                    Authentication: Open System Authentication
                    WPA Pairwise: Both

                    When I look into the WLAN logfiel of the FritzBox! it indicates that the pfSense box is properly registred

                    06.08.11	21:30:57	WLAN device registered (2,4 GHz). Name: sargas, IP address: 192.168.178.20, MAC address: 00:80:48:52:FF:3D, throughput: 11 Mbit/s

                    The logfile on the pfSense box also shows that the DHCP client is properly registred:

                    Jan  2 00:02:52 sargas dhclient: Starting add_new_address()
Jan  2 00:02:52 sargas dhclient: ifconfig ath0_wlan0 inet 192.168.178.20 netmask 255.255.255.0 broadcast 192.168.178.255 
Jan  2 00:02:52 sargas dhclient: New IP Address (ath0_wlan0): 192.168.178.20
Jan  2 00:02:52 sargas dhclient: New Subnet Mask (ath0_wlan0): 255.255.255.0
Jan  2 00:02:52 sargas dhclient: New Broadcast Address (ath0_wlan0): 192.168.178.255
Jan  2 00:02:52 sargas dhclient: New Routers (ath0_wlan0): 192.168.178.1

                    But if I look at the dashboard I don't see the right IP address but:

                    DS/11Mbps mode 11b

                    No idea what DS means?

                    Checking ifconfig

                    $ ifconfig ath0_wlan0
ath0_wlan0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
	ether 00:80:48:52:ff:3d
	inet6 fe80::280:48ff:fe52:ff3d%ath0_wlan0 prefixlen 64 scopeid 0x9 
	nd6 options=3 <performnud,accept_rtadv>media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11b
	status: associated
	ssid WirelessRouter-III channel 1 (2412 MHz 11b) bssid bc:05:43:bc:85:93
	country US ecm authmode WPA2/802.11i privacy ON deftxkey UNDEF
	TKIP 2:128-bit txpower 25.5 bmiss 7 scanvalid 450 bgscan
	bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 1 burst
	roaming MANUAL</performnud,accept_rtadv></up,broadcast,running,simplex,multicast>
                    1 Reply Last reply Reply Quote 0
                    • W
                      wallabybob last edited by

                      It is strange that dhclient reports being assigned an IPv4 IP address but ifconfig doesn't report an IPv4 address.

                      I don't know what the DS in

                      media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11b

                      means.

                      Can you get your link to operate in 802.11g mode rather than 802.11b? You may need to make adjustments at both ends OR it may be forced into 11b mode by an 11b only device.

                      1 Reply Last reply Reply Quote 0
                      • B
                        Bo last edited by

                        Switching over to 11g mode does not seem to be an issue. Signal strength is at its maximum, Both sides report that they communicate with each other in 11g mode:

                        sargas 	192.168.178.20	00:80:48:52:FF:3D	54 Mbit/s	WPA

                        But still only if I turn off the ecryption the DHCP client receives an IP address.

                        1 Reply Last reply Reply Quote 0
                        • W
                          wallabybob last edited by

                          I wonder if it would help to tighten the encryption parameters step by step and record the results. On pfSense change WPA mode from Both to WPA2 and make the corresponding change in Fritzbox. DHCP exchange? If no, tighten WPA2 Pairwise from Both to AES and make corresponding change in Fritzbox. Does DHCP work? If not try WPA2 Pairwise as TKIP and make corresponding change in Fritzbox. etc.

                          I saw a software upgrade on my netbook break WiFi. WiFi on windows laptops continued operating. I changed my pfSense access point: WPA2 Pairwise from Both to AES fixed the problem.

                          I'm not very confident my suggestion will help you discover a working set of parameters but might provide some useful data.

                          1 Reply Last reply Reply Quote 0
                          • jahonix
                            jahonix last edited by

                            Just out of curiosity, please show your interface assign page.
                            I saw you using ath0_wlan1 which is a virtual second IF on your atheros card. That one directly would be ath0.

                            Chances are you configure the 'other' interface which is not currently assigned to a network.

                            I've taken a screenshot from my test box which contains two separate atheros cards (ath0 and ath1) and a virtual one (ath0_wlan1) just to show you:

                            Why do you have a second virtual IF at all? Just assign ath0 to your WAN.
                            Depending on the pfSense build you're using, there seem to be some inconsistencies with real and virtual IFs.
                            I had an ALIX system where I couldn't bridge vr1 and ath0; using vr1 and ath0_wlan1 worked immediately.
                            Just a guess, though…

                            1 Reply Last reply Reply Quote 0
                            • B
                              Bo last edited by

                              Meanwhile I've tried to thighten up the Wifi encryption from scratch but so far I haven't found an encryption option that works (didn't try WEP ;-D).

                              I am quiet sure I've tried all possible combinations, but no succes so far!

                              I've tested the option to define a virtual Wifi card as well, but pfSense does not allow me to define a virtual Wifi card a Infrastructure BBS.

                              For the record, here are my interface assignments:
                              WAN: ath0
                              LAN: vr0
                              OPT1: vr1

                              1 Reply Last reply Reply Quote 0
                              • W
                                wallabybob last edited by

                                @Bo:

                                I've tested the option to define a virtual Wifi card as well, but pfSense does not allow me to define a virtual Wifi card a Infrastructure BBS.

                                The FreeBSD man page for ath says

                                The driver supports station, adhoc, adhoc-demo, hostap, mesh, wds, and monitor mode operation.  Multiple hostap virtual interfaces may be configured for simultaneous use on cards that use a 5212 part.  When multiple interfaces are configured each may have a separate mac address that is formed by setting the U/L bits in the mac address assigned to the underlying device.  Any number of wds virtual interfaces may be configured together with hostap interfaces.  _Multiple station interfaces may be operated together with hostap interfaces to construct a wireless repeater device. _

                                The man page (or at least this paragraph) leaves unclear whether multiple station interfaces may be operated WITHOUT a hostap interface.

                                1 Reply Last reply Reply Quote 0
                                • B
                                  Bo last edited by

                                  Although it would be nice to also be able to configure the pfSense box as an secondary AP next to the infrastructure (BBS) connection, but that would be the icing on the cake.

                                  I am refuse to believe that I am the first one to bump into this issue and strongly have the feeling that there is some easy workaround, but …...............

                                  what's causing the security conflict? based on the ifconfig ath0_wlan0 output I have the feeling that the box is switching to IPv6 mode without having it configured (see log in my reply on Posted on: August 06, 2011, 04:17:23 pm).

                                  1 Reply Last reply Reply Quote 0
                                  • W
                                    wallabybob last edited by

                                    @Bo:

                                    I am refuse to believe that I am the first one to bump into this issue and strongly have the feeling that there is some easy workaround, but …...............

                                    My readings of the forums suggest it is much more common to use a pfSense WiFi link as an AP than as an AP client. I think your post is the first mention I have seen of a Fritzbox. This suggests your configuration is probably fairly rare.

                                    @Bo:

                                    what's causing the security conflict? based on the ifconfig ath0_wlan0 output I have the feeling that the box is switching to IPv6 mode without having it configured (see log in my reply on Posted on: August 06, 2011, 04:17:23 pm).

                                    I don't know what is causing the security conflict. I don't know what facilities there are in FreeBSD to debug this kind of issue. Concerning the IPv6: for some releases now FreeBSD has "automatically" configured "link local" IPv6 addresses based on MAC address for those interfaces with a MAC address. It is rather unlikely that enabling encryption on a WiFi interface would also turn it into "drop IPv4 traffic" mode if the interface is in client mode but not if it is in AP mode. (I have an ath interface in AP mode using encryption and successfully passing IPv4 traffic.)

                                    1 Reply Last reply Reply Quote 0
                                    • B
                                      Bo last edited by

                                      Well I've used the same pfSense box for multiple years as an Wifi AP using WPA+WPA2 as encryption and never experienced any problems. It might be the other side of the line: the Fritz!Box causing all the issues.

                                      I'll go and look for another AP and check if the pfSense box can establish a secured connection in Infrastructure mode with this AP.

                                      1 Reply Last reply Reply Quote 0
                                      • jahonix
                                        jahonix last edited by

                                        Yesterday i tried to connect an ALIX with ath0 cards to a Linksys WRT54GL wireless AP (which is running DD-WRT).
                                        I was able to get an IP from the DHCP pool (hence encryption [WPA2 AES] is working) but wasn't able to pass traffic. I couldn't even ping anything on ALIX WAN.

                                        And you were right, Bo, Infrastructure mode only works on the virtual ath0_wlan1 interface, not the native card IF ath0.
                                        I think there were issues with some of the snapshot builds in the past where you couldn't assign IFs correctly. Will try a recent snapshot tonight and report back.

                                        1 Reply Last reply Reply Quote 0
                                        • B
                                          Bo last edited by

                                          Good to hear I am not alone out there!

                                          1 Reply Last reply Reply Quote 0
                                          • B
                                            Bo last edited by

                                            I think there were issues with some of the snapshot builds in the past where you couldn't assign IFs correctly. Will try a recent snapshot tonight and report back.

                                            Any news on the recent snapshots? Are these issues resolved in these snapshots?

                                            1 Reply Last reply Reply Quote 0
                                            • jahonix
                                              jahonix last edited by

                                              Sorry, didn't have the time to do anything with pfSense in the last days.
                                              Busy at work and even more busy at home, fixing other stuff.

                                              I'll report back as soon as I had the time to test.

                                              1 Reply Last reply Reply Quote 0
                                              • B
                                                Bo last edited by

                                                Chris, great that your still willing to spend some time testing the recent snapshots!
                                                Take your time, since I'll be on holidays the next three weeks!

                                                1 Reply Last reply Reply Quote 0
                                                • B
                                                  Bo last edited by

                                                  Any news already on the new snapshots?

                                                  1 Reply Last reply Reply Quote 0
                                                  • E
                                                    EricMc last edited by

                                                    Have you had any luck with this?  I am having the same problem with the 2.0 release on an Alix board.  The router I am connecting to is a Sierra Wireless AirCard 754s (AT&T Elevate).  I can get an IP from it when security is turned off, but not with WPA/WPA2.

                                                    1 Reply Last reply Reply Quote 0
                                                    • S
                                                      Saturn2888 last edited by

                                                      I've been in the same boat, can't ever connect to any wireless AP using WPA, but I can if it's open.

                                                      EDIT: I just switched to a different Wi-Fi adapter, and it worked.

                                                      The issue here is with the driver for that device. I know it supports WPA and WPA2 since it works in Windows.

                                                      Didn't work:
                                                      ural
                                                      run

                                                      Worked
                                                      utrw

                                                      Two of the USB devices wouldn't even show up. One of them was a TP-Link TL-WN722N which showed up as <atheros>and the other I can't figure out which it is until I start unplugging them.</atheros>

                                                      1 Reply Last reply Reply Quote 0
                                                      • First post
                                                        Last post

                                                      Products

                                                      • Platform Overview
                                                      • TNSR
                                                      • pfSense
                                                      • Appliances

                                                      Services

                                                      • Training
                                                      • Professional Services

                                                      Support

                                                      • Subscription Plans
                                                      • Contact Support
                                                      • Product Lifecycle
                                                      • Documentation

                                                      News

                                                      • Media Coverage
                                                      • Press
                                                      • Events

                                                      Resources

                                                      • Blog
                                                      • FAQ
                                                      • Find a Partner
                                                      • Resource Library
                                                      • Security Information

                                                      Company

                                                      • About Us
                                                      • Careers
                                                      • Partners
                                                      • Contact Us
                                                      • Legal
                                                      Our Mission

                                                      We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                                                      Subscribe to our Newsletter

                                                      Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                                                      © 2021 Rubicon Communications, LLC | Privacy Policy