Green and blue network down since upgrade core 190

Networking
1

Hello everyone, I installed about a year ago a firewall/proxy with a blue and green network interface, and since updating from Core 189 to Core 190, for reasons unknown, several times a day, these network interfaces no longer work.
I still have access from home via OpenVPN but all equipment is down. When I connect with OpenVPN and SSH session, the arp command returns lines indicating incomplete names of computers.
A reboot of the firewall resolves the issue for one to two hours but not more.

Can someone please help me ?

Thanks a lot

I found many unbound errors in the /var/log/messages like this:

Jan  6 10:27:49 ipfire unbound: [2068:0] info: service stopped (unbound 1.22.0).
Jan  6 10:27:49 ipfire unbound: [2068:0] info: server stats for thread 0: 310 queries, 187 answers from cache, 123 recursions, 6 prefetch, 0 rejected by ip ratelimiting
Jan  6 10:27:49 ipfire unbound: [2068:0] info: server stats for thread 0: requestlist max 58 avg 8.89922 exceeded 0 jostled 0
Jan  6 10:27:49 ipfire unbound: [2068:0] info: average recursion processing time 0.089139 sec
Jan  6 10:27:49 ipfire unbound: [2068:0] info: histogram of recursion processing times
Jan  6 10:27:49 ipfire unbound: [2068:0] info: [25%]=0.0256683 median[50%]=0.0642253 [75%]=0.125952
Jan  6 10:27:49 ipfire unbound: [2068:0] info: lower(secs) upper(secs) recursions
Jan  6 10:27:49 ipfire unbound: [2068:0] info:    0.000000    0.000001 9
Jan  6 10:27:49 ipfire unbound: [2068:0] info:    0.004096    0.008192 1
Jan  6 10:27:49 ipfire unbound: [2068:0] info:    0.008192    0.016384 12
Jan  6 10:27:49 ipfire unbound: [2068:0] info:    0.016384    0.032768 15
Jan  6 10:27:49 ipfire unbound: [2068:0] info:    0.032768    0.065536 25
Jan  6 10:27:49 ipfire unbound: [2068:0] info:    0.065536    0.131072 32
Jan  6 10:27:49 ipfire unbound: [2068:0] info:    0.131072    0.262144 24
Jan  6 10:27:49 ipfire unbound: [2068:0] info:    0.262144    0.524288 4
Jan  6 10:27:49 ipfire unbound: [2068:0] notice: Restart of unbound 1.22.0.
Jan  6 10:27:49 ipfire unbound: [2068:0] notice: init module 0: validator
Jan  6 10:27:49 ipfire unbound: [2068:0] notice: init module 1: iterator
Jan  6 10:27:49 ipfire unbound: [2068:0] info: start of service (unbound 1.22.0).
Jan  6 10:27:49 ipfire unbound: [2068:0] info: generate keytag query _ta-4a5c-4f66. NULL IN
Jan  6 10:30:30 ipfire unbound: [2068:0] error: SERVFAIL <251.36.139.176.in-addr.arpa. PTR IN>: misc failure
Jan  6 13:34:36 ipfire unbound: [2068:0] info: service stopped (unbound 1.22.0).
Jan  6 13:34:36 ipfire unbound: [2068:0] info: server stats for thread 0: 20330 queries, 13708 answers from cache, 6622 recursions, 661 prefetch, 0 rejected by ip ratelimiting

EDIT: moderator formatted code block

2

In a root SSH shell or at the terminal type:

cd /etc/unbound

unbound-checkconf

Post the output.

3

I change the root.hints file with 18 december file and I will check.

ok here le output now :

[root@ipfire unbound]# unbound-checkconf
unbound-checkconf: no errors in /etc/unbound/unbound.conf
[root@ipfire unbound]#

4

Concerning the message log there is only one ā€œerrorā€.

The remaining are either a notice: or an info: and can be ignored.

Are there other errors?

1 Like
5

That file does not change content often.

Should be the same as the file called named.cache at ftp://ftp.internic.net

which is:

;       This file holds the information on root name servers needed to 
;       initialize cache of Internet domain name servers
;       (e.g. reference this file in the "cache  .  <file>"
;       configuration file of BIND domain name servers). 
; 
;       This file is made available by InterNIC 
;       under anonymous FTP as
;           file                /domain/named.cache 
;           on server           FTP.INTERNIC.NET
;       -OR-                    RS.INTERNIC.NET
; 
;       last update:     July 03, 2019 
;       related version of root zone:     2019070301
; 
; FORMERLY NS.INTERNIC.NET 
;
.                        3600000      NS    A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.      3600000      A     198.41.0.4
A.ROOT-SERVERS.NET.      3600000      AAAA  2001:503:ba3e::2:30
; 
; FORMERLY NS1.ISI.EDU 
;
.                        3600000      NS    B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.      3600000      A     199.9.14.201
B.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:200::b
; 
; FORMERLY C.PSI.NET 
;
.                        3600000      NS    C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.      3600000      A     192.33.4.12
C.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:2::c
; 
; FORMERLY TERP.UMD.EDU 
;
.                        3600000      NS    D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET.      3600000      A     199.7.91.13
D.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:2d::d
; 
; FORMERLY NS.NASA.GOV
;
.                        3600000      NS    E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET.      3600000      A     192.203.230.10
E.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:a8::e
; 
; FORMERLY NS.ISC.ORG
;
.                        3600000      NS    F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET.      3600000      A     192.5.5.241
F.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:2f::f
; 
; FORMERLY NS.NIC.DDN.MIL
;
.                        3600000      NS    G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET.      3600000      A     192.112.36.4
G.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:12::d0d
; 
; FORMERLY AOS.ARL.ARMY.MIL
;
.                        3600000      NS    H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET.      3600000      A     198.97.190.53
H.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:1::53
; 
; FORMERLY NIC.NORDU.NET
;
.                        3600000      NS    I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET.      3600000      A     192.36.148.17
I.ROOT-SERVERS.NET.      3600000      AAAA  2001:7fe::53
; 
; OPERATED BY VERISIGN, INC.
;
.                        3600000      NS    J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET.      3600000      A     192.58.128.30
J.ROOT-SERVERS.NET.      3600000      AAAA  2001:503:c27::2:30
; 
; OPERATED BY RIPE NCC
;
.                        3600000      NS    K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET.      3600000      A     193.0.14.129
K.ROOT-SERVERS.NET.      3600000      AAAA  2001:7fd::1
; 
; OPERATED BY ICANN
;
.                        3600000      NS    L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET.      3600000      A     199.7.83.42
L.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:9f::42
; 
; OPERATED BY WIDE
;
.                        3600000      NS    M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET.      3600000      A     202.12.27.33
M.ROOT-SERVERS.NET.      3600000      AAAA  2001:dc3::35
; End of file
6

I replaced the root.hints file, which dated from July 2019, with the one available on internic dating from December 2024. For now, there is no problem; it was not the solution to be made?

1 Like
7

the network drops againā€¦
impossible to navigate on the internet,
forced to restart the server

9

rarely the ip addresses for those server ever change and your problem did not arise until you updated.

what do you get when you execute:

uname -srm
10

[root@ipfire ~]# uname -srm
Linux 6.6.63-ipfire x86_64

11

I would login to the web gui, go to ipfire->pakfire and at the bottom of the page, set the repository to ā€˜unstableā€™, save reboot. Then go back ino pakfire and upgrade it to 192 since your kernel is 6.6.63 and maybe causing the issues. 192 is running 6.11 which is the current stable experimental version they are testing for adoption as the LTS stable version.

12

Here is what the IPFire wiki says on Unstable

  • Unstable - The current testing version based on ā€œnextā€ nightly build (may be incomplete / dangerous).
    • Everything that a developer does goes to the development mailing list. Patches are reviewed and fixed there and then selected by Arne for going into the next release. That process is important to only select patches that have been seen by enough people and pair them together to bake a nice update. This tree is called unstable and everything in there is literally that. Developers have tested the code, but it has not been tested by a wider audience.

It is fine on an evaluation or development system but not appropriate for a production system.

1 Like
13

Thank you very much for the information, but I cannot afford to test an unstable development version. If there is a problem, more than 50 people will not
be able to work and we will have to wait until I install a new server :frowning: For now itā€™s stable, has the new file in /etc/unbound been taken into account
by crontab? I donā€™t knowā€¦

14

Its not my fault the current stable Linux kernel is not the current LTS kernel. This happens every once in a while. Last time the Linux ecosystem has witness this behaviour is when everything was getting migrated for 64 bit distributions back in 2008.

I think March is when they will finalise 6.11 to 6.13 LTS. But hopefully they will release it sooner for core instead of waiting for the main distribution releases in April.

15

Hello everyone, there are no longer any network interface down issues, I hope everything will work throughout the day, I could close this issue. Thank you all, Iā€™ll keep you informed

16

Could you give some info on how you fixed it.

2 Likes
17

I replaced the root.hints file, which dated from July 2019, with the one available on internic dating from December 2024, this is the only fix for the moment :frowning:

18

the network is down since 20 minā€¦I restart the ipfireā€¦

19

well maybe the ipfire devs will update 190 kernel, but it makes me wonder if you donā€™t have something going on in the hardware side.

check to see if the power management is turned off and turn off hypertheading.

gimm posted 6.13rc6 in kernel/git/stable/linux.git - Linux kernel stable tree
three days ago.

so soon we will have ā€œBaby Opossum Posseā€ running ipfire.

20

Probably some sort of file corruption.
The easiest fix is Probably a recent backup and a fresh install.
I always create and download backup from firwall. Then grab Iso from ipfire website.
Then I have everything incase of upgrade failure.
Install and restore are quick.

21

I can possibly restart the server with a file check and see the resultā€¦

1 Like