Bonne idée.

Par contre je me demande si la box ne peut pas changer à la volée le port source ?

Imaginons deux PC sur le même LAN qui démarrent une connexion avec le même port source, que fait le NAT de la box ? Elle ne va pas changer le port vers le serveur ?

---

Je viens d'avoir @Nico_Chevalier sur twitter. Il a des souci de reset, mais pas de blocage de connexion TCP, du moins en ce moment.



D'autres retours de @_Charlus_ mais on n'est pas sur d'être sur le même bug.

Je pense qu’elle devrait changer le port en effet. Il faudrait tenter le test avec absolument 0 device connecté à la box autre qu’un PC, et qu’absolument aucun programme si ce n’est curl sur le PC ne communique avec l’extérieur.
La plupart des NAT réutilisent le port source initial. Mais si celui-ci est déjà mappé, là ça peut devenir Random et c’est incontrôlable.

Chez moi, 5 ou 6 devices connectés en permanence sur la box, en ethernet avec système de communifation alarme/domotique, boitier Dect/SIP, Sonde Ripe, quelques PC dont 2 actifs en permanence quand je n'ai pas une ou 2 bécanes en "convalescence"...
Clair que le NAT de la box, il re-dispatche les ports gaiement...
Là, on n'est pas dans ce contexte, mais je me pose la question pour des box en IPV4 1/4 de ports... Clair qu'elle ne peuvent pas systématiquement utiliser le port origine s'il n'est pas dans leur "scope" de retour, sinon, la réponse, out!

---

Il a des souci de reset, mais pas de blocage de connexion TCP, du moins en ce moment.

Les reset ci-dessus ne me semblent pas forcément être un problème réseau.

Une connexion TCP  peut toujours être fermée par RST, si le client n'est pas intéressé par la totalité du message (ex: il passe à la page WEB suivante avant la fin de la page en cours). Il resette alors la connexion, et répondra aussi RST à tous les paquets TCP encore en vol ou retransmis. Si TCP continue à répondre (et même si ce sont des RST), on ne peut  dire à mon sens qu'on a un problème de fermeture (sauf peut-être au niveau applicatif).

Le problème de "fermeture" que j'avais eu (message supra, et image jointe) était différent: TCP ne répondait RIEN DU TOUT, et ça c'est anormal (un serveur, même saturé au niveau appli, continue en général à répondre au niveau TCP). Ce qui m'avait conduit à émettre l'idée qu'on avait peut-être un équipement intermédiaire qui gère mal les connexions TCP: mauvaise gestion des contextes (en début et en fin de connexion); mauvaise libération qui conduit à la pénurie etc...Et ce d'autant plus que les paquets TCP continuent à très bien transiter sur les connexions établies. Mais ce n'était qu'une idée parmi d'autres sur un problème encore en cours...

Après je pense que dans les faits n’avoir que 1/4 des ports te permet quand même plus de 16 000 connexions TCP simultanées (et autant d’UDP), ça doit pas être un facteur limitant chez un particulier.

Ç'aurait été un problème dans le passé, à l'époque du Peer to Peer (et de certaines box dont le NAT moisi s'écroulait pour cause de trop de sessions simultanées à gérer).
Mais avec sa quasi disparition, ça n'est plus vraiment un problème, le Peer to Peer qui reste étant surtout des saloperies type Streamroot (CDN qui vole la bande passante sortante des eyeballs pour faire rebondir le trafic).

L'idée de scripter un moyen de tester tous les ports source possible pourrait permet de circonSCRire le problème, non ? (curl --local-port)

Très bonne idée.

Pour que ce soit faible, j'ai fait une capture coté serveur, afin d'être sur que c'est le bon port qui est utilisé.

J'ai testé 233 ports et j'ai eu 30 bloqués, soit 13%.
Avec la même IP publique, même IP destination, même port source, même port destination, un port est systématiquement bloqué (j'ai fait plusieurs tentatives)
Ce pourrait donc être un lag de 8 port 10 Gb/s avec un port défectueux.

La commande utilisée coté client : curl -4 -o /dev/null http://k-net.testdebit.info/0.iso --local-port

Liste des ports source testés :
32768
32769
32770
32771
32772 => ko
32773
32774
32775
32776
32777 => ko
32778
32779
32780
32781
32782
32783
32784 => ko
32785
32786
32787
32788
32789 => ko
32790
32791
32792 => ko
32793
32794
32795
32796
32797
32798
32799
32800 => ko
32801
32802
32803
32804
32805
32806
32807
32808
32809
32810
32811
32812 => ko
32813
32814 => ko
32815
32816
32817
32818
32819
32820
32821
32822
32823 => ko
32824
32825 => ko
32826
32827 => ko
32828
32829
32830
32831
32832
32833
32834
32835
32836
32837
32838
32839
32840
32841
32842
32843 => ko
32844
32845
32846
32847 => ko
32848
32849
32850
32851
32852
32853 => ko
32854
32855
32856
32857 => ko
32858 => ko
32859 => ko
32860
32861
32862
32863
32864
32865
32866
32867
32868
32869
32870
32871
32872
32873
32874
32875
32876
32877
32878 => ko
32879
32880 => ko
32881
32882
32883
32884
32885
32886
32887
32888
32889
32890
32891
32892 => ko
32893
32894 => ko
32895
32896
32897
32898
32899
32900
32901
32902
32903
32904
32905
32906
32907
32908
32909
32910
32911
32912
32913
32914
32915
32916
32917
32918
32919
32920 => ko
32921
32922
32923
32924
32925
32926
32927
32928
32929
32930
32931
32932 => ko
32933
32934
32935
32936
32937
32938
32939
32940
32941
32942
32943
32944
32945
32946
32947
32948
32949
32950 => ko
32951
32952
32953
32954
32955
32956
32957
32958
32959 => ko
32960
32961
32962
32963
32964 => ko
32965
32966
32967
32968
32969
32970
32971
32972
32973
32974 => ko
32975
32976 => ko
32977
32978
32979 => ko
32980
32981
32982
32983
32984
32985
32986
32987
32988
32989
32990
32991
32992
32993
32994
32995
32996
32997 => ko
32998
32999
33000

Un lag n'est pas sensé être résilient ?