Nighthawk X6 WAP issues



  • Hello all, I'm new to pfsense and recently built a pfsense router with some new and old hardware I had and a few I ordered. I have it up and running great but my wireless is not the best. I'm having issues with websites taking several minutes to load and sometimes not loading at all, weird latency issues and most times when I try to do a speed test on wireless it will not work and has network communication issues. I am wanting my wifi to feel more like it did when I was just running my X6 as a standalone router, what should I do to get it to feel like that again. Also I just have the standard firewall settings on my instalation right now except with a rule for my Lans to talk to each other. Below is my hardware setup

    Mobo: Asus motherboard
    CPU: Intel Xeon X5650
    Ram: 16gb ddr3
    Hdd: 1tb WD green
    Nic: Intel 4port gigabit switch
    PSU: 500w EVGA
    Switch: 8 port Netgear gigabit web managed switch
    WAP: Nighthawk X6 in WAP mode

    I know some of my hardware is a little OP but I had it laying around. And in a side note my wired is fine except I am getting strict NAT type in some games that could be causing some issues in the future.



  • Bump


  • Netgate Administrator

    I would run a packet capture to see what's actually happening there.

    Several minutes to load a site is catastrophically bad unless your WAN is very slow. There must be something significantly wrong like an interface speed/duplex mismatch or an actual bad NIC.

    What results do you see attached to one of the Ethernet ports on the X6?

    Steve



  • I'll run a packet capture thismorning when I get home on some of the websites that have bad issues and report back with my results

    The WAN is gigabit symetrical, I am getting 960 up and down consistantly on wired and when I can get the speed test to work and not have some weird network issue on wireless I get around 300 to 450 down

    I have not tried the ethernet ports on the X6 as it is now being used as a AP only so I have been using my switch but I will test it and see tomorrow if I can get anything on it.

    Another thing I was thinking is to try putting the X6 on a static as it is on DHCP address mode currently but IDK if that will do much of anything to help

    Thank you!


  • Netgate Administrator

    The actual IP setup of the X6 shouldn't make any difference. In AP mode it should be operating entirely at later 2 just passing wireless traffic to pfSense.
    Does it connect via it's WAN port in AP mode or one of the LAN ports? They may all be connected as one switch in that mode anyway.
    Testing from the X6 ports should prove the connection to the pfSense box anyway. If it's good there it can only be a wifi issue or something the X6 is doing between wireless and wired.

    Steve



  • Alright I ran a packet capture for about a minute while trying to load a few websites. The one that would not load was dell.com

    16:48:51.636951 IP XXX > 173.240.128.1: ICMP echo request, id 26336, seq 41822, length 8
    16:48:51.638395 IP 173.240.128.1 > XXX: ICMP echo reply, id 26336, seq 41822, length 8
    16:48:51.844434 IP XXX.48663 > 64.233.185.138.443: tcp 92
    16:48:51.844677 IP XXX.48663 > 64.233.185.138.443: tcp 46
    16:48:51.845050 IP XXX.48663 > 64.233.185.138.443: tcp 198
    16:48:51.857510 IP 64.233.185.138.443 > XXX.48663: tcp 0
    16:48:51.857759 IP 64.233.185.138.443 > XXX.48663: tcp 0
    16:48:51.857884 IP 64.233.185.138.443 > XXX.48663: tcp 46
    16:48:51.870627 IP 64.233.185.138.443 > XXX.48663: tcp 77
    16:48:51.870635 IP 64.233.185.138.443 > XXX.48663: tcp 93
    16:48:51.870751 IP 64.233.185.138.443 > XXX.48663: tcp 147
    16:48:51.870759 IP 64.233.185.138.443 > XXX.48663: tcp 46
    16:48:51.877656 IP XXX.48663 > 64.233.185.138.443: tcp 0
    16:48:51.878405 IP XXX.48663 > 64.233.185.138.443: tcp 46
    16:48:51.931591 IP 64.233.185.138.443 > XXX.48663: tcp 0
    16:48:52.088496 IP 104.16.59.37.443 > XXX: tcp 82
    16:48:52.129756 IP XXX.22783 > 104.16.59.37.443: tcp 0
    16:48:52.169197 IP XXX > 173.240.128.1: ICMP echo request, id 26336, seq 41823, length 8
    16:48:52.170568 IP 173.240.128.1 > XXX: ICMP echo reply, id 26336, seq 41823, length 8
    16:48:52.559208 IP 172.104.216.121.443 > XXX.17909: tcp 34
    16:48:52.599715 IP XXX.17909 > 172.104.216.121.443: tcp 0
    16:48:52.701452 IP XXX > 173.240.128.1: ICMP echo request, id 26336, seq 41824, length 8
    16:48:52.702867 IP 173.240.128.1 > XXX: ICMP echo reply, id 26336, seq 41824, length 8
    16:48:53.233701 IP XXX > 173.240.128.1: ICMP echo request, id 26336, seq 41825, length 8
    16:48:53.235041 IP 173.240.128.1 > XXX: ICMP echo reply, id 26336, seq 41825, length 8
    16:48:53.722498 IP 104.16.59.37.443 > XXX.22783: tcp 82
    16:48:53.763754 IP XXX.22783 > 104.16.59.37.443: tcp 0
    16:48:53.765954 IP XXX > 173.240.128.1: ICMP echo request, id 26336, seq 41826, length 8
    16:48:53.767340 IP 173.240.128.1 > XXX: ICMP echo reply, id 26336, seq 41826, length 8
    16:48:54.298209 IP XXX > 173.240.128.1: ICMP echo request, id 26336, seq 41827, length 8
    16:48:54.299639 IP 173.240.128.1 > XXX: ICMP echo reply, id 26336, seq 41827, length 8
    16:48:54.830345 IP XXX > 173.240.128.1: ICMP echo request, id 26336, seq 41828, length 8
    16:48:54.831689 IP 173.240.128.1 > XXX: ICMP echo reply, id 26336, seq 41828, length 8
    16:48:55.029570 IP 104.16.59.37.443 > XXX.22783: tcp 192
    16:48:55.069713 IP XXX.22783 > 104.16.59.37.443: tcp 0
    16:48:55.292693 IP XXX.37290 > 64.233.185.102.443: tcp 0
    16:48:55.305898 IP 64.233.185.102.443 > XXX.37290: tcp 0
    16:48:55.362590 IP XXX > 173.240.128.1: ICMP echo request, id 26336, seq 41829, length 8
    16:48:55.364112 IP 173.240.128.1 > XXX: ICMP echo reply, id 26336, seq 41829, length 8
    16:48:55.894841 IP XXX > 173.240.128.1: ICMP echo request, id 26336, seq 41830, length 8
    16:48:55.896536 IP 173.240.128.1 > XXX: ICMP echo reply, id 26336, seq 41830, length 8
    16:48:56.082762 IP XXX.40657 > 216.239.36.10.53: UDP, length 41
    16:48:56.096914 IP 216.239.36.10.53 > XXX.40657: UDP, length 80
    16:48:56.096999 IP XXX.23910 > 216.239.36.10.53: UDP, length 53
    16:48:56.110821 IP XXX.39625 > 169.44.166.66.5938: tcp 24
    16:48:56.110906 IP 216.239.36.10.53 > XXX.23910: UDP, length 298
    16:48:56.143058 IP XXX.19212 > 172.217.11.142.443: UDP, length 1350
    16:48:56.145803 IP XXX.29181 > 172.217.11.142.443: tcp 0
    16:48:56.157752 IP 172.217.11.142.443 > XXX.19212: UDP, length 1350
    16:48:56.157763 IP 172.217.11.142.443 > XXX.19212: UDP, length 31
    16:48:56.158876 IP 172.217.11.142.443 > XXX.29181: tcp 0
    16:48:56.164281 IP XXX.29181 > 172.217.11.142.443: tcp 0
    16:48:56.166030 IP XXX.19212 > 172.217.11.142.443: UDP, length 39
    16:48:56.166278 IP 173.XXX.19212 > 172.217.11.142.443: UDP, length 30
    16:48:56.167528 IP XXX.19212 > 172.217.11.142.443: UDP, length 1337
    16:48:56.168528 IP XXX.29181 > 172.217.11.142.443: tcp 517
    16:48:56.179612 IP 169.44.166.66.5938 > 173.XXX.39625: tcp 24
    16:48:56.180487 IP 172.217.11.142.443 > XXX.19212: UDP, length 22
    16:48:56.181737 IP 172.217.11.142.443 > XXX.29181: tcp 0
    16:48:56.181861 IP 172.217.11.142.443 > XXX.29181: tcp 156
    16:48:56.186642 IP XXX.29181 > 172.217.11.142.443: tcp 0
    16:48:56.187515 IP XXX.29181 > 172.217.11.142.443: tcp 51
    16:48:56.197602 IP 172.217.11.142.443 > XXX.19212: UDP, length 262
    16:48:56.197608 IP 172.217.11.142.443 > XXX.19212: UDP, length 16
    16:48:56.200100 IP 172.217.11.142.443 > XXX.29181: tcp 69
    16:48:56.216623 IP XXX.19212 > 172.217.11.142.443: UDP, length 30
    16:48:56.220746 IP XXX.39625 > 169.44.166.66.5938: tcp 0
    16:48:56.235862 IP XXX.29181 > 172.217.11.142.443: tcp 0
    16:48:56.427098 IP XXX > 173.240.128.1: ICMP echo request, id 26336, seq 41831, length 8
    16:48:56.428585 IP 173.240.128.1 > XXX: ICMP echo reply, id 26336, seq 41831, length 8
    16:48:56.705589 IP XXX.61006 > 8.8.8.8.53: UDP, length 32
    16:48:56.706457 IP XXX.57796 > 8.8.4.4.53: UDP, length 32
    16:48:56.719782 IP 8.8.4.4.53 > XXX.57796: UDP, length 128
    16:48:56.720031 IP 8.8.8.8.53 > XXX.61006: UDP, length 128
    16:48:56.959353 IP XXX > 173.240.128.1: ICMP echo request, id 26336, seq 41832, length 8
    16:48:56.960759 IP 173.240.128.1 > XXX: ICMP echo reply, id 26336, seq 41832, length 8
    16:48:57.491605 IP XXX > 173.240.128.1: ICMP echo request, id 26336, seq 41833, length 8
    16:48:57.492933 IP 173.240.128.1 > XXX: ICMP echo reply, id 26336, seq 41833, length 8
    16:48:57.695063 IP 104.16.59.37.443 > XXX.22783: tcp 89
    16:48:57.734696 IP XXX.22783 > 104.16.59.37.443: tcp 0
    16:48:57.782041 IP XXX.37463 > 35.186.224.47.443: tcp 50
    16:48:57.795373 IP 35.186.224.47.443 > XXX.37463: tcp 0
    16:48:57.842471 IP 35.186.224.47.443 > XXX.37463: tcp 47
    16:48:57.882729 IP XXX.37463 > 35.186.224.47.443: tcp 0
    16:48:58.023860 IP XXX > 173.240.128.1: ICMP echo request, id 26336, seq 41834, length 8
    16:48:58.025232 IP 173.240.128.1 > XXX: ICMP echo reply, id 26336, seq 41834, length 8
    16:48:58.556111 IP XXX > 173.240.128.1: ICMP echo request, id 26336, seq 41835, length 8
    16:48:58.557531 IP 173.240.128.1 > XXX: ICMP echo reply, id 26336, seq 41835, length 8
    16:48:58.578394 IP 104.16.59.37.443 > XXX.22783: tcp 99
    16:48:58.618780 IP XXX.22783 > 104.16.59.37.443: tcp 0
    16:48:59.088366 IP XXX > 173.240.128.1: ICMP echo request, id 26336, seq 41836, length 8
    16:48:59.089705 IP 173.240.128.1 > XXX: ICMP echo reply, id 26336, seq 41836, length 8
    16:48:59.406638 IP 104.16.59.37.443 > XXX.22783: tcp 77
    16:48:59.446773 IP XXX.22783 > 104.16.59.37.443: tcp 0
    16:48:59.615588 IP XXX > 173.240.128.1: ICMP echo request, id 26336, seq 41837, length 8
    16:48:59.616883 IP 173.240.128.1 > XXX: ICMP echo reply, id 26336, seq 41837, length 8
    16:49:00.147837 IP XXX > 173.240.128.1: ICMP echo request, id 26336, seq 41838, length 8
    16:49:00.150306 IP 173.240.128.1 > XXX: ICMP echo reply, id 26336, seq 41838, length 8
    16:49:00.192818 IP XXX.12528 > 173.194.219.132.443: tcp 0
    16:49:00.205772 IP 173.194.219.132.443 > XXX..12528: tcp 0

    I went through and swapped my IP with ''XXX''. I have not been able to try my ethernet ports on my X6 but the LAN connection to it is connected to its WAN port.


  • Netgate Administrator

    Really you'd need to open that in Wireshark and look for TCP resets or retransmissions. Or just missing packets.

    Steve



  • @god_bmxes said in Nighthawk X6 WAP issues:

    I have not been able to try my ethernet ports on my X6 but the LAN connection to it is connected to its WAN port.

    Basic rule when using routers/gateways as AP, don't use the WAN port.


  • Netgate Administrator

    Ah, missed that.
    If AP mode is intended to use the WAN that way it should be OK. But I would definitely test connecting the link to pfSense to one of it's 'LAN' ports.

    Steve



  • @stephenw10 said in Nighthawk X6 WAP issues:

    If AP mode is intended to use the WAN that way it should be OK.

    The thing with these devices is that they do allow you to use the WAN port as a LAN port in AP mode. But they do it by using a software bridge between WAN and LAN, and this comes with the usual caveats and performance issues. So if you must you can use that WAN port for a single client, but never use it as your uplink.



  • I just swapped the x6 port I'm using from the Wan to lan4. So I'll see what it does when it comes back up


  • Netgate Administrator

    @grimson said in Nighthawk X6 WAP issues:

    The thing with these devices is that they do allow you to use the WAN port as a LAN port in AP mode. But they do it by using a software bridge between WAN and LAN, and this comes with the usual caveats and performance issues.

    That can certainly be the case and if it is the throughput would likely be limited.
    However the ports might be on the same switch IC separated by VLANs in which case AP mode could simply add that port to the existing VLAN. If it's been programmed to do so. 😉
    The wifi is usually bridged to the LAN anyway so it should be capable.

    Steve



  • Well, it didn't take long to find out but the Wan and lan ports are running about the same lol


  • Netgate Administrator

    Ok, that's still testing via the wifi though?

    We need to confirm it's good (or bad) with a wired client connected to the X6.

    Steve



  • This post is deleted!


  • @stephenw10 so run it as an AP and connect a wired device to connect through the X6?


  • Netgate Administrator

    Yes. If it's still bad there then there is some issue with the connection between the X6 and pfSense.

    If it's good there then the issue lies with how the wifi is connected to the Ethernet ports in the X6.

    Steve



  • Alright, I'll go and run something off of that it and see. Also downloaded Wireshark to see if there is dropped packets etc



  • @stephenw10 said in Nighthawk X6 WAP issues:

    However the ports might be on the same switch IC separated by VLANs in which case AP mode could simply add that port to the existing VLAN. If it's been programmed to do so. 😉

    For the last ~10 years I have been knee deep in the open source firmware parts of those Netgear, Linksys and Asus routers, and let me tell you it's ugly and one of the mayor reasons I switched to pfSense for my home too. Yes they could change the VLANs but they don't, or at least they did not until the end of 2017.



  • Alright, I have my desktop connected to the X6 on a lan port and I have the line in from the switch coming from the switch going to the lan port aswell on the x6. I do not get internet on the desktop now while it's hardwired to the x6 in AP mode. I did download the cable shark, but I have no ideas what I'm looking at in the logs. So I think the x6 may be the issue right now. Maybe I should look at a different ap


  • Netgate Administrator

    Hmm, looks like AP mode on that just bridges wifi to the WAN port. And in fact disables the switch entirely. Odd design choice...

    You could just set it back to router mode, disable DHCP and connect to the LAN ports as you have it. That should do the same thing. As described here for devices that don't have a specific AP mode:
    https://www.netgate.com/docs/pfsense/wireless/use-an-existing-wireless-router-with-pfsense.html

    Steve



  • @stephenw10 I don't need the ports, just need the wifi. I'll probably pick up a ubiquity AP and give that a shot. Also gonna look at the logs and see what is dropping etc. It's all on the same vlan and switch though so there is no reason for the wifi issues in theory


  • Netgate Administrator

    Yes, running in router mode is not to give you ports rather it's to enable you to test. Also since that's how it's configured normally we know it behaves as expected in router mode.

    Steve



  • @god_bmxes said in Nighthawk X6 WAP issues:

    I know some of my hardware is a little OP but I had it laying around. And in a side note my wired is fine except I am getting strict NAT type in some games that could be causing some issues in the future.

    Nobody helped you with this part yet, but when you figure out your access point thing, here are the steps to get the NAT type fixed for your game console.

    You need to set static DHCP leases for your PS4 or XBox. After this is set, in the NAT section, under Outbound, select Hybrid Outbound NAT and make 1 mapping rule.

    Interface: WAN
    Protocol: Any
    Source: Network, your static IP address for your console goes here, pick /32 from the drop down list
    Translation: Static Port checked
    Description: PS4 or XBox

    When I setup this outbound NAT mapping, my PS4 went from a level 3 to a level 2.

    Hope that helps!

    Jeff



  • Thank you, it's so far only on my PC but I'll do that as it already has a static set on it.



  • @god_bmxes said in Nighthawk X6 WAP issues:

    Thank you, it's so far only on my PC but I'll do that as it already has a static set on it.

    That should work for a PC too. There are no specific ports set up in that mapping, everything is passed outbound.

    Jeff