Clients can connect to both wifi networks without issues.
Network setup
- WNDR4500 (192.168.1.1)
- Laptop (192.168.1.100, connected to 5 GHz)
- Wireless AP+Switch (192.168.1.5, connected to 2.4 GHz)
- Multimedia PC (192.168.1.200, connected with cable to Wireless AP+Switch)
"Laptop" and "Multimedia PC" are DHCP-configured, i.e. they can see and talk to the router.
From WNDR4500
- ping works to all connected devices
From Laptop, when it's connected to the 5GHz wifi (wl1):
- ping 192.168.1.1 (works)
- ping 192.168.1.5 (works)
- ping 192.168.1.200 (Reply from 192.168.1.100: Destination host unreachable.)
From Laptop, when it's connected to the 2.4GHz wifi (wl0):
- ping 192.168.1.1 (works)
- ping 192.168.1.5 (works)
- ping 192.168.1.200 (works)
From Laptop, when it's connected to the 5GHz wifi (wl1) AFTER I set a manual route (route add 192.168.1.200 mask 255.255.255.255 192.168.1.1)
- ping 192.168.1.1 (works)
- ping 192.168.1.5 (works)
- ping 192.168.1.200 (works)
So this is not a firewall issue, packets do get through.
Tried with other clients to rule out the Laptop as the cause, same behavior everywhere.
I can only imagine that there is some fundamental setting between the 2.4 GHz interface and the 5 GHz interface that I forgot to enable.
Joined: 08 May 2018 Posts: 14223 Location: Texas, USA
Posted: Mon Nov 22, 2021 16:53 Post subject:
Is "filter anonymous WAN requests (ping)" enabled on the Security tab? Is AP or NET isolation enabled anywhere? It's been a while since I checked on my E4200s, but I do seem to recall that you could not ping from wireless to wireless and I can't remember if I ever got it working. _________________ "Life is but a fleeting moment, a vapor that vanishes quickly; All is vanity"
Contribute To DD-WRT Pogo - A minimal level of ability is expected and needed... DD-WRT Releases 2023 (PolitePol)
DD-WRT Releases 2023 (RSS Everything)
----------------------
Linux User #377467 counter.li.org / linuxcounter.net
Is "filter anonymous WAN requests (ping)" enabled on the Security tab? Is AP or NET isolation enabled anywhere?
No, AP Isolation is not enabled. Both networks are set to "bridged", that option does not even appear. (There is a guest wifi (wl0.1) with AP isolation enabled, but that should not affect the main interface IMHO.)
It's been working just fine for years on that device with an older build, so it's not a hardware issue, either.
Also, the ping runs through when I set a manual route on the laptop (!), in other words: it can't be a filter. "Block Anonymous WAN Requests (ping)" is enabled but I don't think that's related for the same reason - it can't be a filter, otherwise it would not work at all.
Maybe it has to do with some low-level broadcasts (ARP?) not being forwarded?
Joined: 08 May 2018 Posts: 14223 Location: Texas, USA
Posted: Tue Nov 23, 2021 2:41 Post subject:
Output of iptables -vnL and other iptables outputs would help, but last I recall, disabling block anonymous wan ping requests fixed it. You'll see the rule come up when you list your iptables rules; there is only ONE ICMP filter with it enabled, and it's not correct. _________________ "Life is but a fleeting moment, a vapor that vanishes quickly; All is vanity"
Contribute To DD-WRT Pogo - A minimal level of ability is expected and needed... DD-WRT Releases 2023 (PolitePol)
DD-WRT Releases 2023 (RSS Everything)
----------------------
Linux User #377467 counter.li.org / linuxcounter.net
Output of iptables -vnL and other iptables outputs would help
See attached. The "drop icmp from vlan2 (i.e. WAN port)" rule is in there.
In the meantime, I've deleted the virtual AP wl0.1 and rebooted the router. Lo and behold, I didn't get "Destination host unreachable" anymore - independently of whether I was connected to the one or the other wifi:
Code:
> ping 192.168.17.200
Pinging 192.168.17.200 with 32 bytes of data:
Reply from 192.168.17.200: bytes=32 time=7ms TTL=64
So I've set up the virtual AP wl0.1 once again, exactly as it was before. The iptables output before I deleted wl0.1 and after I re-added wl0.1 are exactly the same, too.
...and it still works. I mean, I'll take it, but it makes zero sense to me. ¯\_(ツ)_/¯
Switching off "Block Anonymous WAN Requests (ping)" was not necessary.
Well... I'd prefer understanding what exactly happened there, i.e. under which circumstances my own machine decides that a host on the same LAN segment can't be reached.
Code:
ping 192.168.1.200
Reply from 192.168.1.100: Destination host unreachable.
So when I am 192.168.1.100, then that message means the packet never left my machine. It did not even hit the router, my machine just decided that it would be impossible and gave up.
And I'd really like to understand what the technical reason for this could be. I would write this off to Windows being weird, but Linux did the exact same thing, so this must be more than a one-off.
Joined: 08 May 2018 Posts: 14223 Location: Texas, USA
Posted: Wed Nov 24, 2021 16:54 Post subject:
It happens. I mis-read plenty of posts. It's all out in the open for everyone to see. And if it's been "sanitized", there are folks kind enough to webarchive or screen-shot the incidents and log them for posterity like childish adolescents. _________________ "Life is but a fleeting moment, a vapor that vanishes quickly; All is vanity"
Contribute To DD-WRT Pogo - A minimal level of ability is expected and needed... DD-WRT Releases 2023 (PolitePol)
DD-WRT Releases 2023 (RSS Everything)
----------------------
Linux User #377467 counter.li.org / linuxcounter.net
If so a repeater bridge is a kind of hack which uses an ARP proxy.
Okay, so the underlying reason really had to do with ARP, just as I suspected initially as well.
Code:
root@router:~# dmesg
...
arp spoofing detected ip=192.168.1.200 mac is 90:0e:b3:3b:9e:19 but should be 80:1f:02:4a:32:46
arp spoofing detected ip=192.168.1.200 mac is 90:0e:b3:3b:9e:19 but should be 80:1f:02:4a:32:46
arp spoofing detected ip=192.168.1.200 mac is 90:0e:b3:3b:9e:19 but should be 80:1f:02:4a:32:46
arp spoofing detected ip=192.168.1.200 mac is 90:0e:b3:3b:9e:19 but should be 80:1f:02:4a:32:46
...
Disabling "ARP Spoofing Protection" under the Security tab on in the router's configuration made the "Destination host unreachable" problem go away.
The thing is, 192.168.1.200 really is 90:0e:b3:3b:9e:19, while 80:1f:02:4a:32:46 is the wireless AP/switch that I cabled 192.168.1.200 to.
I guess I have to try and find a different configuration mode for that AP, which actually seems to do ARP proxying. I had never given much thought. At least now I know where to look.
Last edited by CmdrTomalak on Fri Nov 26, 2021 14:50; edited 1 time in total
Joined: 31 Jul 2021 Posts: 2146 Location: All over YOUR webs
Posted: Fri Nov 26, 2021 11:31 Post subject:
CmdrTomalak wrote:
Okay, so the underlying reason really had to do with ARP, just as I suspected initially as well.
Disabling "ARP Spoofing Protection" under the Security tab on in the router's configuration made the "Destination host unreachable" problem go away.
