Connection issue after migration to 24.10.0: Router can curl a URL, clients cannot

Installing and Using OpenWrt
1

Dear all,

could you help me solve this puzzle?

I migrated my router (WRTACS1900ACS) from 22.3 to 24.10.0. As the previous upgrade attempt to 23.x failed (last year?), I did a factory reset, installed a factory 24.10.0 image and then piece by piece copied back my old configuration and adapted it where necessary. Last time the network configuration seemed to have been the culprit, due to the change to DSA switch infrastructure (or whatever it was called).

I have some WAN DHCP issues (see this thread) but I noticed something else (if I can get a WAN IP address, that is).

I noticed that although my router can ping and curl a website, the clients behind it can only ping it. Running a curl on a client connected to the router hangs and fails finally. empty reply from server

It does not matter whether the client is connected via Wifi or via LAN.

I can ping the server from the client without issues.

Any ideas what could be wrong? Firewall configuration? Vodafone having infrastructure issues? (Maybe related to the WAN DHCP issues)?

Any ideas are highly appreciated! I can debug this for two more days, then I need my internet connection back... :slight_smile:

Thanks in advance!

Kind Regards,
Johannes

2

OK, funny. Currently it seems like clients connected via Wifi (directly to the router) can successfully reach servers, while clients connected via LAN or via Wifi on the access point (which is connected via LAN) cannot connect.

Ping and DNS queries (with both TCP and UDP) are working fine from all clients to all hosts I tried.

Any ideas where that might come from? Wifi connections not being tagged while LAN connections have a VLAN?

Kind Regards,
Johannes

3

OK, it really boils down to this:

Connections via LAN are NOT working.
Connections via Wifi directly on the router ARE working.
Connections via Wifi on the access point are NOT working.

WTF?

4

Is there just a single device here or do you have a router and then additional APs? If the latter, can we see a network topology diagram.

And let’s look at your configs:

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
5

Thanks for the reply, @psherman.

For now, let's trim this down and forget about the APs. I have a VLAN LAN79 where both a LAN port and a Wifi are connected to. This is the one I tested with (also I also tested other VLANs, not all of which have a related wifi). So, let's use this one.

I connected the laptop to the router via Wifi.
Then I connected the Laptop via LAN to a switch, which has a PVID of 79 on the port where I connected and sends the packets tagged to the router's LAN port.
This setup has not changed since before the upgrade. And the general VLAN connection is working, i.e. I can ping and reach the router and all internal devices in this and other VLANs (as far as the firewall rules allow that).

I am currently trimming down the firewall configuration to get rid of some old stuff, but as the wifi and the LAN79 are using the same firewall zone, I do not expect this to be the cause.

# ubus call system board
{
        "kernel": "6.6.73",
        "hostname": "openwrt-router",
        "system": "ARMv7 Processor rev 1 (v7l)",
        "model": "Linksys WRT1900ACS",
        "board_name": "linksys,wrt1900acs",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "24.10.0",
                "revision": "r28427-6df0e3d02a",
                "target": "mvebu/cortexa9",
                "description": "OpenWrt 24.10.0 r28427-6df0e3d02a",
                "builddate": "1738624177"
        }
}

/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 'fdb2:f5e5:49a1::/48'
	option packet_steering '0'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'
	list ports 'lan4'
	option bridge_empty '1'
	option ipv6 '0'

config device
	option name 'wan'

config device
	option name 'br-lan.79'
	option type '8021q'
	option ifname 'br-lan'
	option vid '79'
	option ipv6 '0'

config bridge-vlan
	option device 'br-lan'
	option vlan '79'
	list ports 'lan1:t'
	list ports 'lan2:t'
	list ports 'lan3:t'
	list ports 'lan4:t'

config interface 'wan'
	option device 'wan'
	option proto 'dhcp'
	list dns '46.182.19.48'
	list dns '80.241.218.68'
	list dns '159.69.114.157'
	option peerdns '0'
	option broadcast '1'
	option hostname '*'
	option delegate '0'
	option vendorid 'openwrt'

config interface 'wan6'
	option device 'wan'
	option proto 'dhcpv6'
	option reqaddress 'none'
	option reqprefix 'no'
	option norelease '1'
	option disabled '1'

config interface 'LAN79'
	option device 'br-lan.79'
	option proto 'static'
	option ipaddr '192.168.79.1'
	option netmask '255.255.255.0'

/etc/config/wireless:

config wifi-device 'radio0'
        option cell_density '0'
        option channel 'auto'
        option country 'DE'
        option hwmode '11a'
        option path 'soc/soc:pcie/pci0000:00/0000:00:01.0/0000:01:00.0'
        option type 'mac80211'
        option htmode 'VHT80'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option key 'SECRET'
        option macaddr 'some-mac-address'
        option mode 'ap'
        option network 'LAN79'
        option ssid 'SECRET'
        option wpa_disable_eapol_key_retries '1'
        option encryption 'psk2+ccmp'
        option ieee80211r '1'
        option mobility_domain '123C'
        option ft_over_ds '0'
        option ft_psk_generate_local '1'
        option ieee80211w '2'

config wifi-device 'radio1'
        option cell_density '0'
        option channel '1'
        option country 'DE'
        option htmode 'HT40'
        option hwmode '11g'
        option path 'soc/soc:pcie/pci0000:00/0000:00:02.0/0000:02:00.0'
        option type 'mac80211'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option encryption 'psk2+ccmp'
        option key 'SECRET'
        option macaddr 'some-other-mac-address'
        option mode 'ap'
        option network 'LAN79'
        option ssid 'SECRET'
        option ieee80211r '1'
        option mobility_domain '123A'
        option ft_over_ds '0'
        option ft_psk_generate_local '1'
        option ieee80211w '1'
        option wpa_disable_eapol_key_retries '1'

