-
Notifications
You must be signed in to change notification settings - Fork 759
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Erratic behaviour of WAN after R19.1 update and apply changes to the WAN interface settings #3200
Comments
|
Keep in mind that #3198 only impacts installations where media wasn't set to default. |
|
#3198 is worse than my issue... toggling the speed settings on LAN made my system totally unresponsive. Maybe I should have tested on WAN to keep LAN accessable. Anyhow, rebooted and applied patch which seems to solve that issue. Toggling speed is possible without problems. Changed option modifier again by filling in "supersed ...." , pressed save and system goes into high CPU again. My issue above seems unrelated and system seems to stay responsive, although CPU is high. In DMESG igb0 (wan) flips from up to down and back again. Do you need any logging to debug this issue? If so, which? |
|
just to be sure, you didn't remove / disable core/src/etc/inc/interfaces.inc Lines 3216 to 3218 in 7aab4a9
|
|
@AdSchellevis no, I didn't. The box is ticked, so I assumed that the patch is in place for 19.1.1. I only removed the text in the options modifier box. In itself this should not change a thing, as patch is applied through the tick box. Ifconfig still shows MTU of 1500, which confirms this. The system just goes into high cpu load and router advertisement deamon goes to 'red'. A reboot solves everything and cpu load goes to normal. Apparently it just has to do with updating the WAN settings in general, because changing Interfaces>Wan>General configuration>Description from "" into "test" generates the same behaviour. |
|
and what does /var/log/syslog show when you tail it? |
|
Hi, Just renamed the WAN interface again, did a "Save" followed by "Apply" and it results in the following (starting at 22:04): Feb 6 21:51:09 OPNsense flowd_aggregate.py: start watching flowd |
|
NB: did not test on LAN, but might behave in the same way... if necessary I can test day after tomorrow |
|
Looks like issues with hardware/driver or cabling, card goes down, all events between are a result of the loss of link. You could check your offloading settings, different switch / cable and media settings. |
|
Driver seems unlikely, as this used to work with 18.7? Did not change anything in the cabling, but will do some checking on that side this evening. Don't know what you mean with offloading settings. There is no switch on igb0. It is directly connected to a bridged cable modem. |
|
19.1 has a different kernel (HardenedBSD 11.2), so driver might be different, although I haven't seen similar issues on the machines we're selling (also using igb drivers). offloading settings, can be located Interfaces -> Settings (a screenshot might help) and the media settings on the interface can also shed light. |
|
OK, I did some more testing. Once I change the IPv4 Configuration Type from DHCP to Static, using the last known IP and gateway from my ISP, the WAN interface stays stable and I can change the Description or any other field without any problems. Apparently the interface flapping has something to do with the DHCP settings or rc.linkup: Hotplug event?. See log below of changing the Description without any link up/down issues.... CPU is behaving nicely with a flat line around 20% usage... Unfortunately I do not have an ISP with static IP, so need to revert to DHCP sometime in near future.... Any ideas how to debug further? As far as driver issue or wrong cabling I would suspect also issues in static state (while not updating a field on interface settings), correct? Feb 7 21:57:37 OPNsense opnsense: /usr/local/etc/rc.linkup: Hotplug event detected for Test(wan) but ignoring since interface is configured with static IP (82.74.106.222 ::) |
|
Probably same as #3197 and there is a patch in there to try as well. |
|
This is what happens when changing from Fixed IP to DHCP without opnsense-patch [c83bb8d] applied Feb 7 23:55:25 OPNsense opnsense: /index.php: Successful login for user 'root' from: 192.168.1.41 |
|
But when I leave WAN on DHCP and do a reboot, IP is acquired and no up/down changes. Apparently there is a difference between changing settings through the UI or doing a cold boot. In case of UI change, a HOTPLUG event is detected (although cable is not detached from NIC) Feb 8 00:07:36 OPNsense reboot: rebooted by root |
|
#2372 (comment) also looks awfully similar |
|
I think I can rule out cable and router HW. Changed cable, does not change issue, changed interfaces and issue moves with WAN interface selected. It either has to do with my Modem (did not change) or with the software. What I notice is that everything runs smoothly when doing a fresh boot. When I change something on the opnsense WAN interface settings (indepentent if this is igb0 or igb1), the software change triggers a Hotplug event and following this event, somehow a loop is triggered.
Tried the following steps:
See full log since 'rm /var/log/system.log' below root@OPNsense:~ # cat /var/log/system.log |
|
@fichtner Tried patch 90c0c39 provided in #3197 (comment) to see if it would solve this issue, but to no avail. Apparently the issue described above is not related with #3197 |
|
OK, decided to do a factory reset again and start from scratch. Once starting from scratch, no issues with high process peaks. Apparently something wrong in the configuration that was (partially) loaded from 18.7 configuration backup . Don't know what/why or where, but happy to provide backup XML for reviewing purposes. |
I was already on the mentioned bios version, prior to upgrading R19.1, so we can also rule out that rootcause |
|
As issue seems to be resolved when configuring from 'fresh factory defaults' in stead of loading a 18.7 config file, I am closing this issue. |
After install of R19.1 I experienced the MTU bug on WAN side (#3173 ), so applied the provided 'patch' with supersede interface-mtu 0
Now I applied R19.1.1, removed the supersede interface-mtu 0 option modifier, pressed 'save' and 'apply changes' and all of a sudden CPU spikes to 100% and WAN Gateway and Interface start behaving like a traffic light -> on / off / on / off....
Update: applies to any update done on the WAN interface settings, like Interfaces>Wan>General configuration>Description from "" into "test"
See screenshots. A reboot solves the issue, but this should not be necessary IMHO?
Sounds related to #3198
Hardware: Apu2d4. Error is reproducable. Willing to provide debugging info if shown where to look :-)
The text was updated successfully, but these errors were encountered: