New router - devices on wired lan cannot ssh to devices connected to the new wifi

Hi,
recently changed my router to N100 minipc and after some effort I managed to set up my 5GHz network with Netgear A6210 usb wifi dongle (iirc it uses MT7612u chipset) and 2.4GHz with the internal Intel wifi.

My simplified network setup is like follows:

wired
modem -> router -> managed switch -> pcs

wireless
Deco M4 AP 5GHz/2.4GHz plugged into the managed switch
router 5GHz AP via Netgear dongle, 2.4GHz ap via built in Intel wifi

To my surprise after the migration absolutely everything works, no slowdowns, no dropouts no nothing apart from one thing:

If I connect my laptop via the AP running on the router, then try to ssh into it from a wired pc it fails (laptop has lan/internet access through the AP). If I connect laptop via the Deco M4 AP I can ssh in to laptop just fine.

Googling this issue is almost impossible as everyone tries for w/e reason to ssh into the router over wifi which in my head should not work anyway, but I digress. I found these 2 similar threads which are years old and claim the issue been fixed:

It's more of a curiosity for me, the router APs are "emergency" if for w/e reason the Deco AP fails as I exclusively use the Deco AP, but it might come to the point I'll need to use the router AP and ssh into wireless device and I would like to know why I can't.

Any ideas? Is it wireless config? Firewall config? There's just such an overwhelming amount of undescribed/incomprehensibly described knobs and checkboxes in the luci ui I've no idea what I would be looking for.

Thanks for any suggestions, let me know if any logs are needed or something.

Let's take a look at your config.... we probably only need to look at the main router since it seems like connections elsewhere on the network are functioning as expected (if I've misinterpreted, please correct me).

Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:
grafik
Remember to redact passwords, MAC addresses and any public IP addresses you may have:

ubus call system board
cat /etc/config/network
cat /etc/config/wireless
cat /etc/config/dhcp
cat /etc/config/firewall
1 Like

Here's the requested info:

root@openwrt:~# ubus call system board
{
        "kernel": "6.6.86",
        "hostname": "openwrt",
        "system": "Intel(R) N100",
        "rootfs_type": "ext4",
        "release": {
                "distribution": "OpenWrt",
                "version": "24.10.1",
                "revision": "r28597-0425664679",
                "target": "x86/64",
                "description": "OpenWrt 24.10.1 r28597-0425664679",
                "builddate": "1744562312"
        }
}
root@openwrt:~# cat /etc/config/network

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fda5:96fb:862f::/48'
        option packet_steering '1'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth0'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option ipaddr '192.168.1.1'
        option netmask '255.255.255.0'
        option ip6assign '60'

config interface 'wan'
        option device 'eth1'
        option proto 'pppoe'
        option username '[REDACTED]'
        option password '[REDACTED]'
        option ipv6 'auto'
        option peerdns '0'

config interface 'wan6'
        option device 'eth1'
        option proto 'dhcpv6'
        option reqaddress 'try'
        option reqprefix 'auto'
        option norelease '1'

config interface 'docker'
        option device 'docker0'
        option proto 'none'
        option auto '0'

config device
        option type 'bridge'
        option name 'docker0'
        option ipv6 '0'
root@openwrt:~# cat /etc/config/wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option path 'pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0'
        option band '5g'
        option channel '40'
        option htmode 'VHT80'
        option country 'GB'
        option cell_density '0'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid 'site19.scp'
        option encryption 'sae-mixed'
        option key '[REDACTED]'
        option ocv '0'
        option wps_pushbutton '1'

config wifi-device 'radio1'
        option type 'mac80211'
        option path 'pci0000:00/0000:00:1d.0/0000:02:00.0'
        option band '2g'
        option channel '1'
        option country 'GB'
        option cell_density '0'
        option htmode 'HT40'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option network 'lan'
        option mode 'ap'
        option ssid 'Erratas'
        option encryption 'psk-mixed'
        option key '[REDACTED]'
        option wps_pushbutton '1'
root@openwrt:~# cat /etc/config/dhcp

config dnsmasq
        option domainneeded '1'
        option localise_queries '1'
        option local '/lan/'
        option domain 'lan'
        option expandhosts '1'
        option readethers '1'
        option localservice '1'
        option nonegcache '1'
        option leasefile '/tmp/dhcp.leases'
        option authoritative '1'
        option confdir '/tmp/dnsmasq.d'
        option rebind_protection '0'
        option ednspacket_max '1232'
        option localuse '0'
        option port '54'
        list server '192.168.1.1'

config dhcp 'lan'
        option interface 'lan'
        option start '102'
        option limit '148'
        option leasetime '10m'
        option force '1'
        option dhcpv6 'server'
        option ra_management '1'
        list dhcp_option '6,192.168.1.1'
        list dhcp_option '3,192.168.1.1'
        list dns 'fda5:96fb:862f::1'
        list ntp 'fda5:96fb:862f::1'
        list ntp '192.168.1.1'

config dhcp 'wan'
        option interface 'wan'
        option ignore '1'

config odhcpd 'odhcpd'
        option maindhcp '0'
        option leasetrigger '/usr/sbin/odhcpd-update'
        option loglevel '4'
        option leasefile '/tmp/odhcpd'

DNS listens on 54 as I use adguardhome which listens on 53 and redirects to 54. I have omitted the static dhcp leases of my network devices as the list is rather long and I didn't want to go through censoring all the ip and macs I hope that is fine

root@openwrt:~# cat /etc/config/firewall

config defaults
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option synflood_protect '1'
        option drop_invalid '1'

config zone
        option name 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        list network 'lan'

config zone
        option name 'wan'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'
        list network 'wan'
        list network 'wan6'

config forwarding
        option src 'lan'
        option dest 'wan'

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'

config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option icmp_type 'echo-request'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-IGMP'
        option src 'wan'
        option proto 'igmp'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-DHCPv6'
        option src 'wan'
        option proto 'udp'
        option src_ip 'fc00::/6'
        option dest_ip 'fc00::/6'
        option dest_port '546'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-MLD'
        option src 'wan'
        option proto 'icmp'
        option src_ip 'fe80::/10'
        list icmp_type '130/0'
        list icmp_type '131/0'
        list icmp_type '132/0'
        list icmp_type '143/0'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Input'
        option src 'wan'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        list icmp_type 'router-solicitation'
        list icmp_type 'neighbour-solicitation'
        list icmp_type 'router-advertisement'
        list icmp_type 'neighbour-advertisement'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Forward'
        option src 'wan'
        option dest '*'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-IPSec-ESP'
        option src 'wan'
        option dest 'lan'
        option proto 'esp'
        option target 'ACCEPT'

config rule
        option name 'Allow-ISAKMP'
        option src 'wan'
        option dest 'lan'
        option dest_port '500'
        option proto 'udp'
        option target 'ACCEPT'

config include
        option path '/etc/firewall.user'

config include 'miniupnpd'
        option type 'script'
        option path '/usr/share/miniupnpd/firewall.include'

config include 'bcp38'
        option type 'script'
        option path '/usr/lib/bcp38/run.sh'

config zone 'docker'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        option name 'docker'
        list network 'docker'
        option family 'ipv4'

I have omitted my portforwards from the above output for the same reasons

edit:
when laptop is on new AP, it can ssh to other machines on lan, but not other way around.

windows machine trying to ssh into the laptop on the new ap says

A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. (os error 10060)

on linux it says:

No route to host (os error 113)

but the laptop can ssh into those machines I don't get it.

I don't see anything that would cause the problem you're describing, but it would be good to know what IP address your windows and linux machines are getting when connecting to the wifi that's problematic.

Aside from that, a few comments:

  • Why do you have a 10 minute lease time on your DHCP server? That's unnecessarily short.
  • Don't use sae-mixed or psk-mixed -- both of these can cause problems. Instead, use WPA2 or WPA3.

That 10m lease is from some testing back in the day I did and never reverted back I think, I'll put it back to default.

I will change the WPA modes and re-test.

As to the IPs, it's only laptop that connects to wifi, all other machines are connected via ethernet cable into the managed switch.

situation a)
PCs on lan, laptop connected to router AP
laptop can ssh into PCs, PCs cannot ssh into laptop

situation b)
PCs on lan, laptop connected to AP that is plugged to the managed switch
laptop can ssh into PCs, PCs can ssh into laptop

both the pcs have static lease:

linux pc

config host
        option name 'viglen-garuda'
        option ip '192.168.1.129'
        list mac '00:E0:4C:6B:04:B3'

windows pc

config host
        option name 'turbojeba'
        option ip '192.168.1.163'
        option mac '04:7C:16:6D:68:D3'

laptop when connected via new AP

config host
        option ip '192.168.1.141'
        option mac '2C:8D:B1:AA:B0:59'

laptop when connected via deco AP

config host
        option ip '192.168.1.141'
        option mac '2C:8D:B1:AA:B0:59'

edit:
I changed the AP to WPA2-PSK, forgot the wifi on laptop, reconnected to it, situation remains the same

Is the laptop running windows? Try disabling the windows firewall.

My theory is predicated on the assumption that the SSIDs are different between situations an and b. In that scenario, the Windows firewall believes that the wifi from the router is part of an untrusted network whereas the other AP/SSID is trusted.

I should have mentioned, the laptop uses Linux

Linux g15-garuda 6.14.3-zen1-1-zen #1 ZEN SMP PREEMPT_DYNAMIC Sun, 20 Apr 2025 12:38:36 +0000 x86_64 GNU/Linux

