@DenverDesktopsSupport you should see your AP sending traffic to the IP of the controller over 8080 Here I can see my APs talking to the controller 192.168.2.13, .2 is AP, .3 is AP .6 is a flex mini - sure if I let it run longer would see .4 checking in. Another one of my AP. root@UC:/home/user# tcpdump tcp port 8080 -n tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on ens3, link-type EN10MB (Ethernet), snapshot length 262144 bytes 18:06:51.984496 IP 192.168.2.2.33366 > 192.168.2.13.8080: Flags [S], seq 1295904412, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 4], length 0 18:06:51.984574 IP 192.168.2.13.8080 > 192.168.2.2.33366: Flags [S.], seq 1349332694, ack 1295904413, win 64240, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 18:06:51.985319 IP 192.168.2.2.33366 > 192.168.2.13.8080: Flags [.], ack 1, win 1825, length 0 18:06:51.985819 IP 192.168.2.2.33366 > 192.168.2.13.8080: Flags [.], seq 1:2921, ack 1, win 1825, length 2920: HTTP: POST /inform HTTP/1.1 18:06:51.985872 IP 192.168.2.13.8080 > 192.168.2.2.33366: Flags [.], ack 2921, win 497, length 0 18:06:51.985903 IP 192.168.2.2.33366 > 192.168.2.13.8080: Flags [.], seq 2921:5841, ack 1, win 1825, length 2920: HTTP 18:06:51.985917 IP 192.168.2.13.8080 > 192.168.2.2.33366: Flags [.], ack 5841, win 485, length 0 18:06:51.985953 IP 192.168.2.2.33366 > 192.168.2.13.8080: Flags [.], seq 5841:7301, ack 1, win 1825, length 1460: HTTP 18:06:51.985966 IP 192.168.2.13.8080 > 192.168.2.2.33366: Flags [.], ack 7301, win 479, length 0 18:06:51.985986 IP 192.168.2.2.33366 > 192.168.2.13.8080: Flags [.], seq 7301:8761, ack 1, win 1825, length 1460: HTTP 18:06:51.985996 IP 192.168.2.13.8080 > 192.168.2.2.33366: Flags [.], ack 8761, win 473, length 0 18:06:51.986032 IP 192.168.2.2.33366 > 192.168.2.13.8080: Flags [P.], seq 8761:9995, ack 1, win 1825, length 1234: HTTP 18:06:51.986042 IP 192.168.2.13.8080 > 192.168.2.2.33366: Flags [.], ack 9995, win 467, length 0 18:06:51.992519 IP 192.168.2.13.8080 > 192.168.2.2.33366: Flags [P.], seq 1:739, ack 9995, win 501, length 738: HTTP: HTTP/1.1 200 18:06:51.992926 IP 192.168.2.2.33366 > 192.168.2.13.8080: Flags [.], ack 739, win 1918, length 0 18:06:51.993288 IP 192.168.2.2.33366 > 192.168.2.13.8080: Flags [F.], seq 9995, ack 739, win 1918, length 0 18:06:51.999471 IP 192.168.2.13.8080 > 192.168.2.2.33366: Flags [F.], seq 739, ack 9996, win 501, length 0 18:06:51.999900 IP 192.168.2.2.33366 > 192.168.2.13.8080: Flags [.], ack 740, win 1918, length 0 18:06:53.722261 IP 192.168.2.3.43278 > 192.168.2.13.8080: Flags [S], seq 783712136, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 4], length 0 18:06:53.722342 IP 192.168.2.13.8080 > 192.168.2.3.43278: Flags [S.], seq 4229788064, ack 783712137, win 64240, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 18:06:53.723115 IP 192.168.2.3.43278 > 192.168.2.13.8080: Flags [.], ack 1, win 1825, length 0 18:06:53.723890 IP 192.168.2.3.43278 > 192.168.2.13.8080: Flags [P.], seq 1:8071, ack 1, win 1825, length 8070: HTTP: POST /inform HTTP/1.1 18:06:53.723948 IP 192.168.2.13.8080 > 192.168.2.3.43278: Flags [.], ack 8071, win 473, length 0 18:06:53.735694 IP 192.168.2.13.8080 > 192.168.2.3.43278: Flags [P.], seq 1:571, ack 8071, win 501, length 570: HTTP: HTTP/1.1 200 18:06:53.736341 IP 192.168.2.3.43278 > 192.168.2.13.8080: Flags [.], ack 571, win 1897, length 0 18:06:53.736530 IP 192.168.2.3.43278 > 192.168.2.13.8080: Flags [F.], seq 8071, ack 571, win 1897, length 0 18:06:53.739507 IP 192.168.2.13.8080 > 192.168.2.3.43278: Flags [F.], seq 571, ack 8072, win 501, length 0 18:06:53.739953 IP 192.168.2.3.43278 > 192.168.2.13.8080: Flags [.], ack 572, win 1897, length 0 18:06:54.183099 IP 192.168.2.2.33368 > 192.168.2.13.8080: Flags [S], seq 572379967, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 4], length 0 18:06:54.183179 IP 192.168.2.13.8080 > 192.168.2.2.33368: Flags [S.], seq 2259487007, ack 572379968, win 64240, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 18:06:54.183523 IP 192.168.2.2.33368 > 192.168.2.13.8080: Flags [.], ack 1, win 1825, length 0 18:06:54.186178 IP 192.168.2.2.33368 > 192.168.2.13.8080: Flags [P.], seq 1:1048, ack 1, win 1825, length 1047: HTTP: POST /inform HTTP/1.1 18:06:54.186237 IP 192.168.2.13.8080 > 192.168.2.2.33368: Flags [.], ack 1048, win 501, length 0 18:06:54.189203 IP 192.168.2.13.8080 > 192.168.2.2.33368: Flags [P.], seq 1:221, ack 1048, win 501, length 220: HTTP: HTTP/1.1 200 18:06:54.201339 IP 192.168.2.2.33368 > 192.168.2.13.8080: Flags [.], ack 221, win 1892, length 0 18:06:54.201339 IP 192.168.2.2.33368 > 192.168.2.13.8080: Flags [F.], seq 1048, ack 221, win 1892, length 0 18:06:54.201816 IP 192.168.2.13.8080 > 192.168.2.2.33368: Flags [F.], seq 221, ack 1049, win 501, length 0 18:06:54.202194 IP 192.168.2.2.33368 > 192.168.2.13.8080: Flags [.], ack 222, win 1892, length 0 18:06:55.250457 IP 192.168.2.6.61641 > 192.168.2.13.8080: Flags [S], seq 2944371139, win 2144, options [mss 536], length 0 18:06:55.250533 IP 192.168.2.13.8080 > 192.168.2.6.61641: Flags [S.], seq 3678065154, ack 2944371140, win 64240, options [mss 1460], length 0 18:06:55.251135 IP 192.168.2.6.61641 > 192.168.2.13.8080: Flags [.], ack 1, win 2144, length 0 18:06:55.251869 IP 192.168.2.6.61641 > 192.168.2.13.8080: Flags [.], seq 1:537, ack 1, win 2144, length 536: HTTP: POST /inform HTTP/1.1 18:06:55.251919 IP 192.168.2.13.8080 > 192.168.2.6.61641: Flags [.], ack 537, win 63784, length 0 18:06:55.251968 IP 192.168.2.6.61641 > 192.168.2.13.8080: Flags [P.], seq 537:1073, ack 1, win 2144, length 536: HTTP 18:06:55.251978 IP 192.168.2.13.8080 > 192.168.2.6.61641: Flags [.], ack 1073, win 63784, length 0 18:06:55.252691 IP 192.168.2.6.61641 > 192.168.2.13.8080: Flags [.], seq 1073:1609, ack 1, win 2144, length 536: HTTP 18:06:55.252732 IP 192.168.2.13.8080 > 192.168.2.6.61641: Flags [.], ack 1609, win 63784, length 0 18:06:55.252769 IP 192.168.2.6.61641 > 192.168.2.13.8080: Flags [P.], seq 1609:2145, ack 1, win 2144, length 536: HTTP 18:06:55.252778 IP 192.168.2.13.8080 > 192.168.2.6.61641: Flags [.], ack 2145, win 63784, length 0 18:06:55.253495 IP 192.168.2.6.61641 > 192.168.2.13.8080: Flags [.], seq 2145:2681, ack 1, win 2144, length 536: HTTP 18:06:55.253531 IP 192.168.2.13.8080 > 192.168.2.6.61641: Flags [.], ack 2681, win 63784, length 0 18:06:55.253575 IP 192.168.2.6.61641 > 192.168.2.13.8080: Flags [P.], seq 2681:3217, ack 1, win 2144, length 536: HTTP 18:06:55.253585 IP 192.168.2.13.8080 > 192.168.2.6.61641: Flags [.], ack 3217, win 63784, length 0 18:06:55.254271 IP 192.168.2.6.61641 > 192.168.2.13.8080: Flags [.], seq 3217:3753, ack 1, win 2144, length 536: HTTP 18:06:55.254292 IP 192.168.2.13.8080 > 192.168.2.6.61641: Flags [.], ack 3753, win 63784, length 0 18:06:55.254334 IP 192.168.2.6.61641 > 192.168.2.13.8080: Flags [P.], seq 3753:4289, ack 1, win 2144, length 536: HTTP 18:06:55.254345 IP 192.168.2.13.8080 > 192.168.2.6.61641: Flags [.], ack 4289, win 63784, length 0 18:06:55.255010 IP 192.168.2.6.61641 > 192.168.2.13.8080: Flags [.], seq 4289:4825, ack 1, win 2144, length 536: HTTP 18:06:55.255087 IP 192.168.2.13.8080 > 192.168.2.6.61641: Flags [.], ack 4825, win 63784, length 0 18:06:55.255465 IP 192.168.2.6.61641 > 192.168.2.13.8080: Flags [P.], seq 4825:4887, ack 1, win 2144, length 62: HTTP 18:06:55.255489 IP 192.168.2.13.8080 > 192.168.2.6.61641: Flags [.], ack 4887, win 63784, length 0 18:06:55.257519 IP 192.168.2.13.8080 > 192.168.2.6.61641: Flags [P.], seq 1:275, ack 4887, win 63784, length 274: HTTP: HTTP/1.1 200 18:06:55.258734 IP 192.168.2.6.61641 > 192.168.2.13.8080: Flags [F.], seq 4887, ack 275, win 1870, length 0 18:06:55.260294 IP 192.168.2.13.8080 > 192.168.2.6.61641: Flags [F.], seq 275, ack 4888, win 63784, length 0 18:06:55.260772 IP 192.168.2.6.61641 > 192.168.2.13.8080: Flags [.], ack 276, win 1869, length 0 No need for wireshark - you can do the packet capture right on pfsense, or right on the AP even - here is running tcpdump right on the AP and you can see the traffic to the controller from this AP Hallway-BZ.6.7.10# tcpdump tcp port 8080 -n tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 18:13:02.035317 IP 192.168.2.2.33482 > 192.168.2.13.8080: Flags [S], seq 1380051285, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 4], length 0 18:13:02.035816 IP 192.168.2.13.8080 > 192.168.2.2.33482: Flags [S.], seq 3050138923, ack 1380051286, win 64240, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 18:13:02.035995 IP 192.168.2.2.33482 > 192.168.2.13.8080: Flags [.], ack 1, win 1825, length 0 18:13:02.037520 IP 192.168.2.2.33482 > 192.168.2.13.8080: Flags [.], seq 1:1461, ack 1, win 1825, length 1460: HTTP: POST /inform HTTP/1.1 18:13:02.037621 IP 192.168.2.2.33482 > 192.168.2.13.8080: Flags [.], seq 1461:2921, ack 1, win 1825, length 1460: HTTP 18:13:02.037697 IP 192.168.2.2.33482 > 192.168.2.13.8080: Flags [.], seq 2921:4381, ack 1, win 1825, length 1460: HTTP 18:13:02.037771 IP 192.168.2.2.33482 > 192.168.2.13.8080: Flags [.], seq 4381:5841, ack 1, win 1825, length 1460: HTTP 18:13:02.037815 IP 192.168.2.13.8080 > 192.168.2.2.33482: Flags [.], ack 1461, win 501, length 0 18:13:02.037879 IP 192.168.2.13.8080 > 192.168.2.2.33482: Flags [.], ack 4381, win 491, length 0 18:13:02.038025 IP 192.168.2.2.33482 > 192.168.2.13.8080: Flags [.], seq 5841:7301, ack 1, win 1825, length 1460: HTTP 18:13:02.038565 IP 192.168.2.13.8080 > 192.168.2.2.33482: Flags [.], ack 9960, win 497, length 0 18:13:02.043170 IP 192.168.2.13.8080 > 192.168.2.2.33482: Flags [P.], seq 1:739, ack 9960, win 501, length 738: HTTP: HTTP/1.1 200

