Fwd: Re: [qmp-dev] TunOutTimeout to zero by default

List overview All Threads
Download

newer

older

Fwd: [Interop-dev] Battlemesh...

Fwd: Re: [qmp-dev] TunOutTimeout...

Pau

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:

...

I would not do that!!! tunOutTimeout=0 means that all possible tunnels are activated by default! For a large qmp cloud with each node offering its own ipv4 and ipv6 tunnel endpoints this would be a massive amount of always activated tunnels !!! Something very upgly when looking at those nodes interface list. A tunOutTimeout != 0 means they are only activated on demand and the list of active tunnel interfaces remains usually small. A compromise could be to configure a large value (eg tunOutTimeout = 3600000) which means that tunnels are setup on demand but temporary cut down only every hour. /axel On 10.06.2015 10:42, Pau wrote:

Hello. Following the thread discussion [1], where the user reports problems with streaming cuts, I would propose to add the option tunOutTimeout=0 by default in the qMp system. The advantages of this timeout are just cosmetics (as far as I know). So I would disable it for the moment to avoid persistent connection problems as reported by that user and some others. Find the patch at the end of this mail and feel free to apply it if agreed. [1] https://mail.dabax.net/pipermail/qmp-users/2015-June/000802.html diff --git a/packages/qmp-system/files/etc/qmp/qmp_functions.sh b/packages/qmp-system/files/etc/qmp/qmp_functions.sh index eba5887..450a2a7 100755 --- a/packages/qmp-system/files/etc/qmp/qmp_functions.sh +++ b/packages/qmp-system/files/etc/qmp/qmp_functions.sh @@ -727,6 +727,7 @@ qmp_configure_bmx6() { qmp_configure_prepare $conf uci set $conf.general="bmx6" + uci set $conf.general.tunOutTimeout=0 uci set $conf.bmx6_config_plugin=plugin uci set $conf.bmx6_config_plugin.plugin=bmx6_config.so _______________________________________________ qmp-dev mailing list qmp-dev(a)mail.qmp.cat https://mail.dabax.net/cgi-bin/mailman/listinfo/qmp-dev

_______________________________________________ qmp-dev mailing list qmp-dev(a)mail.qmp.cat https://mail.dabax.net/cgi-bin/mailman/listinfo/qmp-dev

-- ./p4u

Attachments:

AttachedMessagePart.txt (text/plain — 146 bytes)
signature.asc (application/pgp-signature — 473 bytes)

Show replies by date

Gui Iribarren

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

...

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?

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!

...

Thanks. On 10/06/15 11:29, Axel Neumann wrote: > I would not do that!!! > > tunOutTimeout=0 means that all possible tunnels are activated by > default! > > For a large qmp cloud with each node offering its own ipv4 and > ipv6 tunnel endpoints this would be a massive amount of always > activated tunnels !!! Something very upgly when looking at those > nodes interface list. > > A tunOutTimeout != 0 means they are only activated on demand and > the list of active tunnel interfaces remains usually small. > > A compromise could be to configure a large value (eg > tunOutTimeout = 3600000) which means that tunnels are setup on > demand but temporary cut down only every hour. > > > /axel > > On 10.06.2015 10:42, Pau wrote: >> Hello. Following the thread discussion [1], where the user >> reports problems with streaming cuts, I would propose to add >> the option tunOutTimeout=0 by default in the qMp system. The >> advantages of this timeout are just cosmetics (as far as I >> know). So I would disable it for the moment to avoid persistent >> connection problems as reported by that user and some others. >> >> Find the patch at the end of this mail and feel free to apply >> it if agreed. >> >> [1] >> https://mail.dabax.net/pipermail/qmp-users/2015-June/000802.html >> >> >>

diff --git a/packages/qmp-system/files/etc/qmp/qmp_functions.sh

...