/etc/config/dhcp:

config dnsmasq
        option domainneeded '1'
        option localise_queries '1'
        option rebind_protection '0'
        option local '/openwrt.example.org/'
        option domain 'openwrt.example.org'
        option expandhosts '1'
        option cachesize '1000'
        option authoritative '1'
        option readethers '1'
        option leasefile '/tmp/dhcp.leases'
        option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
        option localservice '1'
        option ednspacket_max '1232'
        option nonegcache '1'
        option filter_aaaa '1'
        option boguspriv '0'

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'

config dhcp 'LAN79'
        option interface 'LAN79'
        option start '41'
        option limit '49'
        option leasetime '12h'
        list dhcp_option '15,something.example.org'
6

Did you edit the firewall?

(We can't guess.)

It seems like you're already having the same discussion in another thread.

7

Thanks for the reply. Yes, I separated the two issues, so this one is purely about the funny connection issues.

Regarding the firewall, I am currently trying to clean up and will post the leftover then. But as both the Wifi and LAN79 are in the same firewall zone, why should this make a difference?

From /etc/config/wireless:

config wifi-iface 'default_radio1'
[...]
        option network 'LAN79'
8

It'll be much easier to post the config - then we don’t need to guess with additional information in subsequent threads.

It'll be easier to standby for the rest of your config.

Lastly:

Are your clients appending this to the domain when running tests?

9

OK, here is the current firewall configuration.

I refactored it and removed lots of rules that are not required for testing. But still curl only works from Wifi clients, not from ones connected via LAN:


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

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 zone
	option name 'zone_lan79'
	list network 'LAN79'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'ACCEPT'

# all other zone_lanXX zone configurations were removed here
[...]
config forwarding
	option src 'zone_lan79'
	option dest 'wan'

# forward from zone_lanXX to WAN configurations were removed here
[...]

config forwarding
	option src 'zone_lan79'
	option dest 'zone_lan19'

config forwarding
	option src 'zone_lan79'
	option dest 'zone_lan39'

config forwarding
	option src 'zone_lan79'
	option dest 'zone_lan49'

config forwarding
	option src 'zone_lan79'
	option dest 'zone_lan59'

config forwarding
	option src 'zone_lan79'
	option dest 'zone_lan69'

config forwarding
	option src 'zone_lan79'
	option dest 'zone_lan89'

config forwarding
	option src 'zone_lan79'
	option dest 'zone_lan99'

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 dest_port '67 68'
	list proto 'udp'
	option name 'Allow DHCP'
	option target 'ACCEPT'
	option src '*'
	list src_ip '0.0.0.0'

config rule
	option dest_port '53'
	option src '*'
	option target 'ACCEPT'
	option name 'DNS aus allen Netzen erlauben'

config rule
	option target 'ACCEPT'
	list dest_ip '192.168.79.1'
	list proto 'tcp'
	option src 'zone_lan79'
	option dest_port '80 443'
	option name 'OpenWRT GUI from lan79'

config rule
	option dest_port '12345'
	option src 'zone_lan79'
	option name 'SSH Port 12345 from lan79'
	option target 'ACCEPT'
	list proto 'tcp'

config rule
	list proto 'tcp'
	option src 'zone_lan79'
	list dest_ip '192.168.79.1'
	option dest_port '22'
	option target 'ACCEPT'
	option name 'SSH Port 22 from lan79'
	option family 'ipv4'
10

I tested with both DHCP and static IP addresses on both LAN and wifi.

I can ping and dig the URL and get the same IP address on all of them.

When running curl -v https://URL I get the same output for both working and non-working clients:

$ curl -vL johannes-kastl.de
* Host johannes-kastl.de:80 was resolved.
* IPv6: (none)              
* IPv4: 78.46.194.159
*   Trying 78.46.194.159:80...
* Connected to johannes-kastl.de (78.46.194.159) port 80
[...]

So, no this dhcp option does not have any influence. If so, it would affect both LAN and Wifi clients as both are using the same DHCP server for this LAN79 network.

1 Like
11

Edit: Sorry, seems to have been a false alarm. Maybe I was too quick and the firewall was not completely reloaded. Now it no longer works, as before...

OK, I just disabled hardware offloading in the firewall settings.

And now the curl from a LAN clients goes through without issues.

WTF?

This was working on 22.x, am I missing a module or a package in 24.10.0?

1 Like
12

OK, it seems like this is really caused by hardware offloading.

I rebooted the router and noticed hardware offloading was enabled again. This is way the errors were back before. Disabled HW offloading and made sure it was disabled. No the errors are gone and the connection succeeds.

So, the question is: Why is hardware offloading not working, while it was working on 22.3?

Am I missing package or kernel module?

(I am building my own images, but made sure to keep all packages included that are in the official image for this device model)

Thanks for your help, @lleachii and @psherman!

1 Like
13

OK, all packages in the official image are also included in my image (except the PPPoE related ones):
https://firmware-selector.openwrt.org/?version=24.10.0&target=mvebu%2Fcortexa9&id=linksys_wrt1900acs

14

23.x had procd and procd-seccomp in the package list, but those are a) unrelated and b) also installed on my router (dependency of procd-ujail).