Upgraded 19.07 to 21.02 and router stopped working

I see. I updated the configuration with your suggestions, but the problem remains as was:
/etc/config/dhcp: https://pastebin.com/raw/AYPxJiC2

Install tcpdump opkg update; opkg install tcpdump
Run packet capture to see what is going on to the packets: tcpdump -i any -evn host 8.8.4.4
Then on a lan host run the ping 8.8.4.4 , stop it after a few lost packets, count the lost packets, stop tcpdump and copy paste here the output and the amount of lost packets.

1 Like

And post the output of sysctl net.ipv4.ip_forward

1 Like

tcpdump -i any -evn host 8.8.4.4
https://pastebin.com/raw/7juQ4n3q

# ping 8.8.4.4
PING 8.8.4.4 (8.8.4.4) 56(84) bytes of data.
--- 8.8.4.4 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3096ms

# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

Problem is that packets are leaving the router with the original source address, while they should be NATed. Eg. notice the In and Out

18:19:47.944977  In 56:8c:15:24:6e:09 ethertype IPv4 (0x0800), length 100: (tos 0x0, ttl 64, id 63814, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.7.2 > 8.8.4.4: ICMP echo request, id 2, seq 4, length 64

18:19:47.945072 Out 00:90:27:77:fb:02 ethertype IPv4 (0x0800), length 100: (tos 0x0, ttl 63, id 63814, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.7.2 > 8.8.4.4: ICMP echo request, id 2, seq 4, length 64

What is the output of iptables-save -c -t nat ?

# iptables-save -c -t nat 
# Generated by iptables-save v1.8.7 on Tue Feb 15 19:35:51 2022
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
# Completed on Tue Feb 15 19:35:51 2022

Nothing in there, run service firewall restart and paste it here.

# service firewall restart 
sh: service: not found

/etc/init.d/firewall restart

# /etc/init.d/firewall restart
Warning: Unable to locate ipset utility, disabling ipset support
Warning: Section @defaults[0] requires unavailable target extension FLOWOFFLOAD, disabling
Warning: Section @defaults[0] requires unavailable target extension FLOWOFFLOAD, disabling
 * Set tcp_ecn to off
 * Set tcp_syncookies to on
 * Set tcp_window_scaling to on
 * Running script '/etc/firewall.user'

Evidently there is something weird going on with the firewall as well as the image, since service is missing. As I am not experienced with container installation, I'll refer it to some other members of the forum and hopefully you'll get more lucky.
Just mention where did you get the image from.

I got the image from here: https://openwrt.org/docs/guide-user/virtualization/lxc
Except I am using an LXD command, not the naked LXC. It is:

lxc launch images:openwrt/21.02 router

Which service is missing?

@xorbug @anon50098793 any ideas?

1 Like

afaik...

  • above is about the 'service' function from /etc/profile not existing
  • lxc is probably similar to qemu in that the init process is 'special'... but pretty sure that kind of stuff would be mentioned where you downloaded your stuff
1 Like

Thanks! Any idea about the firewall not being configured?

afaik, when you run openwrt in qemu and probably lxc certain changes need to be made to the way somethings startup...

not an expert in this area but it should be explained where the dude downloaded his image... as they probably made all the necessary modifications or some or none... answer changes depending on that...

i.e.; this message;

is probably referring to the lxc host-os kernel... etc. etc.

If it adds anything to the discussion, on 19.07 (also in LXD) I get the same:

# service firewall restart 
sh: service: not found

yet the router has been working properly since over a year now.

did you keep settings / restore a backup file across those versions?

Ok I just checked quickly... two things:

Probably you are lxc-attaching right? Because attach notoriously doesn't export all paths and variables. It's the same for me. If you go over ssh, and I guess lxc-console as well, it's everything in place tho.

Probably you restored a configuration from another router? Because SFO should not be available for x86_64. See Software flow offloading for containerized OpenWrt

As also @anon50098793 said, that's related to the host kernel.Kernels from major distros (at least Debian based) appear to work well without any specific tuning, at least i had no issues so far. And in any case it's just a warning, should be safe to ignore.

1 Like

did you keep settings / restore a backup file across those versions?

I tried with restore, and with manual setup from scratch. Same result both times.

Probably you are lxc-attaching right? Because attach notoriously doesn't export all paths and variables. It's the same for me. If you go over ssh, and I guess lxc-console as well, it's everything in place tho.

Great point. That's right. I use LXD, so it's lxc exec but this is just a wrapper for lxc commands.
So after logging through ssh, I got a correct response from the service:
https://pastebin.com/raw/ygH5Agfu