[fli4l] NA?==?utf-8?Q?T timeout für udp und tcp

[Erwin Lottermann]

Zitat: Christoph Schulz schrieb am Fr, 19 August 2016 15:40
----------------------------------------------------
> Hallo!
> 
> Am Thu, 18 Aug 2016 12:08:52 +0200 schrieb Erwin Lottermann:
> 
> > Schaut man sich die Log-Einträge von Thomas/News[1] an, dann
> > sieht es so
> > aus, als wenn der SIP-Conntrack-Helper das Timeout für
> > UDP-Verbindungen
> > von 180s auf 3600s erhöht.
> 
> So ist es. Aus include/linux/netfilter/nf_conntrack_sip.h:
> 
> #define SIP_TIMEOUT     3600
> 
> Die Beschreibung des Modul-Parameters lautet "timeout for the master
> SIP 
> session". 

D.h. das muss gar keine generelle Vergrößerung des Timeouts für alle
UDP-Verbindungen sein, sondern könnte ausschließlich für
SIP-Verbindungen gelten, so dass sich die Frage nach negativen
Auswirkungen für andere UDP-Verbindungen gar nicht stellt.

> Somit kannst du den SIP-Timeout-Wert als Modul-Parameter 
> angeben. Zum Testen könntest du über ein selbstgeschriebenes
> Skript /etc/
> rc.d/rc050.sip-timeout o.ä. den folgenden Eintrag an die /etc/
> modprobe.conf anhängen:
> 
>   options nf_conntrack_sip sip_timeout=600
> 
> Das würde den Timeout auf 600 Sekunden senken. Das Skript könnte
> etwa so 
> aussehen:
> 
>   #!/bin/sh
>   echo "options nf_conntrack_sip sip_timeout=600" >>
> /etc/modprobe.conf
> 

D.h. man kann das Timeout für die SIP-Verbindung nach Bedarf
einstellen.
z.B. wenn der SIP-Provider ein Reconnect-Intervall von mehr als 1h
vorgibt, würde es wahrscheinlich Sinn machen, den Timeout-Wert noch
größer einzustellen.

> Wenn du der C-Programmiersprache mächtig bist, solltest du dir den
> 
> Quelltext der Datei net/netfilter/nf_conntrack_sip.c anschauen. Dort
> 
> findest du vermutlich alle Informationen, die du brauchst.
> Interessant 
> wären vermutlich:
> 
> /* Parse a REGISTER request and create a permanent expectation for 
> incoming
>  * signalling connections. The expectation is marked inactive and is
> 
> activated
>  * when receiving a response indicating success from the registrar.
>  */
> static int process_register_request(struct sk_buff *skb, unsigned
> int 
> protoff,
>                                     unsigned int dataoff,
>                                     const char **dptr, unsigned int
> 
> *datalen,
>                                     unsigned int cseq)
> 
> und
> 
> static int process_register_response(struct sk_buff *skb, unsigned
> int 
> protoff,
>                                      unsigned int dataoff,
>                                      const char **dptr, unsigned int
> 
> *datalen,
>                                      unsigned int cseq, unsigned int
> code)
> 

Zum Verstehen von C-Quelltext reicht es bei mir nicht.
Für das Verständnis wird man aber auch die SIP-Spezifikationen
verstanden haben müssen.
In denen habe ich ein wenig gelesen und danach machen deine Hinweise
schon Sinn.

Der SIP-Conntrack-Helper soll vermutlich nur die SIP-Verbindungen am
Leben halten (Timeout erhöhen), die bei einer erfolgreichen
SIP-Registrierung entstanden sind. Dazu wird zuerst die ausgehende
Request-Message geparst, um zu sehen, ob es sich um eine
Register-Message handelt und die Call-ID zu bestimmen, damit die
eingehende Message zugeordnet werden kann.
Dann wird die eingehende Antwortmessage des SIP-Servers geparst, um
herauszufinden, ob es eine Register-Response ist und die Registrierung
erfolgreich war.

> > Kann jemand sagen, ob es Szenarien gibt, bei denen ein so
> > großes Timeout
> > für UDP-Verbindungen störend sein kann?
> 
> Ich wüsste nicht, warum das so sein sollte. Wenn die
> Internet-Verbindung 
> neu aufgebaut wird, wird die Conntrack-Tabelle sowieso geleert.
>

Wie schon oben gesagt: Wenn es nur die SIP-Verbindungen betrifft, dann
ist die Frage wohl hinfällig. 

Vielen Dank
Erwin