10 Jun
2015
10 Jun
'15
10:22 a.m.
-------- Forwarded Message --------
Subject: Re: [qmp-dev] TunOutTimeout to zero by default
Date: Wed, 10 Jun 2015 12:17:32 +0200
From: Pau <pau(a)dabax.net>
Reply-To: quick mesh project development mailing list <qmp-dev(a)mail.qmp.cat>
To: qmp-dev(a)mail.qmp.cat
But still, as far as I know, it is just a cosmetic thing. There will be
a lot of network interfaces but at least the TCP connections will
persist over the time.
I don't like the idea of saying "in qMp the maximum persistent time is
1h", after that your connections will be reseted :P
What would fix the problem is to create the tunnel On demand but make it
persistent forever. Thus the nodes will only have the tunnels created
with the nodes which have been contacted at least one time (until the
next reboot).
What do you think, can you implement this option?
Thanks.
On 10/06/15 11:29, Axel Neumann wrote:
--
./p4u
11 Jun
11 Jun
6:39 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 10/06/15 07:22, Pau wrote:
ugh :(
fetching stats through snmp with observium will be affected too
(maaaany interfaces)
I don't like the idea of saying "in qMp the maximum persistent time
is 1h", after that your connections will be reseted :P
i'd be fine if the maximum persisten time is 24hs.
in deltalibre i set the RA prefix time to 24hs (which makes
networkmanager reconnect to renew the privacy address, every 24hs) and
never bothered me (i.e. i never need a persistent connection for 24hs)
previously, prefix lifetime was set to 1hour, which made network
manager reconnect every 20 mins, and it was exasperating :(
i'm mixing concepts here (RA prefix lifetime has nothing to do with
bmx6 or tunnels) but i'm using it as a real life experience of an
acceptable value for breaking persistent connections
that could be nice, but i think a 24h timeout would suffice.
the question... is that a valid value for current tunOutTimeout????
it doesn't seem so..
root@berni:~# bmx6 -c --version
BMX6-0.1-alpha comPatibility=16 revision=8b0585e84ca8a0110bd4587e...
root@berni:~# bmx6 -c tunOutTimeout 3600000
ERROR : --tunOutTimeout value 3600000 is invalid! Must be 0 <= <value>
<= 100000 !
ERROR : --tunOutTimeout 3600000 # Failed ! ( diff:0 ad:0 val:0
min:0 max:100000 def:60000 OPT_PATCH 2 1 7 )
ERROR apply_stream_opts: invalid argument: 3600000
digging the code:
hna.h:#define MAX_TUN_OUT_TO REGISTER_TASK_TIMEOUT_MAX
and that in turn is defined in:
schedule.h:#define REGISTER_TASK_TIMEOUT_MAX XMIN( 100000, TIME_MAX>>2)
so that max 100 seconds is hardcoded, and would need to be patched.
axel: does 86400000 (24hs) sound like an unreasonable value for that
MAX_TUN_OUT_TO?
i imagine redefining REGISTER_TASK_TIMEOUT_MAX would have extra side
effects, so i'd just do this:
diff --git a/hna.h b/hna.h
index 91ddf1b..11048b4 100644
- --- a/hna.h
+++ b/hna.h
@@ -71,7 +71,7 @@ extern struct avl_tree tun_in_tree;
#define ARG_TUN_OUT_TIMEOUT "tunOutTimeout"
#define MIN_TUN_OUT_TO 0
- -#define MAX_TUN_OUT_TO REGISTER_TASK_TIMEOUT_MAX
+#define MAX_TUN_OUT_TO 86400000
#define DEF_TUN_OUT_TO 60000
#define DEF_TUN_OUT_PERSIST 1
axel: any thoughts or concerns?
cheers!
diff --git a/packages/qmp-system/files/etc/qmp/qmp_functions.sh
7:20 p.m.
Sorry Gui but your life experience does not convince me. Of course it
may be accepted by an individual, but I think this artificial limitation
is not a good characteristic for a network focused operating system. I
can image some use cases which requires more than 24h persistent
connection, such as a FTP/telnet connection or a live video streaming of
a web cam. In any case, if there is some possible solution I would
prefer to apply it instead of accept this issue by default.
On 11/06/15 20:39, Gui Iribarren wrote:
--
./p4u
16 Jun
16 Jun
2:07 p.m.
It seems that it has been fixed, quote from Axel:
The below two commits ([1][2]) address the problem more or less as
suggested:
Only if a tunnel has not been actively used (for sending a packets) in
last tunOutTimeout ms it is destroyed.
openwrt-routing bmx6 packages of master, for-14.07, and 15.07 branches
got already updated.
[1]
https://github.com/axn/bmx6/commit/8f26909e8808ed7fab0359afc15a3e44563fbd40
[2]
https://github.com/axn/bmx6/commit/a9427a7858a683ce253a32ec4d70c067d04e2123
On 11/06/15 21:20, Pau wrote:
--
./p4u
3714
days inactive
3720
days old
3 comments
2 participants
participants (2)
-
Gui Iribarren -
Pau