Comment empêcher un paquet UDP particulier de parvenir à Linphone ?
22 réponses
Geo Cherchetout
Bonjour,
Je pense avoir identifié la cause exacte de mes échecs répétés quand je
tente d'envoyer un fax à l'aide de Linphone dans le rôle de transmetteur.
Quand Linphone reçoit une requête INVITE décrivant une session T38, au lieu
de répondre par un message du genre 488 (not acceptable here), il répond OK
et c'est le début d'un dialogue de sourd qui ne prend fin que quand le
télécopieur de mon correspondant décide de raccrocher.
Je précise que ni ce télécopieur ni mon fax-modem ne connaissent le
protocole T38. C'est apparemment la passerelle entre OVH et Orange qui prend
l'initiative malencontreuse de me faire envoyer ce paquet pour une raison
que j'ignore.
Je voudrais donc voir ce qu'il se passerait si le paquet UDP fautif de
trouble était escamoté silencieusement avant de parvenir à Linphone.
Ce paquet est reconnaissable en ce qu'il comporte une fois la chaîne de
caractères t38 et plusieurs fois T38. Je suppose qu'iptables est l'outil
adéquat mais il serait absurde que je passe des jours à apprivoiser cette
usine à gaz si un aimable contributeur pouvait en une minute me donner la
recette. ;-) Merci d'avance à lui ou elle.
Ce paquet est reconnaissable en ce qu'il comporte une fois la chaîne de caractères t38 et plusieurs fois T38. Je suppose qu'iptables est l'outil adéquat mais il serait absurde que je passe des jours à apprivoiser cette usine à gaz si un aimable contributeur pouvait en une minute me donner la recette. ;-) Merci d'avance à lui ou elle.
Pour avoir une réponse, je pense qu'il faudrait donner plus d'informations.
Est-ce que le port udp est toujours le même? Qui initie cette connexion? Si ce n'est pas toi, ce doit être filtrable.
Peut-être que le résultat de la commande suivante peut donner des pistes :
-- Stéphane <http://pasdenom.info/fortune/?> électromécanicienne ici n'a ce mort celé -- Esposito-Farese, Gilles
Salut,
Geo Cherchetout a tapoté, le 13/12/2013 11:16:
Ce paquet est reconnaissable en ce qu'il comporte une fois la chaîne de
caractères t38 et plusieurs fois T38. Je suppose qu'iptables est l'outil
adéquat mais il serait absurde que je passe des jours à apprivoiser cette
usine à gaz si un aimable contributeur pouvait en une minute me donner la
recette. ;-) Merci d'avance à lui ou elle.
Pour avoir une réponse, je pense qu'il faudrait donner plus d'informations.
Est-ce que le port udp est toujours le même?
Qui initie cette connexion? Si ce n'est pas toi, ce doit être filtrable.
Peut-être que le résultat de la commande suivante peut donner des pistes :
Ce paquet est reconnaissable en ce qu'il comporte une fois la chaîne de caractères t38 et plusieurs fois T38. Je suppose qu'iptables est l'outil adéquat mais il serait absurde que je passe des jours à apprivoiser cette usine à gaz si un aimable contributeur pouvait en une minute me donner la recette. ;-) Merci d'avance à lui ou elle.
Pour avoir une réponse, je pense qu'il faudrait donner plus d'informations.
Est-ce que le port udp est toujours le même? Qui initie cette connexion? Si ce n'est pas toi, ce doit être filtrable.
Peut-être que le résultat de la commande suivante peut donner des pistes :
-- Stéphane <http://pasdenom.info/fortune/?> électromécanicienne ici n'a ce mort celé -- Esposito-Farese, Gilles
Geo Cherchetout
Le 13/12/2013 13:23, *yamo'* a écrit fort à propos :
Pour avoir une réponse, je pense qu'il faudrait donner plus d'informations.
Est-ce que le port udp est toujours le même?
Oui, les ports source (5060) et destination (5061) des paquets relatifs à la signalisation sont invariables ainsi que l'IP source (91.121.129.20) dès lors que j'utilise Linphone configuré par mes soins et le « sip provider » OVH, mais cela ne suffit pas pour caractériser le paquet indésirable parce que quelques paquets utiles ont déjà été reçus auparavant répondant à ces seuls critères.
Qui initie cette connexion? Si ce n'est pas toi, ce doit être filtrable.
La communication téléphonique est initiée par moi et semble devoir se dérouler normalement pendant quelques secondes jusqu'à la réception de cette requête incongrue. (À l'initiative, donc, de l'extrémité distante.) Pas sûr de comprendre la signification du mot connexion dans cette question...
Peut-être que le résultat de la commande suivante peut donner des pistes :
J'essaierai ça prochainement, merci. La suite en fin d'après-midi.
Le 13/12/2013 13:23, *yamo'* a écrit fort à propos :
Pour avoir une réponse, je pense qu'il faudrait donner plus
d'informations.
Est-ce que le port udp est toujours le même?
Oui, les ports source (5060) et destination (5061) des paquets relatifs à la
signalisation sont invariables ainsi que l'IP source (91.121.129.20) dès
lors que j'utilise Linphone configuré par mes soins et le « sip provider »
OVH, mais cela ne suffit pas pour caractériser le paquet indésirable parce
que quelques paquets utiles ont déjà été reçus auparavant répondant à ces
seuls critères.
Qui initie cette connexion? Si ce n'est pas toi, ce doit être filtrable.
La communication téléphonique est initiée par moi et semble devoir se
dérouler normalement pendant quelques secondes jusqu'à la réception de cette
requête incongrue. (À l'initiative, donc, de l'extrémité distante.)
Pas sûr de comprendre la signification du mot connexion dans cette question...
Peut-être que le résultat de la commande suivante peut donner des pistes
:
Le 13/12/2013 13:23, *yamo'* a écrit fort à propos :
Pour avoir une réponse, je pense qu'il faudrait donner plus d'informations.
Est-ce que le port udp est toujours le même?
Oui, les ports source (5060) et destination (5061) des paquets relatifs à la signalisation sont invariables ainsi que l'IP source (91.121.129.20) dès lors que j'utilise Linphone configuré par mes soins et le « sip provider » OVH, mais cela ne suffit pas pour caractériser le paquet indésirable parce que quelques paquets utiles ont déjà été reçus auparavant répondant à ces seuls critères.
Qui initie cette connexion? Si ce n'est pas toi, ce doit être filtrable.
La communication téléphonique est initiée par moi et semble devoir se dérouler normalement pendant quelques secondes jusqu'à la réception de cette requête incongrue. (À l'initiative, donc, de l'extrémité distante.) Pas sûr de comprendre la signification du mot connexion dans cette question...
Peut-être que le résultat de la commande suivante peut donner des pistes :
Pour Linphone, le port 7078 est dédié aux flux audio. Les captures que j'ai pu faire avec wireshark ne révèlent aucun échange passant par le port 7079, ou du moins je n'ai rien vu de tel. J'ai choisi le port 5061 comme port sip dans la configuration de linphone dans l'intention d'éviter les conflits avec l'ATA de mon modem-routeur qui utilise le 5060.
Le 13/12/2013 13:23, *yamo'* a écrit fort à propos :
Peut-être que le résultat de la commande suivante peut donner des pistes :
Pour Linphone, le port 7078 est dédié aux flux audio.
Les captures que j'ai pu faire avec wireshark ne révèlent aucun échange
passant par le port 7079, ou du moins je n'ai rien vu de tel.
J'ai choisi le port 5061 comme port sip dans la configuration de linphone
dans l'intention d'éviter les conflits avec l'ATA de mon modem-routeur qui
utilise le 5060.
Pour Linphone, le port 7078 est dédié aux flux audio. Les captures que j'ai pu faire avec wireshark ne révèlent aucun échange passant par le port 7079, ou du moins je n'ai rien vu de tel. J'ai choisi le port 5061 comme port sip dans la configuration de linphone dans l'intention d'éviter les conflits avec l'ATA de mon modem-routeur qui utilise le 5060.
Benoit Izac
Bonjour,
le 13/12/2013 à 11:16, Geo Cherchetout a écrit dans le message <l8emp3$tqr$ :
Je pense avoir identifié la cause exacte de mes échecs répétés quand je tente d'envoyer un fax à l'aide de Linphone dans le rôle de transmetteur. Quand Linphone reçoit une requête INVITE décrivant une session T38, au lieu de répondre par un message du genre 488 (not acceptable here), il répond OK et c'est le début d'un dialogue de sourd qui ne prend fin que quand le télécopieur de mon correspondant décide de raccrocher. Je précise que ni ce télécopieur ni mon fax-modem ne connaissent le protocole T38. C'est apparemment la passerelle entre OVH et Orange qui prend l'initiative malencontreuse de me faire envoyer ce paquet pour une raison que j'ignore.
Je voudrais donc voir ce qu'il se passerait si le paquet UDP fautif de trouble était escamoté silencieusement avant de parvenir à Linphone.
Ce paquet est reconnaissable en ce qu'il comporte une fois la chaîne de caractères t38 et plusieurs fois T38. Je suppose qu'iptables est l'outil adéquat mais il serait absurde que je passe des jours à apprivoiser cette usine à gaz si un aimable contributeur pouvait en une minute me donner la recette. ;-) Merci d'avance à lui ou elle.
Le patch string devrait convenir pour faire ton test : <http://www.netfilter.org/documentation/HOWTO/fr/netfilter-extensions-HOWTO-3.html#ss3.18>
Un petit modprobe xt_string avant ou recompiler avec CONFIG_NETFILTER_XT_MATCH_STRING.
Après, c'est peu être aussi rapide de dire à linphone (que je ne connais pas) de ne pas utiliser T38.
-- Benoit Izac
Bonjour,
le 13/12/2013 à 11:16, Geo Cherchetout a écrit dans le message
<l8emp3$tqr$1@obelix.gegeweb.org> :
Je pense avoir identifié la cause exacte de mes échecs répétés quand
je tente d'envoyer un fax à l'aide de Linphone dans le rôle de
transmetteur. Quand Linphone reçoit une requête INVITE décrivant une
session T38, au lieu de répondre par un message du genre 488 (not
acceptable here), il répond OK et c'est le début d'un dialogue de
sourd qui ne prend fin que quand le télécopieur de mon correspondant
décide de raccrocher.
Je précise que ni ce télécopieur ni mon fax-modem ne connaissent le
protocole T38. C'est apparemment la passerelle entre OVH et Orange qui
prend l'initiative malencontreuse de me faire envoyer ce paquet pour
une raison que j'ignore.
Je voudrais donc voir ce qu'il se passerait si le paquet UDP fautif de
trouble était escamoté silencieusement avant de parvenir à Linphone.
Ce paquet est reconnaissable en ce qu'il comporte une fois la chaîne
de caractères t38 et plusieurs fois T38. Je suppose qu'iptables est
l'outil adéquat mais il serait absurde que je passe des jours à
apprivoiser cette usine à gaz si un aimable contributeur pouvait en
une minute me donner la recette. ;-) Merci d'avance à lui ou elle.
Le patch string devrait convenir pour faire ton test :
<http://www.netfilter.org/documentation/HOWTO/fr/netfilter-extensions-HOWTO-3.html#ss3.18>
Un petit modprobe xt_string avant ou recompiler avec
CONFIG_NETFILTER_XT_MATCH_STRING.
Après, c'est peu être aussi rapide de dire à linphone (que je ne connais
pas) de ne pas utiliser T38.
le 13/12/2013 à 11:16, Geo Cherchetout a écrit dans le message <l8emp3$tqr$ :
Je pense avoir identifié la cause exacte de mes échecs répétés quand je tente d'envoyer un fax à l'aide de Linphone dans le rôle de transmetteur. Quand Linphone reçoit une requête INVITE décrivant une session T38, au lieu de répondre par un message du genre 488 (not acceptable here), il répond OK et c'est le début d'un dialogue de sourd qui ne prend fin que quand le télécopieur de mon correspondant décide de raccrocher. Je précise que ni ce télécopieur ni mon fax-modem ne connaissent le protocole T38. C'est apparemment la passerelle entre OVH et Orange qui prend l'initiative malencontreuse de me faire envoyer ce paquet pour une raison que j'ignore.
Je voudrais donc voir ce qu'il se passerait si le paquet UDP fautif de trouble était escamoté silencieusement avant de parvenir à Linphone.
Ce paquet est reconnaissable en ce qu'il comporte une fois la chaîne de caractères t38 et plusieurs fois T38. Je suppose qu'iptables est l'outil adéquat mais il serait absurde que je passe des jours à apprivoiser cette usine à gaz si un aimable contributeur pouvait en une minute me donner la recette. ;-) Merci d'avance à lui ou elle.
Le patch string devrait convenir pour faire ton test : <http://www.netfilter.org/documentation/HOWTO/fr/netfilter-extensions-HOWTO-3.html#ss3.18>
Un petit modprobe xt_string avant ou recompiler avec CONFIG_NETFILTER_XT_MATCH_STRING.
Après, c'est peu être aussi rapide de dire à linphone (que je ne connais pas) de ne pas utiliser T38.
-- Benoit Izac
Geo Cherchetout
Le 13/12/2013 19:05, *Benoit Izac* a écrit fort à propos :
Le patch string devrait convenir pour faire ton test : <http://www.netfilter.org/documentation/HOWTO/fr/netfilter-extensions-HOWTO-3.html#ss3.18>
Un petit modprobe xt_string avant ou recompiler avec CONFIG_NETFILTER_XT_MATCH_STRING.
Le module se charge bien à ma demande, voila un truc à ma portée que j'essaie dès demain. :-)
Après, c'est peu être aussi rapide de dire à linphone (que je ne connais pas) de ne pas utiliser T38.
Oui mais il faudrait modifier le code et j'en suis bien incapable. J'en ai parlé sur la liste de discussion des développeurs de Linphone mais sans aucun écho à ce jour. (Linphone ignore T38 et moi j'ignore pourquoi il accepte ce genre de requête.)
Le 13/12/2013 19:05, *Benoit Izac* a écrit fort à propos :
Le patch string devrait convenir pour faire ton test :
<http://www.netfilter.org/documentation/HOWTO/fr/netfilter-extensions-HOWTO-3.html#ss3.18>
Un petit modprobe xt_string avant ou recompiler avec
CONFIG_NETFILTER_XT_MATCH_STRING.
Le module se charge bien à ma demande, voila un truc à ma portée que
j'essaie dès demain. :-)
Après, c'est peu être aussi rapide de dire à linphone (que je ne connais
pas) de ne pas utiliser T38.
Oui mais il faudrait modifier le code et j'en suis bien incapable. J'en ai
parlé sur la liste de discussion des développeurs de Linphone mais sans
aucun écho à ce jour. (Linphone ignore T38 et moi j'ignore pourquoi il
accepte ce genre de requête.)
Le 13/12/2013 19:05, *Benoit Izac* a écrit fort à propos :
Le patch string devrait convenir pour faire ton test : <http://www.netfilter.org/documentation/HOWTO/fr/netfilter-extensions-HOWTO-3.html#ss3.18>
Un petit modprobe xt_string avant ou recompiler avec CONFIG_NETFILTER_XT_MATCH_STRING.
Le module se charge bien à ma demande, voila un truc à ma portée que j'essaie dès demain. :-)
Après, c'est peu être aussi rapide de dire à linphone (que je ne connais pas) de ne pas utiliser T38.
Oui mais il faudrait modifier le code et j'en suis bien incapable. J'en ai parlé sur la liste de discussion des développeurs de Linphone mais sans aucun écho à ce jour. (Linphone ignore T38 et moi j'ignore pourquoi il accepte ce genre de requête.)
Geo Cherchetout
Le 13/12/2013 19:05, *Benoit Izac* a écrit fort à propos :
Le patch string devrait convenir pour faire ton test : <http://www.netfilter.org/documentation/HOWTO/fr/netfilter-extensions-HOWTO-3.html#ss3.18>
# iptables -A INPUT -m string --string 't38' -j QUEUE iptables v1.4.17: string: option "--algo" must be specified
Try `iptables -h' or 'iptables --help' for more information.
# iptables -A INPUT -m string --string 't38' -j DROP iptables v1.4.17: string: option "--algo" must be specified
Try `iptables -h' or 'iptables --help' for more information.
# iptables -A INPUT -m string --string [!] 't38' -j DROP Bad argument `t38' Try `iptables -h' or 'iptables --help' for more information.
Qu'est-ce que je mets pour cette option --algo dont le manuel ne dit rien ?
Le 13/12/2013 19:05, *Benoit Izac* a écrit fort à propos :
Le patch string devrait convenir pour faire ton test :
<http://www.netfilter.org/documentation/HOWTO/fr/netfilter-extensions-HOWTO-3.html#ss3.18>
# iptables -A INPUT -m string --string 't38' -j QUEUE
iptables v1.4.17: string: option "--algo" must be specified
Try `iptables -h' or 'iptables --help' for more information.
# iptables -A INPUT -m string --string 't38' -j DROP
iptables v1.4.17: string: option "--algo" must be specified
Try `iptables -h' or 'iptables --help' for more information.
# iptables -A INPUT -m string --string [!] 't38' -j DROP
Bad argument `t38'
Try `iptables -h' or 'iptables --help' for more information.
Qu'est-ce que je mets pour cette option --algo dont le manuel ne dit rien ?
Bon, deux arguments sont possibles, bm et kmp et le premier est accepté :
# iptables -A INPUT -m string --string 't38' --algo bm -j DROP
# iptables --list Chain INPUT (policy ACCEPT) target prot opt source destination DROP all -- anywhere anywhere STRING match "t38" ALGO name bm TO 65535
Bon, deux arguments sont possibles, bm et kmp et le premier est accepté :
# iptables -A INPUT -m string --string 't38' --algo bm -j DROP
# iptables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP all -- anywhere anywhere STRING match "t38" ALGO name bm
TO 65535
Bon, deux arguments sont possibles, bm et kmp et le premier est accepté :
# iptables -A INPUT -m string --string 't38' --algo bm -j DROP
# iptables --list Chain INPUT (policy ACCEPT) target prot opt source destination DROP all -- anywhere anywhere STRING match "t38" ALGO name bm TO 65535
Le 13/12/2013 23:20, *Benoit Izac* a écrit fort à propos :
Tu cherches au mauvais endroit, les extensions sont documentées dans iptables-extensions(8) :
OK, merci.
Pascal Hambourg
Salut,
Geo Cherchetout a écrit :
# iptables -A INPUT -m string --string 't38' --algo bm -j DROP
C'est un peu large. Par exemple cette règle risque d'empêcher la réception de ce message en bloquant le segment qui contient 't38'. Il faudrait affiner en ajoutant le protocole UDP et les ports 5060:5061, voire l'adresse source de la passerelle SIP.
Salut,
Geo Cherchetout a écrit :
# iptables -A INPUT -m string --string 't38' --algo bm -j DROP
C'est un peu large. Par exemple cette règle risque d'empêcher la
réception de ce message en bloquant le segment qui contient 't38'.
Il faudrait affiner en ajoutant le protocole UDP et les ports 5060:5061,
voire l'adresse source de la passerelle SIP.
# iptables -A INPUT -m string --string 't38' --algo bm -j DROP
C'est un peu large. Par exemple cette règle risque d'empêcher la réception de ce message en bloquant le segment qui contient 't38'. Il faudrait affiner en ajoutant le protocole UDP et les ports 5060:5061, voire l'adresse source de la passerelle SIP.