b/packages/qmp-system/files/etc/qmp/qmp_functions.sh index eba5887..450a2a7 100755 --- a/packages/qmp-system/files/etc/qmp/qmp_functions.sh +++ b/packages/qmp-system/files/etc/qmp/qmp_functions.sh @@ -727,6 +727,7 @@ qmp_configure_bmx6() { qmp_configure_prepare $conf uci set $conf.general="bmx6" + uci set $conf.general.tunOutTimeout=0 uci set $conf.bmx6_config_plugin=plugin uci set $conf.bmx6_config_plugin.plugin=bmx6_config.so _______________________________________________ qmp-dev mailing list qmp-dev(a)mail.qmp.cat https://mail.dabax.net/cgi-bin/mailman/listinfo/qmp-dev

_______________________________________________ qmp-dev mailing list qmp-dev(a)mail.qmp.cat https://mail.dabax.net/cgi-bin/mailman/listinfo/qmp-dev

_______________________________________________ Dev mailing list Dev(a)lists.libre-mesh.org https://lists.libre-mesh.org/mailman/listinfo/dev

...PGP SIGNATURE...

-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBCgAGBQJVedXgAAoJEIJqNBvBfxrIwmgP/1GJLI827PD+O/IqgrE2dCfJ ZK0zLJkofDZMSOzvV2otZXC8Cm0VcWb8l/eWyEJonm064xuwXv40YblI/71zzXPo GsbjNKFolJ0RKdrJ8ydRUWSIPL+mnrba8LsTeIWBgQwQVtxoL6z4EfIFfbQpt1em 6xxjfvCd0yx2j5bsGE9WKX7RPHXbLkSnLk6F+oYLemmHd1tpk9rve8K+k74HDi4A EnCKqYajoos54LKnSdjc154QXlhI3iAQjzI5JM0jGFt+5NJ8nN1PyPJ1CJFWaywu rfKXQowvCchvflkvjejRL/k6lyrCuM18KoBhkUnZR7bbkmyNnuoSpmUKwtla9zh8 tjtQwaGtYA0ECNTfbHgdgo0pl7rbdTzOOdPGFNBEHPhiRrYUfmo23Sqf1VNFhEHU SqifZpCOpcKVcOAoHGP5i41PFqxBLsNyRCdXgVhmgAFNcn/neJgRHGfg+yu0Bc52 fY/9UH72rVDHmmGLtCTk6IenA4cwJerQ+Tw7UGQRYv9leYGvo7zuzLQWiYC/2jBh DYc1BRYhQegnfgJouDYK9qd2ayYSa5/8nUKCGjlQYuUrh4sY/Jcnm+khmnz0GDye nEERrhJzA/qTMCrMcJ2a3jHfdQwC2UYulysDWyw67x8V4peR3cI7/UK5HbiXp39O D7U888ua4c7pOn8ZMPg6 =Bxvf -----END PGP SIGNATURE-----

Pau

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:

...

On 10/06/15 07:22, Pau wrote:

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.

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

What do you think, can you implement this option?

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!

Thanks.

On 10/06/15 11:29, Axel Neumann wrote: > I would not do that!!! > > tunOutTimeout=0 means that all possible tunnels are activated by > default! > > For a large qmp cloud with each node offering its own ipv4 and > ipv6 tunnel endpoints this would be a massive amount of always > activated tunnels !!! Something very upgly when looking at those > nodes interface list. > > A tunOutTimeout != 0 means they are only activated on demand and > the list of active tunnel interfaces remains usually small. > > A compromise could be to configure a large value (eg > tunOutTimeout = 3600000) which means that tunnels are setup on > demand but temporary cut down only every hour. > > > /axel > > On 10.06.2015 10:42, Pau wrote: >> Hello. Following the thread discussion [1], where the user >> reports problems with streaming cuts, I would propose to add >> the option tunOutTimeout=0 by default in the qMp system. The >> advantages of this timeout are just cosmetics (as far as I >> know). So I would disable it for the moment to avoid persistent >> connection problems as reported by that user and some others. >> >> Find the patch at the end of this mail and feel free to apply >> it if agreed. >> >> [1] >> https://mail.dabax.net/pipermail/qmp-users/2015-June/000802.html >> >> >>

diff --git a/packages/qmp-system/files/etc/qmp/qmp_functions.sh

>> b/packages/qmp-system/files/etc/qmp/qmp_functions.sh index >> eba5887..450a2a7 100755 --- >> a/packages/qmp-system/files/etc/qmp/qmp_functions.sh +++ >> b/packages/qmp-system/files/etc/qmp/qmp_functions.sh @@ -727,6 >> +727,7 @@ qmp_configure_bmx6() { >> >> qmp_configure_prepare $conf uci set $conf.general="bmx6" + uci >> set $conf.general.tunOutTimeout=0 uci set >> $conf.bmx6_config_plugin=plugin uci set >> $conf.bmx6_config_plugin.plugin=bmx6_config.so >> >> >> >> >> >> >> _______________________________________________ qmp-dev >> mailing list qmp-dev(a)mail.qmp.cat >> https://mail.dabax.net/cgi-bin/mailman/listinfo/qmp-dev >> > > _______________________________________________ qmp-dev mailing > list qmp-dev(a)mail.qmp.cat > https://mail.dabax.net/cgi-bin/mailman/listinfo/qmp-dev >

_______________________________________________ Dev mailing list Dev(a)lists.libre-mesh.org https://lists.libre-mesh.org/mailman/listinfo/dev

-- ./p4u

Pau

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:

...

On 10/06/15 07:22, Pau wrote:

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.

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

What do you think, can you implement this option?

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!

Thanks.

diff --git a/packages/qmp-system/files/etc/qmp/qmp_functions.sh

_______________________________________________ Dev mailing list Dev(a)lists.libre-mesh.org https://lists.libre-mesh.org/mailman/listinfo/dev

-- ./p4u

3477

days inactive

3483

days old

lime-dev@lists.libremesh.org

Manage subscription

3 comments

2 participants

tags (0)

participants (2)

Gui Iribarren
Pau