@elvisimprsntr I haven't experienced any issues. I'm aware about travel routers etc. My particular case hotspot from phone, directly to pfsense. that's for emergency only which is rare but happens few times per year. for that I can't afford to purchase travel router for hundreds of dollars and dedicated sim with internet package. that makes no sense. and about standards and speeds, again for emergency 30-50mbps is more than enough for browsing communications... that's exactly my case and solution is 20 bucks, ya? I wrote that post to clarify for others as it took me quite some time to figure out particular models which works out of a box

Got it, thanks for the confirmation! The restriction of =< 802.11n and no AP mode works OK for my situation: we have one 3d printer which, for some reason, doesn't work well with the office wifi, and it's located right next to our pfSense gateway. It also doesn't have an Ethernet port (incredibly unfortunate). (So if it doesn't support station, but does support adhoc mode, I'm good here.) This hardly something that I'd want to call "production ready" and more "a useful hack" until we get a better 3D printer with real functionality. I'll do a cross-compile and report back with the results.

@elspoon said in ASUS GT-AX11000 Access Point?: FWIW not sure if relevant but my ASUS is running the Merlin-WRT setup. That seems very relevant! Far more likely to have a true access point mode with a 3rd party firmware. There should be some docs for it on their site I would think. It looks like it does put the single interface as a dhcp client in AP mode from some breif reading so you should be able to just check the pfSense DHCP lease tables to find it's IP address. Once you do find it I would add it as a static mapping in pfSense so it always gets the same IP address. Steve

