Hi. The Expire Time is not updating for the Established Internet Connections ESTABLISHED 119:59:59 . The other connections leave the log. Changed DHCP to 30 minutes as a test but still 120 minutes. In front of IPFire is a FritzBox with a Mobile Connection.
To apply the new DHCP lease time, you may need to flush the current DHCP table. In the Web User Interface, disable the DHCP server for the relevant zone (e.g., green), save the settings, then re-enable the DHCP server and save again. This should flush existing leases and enforce the new lease time for future connections.
1 Like
The expires time in the connection tracking page is nothing to do with the dhcp lease times on the dhcp server page.
2 Likes
You are absolutely correct. For the benefit of @smice-byte this is my summary of the issue.
The “Expire Time” for the established Internet connections in the connection tracking page is unrelated to the DHCP lease time settings.
-
Expire Time in Connection Tracking: This is the time after which a tracked connection will be removed from the connection tracking table if it remains inactive. This is a function of the firewall and is designed to manage active connections through the firewall.
-
DHCP Lease Time: This is the length of time that a DHCP server will lease an IP address to a client device. When the lease time expires, the client must renew the lease to continue using that IP address.
The two times serve different purposes and operate independently of each other. Flushing the DHCP lease table will not affect the expiration times seen in the connection tracking table.
OK. Thanks Adolf for clarifying the difference. What then, does the problem of static expiration time signify. Image shows five minutes after initiating contact and the expiration time is relatively frozen.
Expiration time in connection tracking is reset with each activity on this connection.
Otherwise an established connection would be deleted after the default ( 2 minutes ).
1 Like
OK Bernhard, but explain why the Timer doesn’t change - it is fixed at that 119.59:59!
Bear in mind that it is a browser screen that you are looking at so it is not a real time display getting continuously updated.
You need to refresh the browser or re-select the connections page and you will then get an updated screen which will have many changes on it.
I just selected the connections menu three time in sequence (probably 1 or 2 secs between refreshes) and the display of connections changed significantly between the three displays.
2 Likes
A deeper look into the sources shows, that the expiration time displayed is hours:minutes:seconds-
So 119:59:59 means approx. 5 days.
For a not so active connection the last value(s) should count down. A connection with traffic with a period < 1s should remain at this max(?).
Then the cgi page needs to be updated as it says Secs for the Expires column. That needs to be changed to something like H:M:S or h:m:s in place of the secs heading.
2 Likes
The cause of the Contact with the Forum was that previously the Expiration Time counted down like a normal count down timer and herewith it appears stopped. If that’s OK with the Developers then it is OK.
I think this depends on the kind of connection. If there is a high frequency of information exchange, the expiration timer is reset very often.
@bonnietwin , you are right. I suppose there was a change in readability of the timer. But the heading wasn’t adapted.
It is a problem. A Bug. Or trace of a Hack. Consider the quantity of data and the expiration is : upload/download 35M / 472M 119:59:59.
I will be changing the header to H:M:S when I can get the time to do it, including all the language versions of it.
However the time counting down like a normal timer, I don’t recall ever seeing that work like that for me.
Looking at the commit changes to the connections.cgi file in the git repo I have not found any change that would impact the display of the connections back to commits from 2015.
The changes I found were things like updating the SANS ISC url, fixing the connection list if there is no green interface present, use of safe system output function to get all available routes, …
so nothing related to the display of the page in the browser.
2 Likes
H:M:S - may not be right. That list would be way longer it it takes 120 hours to expire a connection.
Two minutes seems to sound more right… (just my opinion)
But I dont know why it would be:
seconds : 1/60 or a second (as a remainder) : and then another remainder
The code is definitely calculating hours, minutes and seconds and displaying those with a colon between the three.
The heading only prints secs currently.
1 Like
And that may be what is wrong.
Here is a small snippet of conntrack that might help. The time is epoch.
[root@ipfire ~]# conntrack -E -o timestamp -p udp --orig-port-dst 53 -e NEW,UPDATE
[1604112868.160083] [NEW] udp 17 30 src=192.168.60.147 dst=192.168.60.1 sport=52767 dport=53 [UNREPLIED] src=192.168.60.1 dst=192.168.60.147 sport=53 dport=52767
[1604112868.480392] [UPDATE] udp 17 30 src=192.168.60.147 dst=192.168.60.1 sport=52767 dport=53 src=192.168.60.1 dst=192.168.60.147 sport=53 dport=52767
[1604112869.365823] [NEW] udp 17 30 src=192.168.60.230 dst=192.168.60.1 sport=59822 dport=53 [UNREPLIED] src=192.168.60.1 dst=192.168.60.230 sport=53 dport=59822
[1604112869.365972] [UPDATE] udp 17 30 src=192.168.60.230 dst=192.168.60.1 sport=59822 dport=53 src=192.168.60.1 dst=192.168.60.230 sport=53 dport=59822
Here is the code from connections.cgi for the header label
434 <th style='text-align:center'>
435 $Lang::tr{'connection'}<br>$Lang::tr{'status'}
436 </th>
437 <th style='text-align:center'>
438 $Lang::tr{'expires'}<br>($Lang::tr{'seconds'})
439 </th>
This shows that it is writing the header as expires seconds, with the words being translated for each language.
Here is the code section that calls the time format for the ttl value
564 # Format TTL
565 $ttl = format_time($ttl);
The format_time function is defined as follows
674 sub format_time($) {
675 my $time = shift;
676
677 my $seconds = $time % 60;
678 my $minutes = $time / 60;
679
680 my $hours = 0;
681 if ($minutes >= 60) {
682 $hours = $minutes / 60;
683 $minutes %= 60;
684 }
685
686 return sprintf("%3d:%02d:%02d", $hours, $minutes, $seconds);
687 }
So the ttl value is provided in seconds and is then formatted into hours, minutes and seconds separated by colons.
Then this section prints the formatted ttl value
647 <td style='text-align:center'>$ttl</td>
I went back to Core Update 100, 7 years ago and the code is exactly the same so the heading has been seconds and the actual time shown in Hours:Mins:Secs at for the last 7 years, probably longer.
1 Like
I’ll take a look …
Also there must be a time based split. Display anything longer that 119:30:00 and display anything less than 02:00:00 (or something near those limits). ignore the rest.
EDIT:
Looks like the list comes from here:
and seconds is the fifth column (big seconds on top and little seconds on the bottom).
1 Like
Yes, you are correct. It would be good to change the label from Secs to HH:MM:SS
(Now I am curious why a connection could last 5 days.)
EDIT:
AND I am curious about the “split”
Here is where the info on the connections.cgi WebGUI page comes from:
cat /proc/net/nf_conntrack | sort -k 5,5 --numeric-sort --reverse
2 Likes