the linux pc uses the same os/kernel

the windows pc uses

Edition Windows 11 Pro
Version 24H2
Installed on ā€Ž09/ā€Ž04/ā€Ž2025
OS build 26100.3775
Experience Windows Feature Experience Pack 1000.26100.66.0

What happens if you set the SSID, encryption, and passphrase to be the same as the other AP, and then shut down the other AP so that you can guarantee the laptop is connecting to the router's AP?

1 Like

I cannot afford to shut down the other AP just now, the rest of the household is just about waking up and getting ready for work and they'd be rather cross with wifi interruptions :smile:

I am sure the laptop connects via the new ap as it shows in luci:

Ok... do they have the same SSID, encryption, and passphrase?

Not atm, would that couse issues if I have 2 SSIDs with the same name? If not I'll do that and make sure laptop is connected to the AP on router.

Just to make sure (english is not my 1st lang) you want me to change the SSID of the new AP to the same name/password as the other AP and then connect the laptop to it, while the other ap is still running yes?

If that won't cause wifi interruption to others connected to the "old" ap I can do it otherwise in about an hour I can fully shutdown the old AP and try it that way.

Thank you for your patience and time spent on my issue btw!

No. In fact, that is the preferred method of setting up wifi when you have 2 or more APs. this enables devices to roam seamlessly.

Yes. Ideally, the other AP could be turned off so that you can absolutely guarantee the laptop connects to the desired AP, but hopefully you'll manage to connect with the benefit of physical proximity.

It shouldn't cause any disruption.

Also, it's worth noting that hanging a USB wifi adapter off an x86 machine is generally not recommended as an AP. You'll always be better off with a proper purpose built AP (or all-in-one wifi router).

I was not aware of this and having knowing this in the past would have saved me so much headache, thank you!

I understand that, hence the deco AP as main, but I want to have AP on the router as well for emergencies. I understand about the USB being not ideal I continually run into issues with passing usb bus through to vm or lxc in my homelab.

Out of curiosity, would the 2.4GHz router AP that comes off pci lane not usb bus be considered "stable" ?

I'm not completely sure how to check the encryption used on the deco, but my android phone says
deco ap: wpa/wpa2/wpa3-personal
new ap: wpa/wpa2-personal

I renamed the AP on router and gave it the same password, but I'll have to wait until the house is empty (should be by 8am), the deco has apparently much stronger signal, the devices pop up in luci for a second then swap to the deco AP.

This is a VM?? Simply put, that's probably your problem. Working with wireless USB adapters in a virtualized environment is particularly tricky and is outside the scope of this forum. You need to ask the question in support channels for the virtualizer/supervisor/hypervisor that you'r using as it is highly dependent on both the host OS and the virtual environment.

And with that in mind...

With a VM or any x86 system, you can simply use a keyboard and display on the machine itself to deal with issues. Or dedicate an ethernet port to the VM for a direct connection. Wifi is not a good choice as an emergency interface.

I would recommend running your router bare-metal... and in that case, your wifi may work properly on that device without too much difficulty (once you've installed the relevant drivers).

Generally speaking, wifi coming from an x86 system using USB or PCI has a number of limitations -- mainly in range/signal quality/bandwidth and multi-user AP performance... fundamentally, you have a suboptimal physical environment and antenna system, especially when compared against a properly designed AP or all-in-one wifi router.

No no the router is absolutely baremetal physical machine (I have tried virtualized router once in the past and it was no bueno). I just mentioned vms and homelab in relation to having encountered unrelated issues stemming from using usb adapters there

Honestly I wouldn't even notice the issue, If I didn't forget the laptop connected to the "emergency" router AP instead of the deco after I was testing if the router usb wifi adapter ap works. As an Arch user I'm compelled to obsessively update, which is when I tried to ssh into the laptop and discovered this single kink in the new setup.

As I said, it's more of a curiosity as even if I was in a situation that the deco AP would die and I would need to ssh into the laptop I could still just plug it into the switch with ethernet cable. It just bugs me is all.

Will update once I can turn off the deco AP.

Turned off the Deco AP, signed to the renamed AP on router with laptop and everything works I can ssh into it.

What a strange issue, why would SSID name cause a single device to "drop?" incoming ssh packets or w/e was happening?

I am keeping the old router for now, but if the N100 runs and doesn't exhibit any issue for a month or two I'll probably sell it.

I any case it's solved, many thanks for your help and useful insights about my setup!

I suspect there is a host level firewall causing the issue.

Glad that it is working now.

1 Like

That's a good point I'll investigate that later, I only checked to see if the incoming port is allowed which it is.

I would like to thank you again for the advice about naming SSIDs the same. I renamed all the SSIDs on the router to the same name and password and tried turning the deco AP off - every device be it 2.4GHz or 5GHz seamlessly switched over to the router APs. A true emergency setup!

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.