Est-ce qu'il est possible de modifier la vitesse de retransmission des
paquets (en particulier SYN) par le noyau Linux ? Par systcl ou par
une incantation quelconque au niveau de chaque socket.
En cas de perte de paquets, le pingouin réessaie au bout de 3 s,
j'aimerais bien que ça descende 1.
En gros, je voudrais que mon scanner de ports simpliste ne perde pas
un temps fou face à un BSD qui limite le nombre de RST renvoyés chaque
seconde.
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Vincent Bernat
OoO Pendant le temps de midi du mardi 02 août 2005, vers 12:22, Michel Arboi disait:
Est-ce qu'il est possible de modifier la vitesse de retransmission des paquets (en particulier SYN) par le noyau Linux ? Par systcl ou par une incantation quelconque au niveau de chaque socket.
sysctl -a | grep tcp te donne un certain nombre de variables qui pourraient correspondre : net.ipv4.tcp_retries2 = 15 net.ipv4.tcp_retries1 = 3 net.ipv4.tcp_max_syn_backlog = 1024 -- BOFH excuse #73: Daemons did it
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
OoO Pendant le temps de midi du mardi 02 août 2005, vers 12:22, Michel
Arboi <arboi@alussinan.org> disait:
Est-ce qu'il est possible de modifier la vitesse de retransmission des
paquets (en particulier SYN) par le noyau Linux ? Par systcl ou par
une incantation quelconque au niveau de chaque socket.
sysctl -a | grep tcp te donne un certain nombre de variables qui
pourraient correspondre :
net.ipv4.tcp_retries2 = 15
net.ipv4.tcp_retries1 = 3
net.ipv4.tcp_max_syn_backlog = 1024
--
BOFH excuse #73:
Daemons did it
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
OoO Pendant le temps de midi du mardi 02 août 2005, vers 12:22, Michel Arboi disait:
Est-ce qu'il est possible de modifier la vitesse de retransmission des paquets (en particulier SYN) par le noyau Linux ? Par systcl ou par une incantation quelconque au niveau de chaque socket.
sysctl -a | grep tcp te donne un certain nombre de variables qui pourraient correspondre : net.ipv4.tcp_retries2 = 15 net.ipv4.tcp_retries1 = 3 net.ipv4.tcp_max_syn_backlog = 1024 -- BOFH excuse #73: Daemons did it
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Michel Arboi
On Sat Aug 06 2005 at 09:54, Vincent Bernat wrote:
sysctl -a | grep tcp te donne un certain nombre de variables qui pourraient correspondre :
D'après "man 7 tcp", aucune ne me va.
net.ipv4.tcp_retries2 = 15
Nombre maxi de retransmission sur une connexion établie, 15 donne 13 à 30 minutes de timeout.
net.ipv4.tcp_retries1 = 3
La même chose mais pas tout à fait. Le man n'est pas très clair. Si j'ai bien compris, après 3 retransmissions "normales", le système tente de mettre à jour les routes.
net.ipv4.tcp_max_syn_backlog = 1024
C'est le nombre maxi de connexions en cours d'ouverture, mais du côté "serveur".
****
La solution adopté par namp -sT pour faire ce que je veux consister à gérer le timeout "en userland", et à fermer puis rouvrir les sockets. Mais je préfèrerais laisser faire le noyau, pour des raisons plus philosophiques que techniques ; je me dis que si le noyau ne sait pas faire ce que je veux pour un port scan, la suite des événements va mal se passer.
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
On Sat Aug 06 2005 at 09:54, Vincent Bernat wrote:
sysctl -a | grep tcp te donne un certain nombre de variables qui
pourraient correspondre :
D'après "man 7 tcp", aucune ne me va.
net.ipv4.tcp_retries2 = 15
Nombre maxi de retransmission sur une connexion établie, 15 donne 13 à
30 minutes de timeout.
net.ipv4.tcp_retries1 = 3
La même chose mais pas tout à fait. Le man n'est pas très clair. Si
j'ai bien compris, après 3 retransmissions "normales", le système
tente de mettre à jour les routes.
net.ipv4.tcp_max_syn_backlog = 1024
C'est le nombre maxi de connexions en cours d'ouverture, mais du côté
"serveur".
****
La solution adopté par namp -sT pour faire ce que je veux consister à
gérer le timeout "en userland", et à fermer puis rouvrir les sockets.
Mais je préfèrerais laisser faire le noyau, pour des raisons plus
philosophiques que techniques ; je me dis que si le noyau ne sait pas
faire ce que je veux pour un port scan, la suite des événements va mal
se passer.
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
On Sat Aug 06 2005 at 09:54, Vincent Bernat wrote:
sysctl -a | grep tcp te donne un certain nombre de variables qui pourraient correspondre :
D'après "man 7 tcp", aucune ne me va.
net.ipv4.tcp_retries2 = 15
Nombre maxi de retransmission sur une connexion établie, 15 donne 13 à 30 minutes de timeout.
net.ipv4.tcp_retries1 = 3
La même chose mais pas tout à fait. Le man n'est pas très clair. Si j'ai bien compris, après 3 retransmissions "normales", le système tente de mettre à jour les routes.
net.ipv4.tcp_max_syn_backlog = 1024
C'est le nombre maxi de connexions en cours d'ouverture, mais du côté "serveur".
****
La solution adopté par namp -sT pour faire ce que je veux consister à gérer le timeout "en userland", et à fermer puis rouvrir les sockets. Mais je préfèrerais laisser faire le noyau, pour des raisons plus philosophiques que techniques ; je me dis que si le noyau ne sait pas faire ce que je veux pour un port scan, la suite des événements va mal se passer.
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Kevin Denis
Le 02-08-2005, Michel Arboi a écrit :
Est-ce qu'il est possible de modifier la vitesse de retransmission des paquets (en particulier SYN) par le noyau Linux ? Par systcl ou par une incantation quelconque au niveau de chaque socket.
Par sysctl, amha non. Sinon, chercher RTT et RTO dans les sources du noyau, vers /usr/src/linux/net/ipv4/ genre dans tcp_timer.c * If synack was not acknowledged for 3 seconds, it means * one of the following things: synack was lost, ack was lost, * rtt is high or nobody planned to ack (i.e. synflood).
mais surtout dans /usr/src/linux/include/net/tcp.h #define TCP_RTO_MAX ((unsigned)(120*HZ)) #define TCP_RTO_MIN ((unsigned)(HZ/5)) #define TCP_TIMEOUT_INIT ((unsigned)(3*HZ)) /* RFC 1122 initial RTO value */
Et le HZ est egal a 1s par defaut.
En cas de perte de paquets, le pingouin réessaie au bout de 3 s, j'aimerais bien que ça descende 1.
recompiler?
En gros, je voudrais que mon scanner de ports simpliste ne perde pas un temps fou face à un BSD qui limite le nombre de RST renvoyés chaque seconde.
Je ne comprends pas. Soit un scanner simpliste #! /bin/bash for port in `seq 22 30` do telnet 127.0.0.1 $port & done
J'ai bien une rafale de 8 SYN (puis un arret de 3s, puis 8 autres SYN, puis 6s, etc..) -- Kevin
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Le 02-08-2005, Michel Arboi <arboi@alussinan.org> a écrit :
Est-ce qu'il est possible de modifier la vitesse de retransmission des
paquets (en particulier SYN) par le noyau Linux ? Par systcl ou par
une incantation quelconque au niveau de chaque socket.
Par sysctl, amha non.
Sinon, chercher RTT et RTO dans les sources du noyau, vers
/usr/src/linux/net/ipv4/
genre dans tcp_timer.c
* If synack was not acknowledged for 3 seconds, it means
* one of the following things: synack was lost, ack was lost,
* rtt is high or nobody planned to ack (i.e. synflood).
mais surtout dans
/usr/src/linux/include/net/tcp.h
#define TCP_RTO_MAX ((unsigned)(120*HZ))
#define TCP_RTO_MIN ((unsigned)(HZ/5))
#define TCP_TIMEOUT_INIT ((unsigned)(3*HZ)) /* RFC 1122 initial RTO value */
Et le HZ est egal a 1s par defaut.
En cas de perte de paquets, le pingouin réessaie au bout de 3 s,
j'aimerais bien que ça descende 1.
recompiler?
En gros, je voudrais que mon scanner de ports simpliste ne perde pas
un temps fou face à un BSD qui limite le nombre de RST renvoyés chaque
seconde.
Je ne comprends pas.
Soit un scanner simpliste
#! /bin/bash
for port in `seq 22 30`
do
telnet 127.0.0.1 $port &
done
J'ai bien une rafale de 8 SYN (puis un arret de 3s, puis 8 autres SYN,
puis 6s, etc..)
--
Kevin
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Est-ce qu'il est possible de modifier la vitesse de retransmission des paquets (en particulier SYN) par le noyau Linux ? Par systcl ou par une incantation quelconque au niveau de chaque socket.
Par sysctl, amha non. Sinon, chercher RTT et RTO dans les sources du noyau, vers /usr/src/linux/net/ipv4/ genre dans tcp_timer.c * If synack was not acknowledged for 3 seconds, it means * one of the following things: synack was lost, ack was lost, * rtt is high or nobody planned to ack (i.e. synflood).
mais surtout dans /usr/src/linux/include/net/tcp.h #define TCP_RTO_MAX ((unsigned)(120*HZ)) #define TCP_RTO_MIN ((unsigned)(HZ/5)) #define TCP_TIMEOUT_INIT ((unsigned)(3*HZ)) /* RFC 1122 initial RTO value */
Et le HZ est egal a 1s par defaut.
En cas de perte de paquets, le pingouin réessaie au bout de 3 s, j'aimerais bien que ça descende 1.
recompiler?
En gros, je voudrais que mon scanner de ports simpliste ne perde pas un temps fou face à un BSD qui limite le nombre de RST renvoyés chaque seconde.
Je ne comprends pas. Soit un scanner simpliste #! /bin/bash for port in `seq 22 30` do telnet 127.0.0.1 $port & done
J'ai bien une rafale de 8 SYN (puis un arret de 3s, puis 8 autres SYN, puis 6s, etc..) -- Kevin
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Kevin Denis
Le 02-08-2005, Michel Arboi a écrit :
Est-ce qu'il est possible de modifier la vitesse de retransmission des paquets (en particulier SYN) par le noyau Linux ? Par systcl ou par une incantation quelconque au niveau de chaque socket.
En cas de perte de paquets, le pingouin réessaie au bout de 3 s,
puis 6, puis 12, puis le double, etc.. (le max depend du tcp_syn_retries et d'une autre valeur qui est 120s (de memoire)). Mais c'est normal, c'est adaptatif (enfin je pense ne rien vous apprendre).
j'aimerais bien que ça descende 1.
Je ne suis pas sur que ce soit possible par un sysctl: le tcp_timer.c m'indique: /* Normally all the openreqs are young and become mature * (i.e. converted to established socket) for first timeout. * If synack was not acknowledged for 3 seconds, it means * one of the following things: synack was lost, ack was lost, * rtt is high or nobody planned to ack (i.e. synflood).
Le "3 seconds" me fait penser que c'est code en dur.
Et le /usr/src/linux/include/net/tcp.h indique: #define TCP_RTO_MAX ((unsigned)(120*HZ)) #define TCP_RTO_MIN ((unsigned)(HZ/5)) #define TCP_TIMEOUT_INIT ((unsigned)(3*HZ)) /* RFC 1122 initial RTO value */
Et par defaut, le timer HZ est de 1000ms (en tout ca dans mon asm/param.h). Donc on a bien 3s comme delai de retransmission. Je ne sais pas si linux peut modifier son timer a la volee (c'est pas dans FreeBSD qu'on definit au boot le HZ=.., ou je me trompe?).
En gros, je voudrais que mon scanner de ports simpliste ne perde pas un temps fou face à un BSD qui limite le nombre de RST renvoyés chaque seconde.
Je ne comprends pas trop (?). Soit un scanner a la con: :~$ cat scanalakon #! /bin/bash for port in `seq 22 30` do telnet 127.0.0.1 $port & done
Un tcpdump me montre bien une rafale de SYN envoyes en quelques centiemes de secondes. Pourquoi attendre un retry? -- Kevin
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Le 02-08-2005, Michel Arboi <arboi@alussinan.org> a écrit :
Est-ce qu'il est possible de modifier la vitesse de retransmission des
paquets (en particulier SYN) par le noyau Linux ? Par systcl ou par
une incantation quelconque au niveau de chaque socket.
En cas de perte de paquets, le pingouin réessaie au bout de 3 s,
puis 6, puis 12, puis le double, etc.. (le max depend du tcp_syn_retries et
d'une autre valeur qui est 120s (de memoire)).
Mais c'est normal, c'est adaptatif (enfin je pense ne rien vous apprendre).
j'aimerais bien que ça descende 1.
Je ne suis pas sur que ce soit possible par un sysctl:
le tcp_timer.c m'indique:
/* Normally all the openreqs are young and become mature
* (i.e. converted to established socket) for first timeout.
* If synack was not acknowledged for 3 seconds, it means
* one of the following things: synack was lost, ack was lost,
* rtt is high or nobody planned to ack (i.e. synflood).
Le "3 seconds" me fait penser que c'est code en dur.
Et le /usr/src/linux/include/net/tcp.h indique:
#define TCP_RTO_MAX ((unsigned)(120*HZ))
#define TCP_RTO_MIN ((unsigned)(HZ/5))
#define TCP_TIMEOUT_INIT ((unsigned)(3*HZ)) /* RFC 1122 initial RTO value */
Et par defaut, le timer HZ est de 1000ms (en tout ca dans mon asm/param.h).
Donc on a bien 3s comme delai de retransmission. Je ne sais pas si linux
peut modifier son timer a la volee (c'est pas dans FreeBSD qu'on definit au
boot le HZ=.., ou je me trompe?).
En gros, je voudrais que mon scanner de ports simpliste ne perde pas
un temps fou face à un BSD qui limite le nombre de RST renvoyés chaque
seconde.
Je ne comprends pas trop (?). Soit un scanner a la con:
kevin@zipslack:~$ cat scanalakon
#! /bin/bash
for port in `seq 22 30`
do
telnet 127.0.0.1 $port &
done
Un tcpdump me montre bien une rafale de SYN envoyes en quelques centiemes
de secondes. Pourquoi attendre un retry?
--
Kevin
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Est-ce qu'il est possible de modifier la vitesse de retransmission des paquets (en particulier SYN) par le noyau Linux ? Par systcl ou par une incantation quelconque au niveau de chaque socket.
En cas de perte de paquets, le pingouin réessaie au bout de 3 s,
puis 6, puis 12, puis le double, etc.. (le max depend du tcp_syn_retries et d'une autre valeur qui est 120s (de memoire)). Mais c'est normal, c'est adaptatif (enfin je pense ne rien vous apprendre).
j'aimerais bien que ça descende 1.
Je ne suis pas sur que ce soit possible par un sysctl: le tcp_timer.c m'indique: /* Normally all the openreqs are young and become mature * (i.e. converted to established socket) for first timeout. * If synack was not acknowledged for 3 seconds, it means * one of the following things: synack was lost, ack was lost, * rtt is high or nobody planned to ack (i.e. synflood).
Le "3 seconds" me fait penser que c'est code en dur.
Et le /usr/src/linux/include/net/tcp.h indique: #define TCP_RTO_MAX ((unsigned)(120*HZ)) #define TCP_RTO_MIN ((unsigned)(HZ/5)) #define TCP_TIMEOUT_INIT ((unsigned)(3*HZ)) /* RFC 1122 initial RTO value */
Et par defaut, le timer HZ est de 1000ms (en tout ca dans mon asm/param.h). Donc on a bien 3s comme delai de retransmission. Je ne sais pas si linux peut modifier son timer a la volee (c'est pas dans FreeBSD qu'on definit au boot le HZ=.., ou je me trompe?).
En gros, je voudrais que mon scanner de ports simpliste ne perde pas un temps fou face à un BSD qui limite le nombre de RST renvoyés chaque seconde.
Je ne comprends pas trop (?). Soit un scanner a la con: :~$ cat scanalakon #! /bin/bash for port in `seq 22 30` do telnet 127.0.0.1 $port & done
Un tcpdump me montre bien une rafale de SYN envoyes en quelques centiemes de secondes. Pourquoi attendre un retry? -- Kevin
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Arnaud Launay
Le 08 Aug 2005 20:43:04 GMT, Kevin Denis écrivit:
Et par defaut, le timer HZ est de 1000ms (en tout ca dans mon asm/param.h). Donc on a bien 3s comme delai de retransmission. Je ne sais pas si linux peut modifier son timer a la volee (c'est pas dans FreeBSD qu'on definit au boot le HZ=.., ou je me trompe?).
http://kerneltrap.org/node/5411
En gros, le timer va passer à 250Hz en 2.6.13, et sera modifiable à la compilation, si j'ai bonne mémoire.
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Le 08 Aug 2005 20:43:04 GMT, Kevin Denis écrivit:
Et par defaut, le timer HZ est de 1000ms (en tout ca dans mon
asm/param.h). Donc on a bien 3s comme delai de retransmission.
Je ne sais pas si linux peut modifier son timer a la volee
(c'est pas dans FreeBSD qu'on definit au boot le HZ=.., ou je
me trompe?).
http://kerneltrap.org/node/5411
En gros, le timer va passer à 250Hz en 2.6.13, et sera modifiable
à la compilation, si j'ai bonne mémoire.
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Et par defaut, le timer HZ est de 1000ms (en tout ca dans mon asm/param.h). Donc on a bien 3s comme delai de retransmission. Je ne sais pas si linux peut modifier son timer a la volee (c'est pas dans FreeBSD qu'on definit au boot le HZ=.., ou je me trompe?).
http://kerneltrap.org/node/5411
En gros, le timer va passer à 250Hz en 2.6.13, et sera modifiable à la compilation, si j'ai bonne mémoire.
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Dominique ROUSSEAU
Le lun, 08 aoû 2005 at 20:43 GMT, Kevin Denis a écrit :
Le 02-08-2005, Michel Arboi a écrit :
[...]
En gros, je voudrais que mon scanner de ports simpliste ne perde pas un temps fou face à un BSD qui limite le nombre de RST renvoyés chaque seconde.
Ca peut se faire sur des Linux aussi, il me semble.
Je ne comprends pas trop (?). Soit un scanner a la con: :~$ cat scanalakon #! /bin/bash for port in `seq 22 30` do telnet 127.0.0.1 $port & done
Un tcpdump me montre bien une rafale de SYN envoyes en quelques centiemes de secondes. Pourquoi attendre un retry?
Ne pas transformer le scan en déni de service (SYN flooding) ?
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Le lun, 08 aoû 2005 at 20:43 GMT, Kevin Denis <kevin@nowhere.invalid> a écrit :
Le 02-08-2005, Michel Arboi <arboi@alussinan.org> a écrit :
[...]
En gros, je voudrais que mon scanner de ports simpliste ne perde pas
un temps fou face à un BSD qui limite le nombre de RST renvoyés chaque
seconde.
Ca peut se faire sur des Linux aussi, il me semble.
Je ne comprends pas trop (?). Soit un scanner a la con:
kevin@zipslack:~$ cat scanalakon
#! /bin/bash
for port in `seq 22 30`
do
telnet 127.0.0.1 $port &
done
Un tcpdump me montre bien une rafale de SYN envoyes en quelques centiemes
de secondes. Pourquoi attendre un retry?
Ne pas transformer le scan en déni de service (SYN flooding) ?
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Le lun, 08 aoû 2005 at 20:43 GMT, Kevin Denis a écrit :
Le 02-08-2005, Michel Arboi a écrit :
[...]
En gros, je voudrais que mon scanner de ports simpliste ne perde pas un temps fou face à un BSD qui limite le nombre de RST renvoyés chaque seconde.
Ca peut se faire sur des Linux aussi, il me semble.
Je ne comprends pas trop (?). Soit un scanner a la con: :~$ cat scanalakon #! /bin/bash for port in `seq 22 30` do telnet 127.0.0.1 $port & done
Un tcpdump me montre bien une rafale de SYN envoyes en quelques centiemes de secondes. Pourquoi attendre un retry?
Ne pas transformer le scan en déni de service (SYN flooding) ?
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Michel Arboi
On Mon Aug 08 2005 at 22:43, Kevin Denis wrote:
En gros, je voudrais que mon scanner de ports simpliste ne perde pas un temps fou face à un BSD qui limite le nombre de RST renvoyés chaque seconde.
Je ne comprends pas trop (?).
J'envoie une rafale de SYN, le BSD répond RST aux 100 premiers, puis droppe les autres pendant une seconde. Le pingouin pourrait réessayer au bout d'une seconde, mais il attend 3. La solution adoptée par "nmap -sT" consiste à fermer les sockets et les rouvrir. Ça me déplait pour des raisons philosophiques. Je crains ne pas avoir le choix. Soit je gère les retransmissions à la main (close + re-connect), soit j'accepte d'être lent face à un BSD.
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
On Mon Aug 08 2005 at 22:43, Kevin Denis wrote:
En gros, je voudrais que mon scanner de ports simpliste ne perde pas
un temps fou face à un BSD qui limite le nombre de RST renvoyés chaque
seconde.
Je ne comprends pas trop (?).
J'envoie une rafale de SYN, le BSD répond RST aux 100 premiers, puis
droppe les autres pendant une seconde. Le pingouin pourrait réessayer
au bout d'une seconde, mais il attend 3.
La solution adoptée par "nmap -sT" consiste à fermer les sockets et
les rouvrir. Ça me déplait pour des raisons philosophiques.
Je crains ne pas avoir le choix. Soit je gère les retransmissions à la
main (close + re-connect), soit j'accepte d'être lent face à un BSD.
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
En gros, je voudrais que mon scanner de ports simpliste ne perde pas un temps fou face à un BSD qui limite le nombre de RST renvoyés chaque seconde.
Je ne comprends pas trop (?).
J'envoie une rafale de SYN, le BSD répond RST aux 100 premiers, puis droppe les autres pendant une seconde. Le pingouin pourrait réessayer au bout d'une seconde, mais il attend 3. La solution adoptée par "nmap -sT" consiste à fermer les sockets et les rouvrir. Ça me déplait pour des raisons philosophiques. Je crains ne pas avoir le choix. Soit je gère les retransmissions à la main (close + re-connect), soit j'accepte d'être lent face à un BSD.
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
