Can't get to web ui when wireless is connected?

captaintrav · January 16, 2023, 6:27pm

I have two routers using dd-wrt to form a wireless bridge (ethernet at either end), not using the WAN at all.

When anything is connected to the base WDS session, no one can connect to the web ui on the base unit. The message I get is the connection was closed.

The router is a TP-Link Archer C7 v1.0. Here's where it gets interesting, the problem doesn't seem to be with the config, it's something specific to the firmware on that particular router. I'm using a D-Link at the other end, and it works fine. I reflashed both of them, reset all settings and reversed the roles, the problem follows the TP-Link router, not the config (if it's the WDS client it has the same issue - once the bridge is up connections to port 80/443 on the router are blocked).

Even without using WDS, if I connect a regular client to the base WDS system (the TP-Link), can't get to the web UI. Without even rebooting, if I disconnect everything from the wireless on the TP-Link, I can get to the web ui.

I can post config files and logs if anyone wants to check on that.

psherman · January 16, 2023, 6:29pm

Can you draw a diagram of your topology, complete with the firmware on each device, the IP addresses, and the physical connections?

captaintrav · January 16, 2023, 6:37pm

Here's a basic rundown - I will make a chart if I can find a free tool.

Ethernet clients (dhcp assigned from 192.168.0.1) <-Cat5-> Ethernet LAN ports on D-LINK DIR-835 A1 running OpenWrt 21.02.2 on 192.168.0.253 <-802.11n-> 5GHz Wireless LAN "OpenWRT" with WDS configured <-> TP Link Archer C7 rev 1.0 on 192.168.0.254 <-Cat5-> Ethernet (LAN side) connected to ISP Modem/Router 192.168.0.1 (DNS and DHCP)

DNS/DHCP is disabled on OpenWRT units, WAN port is unused.

psherman · January 16, 2023, 6:40pm

a photo of a sketch on paper can be sufficient here.

psherman · January 16, 2023, 6:45pm

Also, which unit is the "base" unit here? Can the others be reached?

captaintrav · January 16, 2023, 6:51pm

So the "base" unit is the TP-Link, everyone can connect to the wireless on it including the WDS Client (the D-Link router). Once connected, I can get to the webUI on the "client" router (D-Link) just fine, so all network traffic seems to be passed just fine. I just can't get to the web server.

psherman · January 16, 2023, 7:00pm

confirming my understanding... you are unable to access the TP-Link device via the WDS setup when the D-Link is connected. But if you take down the D-Link device, you can reach the TP-Link, correct?

Have you tried connecting by ethernet to the TP-Link device (as a test) while WDS is connected? Can you reach the web interface when you do that? The idea is to understand if this is an issue with the wireless connection or if the WDS connection is killing your access entirely.

captaintrav · January 16, 2023, 7:19pm

Good question and WDS is indeed shutting down the entire thing. When I try to connect via ethernet to the TP-Link web server the same result happens. I can try disabling WDS and connecting then.

The funny thing is I reversed the roles of the two devices, and the problem follows the hardware, not the configuration. When I use the TP-Link as the wireless client, as soon as the client is connected to the wireless, can't get to the web interface via ethernet or wireless either.

psherman · January 16, 2023, 7:25pm

let's see the complete configuration of your TP-Link device...

Please copy the output of the following commands and post it here using the "Preformatted text </> " button:

Remember to redact passwords, MAC addresses and any public IP addresses you may have:

cat /etc/config/network
cat /etc/config/wireless
cat /etc/config/dhcp
cat /etc/config/firewall

captaintrav · January 17, 2023, 4:13pm

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 'fda9:6ed5:4ae5::/48'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'eth1.1'

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

config interface 'wan'
	option device 'eth0.2'
	option proto 'dhcpv6'

config interface 'wan6'
	option device 'eth0.2'
	option proto 'dhcpv6'

config switch
	option name 'switch0'
	option reset '1'
	option enable_vlan '1'

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option ports '2 3 4 5 0t'

config switch_vlan
	option device 'switch0'
	option vlan '2'
	option ports '1 6t'

root@OpenWrt:~# cat /etc/config/wireless 

config wifi-device 'radio0'
	option type 'mac80211'
	option path 'pci0000:00/0000:00:00.0'
	option channel '36'
	option band '5g'
	option htmode 'VHT80'
	option cell_density '0'

config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option ssid 'OpenWrt'
	option encryption 'sae-mixed'
	option key 'redacted'

config wifi-device 'radio1'
	option type 'mac80211'
	option path 'platform/ahb/18100000.wmac'
	option channel '1'
	option band '2g'
	option htmode 'HT20'
	option disabled '1'

config wifi-iface 'default_radio1'
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option ssid 'OpenWrt'
	option encryption 'none'
	option disabled '1'

root@OpenWrt:~# cat /etc/config/dhcp 

config dnsmasq
	option domainneeded '1'
	option boguspriv '1'
	option filterwin2k '0'
	option localise_queries '1'
	option rebind_protection '1'
	option rebind_localhost '1'
	option local '/lan/'
	option domain 'lan'
	option expandhosts '1'
	option nonegcache '0'
	option authoritative '1'
	option readethers '1'
	option leasefile '/tmp/dhcp.leases'
	option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
	option nonwildcard '1'
	option localservice '1'
	option ednspacket_max '1232'

config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '12h'
	option dhcpv4 'server'
	option dhcpv6 'server'
	option ra 'server'
	list ra_flags 'managed-config'
	list ra_flags 'other-config'
	option ignore '1'

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

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

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

config defaults
	option syn_flood '1'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'

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

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

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 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 rule
	list proto 'tcp'
	option dest_port '443'
	option target 'ACCEPT'
	option name 'Allow-HTTPS'
	option src 'wan'

root@OpenWrt:~#

captaintrav · January 17, 2023, 4:17pm

I found this is nothing to do with the wireless/WDS stuff. Above I have the TP-Link (which is actually rev 2) configured hopefully just as AP duties, WAN is disconnected, DHCP is not enabled on the LAN interfaces

ISP modem - 192.168.0.1
| - ethernet LAN1
TP-Link OpenWRT - 192.168.0.254
| - ethernet LAN2
Linux PC - 192.168.0.201

As soon as the 'br-lan' gets traffic going, I get connection refused by the TP-Link device on web ports and even SSH. I can ping the IP though. Even without wireless clients connected, it still dies. If I disconnect LAN1 to the ISP router/rest of devices, within about 30 seconds I can connect to the WebUI again. It seems even routing ethernet traffic is a problem, not wireless.

psherman · January 17, 2023, 5:45pm

To confirm, you are using the one of the lan ports on this device, right? (you've said this a few times, just want to confirm it once more).

Also, have you 100% verified that nothing else on the network is using 192.168.0.254 (and further that it is outside the DHCP pool from your main router)?

You may want to change the DHCP lan server to look like this:

onfig dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '12h'
	option ignore '1'

Mixed mode doesn't always work well, so I typically recommend making this WPA2 (PSK) rather than sae-mixed, but that will not affect the wired connectivity for a host directly connected to the ethernet ports on this device, so that's probably not directly related.

since you're not using the wan port, this is not needed and can be deleted.

captaintrav · January 19, 2023, 9:36am

I tried that 443 firewall rule to see if it would help, it did not. I will make the wireless security changes.

But... the issue is the IP address. It belongs to the ISP's router although it's not documented and I don't know what it's used for. I thought the problem followed the TP-Link device both in "Master" and "Client" mode for WDS, but failed to notice I used the same IP for it all of this time.

The ISP modem/router is a Hitron unit. It's IP for gateway/management is 192.168.0.1, but it indeed is using 254 as well.

I confirmed this by dumping arp tables. It really confused me because the TP-Link OpenWRT device didn't stop responding instantly, but after a short while of the entire network being up. I'm guessing that's a factor of whenever there is another arp request for 192.168.0.254.

Not related to OpenWRT at all! Now I'm digging into why this is. Looks like the only open port on it is 45514, and it responds to ICMP requests, that's it.

psherman · January 19, 2023, 4:04pm

Sorry if I wasn't clear... These were not necessarily expected to solve the issue, but rather some general advice. If sae-mixed actually works in your situation, you can keep it as is... but many people end up having issues, so the fix is often to roll back to wpa2.

That is supremely annoying! It is unusual for a consumer router like this to use two IPs on the same network, so I wouldn't have guessed it directly. However, the general idea of another device inadvertently conflicting is why I had said this

A really quick and easy (but not 100% reliable test) is to do a ping test to the address with your device powered off... if you get a response, something else is clearly using the address you are trying to use. ARP tables and other discovery methods obviously also work, so that was great thinking. Despite the annoyance towards that ISP box, I'm glad you were able to find the problem... now you can use another address (maybe 253) and you should be good.

If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.

captaintrav · January 19, 2023, 10:20pm

I assigned the device 192.168.0.252 and it works perfectly now. 192.168.0.253 was assigned to my WDS client router so I can bridge desktops without WiFi to the other (TP-LInk) device. Weirdly if you look at the arp cache, the ISP's router has wildly different MAC address for the .254 vs the known .1 for the device.

Also, good call on just using WPA2-PSK vs mixed. One of my ancient ThinkPad models definitely doesn't it configured for WPA2/3.

system · January 29, 2023, 10:21pm

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