@elspoon Yes! I now have my RT-AC86U running in AP mode, and just have an Ethernet cable running right into its WAN port. In pfsense DHCP settings (https://192.168.50.1/status_dhcp_leases.php) it shows up as 192.168.50.4 (I have it statically mapped) and so going to http://192.168.50.4 gets me to the web interface for the Asus. Hope this answers your questions!

You need two things to access the router in 192.168.4.X from 192.168.2.X: A firewall rule that passes the traffic on LAN in pfSense. That includes not policy routing it out over the VPN for example. The router must be able to reply. It can probably only reply to requests in the 192.168.4.X subnet because for anything else it will try to use it's WAN which probably isn't connected. So either set the default route there to the wifiguest interface IP in router. That may not be possible though. Or add an outbound NAT rule in pfSense on the wifiguest interface to catch the traffic from LAN to the router and translate it to the interface address.

I have just deployed some Grandstream access points. Price was right, they work well, and can be managed several different ways, including their gdms system for free.

What hardware are you using? How is it connected? Steve

@stephenw10 said in Awful Wi-Fi Speeds: Backhauling everything over Ethernet is almost always better than mesh if you can do it. Backhauling everything over Ethernet is almost always better than mesh if you can do it. Fixed that statement for you ;)

@stephenw10 That makes perfect sense, thank you. I realize the tool-tip says exactly that and I should have read more closely.

