Strange WIO addon behavior

Add-Ons
1

I have a strange behavior with an IPFire installation.

The customer complains of cyclical disconnections from the internet, disconnections that reach about 30-40 seconds.

The situation is the following:

  • IPFire IPFire 2.29 (x86_64) - Core-Update 194
  • Internet connection with static ip and a pool of 4 ip
  • Static IP assigned to the router port
  • Static IP assigned to the RED port of IPFire
  • WIO enabled

Every 15 minutes, at 00,15,30 and 45 minutes, the connection drops, the provider does not highlight any line drops, but if I ping the public address of the router and that of the firewall, I see that every 15 minutes the firewall does not respond to me from the outside.

The thing that left me perplexed is the regularity of the disconnections, precisely every 15 minutes to the second.

After various analyses, I found that the “culprit” is WIO.
On the Green network I have a monitored client that is turned off, if I ask to update the status of that particular IP address, the RED and GREEN go down.

I tried the same test on my IPFire, inserting an IP address that does not exist on my network, I launch WIO, but nothing goes down.

On the client’s firewall I enabled the WIO log, but it does not give me info, is there a way to understand what is happening?
Another strange thing is that we have never noticed this problem, the client has always worked in the cloud, if it had happened previously we would have noticed.

Before reinstalling WIO and losing any debugging info I preferred to disable it and hear from you if you have an idea why this happens.

Giuseppe

2

So when you disable WIO, you no longer have the disconnects, is that correct?

When you say that Red and Green go down, is this based on the status of those nics shown via the ip command. Do you only have red and green networks or do you also have blue and/or orange. If you have blue and/or orange are those also shown as Down by the ip command or are they still Up.

If the red and green interfaces are going down then even if nothing shows in the wio logs, I would expect something to be showing in the main
/var/log/messages
file.

Nothing has been changed on WIO since 2023 and at that time it was just moving the various parts of wio to the standard build locations. Nothing in the actual code of wio was changed. The change of build location for the source code was done in Core Update 175.

The last changes to the wio code were done back in 2020 in Core Update 149.

There has to be something in the logs somewhere if the Network Interfaces are being brought down.

1 Like
3

:thinking:

@bonnietwin
How many pings does IPFire make to a client on the network?

I’m wondering if the client (customer) on the network, when it detects a ping from IPFire, blocks its connection.

4

wio does pings for a time period which is set in the wio configuration file. The default value if not changed is 1 second.

2 Likes
5

yes, if I disable WIO the disconnections do not occur

When you say that Red and Green go down, is this based on the status of those nics shown via the ip command. Do you only have red and green networks or do you also have blue and/or orange. If you have blue and/or orange are those also shown as Down by the ip command or are they still Up.

I only have red and green, yes when the problem happens the cards do not respond to pings.

If the red and green interfaces are going down then even if nothing shows in the wio logs, I would expect something to be showing in the main
/var/log/messages

immagine
immagine960Ă—229 4.9 KB

this is what the log says and the disconnection occurred

7

The problem occurs if a client in the WIO list is turned off.

In fact, if I delete the turned off client from the clients tested by wio, the disconnection error does not occur

8

There could be various reasons for pings not being responded too.

When you have the issue and the pings do not respond then on your IPFire system run the command

ip address show

This will show all of the network interfaces and will show if the state of them is UP or DOWN.

This is what I get for the red and green interfaces on my vm testbed which is also running wio.

2: red0: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 08:00:27:f6:6f:1e brd ff:ff:ff:ff:ff:ff
inet 192.168.26.200/24 brd 192.168.26.255 scope global dynamic noprefixroute red0
valid_lft 863107sec preferred_lft 755107sec
3: green0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 08:00:27:87:52:9b brd ff:ff:ff:ff:ff:ff
inet 192.168.200.254/24 scope global green0
valid_lft forever preferred_lft forever

You can see that the state of both of these is showing as UP (I have made them Bold).

I am running my vm testbed with one client on the green network defined in wio and turned on and another one defined in wio but turned off.

I will run it like this for an hour or so and periodically press the status sync button on wio and run pings to the red and green interfaces on the IPFire.

Based on the problem with your customer there should be 4 events over that hours period, so hopefully I can reproduce at least one event on my system because that will give me something to physically investigate.

1 Like
9

Have you changed the “Time interval for checking” setting in the WIO Config from the default 5 minutes to 15 minutes?

10

So I ran my test for one hour and never had any problem occur.

I then ran a ping script every minute on the green system and ran it for 1.5 hours. All ping commands worked for every minute for the 1,5 hours.

Also the Gateway graph was also continuous for the 1.5 hours so the red connection was also not interrupted.

So I have not been able to reproduce what you are describing.

This makes me think that your definition for that client has some error in it somewhere/somehow.

How is the IP set for this client. Is it via dynamic dhcp or do you have a fixed lease defined for it? If the latter is the IP used outside of the dynamic range specified on the dhcpcd WUI page?

1 Like