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

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

    Scheduled Pinned Locked Moved Wireless
    33 Posts 5 Posters 43.0k Views
    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.
    • B
      Bo
      last edited by

      I am trying to set-up my pfSense Box as Wireless Client on another Wifi Router (FritzBox! 7340)

      WAN -> FritzBox! (7340) (Wifi Client, WPA2, …)
      LAN -> Local Network, DHCP Server .......

      The machine is running on an Alix 2d3, with an wlm54sagp23. The box worked fine for years already with PfSense 1.x with the Wifi board as and AP. However I've recently moved to another house with the best option to set-up my LAN behind the pfSense box via Wireless connection to my Wifi Router (FritzBox!). Otherwise I will need to use a very long UTP cable.

      It turns out that I cannot get the Wifi card switched on in Infrastruture (BBS) mode, even if I assign it to another interface (OPT 1 for example). The card works fine if I switch it to AP mode, but I suppose it does not help me to get it configured as a client to the FritzBox!

      Even if I would be able to run it in Infrastructure mode (BBS) I would not know how to connect it the the AccessPoint (FritzBox!) as a Wifi Client.

      1. Where do I configure SSID of the AccessPoint? I suppose it is not in the same field as where I would define the SSID of the pfSense box itself in AP-mode or?
      2. Can I use the PSK field to define the key for access to my AccessPoint? or do I also need to define that elsewhere?
      3. Do I need to set the Speed and Duplex settings or can I leave it to default?
      4. Is it correct that the WAN interface needs to be connected to a wired network port that is actually connected before the pfSense box will start at all?
      5. What else would I need to configure and connect it to my accesspoint as a wificlient?
      6. Is there a howto available somewhere?

      Many thnx!

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

        @Bo:

        It turns out that I cannot get the Wifi card switched on in Infrastruture (BBS) mode, even if I assign it to another interface (OPT 1 for example). The card works fine if I switch it to AP mode, but I suppose it does not help me to get it configured as a client to the FritzBox!

        I've used 4 different WiFi interfaces in my pfSense boxes and they have all been access points. I don't recall reading of any problem with setting WiFi interfaces into infrastructure mode.
        What version of pfSense are you using?

        What are you doing to "get the wifi card switched on in Infrastructure mode?" And what happens after that attempt that leads to say the attempt failed?

        What is the FreeBSD interface name of the WiFi interface (ath0?, ral0? …)?

        @Bo:

        Even if I would be able to run it in Infrastructure mode (BBS) I would not know how to connect it the the AccessPoint (FritzBox!) as a Wifi Client.

        I expect it would be pretty much set the appropriate parameters through the web GUI, save and apply.

        @Bo:

        1. Where do I configure SSID of the AccessPoint? I suppose it is not in the same field as where I would define the SSID of the pfSense box itself in AP-mode or?

        SSID is SSID. The use of the value in the SSID field depends on the mode. (SSID in an access point specifies the SSID the AP broadcasts, SSID in infrastructure mode specifies the SSID of the AP the interface should associate with.)

        @Bo:

        1. Can I use the PSK field to define the key for access to my AccessPoint? or do I also need to define that elsewhere?

        Yes (if the AP is expecting a Pre Shared Key authentication). No.

        @Bo:

        1. Do I need to set the Speed and Duplex settings or can I leave it to default?

        Leave as default.

        @Bo:

        1. Is it correct that the WAN interface needs to be connected to a wired network port that is actually connected before the pfSense box will start at all?

        Not that I know of,  though startup will stall for a while if the WAN interface gets its parameters by DHCP and it can't talk with the DHCP server.

        @Bo:

        1. What else would I need to configure and connect it to my accesspoint as a wificlient?

        Use the web GUI.

        @Bo:

        1. Is there a howto available somewhere?

        On the pfSense home page click on the Documentation link and follow the links to the documentation Wiki where you will find links to a considerable number of Howtos.

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

          I configured OPT2 (ral0) on one of my pfSense boxes with static IP address and Infrastructure mode and it associated with the access point (shown in Status -> Interfaces.

          I did try configuring it with DHCP assigned IP address but that attempt failed because it was (falsely) alleged there was a configured DHCP server on the interface. I didn't explore why this happened.

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

            Just did such a trick recently when I was on holidays with my family. We were abroad so roaming / tethering was no option.
            Used an Alix 2d3 or so and put in two WLAN NICs (Atheros based CM9s)
            Bridged LAN and WLAN and got connectivity immediately from the config PC.
            Setup WAN with the other WLAN card (ath1) and configured it accordingly. Just as you would configure the other, local WLAN. This time as Infrastructure and not as AP, of course.
            Local provider used a portal page to enter credentials from the WiFi ticket. It popped open once I tried to reach an external IP. After entering user/pwd the connection stayed alive for approx. 24h until I had to re-sign in again.
            We happily shared the connection between 2 laptops, 2 iPhones and an iPad.

            Without the captive portal I would just enter the WLAN password in the corresponding field after making sure I use the right encryption method.
            I think I still have the config somewehere at home. Will try to look it up tonight and report back. But AFAIK there really wasn't anything unusual to this setup.

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

              Thanks for the feedback so far!

              Once more I've tried to setup the pfSense 2.0 RC3 box as an Infrastucture (BBS) connection point. I've assigned the Wifi interface ath0 to the WAN port, used a static IP address, added the IP address of my FritzBox as the gateway address, set the mode to Infrastructure (BBS), set the SSID to the SSID of my Fritzbox, enabled WPA, entered the WPA Pre Shared Key, enterd the WPA mode to "both" as configured in my Fritzbox and saved my settings!

              When I check the status of network cards on the Dashboard and it shows that the WAN port is down! (I have no idea how to turn it on otherwise than checking the box in the interface configuration).

              $ ifconfig ath0
              ath0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 2290
              ether 00:80:48:52:ff:3d
              media: IEEE 802.11 Wireless Ethernet autoselect mode 11b
              status: associated

              $ ifconfig
              vr0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
              options=8280b <rxcsum,txcsum,vlan_mtu,wol_ucast,wol_magic,linkstate>ether 00:0d:b9:17:96:94
              inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
              inet6 fe80::20d:b9ff:fe17:9694%vr0 prefixlen 64 scopeid 0x1
              nd6 options=3 <performnud,accept_rtadv>media: Ethernet autoselect (100baseTX <full-duplex>)
              status: active
              vr1: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
              options=8280b <rxcsum,txcsum,vlan_mtu,wol_ucast,wol_magic,linkstate>ether 00:0d:b9:17:96:95
              inet6 fe80::20d:b9ff:fe17:9695%vr1 prefixlen 64 scopeid 0x2
              inet 192.168.3.100 netmask 0xffffffff broadcast 192.168.3.100
              nd6 options=3 <performnud,accept_rtadv>media: Ethernet autoselect (100baseTX <full-duplex>)
              status: active
              vr2: flags=8802 <broadcast,simplex,multicast>metric 0 mtu 1500
              options=8280b <rxcsum,txcsum,vlan_mtu,wol_ucast,wol_magic,linkstate>ether 00:0d:b9:17:96:96
              media: Ethernet autoselect (none)
              status: no carrier
              ath0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 2290
              ether 00:80:48:52:ff:3d
              media: IEEE 802.11 Wireless Ethernet autoselect mode 11b
              status: associated
              pflog0: flags=100 <promisc>metric 0 mtu 33200
              lo0: flags=8049 <up,loopback,running,multicast>metric 0 mtu 16384
              options=3 <rxcsum,txcsum>inet6 ::1 prefixlen 128
              inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6
              inet 127.0.0.1 netmask 0xff000000
              nd6 options=3 <performnud,accept_rtadv>pfsync0: flags=0<> metric 0 mtu 1460
              syncpeer: 224.0.0.240 maxupd: 128
              enc0: flags=0<> metric 0 mtu 1536
              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
              inet 192.168.178.114 netmask 0xffffffff broadcast 192.168.178.114
              nd6 options=3 <performnud,accept_rtadv>media: IEEE 802.11 Wireless Ethernet autoselect mode 11b
              status: no carrier
              ssid WireLessRouter-III channel 7 (2442 MHz 11b)
              country US ecm authmode WPA1+WPA2/802.11i privacy ON deftxkey UNDEF
              txpower 25.5 bmiss 7 scanvalid 450 bgscan bgscanintvl 300
              bgscanidle 250 roam:rssi 7 roam:rate 1 burst roaming MANUAL

              The Fritzbox is transmitting on channel 1
              but as far as I know the status: no carrier means that the card is not online. Could it be a driver issue?
              or is there a way to diagnose why the card is not starting? or can I kick the card on manually?</performnud,accept_rtadv></up,broadcast,running,simplex,multicast></performnud,accept_rtadv></rxcsum,txcsum></up,loopback,running,multicast></promisc></up,broadcast,running,simplex,multicast></rxcsum,txcsum,vlan_mtu,wol_ucast,wol_magic,linkstate></broadcast,simplex,multicast></full-duplex></performnud,accept_rtadv></rxcsum,txcsum,vlan_mtu,wol_ucast,wol_magic,linkstate></up,broadcast,running,simplex,multicast></full-duplex></performnud,accept_rtadv></rxcsum,txcsum,vlan_mtu,wol_ucast,wol_magic,linkstate></up,broadcast,running,simplex,multicast></up,broadcast,running,simplex,multicast>

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

                I suspect that on your configuration no carrier means your card is not seeing the SSID from the AP.

                However I noticed that ath0 says it is associated. I wonder what it associated with.

                What do you see if you give the pfSense shell command # ifconfig ath0_wlan0 scan - it should display the SSID (and other data) of all the visible wireless networks.

                Your card has a good connection to a suitable antenna?

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

                  @Bo:

                  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
                  inet 192.168.178.114 netmask 0xffffffff broadcast 192.168.178.114
                  nd6 options=3 <performnud,accept_rtadv>media: IEEE 802.11 Wireless Ethernet autoselect mode 11b
                  status: no carrier
                  ssid WireLessRouter-III channel 7 (2442 MHz 11b)
                  country US ecm authmode WPA1+WPA2/802.11i privacy ON deftxkey UNDEF
                  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>

                  That does not correspond to what you wrote above or is suspicious.
                  Are you looking at the right settings page?

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

                    When I checked the status of the wlan card with ifconfig ath0_wlan0 several times I noticed it was actually scanning the network since it showed a different channel each time I executed the command.

                    After I changed the radio settings on my FritzBox to Adjust Radio Channel Settings and set the WLAN standard to 802.11n+g+b. The were able to find each other and the connection is now up and running! Great!

                    However now I still can't get any traffic over the pfSense box. Question is how to define the rules and do I need to add a static route on the FritzBox as well.

                    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

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

                    1 Reply Last reply Reply Quote 0
                    • 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
                                          • jahonixJ
                                            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
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.