Yes, put them on OPT1. Enable it with a different subnet. Enable DHCP on OPT1. Add appropriate firewall rules to allow or prevent connections as you want.

Thank you, everyone. The tips on the controller were helpful and got me going in the right direction. @tgl I will look into MoCA because there is indeed a coax running between the rooms that I need coverage the most. Thanks again!

Thank you two. I wasn't able to dig into the iso to try and add the kernel module since neither my Linux or Windows computer wanted to mount it but I had a spare AP I could steal until I can get wiring installed that seems happy to mesh up and act as my WAN port (Unifi U6). They wouldn't do it when I tried to do the same thing a year ago with another computer, but they've either had a firmware update in the meantime or pfsense is smarter than a more normal OS and could work it out. This should be much better than a little m.2 wifi card anyway.

Create a virtual IP and point it to the interface the router resides on.

@BlazeStar hey there, as @johnpoz already mentioned: set up VLANs on switch and pfsense, make sure it is working create new networks with PVID (as set in 1.) on your cloudkey controller software (under networks) create (under wireless networks) your new wlan networks with ssid mapped to network > VLAN1, 2, 3 etc Done. :)

I would certainly do that because it makes accessing the AP much easier. However that shouldn't be require. The AP doesn't need to have an IP address at all. It should still more traffic at layer 2 between WiFi and Ethernet.

@CharlesT If this is a question / you have a doubt : Are all Access Points with WPA3 equally secure ? Connect to the wifi first. Then fire up your favorite VPN, thus rendering the question to oblivion. You'll be using an encryption into an encryption. Even better, when you are visiting https site (any TLS destination) , you'll just added another encryption layer !

@Patch Thank you for the clarification.

@Tantamount said in IWLWIFI(4) Driver Question: That wouldn't preclude it from working as a way to tether to a hotspot though, right? I mean in that case it should act as a client connecting to the hotspot device? Correct it can run in station mode (as a client) at lower speeds. However as I said above it was removed so you'd need to add it back to use it.

@Dobby_ said in Wifi Client m.2: SparkLan WPEA-127N That's a miniPCIe card not m.2 if you need m.2. I would look for a ath compatible card though. There are some m.2 cards that will work. They are mostly short, 30mm, cards so you might need an adapter.