Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
Le 06/08/2010 00:15, Pascal Hambourg a écrit : giggz a écrit : sous backtrack 4 j'ai exactement le même comportement que sous debian lenny: MTU=1492 et tcp_timestamps=0 - bug MTU=1492 et tcp_timestamps=1 - ok MTU=1500 ou tcp_timestamps=0 - ok MTU=1500 ou tcp_timestamps=1 - ok Ce n'est vraiment que dans le cas où MTU=1492 et tcp_timestamps=0 que le bug apparait. Merci pour ce retour. sous sid je n'ai aucun problème quelques soit la mtu ou la valeur de tcp_timestamps. Mais ce n'est pas le même pc et donc pas la même carte graphique et pas le même driver (b44). Ah oui, j'avais oublié ce détail. Donc a priori le bug existe avec tous les noyaux mais est lié aux pilotes atl1*. Ou alors c'est un bug tordu du NAS qui ne se manifeste que lorsqu'on communique avec lui à travers ces pilotes. Tu as essayé de jouer avec ethtool -k/-K pour désactiver les options d'offload ? non pas encore :) j ai po eu le temps. d apres le man que j ai sous la main: ethtool -K--offload ethX [rx on|off] [tx on|off] [sg on|off] [tso on|off] [ufo on|off] [gso on|off] donc en gros je mets tout a off ? D'apres toi, ai je assez d'éléments pour faire un rapport de bug pour le noyau sur le tracker debian ? Bonne journée -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/i3gcdh$g8...@dough.gmane.org
Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
Le 06/08/2010 09:08, giggzounet a écrit : Le 06/08/2010 00:15, Pascal Hambourg a écrit : giggz a écrit : sous backtrack 4 j'ai exactement le même comportement que sous debian lenny: MTU=1492 et tcp_timestamps=0 - bug MTU=1492 et tcp_timestamps=1 - ok MTU=1500 ou tcp_timestamps=0 - ok MTU=1500 ou tcp_timestamps=1 - ok Ce n'est vraiment que dans le cas où MTU=1492 et tcp_timestamps=0 que le bug apparait. [snip] en regardant sur google, j ai trouvé via cette url https://help.ubuntu.com/community/Firestarter ce bug ci: https://bugs.launchpad.net/ubuntu/+source/firestarter/+bug/258863 ca ressemble étrangement a mon probleme... -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/i3gdoh$lh...@dough.gmane.org
Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
giggzounet a écrit : d apres le man que j ai sous la main: ethtool -K--offload ethX [rx on|off] [tx on|off] [sg on|off] [tso on|off] [ufo on|off] [gso on|off] donc en gros je mets tout a off ? Oui, et si ça remarche tu remets à les options à on une par une pour trouver celle qui foire, ou la combinaison d'options qui foire. D'apres toi, ai je assez d'éléments pour faire un rapport de bug pour le noyau sur le tracker debian ? Je pense, oui. Au fait, le problème ne se produit qu'avec le NAS et pas lors de transferts depuis d'autres machines du LAN ou l'extérieur (sinon je suppose que tu en aurais parlé) ? -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4c5bbd17.9060...@plouf.fr.eu.org
Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
Le 06/08/2010 09:43, Pascal Hambourg a écrit : giggzounet a écrit : d apres le man que j ai sous la main: ethtool -K--offload ethX [rx on|off] [tx on|off] [sg on|off] [tso on|off] [ufo on|off] [gso on|off] donc en gros je mets tout a off ? Oui, et si ça remarche tu remets à les options à on une par une pour trouver celle qui foire, ou la combinaison d'options qui foire. ok. D'apres toi, ai je assez d'éléments pour faire un rapport de bug pour le noyau sur le tracker debian ? Je pense, oui. Au fait, le problème ne se produit qu'avec le NAS et pas lors de transferts depuis d'autres machines du LAN ou l'extérieur (sinon je suppose que tu en aurais parlé) ? - avec le NAS ftp/cifs et NFS foirent. - sur mon LAN j ai aussi un serveur de fichiers qui tourne sous debian lenny. J'exporte les dossier via NFS. Entre mon eeepc et ce serveur de fichiers je n experimente aucun probleme (je n'ai pas de ftp ou de samba). Evidemment le harware est different. La chose vraiment différente est que sur le NAS la carte est capable de faire du gigabit. Mais bon mon routeur n'est pas gigabit... - Entre mon eeepc et mon autre laptop sous sid je fais du rsync a travers du ssh et je n ai aucun probleme. bon parfois l'eeepc freeze...mais ca c'est un probleme 'connu' sur le 1201n. c'est peut etre lié, je n'en sais rien. - qd je télécharge des fichiers depuis le net sur l'eeepc je n'ai pas exprimenté de probleme pour l'instant. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/i3gf7d$q3...@dough.gmane.org
Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
Le 06/08/2010 09:43, Pascal Hambourg a écrit : giggzounet a écrit : d apres le man que j ai sous la main: ethtool -K--offload ethX [rx on|off] [tx on|off] [sg on|off] [tso on|off] [ufo on|off] [gso on|off] donc en gros je mets tout a off ? Oui, et si ça remarche tu remets à les options à on une par une pour trouver celle qui foire, ou la combinaison d'options qui foire. bon j'ai essayé sous debian lenny avec le 2.6.32 et le module du noyau atl1c: - ethtool -k eth0 donne: Offload parameters for eth0: rx-checksumming: on tx-checksumming: on scatter-gather: on tcp segmentation offload: on udp fragmentation offload: off generic segmentation offload: on large receive offload: off - seul ethtool -K eth0 sg off gso off fontionnent. pour tous les autres paramètres j'ai droit à Operation not supported. - avec ethtool -K eth0 sg off gso off le problème reste le même. a savoir avec une mtu de 1492 et tcp_timestamps=0 pas de download possible depuis le NAS. J'ai aussi essayé sous backtrack 4 avec le 2.6.30.9 et le module atl1e. exactement les mêmes résultats. Enfin j'ai testé sur debian lenny avec le noyau 2.6.32 de backport et le dernier module atl1e d'atheros et j'ai encore exactement les mêmes résultats. J'ai regardé du côté du NAS si je pouvais faire la même chose avec ethtool. mais non je ne peux pas. j'ai bien ethtool mais en version 1.3...c'est vieux! Merci! et bon we -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/i3h49m$1k...@dough.gmane.org
Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
Le 04/08/2010 18:13, Pascal Hambourg a écrit : giggz a écrit : les 3 valeurs (tcp_timestamps, tcp_sack, tcp_window_scaling) sont à 0. Est ce normal ? Disons que ce ne sont pas les valeurs par défaut du noyau. Ces options n'existaient pas lors de la conception initiale de TCP, et si la machine en face ne supporte pas l'une d'elle, elle n'est pas utilisée. Elles ont essentiellement pour but d'augmenter les performances dans certaines circonstances : produit débit*latence élevé, pertes de paquets, nombreuses connexions... Bon ça avance!!! si je force via sysctl.conf la valeur de net.ipv4.tcp.timestamps à 1, ça marche parfaitement!!! les 2 autres valeurs tcp_sack et tcp_window_scaling n'ont pas d'influence sur le résultat. Tu pouvais tester en modifiant directement la valeur du paramètre du noyau en ligne de commande avec sysctl -w net.ipv4.tcp_timestamps=1 (le -w n'est apparemment plus obligatoire pour modifier un paramètre) (ou echo 1 /proc/sys/net/ipv4/tcp_timestamps mais c'est laid) d'autant plus que le résultat final au démarrage dépend de l'ordre dans lequel firestarter et le script qui applique sysctl.conf sont exécutés. firestarter a toutjours le dernier mot malheureusement. Une possibilité est de modifier a la main le fichier sysctl-tuning de firestarter...mais c est po tres satisfaisant. et c'est bien firestarter qui modifie cette valeur: dans /etc/firestarter/sysctl-tuning on a la valeur de net.ipv4.tcp.timestamps forcé à 0. Bon je suppose que si cette variable est forcée à 0 il doit y avoir une bonne raison. Certains pare-feu et dispositifs NAT obsolètes ou buggés ne gèrent pas correctement ces options, aussi il est parfois nécessaire de les désactiver. Sinon je ne vois pas trop. je suppose que le rapport de bug doit plutot aller au maintenant du driver atl1c, non ? Je vais encore te donner du travail, mais pourrais-tu vérifier si tcp_timestamps est à 1 et si le mettre à 0 provoque le problème en fonction du MTU avec les autres distributions installées sur la machine (sid, backtrack) ? Je pense que ça permettrait de mieux cerner le bug. En gros vérifier sur chacune si (si j'ai bien compris) : - MTU=1492 et tcp_timestamps=0 - bug - MTU=1500 ou tcp_timestamps=1 - ok En tout cas ce nouvel élément ne m'éclaire pas quant à la cause du bug. bon je teste ca des que je suis sur mon LAN. ce que je peux te dire direct c'est que sous backtrack 4 les valeurs sont a 1 et la mtu a 1492 et que ca marche. Merci! -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/i3do84$8d...@dough.gmane.org
Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
Le 04/08/2010 18:13, Pascal Hambourg a écrit : giggz a écrit : les 3 valeurs (tcp_timestamps, tcp_sack, tcp_window_scaling) sont à 0. Est ce normal ? Disons que ce ne sont pas les valeurs par défaut du noyau. Ces options n'existaient pas lors de la conception initiale de TCP, et si la machine en face ne supporte pas l'une d'elle, elle n'est pas utilisée. Elles ont essentiellement pour but d'augmenter les performances dans certaines circonstances : produit débit*latence élevé, pertes de paquets, nombreuses connexions... Bon ça avance!!! si je force via sysctl.conf la valeur de net.ipv4.tcp.timestamps à 1, ça marche parfaitement!!! les 2 autres valeurs tcp_sack et tcp_window_scaling n'ont pas d'influence sur le résultat. Tu pouvais tester en modifiant directement la valeur du paramètre du noyau en ligne de commande avec sysctl -w net.ipv4.tcp_timestamps=1 (le -w n'est apparemment plus obligatoire pour modifier un paramètre) (ou echo 1 /proc/sys/net/ipv4/tcp_timestamps mais c'est laid) d'autant plus que le résultat final au démarrage dépend de l'ordre dans lequel firestarter et le script qui applique sysctl.conf sont exécutés. et c'est bien firestarter qui modifie cette valeur: dans /etc/firestarter/sysctl-tuning on a la valeur de net.ipv4.tcp.timestamps forcé à 0. Bon je suppose que si cette variable est forcée à 0 il doit y avoir une bonne raison. Certains pare-feu et dispositifs NAT obsolètes ou buggés ne gèrent pas correctement ces options, aussi il est parfois nécessaire de les désactiver. Sinon je ne vois pas trop. je suppose que le rapport de bug doit plutot aller au maintenant du driver atl1c, non ? Je vais encore te donner du travail, mais pourrais-tu vérifier si tcp_timestamps est à 1 et si le mettre à 0 provoque le problème en fonction du MTU avec les autres distributions installées sur la machine (sid, backtrack) ? Je pense que ça permettrait de mieux cerner le bug. En gros vérifier sur chacune si (si j'ai bien compris) : - MTU=1492 et tcp_timestamps=0 - bug - MTU=1500 ou tcp_timestamps=1 - ok sous backtrack 4 j'ai exactement le même comportement que sous debian lenny: MTU=1492 et tcp_timestamps=0 - bug MTU=1492 et tcp_timestamps=1 - ok MTU=1500 ou tcp_timestamps=0 - ok MTU=1500 ou tcp_timestamps=1 - ok Ce n'est vraiment que dans le cas où MTU=1492 et tcp_timestamps=0 que le bug apparait. sous sid je n'ai aucun problème quelques soit la mtu ou la valeur de tcp_timestamps. Mais ce n'est pas le même pc et donc pas la même carte graphique et pas le même driver (b44). Bonne soirée Guillaume -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/i3fcdf$4c...@dough.gmane.org
Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
giggz a écrit : sous backtrack 4 j'ai exactement le même comportement que sous debian lenny: MTU=1492 et tcp_timestamps=0 - bug MTU=1492 et tcp_timestamps=1 - ok MTU=1500 ou tcp_timestamps=0 - ok MTU=1500 ou tcp_timestamps=1 - ok Ce n'est vraiment que dans le cas où MTU=1492 et tcp_timestamps=0 que le bug apparait. Merci pour ce retour. sous sid je n'ai aucun problème quelques soit la mtu ou la valeur de tcp_timestamps. Mais ce n'est pas le même pc et donc pas la même carte graphique et pas le même driver (b44). Ah oui, j'avais oublié ce détail. Donc a priori le bug existe avec tous les noyaux mais est lié aux pilotes atl1*. Ou alors c'est un bug tordu du NAS qui ne se manifeste que lorsqu'on communique avec lui à travers ces pilotes. Tu as essayé de jouer avec ethtool -k/-K pour désactiver les options d'offload ? -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4c5b37f1.4030...@plouf.fr.eu.org
Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
Le 04/08/2010 01:26, Pascal Hambourg a écrit : giggzounet a écrit : Le 02/08/2010 18:14, Pascal Hambourg a écrit : - Les SYN contiennent le minimum syndical d'options TCP : MSS et c'est tout. Ce n'est pas anormal, mais c'est un peu étonnant pour un Linux qui a normalement un certain nombre d'options TCP activées par défaut : timestamp, selective ACK, window scaling... Je n ai rien modifié a ce niveau la. donc j ai un pb avec un des logiciels installes. ou sont activees ces options ? est ce que par exemple sysctl -a peut aider ? Leurs valeurs sont visibles avec sysctl net.ipv4 ou dans /proc/sys/net/ipv4/ (tcp_timestamps, tcp_sack, tcp_window_scaling). bon je vais regarder ca! je poste ca des que possible. je soupconne firestarter de me modifier tout ca. Je ne connais pas, je préfère utiliser mes propres scripts de règles iptables. ben je comprends mais qd on n a pas trop envie de se fatiguer... :) De mon côté, j'ai regardé les changelogs du noyau pour le pilote atl1c (qui est assez jeune, introduit dans le noyau 2.6.29) à la recherche de changements susceptibles d'expliquer la présence du problème avec le noyau 2.6.32 si le MTU est inférieur à 1500 et son absence avec les noyaux 2.6.30.9 et 2.6.34-1 (le MTU est bien à 1492 aussi avec les autres noyaux ?). Sans succès. Je soupçonnais en particulier l'offloading, dont les différentes options sont contrôlables avec ethtool -k/-K, si ça te dit d'essayer de les désactiver... De mon coté j ai appris via google l'existence d'un autre driver supportant ma carte: celui du site atheros. il est normalement plus avancé. j ai donc booté sur mon 2.6.32 et fait un make install. il m'installe un driver du nom de atl1e. mais apparemment c'est normal. le atl1e d'atheros supporte en fait les cartes supportées par les drivers atl1e et atl1c du noyau linux. Bon après reboot, rmmod du atl1c et modprobe du atl1e, j ai bien internet mais le problème demeure! donc ca n a pas l air de venir du driver en lui meme. J ai oublié de préciser: sur backtrack 4 ou je n ai le probleme, c est un 2.6.30.9 avec le module atl1e d'atheros. Ce soir j essaye avec un vieux noyau 2.6.30 de debian! et je tente des bidouille avec ethtool -k/-K. Merci de ton aide! -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/i3b4ju$kt...@dough.gmane.org
Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
Le 04/08/2010 09:24, giggzounet a écrit : Le 04/08/2010 01:26, Pascal Hambourg a écrit : giggzounet a écrit : Le 02/08/2010 18:14, Pascal Hambourg a écrit : - Les SYN contiennent le minimum syndical d'options TCP : MSS et c'est tout. Ce n'est pas anormal, mais c'est un peu étonnant pour un Linux qui a normalement un certain nombre d'options TCP activées par défaut : timestamp, selective ACK, window scaling... Je n ai rien modifié a ce niveau la. donc j ai un pb avec un des logiciels installes. ou sont activees ces options ? est ce que par exemple sysctl -a peut aider ? Leurs valeurs sont visibles avec sysctl net.ipv4 ou dans /proc/sys/net/ipv4/ (tcp_timestamps, tcp_sack, tcp_window_scaling). bon je vais regarder ca! je poste ca des que possible. les 3 valeurs (tcp_timestamps, tcp_sack, tcp_window_scaling) sont à 0. Est ce normal ? si ce n'est pas normal comment je fais pour savoir d'où ça vient ? je soupconne firestarter de me modifier tout ca. Je ne connais pas, je préfère utiliser mes propres scripts de règles iptables. ben je comprends mais qd on n a pas trop envie de se fatiguer... :) De mon côté, j'ai regardé les changelogs du noyau pour le pilote atl1c (qui est assez jeune, introduit dans le noyau 2.6.29) à la recherche de changements susceptibles d'expliquer la présence du problème avec le noyau 2.6.32 si le MTU est inférieur à 1500 et son absence avec les noyaux 2.6.30.9 et 2.6.34-1 (le MTU est bien à 1492 aussi avec les autres noyaux ?). Sans succès. Je soupçonnais en particulier l'offloading, dont les différentes options sont contrôlables avec ethtool -k/-K, si ça te dit d'essayer de les désactiver... De mon coté j ai appris via google l'existence d'un autre driver supportant ma carte: celui du site atheros. il est normalement plus avancé. j ai donc booté sur mon 2.6.32 et fait un make install. il m'installe un driver du nom de atl1e. mais apparemment c'est normal. le atl1e d'atheros supporte en fait les cartes supportées par les drivers atl1e et atl1c du noyau linux. Bon après reboot, rmmod du atl1c et modprobe du atl1e, j ai bien internet mais le problème demeure! donc ca n a pas l air de venir du driver en lui meme. J ai oublié de préciser: sur backtrack 4 ou je n ai le probleme, c est un 2.6.30.9 avec le module atl1e d'atheros. Ce soir j essaye avec un vieux noyau 2.6.30 de debian! et je tente des bidouille avec ethtool -k/-K. bon j'ai testé avec le noyau 2.6.26 officiel de lenny avec atl1c retroporté...et j'ai exactement le même comportement. donc ça n'a pas l'air de venir de la version du noyau. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/i3btnr$eu...@dough.gmane.org
Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
- Les SYN contiennent le minimum syndical d'options TCP : MSS et c'est tout. Ce n'est pas anormal, mais c'est un peu étonnant pour un Linux qui a normalement un certain nombre d'options TCP activées par défaut : timestamp, selective ACK, window scaling... Je n ai rien modifié a ce niveau la. donc j ai un pb avec un des logiciels installes. ou sont activees ces options ? est ce que par exemple sysctl -a peut aider ? Leurs valeurs sont visibles avec sysctl net.ipv4 ou dans /proc/sys/net/ipv4/ (tcp_timestamps, tcp_sack, tcp_window_scaling). bon je vais regarder ca! je poste ca des que possible. les 3 valeurs (tcp_timestamps, tcp_sack, tcp_window_scaling) sont à 0. Est ce normal ? si ce n'est pas normal comment je fais pour savoir d'où ça vient ? Bon ça avance!!! si je force via sysctl.conf la valeur de net.ipv4.tcp.timestamps à 1, ça marche parfaitement!!! les 2 autres valeurs tcp_sack et tcp_window_scaling n'ont pas d'influence sur le résultat. je soupconne firestarter de me modifier tout ca. et c'est bien firestarter qui modifie cette valeur: dans /etc/firestarter/sysctl-tuning on a la valeur de net.ipv4.tcp.timestamps forcé à 0. Bon je suppose que si cette variable est forcée à 0 il doit y avoir une bonne raison. je suppose que le rapport de bug doit plutot aller au maintenant du driver atl1c, non ? Merci! Guillaume -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/i3bvei$m7...@dough.gmane.org
Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
giggz a écrit : les 3 valeurs (tcp_timestamps, tcp_sack, tcp_window_scaling) sont à 0. Est ce normal ? Disons que ce ne sont pas les valeurs par défaut du noyau. Ces options n'existaient pas lors de la conception initiale de TCP, et si la machine en face ne supporte pas l'une d'elle, elle n'est pas utilisée. Elles ont essentiellement pour but d'augmenter les performances dans certaines circonstances : produit débit*latence élevé, pertes de paquets, nombreuses connexions... Bon ça avance!!! si je force via sysctl.conf la valeur de net.ipv4.tcp.timestamps à 1, ça marche parfaitement!!! les 2 autres valeurs tcp_sack et tcp_window_scaling n'ont pas d'influence sur le résultat. Tu pouvais tester en modifiant directement la valeur du paramètre du noyau en ligne de commande avec sysctl -w net.ipv4.tcp_timestamps=1 (le -w n'est apparemment plus obligatoire pour modifier un paramètre) (ou echo 1 /proc/sys/net/ipv4/tcp_timestamps mais c'est laid) d'autant plus que le résultat final au démarrage dépend de l'ordre dans lequel firestarter et le script qui applique sysctl.conf sont exécutés. et c'est bien firestarter qui modifie cette valeur: dans /etc/firestarter/sysctl-tuning on a la valeur de net.ipv4.tcp.timestamps forcé à 0. Bon je suppose que si cette variable est forcée à 0 il doit y avoir une bonne raison. Certains pare-feu et dispositifs NAT obsolètes ou buggés ne gèrent pas correctement ces options, aussi il est parfois nécessaire de les désactiver. Sinon je ne vois pas trop. je suppose que le rapport de bug doit plutot aller au maintenant du driver atl1c, non ? Je vais encore te donner du travail, mais pourrais-tu vérifier si tcp_timestamps est à 1 et si le mettre à 0 provoque le problème en fonction du MTU avec les autres distributions installées sur la machine (sid, backtrack) ? Je pense que ça permettrait de mieux cerner le bug. En gros vérifier sur chacune si (si j'ai bien compris) : - MTU=1492 et tcp_timestamps=0 - bug - MTU=1500 ou tcp_timestamps=1 - ok En tout cas ce nouvel élément ne m'éclaire pas quant à la cause du bug. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4c599199.4010...@plouf.fr.eu.org
Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
Le 02/08/2010 18:14, Pascal Hambourg a écrit : giggz a écrit : En gros voilà ce que j'ai fait : je me connecte sur mon NAS en ftp -p ensuite je me balade dans mes répertoires et lance un get. rien ne se passe. je fais un ctrl+c et encore un autre. puis bye et voilà. Bon, je ne suis pas le super-expert en analyse de trace TCP/IP, hein. Ce que j'ai relevé comme bizarreries ou anomalies : - Les SYN contiennent le minimum syndical d'options TCP : MSS et c'est tout. Ce n'est pas anormal, mais c'est un peu étonnant pour un Linux qui a normalement un certain nombre d'options TCP activées par défaut : timestamp, selective ACK, window scaling... Je n ai rien modifié a ce niveau la. donc j ai un pb avec un des logiciels installes. ou sont activees ces options ? est ce que par exemple sysctl -a peut aider ? je soupconne firestarter de me modifier tout ca. Merci -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/i38eds$ru...@dough.gmane.org
Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
giggzounet a écrit : Le 02/08/2010 18:14, Pascal Hambourg a écrit : - Les SYN contiennent le minimum syndical d'options TCP : MSS et c'est tout. Ce n'est pas anormal, mais c'est un peu étonnant pour un Linux qui a normalement un certain nombre d'options TCP activées par défaut : timestamp, selective ACK, window scaling... Je n ai rien modifié a ce niveau la. donc j ai un pb avec un des logiciels installes. ou sont activees ces options ? est ce que par exemple sysctl -a peut aider ? Leurs valeurs sont visibles avec sysctl net.ipv4 ou dans /proc/sys/net/ipv4/ (tcp_timestamps, tcp_sack, tcp_window_scaling). je soupconne firestarter de me modifier tout ca. Je ne connais pas, je préfère utiliser mes propres scripts de règles iptables. De mon côté, j'ai regardé les changelogs du noyau pour le pilote atl1c (qui est assez jeune, introduit dans le noyau 2.6.29) à la recherche de changements susceptibles d'expliquer la présence du problème avec le noyau 2.6.32 si le MTU est inférieur à 1500 et son absence avec les noyaux 2.6.30.9 et 2.6.34-1 (le MTU est bien à 1492 aussi avec les autres noyaux ?). Sans succès. Je soupçonnais en particulier l'offloading, dont les différentes options sont contrôlables avec ethtool -k/-K, si ça te dit d'essayer de les désactiver... -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4c58a59a.3060...@plouf.fr.eu.org
Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
Le 31/07/2010 12:51, giggz a écrit : Bonjour, derrière mon routeur j'ai : un NAS un laptop un eeepc le NAS est configuré pour faire du ftp, du cifs et du NFS vers ces machines. Chaque machine a une ip fixe attribuée par le routeur. je veux récupérer un fichier situé sur mon NAS à partir de mon eeepc sous debian lenny/backport. et ça ne fonctionne pas. Les symptomes sont les suivants : - je peux me connecter sans problème de mon eeepc vers le NAS via ftp, cifs ou NFS. je peux lister et me balader dans mes partages. Par contre dès que j'essaye de récupérer un fichier, le transfert se bloque quelque soit le logiciel utilisé (ftp, gftp, NFS+rsync, cifs+rsync). et il me transfère 12K... :D Voilà ce que j'ai tenté : - j'ai bouté mon eeepc sous w7. aucun problème de transfert via samba. - j'ai bouté mon eeepc sous backtrack. aucun problème de transfert via ftp. - je pensais à une mauvaise configuration du NAS; j'ai donc tenté avec mon autre laptop sous SID. aucun problème. tout marche : ftp, cifs et NFS. - j'ai pensé à un problème de droits: les users sont les mêmes entre mon laptop et mon eeepc...avec les mêmes uid.; j'ai tenté de télécharger dans /tmp...ça ne marche pas. le transfert se bloque toujours après 12K... - j'ai pensé à un problème de parefeu. j'ai désactivé le parefeu. j'ai activé le parefeu en laissant tout ouvert...le problème persiste... bref je n'y comprends plus rien. Si vous avez des idées d'où ça peut venir...et surtout où chercher... j'ai oublié de préciser: j'ai évidemment regarder les logs (messages, syslog, auth, user) et rien de rien... Je me rappelle avoir jouer avec ettercap entre le laptop et le eeepc il y 2 semaines : j ai lancé ettercap sur le eeepc avec pour cible le laptop et j ai fait du arp poisoning pour voir si je récupérais mes mot de passe (ca marche d ailleurs étonnamment bien). Est ce que ca peut avoir une influence ? apres rebooot du routeur, laptop, NAS et eeepc ? Merci -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/i35uvb$i8...@dough.gmane.org
Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
Le 02/08/2010 10:17, giggzounet a écrit : Le 31/07/2010 12:51, giggz a écrit : Bonjour, derrière mon routeur j'ai : un NAS un laptop un eeepc le NAS est configuré pour faire du ftp, du cifs et du NFS vers ces machines. Chaque machine a une ip fixe attribuée par le routeur. je veux récupérer un fichier situé sur mon NAS à partir de mon eeepc sous debian lenny/backport. et ça ne fonctionne pas. Les symptomes sont les suivants : - je peux me connecter sans problème de mon eeepc vers le NAS via ftp, cifs ou NFS. je peux lister et me balader dans mes partages. Par contre dès que j'essaye de récupérer un fichier, le transfert se bloque quelque soit le logiciel utilisé (ftp, gftp, NFS+rsync, cifs+rsync). et il me transfère 12K... :D Voilà ce que j'ai tenté : - j'ai bouté mon eeepc sous w7. aucun problème de transfert via samba. - j'ai bouté mon eeepc sous backtrack. aucun problème de transfert via ftp. - je pensais à une mauvaise configuration du NAS; j'ai donc tenté avec mon autre laptop sous SID. aucun problème. tout marche : ftp, cifs et NFS. - j'ai pensé à un problème de droits: les users sont les mêmes entre mon laptop et mon eeepc...avec les mêmes uid.; j'ai tenté de télécharger dans /tmp...ça ne marche pas. le transfert se bloque toujours après 12K... - j'ai pensé à un problème de parefeu. j'ai désactivé le parefeu. j'ai activé le parefeu en laissant tout ouvert...le problème persiste... bref je n'y comprends plus rien. Si vous avez des idées d'où ça peut venir...et surtout où chercher... j'ai oublié de préciser: j'ai évidemment regarder les logs (messages, syslog, auth, user) et rien de rien... Je me rappelle avoir jouer avec ettercap entre le laptop et le eeepc il y 2 semaines : j ai lancé ettercap sur le eeepc avec pour cible le laptop et j ai fait du arp poisoning pour voir si je récupérais mes mot de passe (ca marche d ailleurs étonnamment bien). Est ce que ca peut avoir une influence ? apres rebooot du routeur, laptop, NAS et eeepc ? Merci J'ai aussi fait des tests entre mon eeepc et un fixe qui est aussi sur mon LAN et je nai aucun probleme pour monter un partage NFS et telecharger de gros fichiers dessus. Le probleme se concentre donc entre mon NAS et mon eeepc et uniquement en download (quelque soit la méthode utilisée: ftp, samba ou nfs). -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/i35vc4$jf...@dough.gmane.org
Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
Bonjour, - giggzounet giggzou...@gmail.com a écrit : Le 31/07/2010 12:51, giggz a écrit : Bonjour, derrière mon routeur j'ai : un NAS un laptop un eeepc le NAS est configuré pour faire du ftp, du cifs et du NFS vers ces machines. Chaque machine a une ip fixe attribuée par le routeur. je veux récupérer un fichier situé sur mon NAS à partir de mon eeepc sous debian lenny/backport. et ça ne fonctionne pas. Les symptomes sont les suivants : - je peux me connecter sans problème de mon eeepc vers le NAS via ftp, cifs ou NFS. je peux lister et me balader dans mes partages. Par contre dès que j'essaye de récupérer un fichier, le transfert se bloque quelque soit le logiciel utilisé (ftp, gftp, NFS+rsync, cifs+rsync). et il me transfère 12K... :D Voilà ce que j'ai tenté : - j'ai bouté mon eeepc sous w7. aucun problème de transfert via samba. - j'ai bouté mon eeepc sous backtrack. aucun problème de transfert via ftp. - je pensais à une mauvaise configuration du NAS; j'ai donc tenté avec mon autre laptop sous SID. aucun problème. tout marche : ftp, cifs et NFS. - j'ai pensé à un problème de droits: les users sont les mêmes entre mon laptop et mon eeepc...avec les mêmes uid.; j'ai tenté de télécharger dans /tmp...ça ne marche pas. le transfert se bloque toujours après 12K... - j'ai pensé à un problème de parefeu. j'ai désactivé le parefeu. j'ai activé le parefeu en laissant tout ouvert...le problème persiste... bref je n'y comprends plus rien. Si vous avez des idées d'où ça peut venir...et surtout où chercher... j'ai oublié de préciser: j'ai évidemment regarder les logs (messages, syslog, auth, user) et rien de rien... Je me rappelle avoir jouer avec ettercap entre le laptop et le eeepc il y 2 semaines : j ai lancé ettercap sur le eeepc avec pour cible le laptop et j ai fait du arp poisoning pour voir si je récupérais mes mot de passe (ca marche d ailleurs étonnamment bien). Est ce que ca peut avoir une influence ? apres rebooot du routeur, laptop, NAS et eeepc ? Merci Non, pas après reboot de tout ce beau monde et si l'arp poisonning était bien arrêté. Tu pouvais aussi vider les tables ARP à la main sur les machines Linux : 'ip neigh flush'. La durée de vie du cache ARP n'est pas très élevée de toute façon, en un quart d'heure les effets devraient avoir disparus sans aucune action de ta part. Cordialement, -- Christophe -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/2141829.3826231280739108452.javamail.r...@spooler2-g27.priv.proxad.net
Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
bien le bonjour, [snip] Non, pas après reboot de tout ce beau monde et si l'arp poisonning était bien arrêté. Tu pouvais aussi vider les tables ARP à la main sur les machines Linux : 'ip neigh flush'. La durée de vie du cache ARP n'est pas très élevée de toute façon, en un quart d'heure les effets devraient avoir disparus sans aucune action de ta part. ok. bon zut alors une cause possible en moins... :) As tu vu qqch d etrange dans la sortie de tcpdump que j ai jointe précédemment ? Merci de ton aide -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/i361d7$pr...@dough.gmane.org
Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
- giggzounet giggzou...@gmail.com a écrit : bien le bonjour, [snip] Non, pas après reboot de tout ce beau monde et si l'arp poisonning était bien arrêté. Tu pouvais aussi vider les tables ARP à la main sur les machines Linux : 'ip neigh flush'. La durée de vie du cache ARP n'est pas très élevée de toute façon, en un quart d'heure les effets devraient avoir disparus sans aucune action de ta part. ok. bon zut alors une cause possible en moins... :) As tu vu qqch d etrange dans la sortie de tcpdump que j ai jointe précédemment ? Hormis l'incohérence de MTU/MSS, non. Une capture au format pcap avec Wireshark serait la bienvenue, après avoir changé ton mot de passe bien entendu voire ton login... Tout sera visible. Il fait apparaître certains problèmes facilement, en analysant les séquences TCP entre autres. Merci de ton aide De rien ! -- Christophe -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/61.3830821280740571074.javamail.r...@spooler2-g27.priv.proxad.net
Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
Le 02/08/2010 11:16, christophe.f...@free.fr a écrit : - giggzounet giggzou...@gmail.com a écrit : bien le bonjour, [snip] Non, pas après reboot de tout ce beau monde et si l'arp poisonning était bien arrêté. Tu pouvais aussi vider les tables ARP à la main sur les machines Linux : 'ip neigh flush'. La durée de vie du cache ARP n'est pas très élevée de toute façon, en un quart d'heure les effets devraient avoir disparus sans aucune action de ta part. ok. bon zut alors une cause possible en moins... :) As tu vu qqch d etrange dans la sortie de tcpdump que j ai jointe précédemment ? Hormis l'incohérence de MTU/MSS, non. Une capture au format pcap avec Wireshark serait la bienvenue, après avoir changé ton mot de passe bien entendu voire ton login... Tout sera visible. Il fait apparaître certains problèmes facilement, en analysant les séquences TCP entre autres. ok. je fais ca ce soir en rentrant. merci -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/i362f4$tj...@dough.gmane.org
Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
Christophe a écrit : Tes deux machines ne semblent pas avoir la même MTU : 1500 pour ton NAS contre 1492 pour ton eeepc. Ca pourrait poser problème si le NAS n'en tient pas compte. Non, car même si le MTU est réglé plus bas, une interface ethernet accepte quand même les trames de 1500 octets (voire plus). -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4c56a740.1040...@plouf.fr.eu.org
Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
Bonjour, Le lundi 02 août 2010 à 13:08 +0200, Pascal Hambourg a écrit : Christophe a écrit : Tes deux machines ne semblent pas avoir la même MTU : 1500 pour ton NAS contre 1492 pour ton eeepc. Ca pourrait poser problème si le NAS n'en tient pas compte. Non, car même si le MTU est réglé plus bas, une interface ethernet accepte quand même les trames de 1500 octets (voire plus). La commande 'ip link set dev if mtu mtu' tente de régler la MTU pour la couche IP -et- l'interface, qui n'acceptera plus rien au dessus si elle supporte cette MTU en dur. La notion dont tu parles est valide si tu restreins ta MTU sur des routes, auquel cas l'interface pourra entendre des paquets plus gros que la MTU assignée à la route en question. Mais rien ne garantit que l'interface entendra au dessus de la MTU qui lui est assignée par ip link. Sous MS Windows, les réglages sont plus clairs : les options avancées de la carte réseau permettent de régler la MTU dure ou la longueur de trame de l'interface (souvent appelée jumbo frames, avec des valeurs discrètes), et 'netsh interface ipv4 show global' t'indique la MTU utilisée par la pile IP pour cette liaison. Linux règle les deux depuis la commande 'ip link'. Exemple : un de mes pc réglé en 1500 effectue un ping -M do -s 1472 sur un deuxième (mon portable, avec une Marvell 88E8072). Sur ce dernier, le fait de descendre la MTU de l'interface à 1494 l'empêche d'entendre les requêtes d'écho, alors qu'à 1495 il les entend et fragmente ses réponses. Cordialement, -- Christophe -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/1280753060.2924.52.ca...@hp6830s.herblain.cdjh.info
Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
Christophe a écrit : Le lundi 02 août 2010 à 13:08 +0200, Pascal Hambourg a écrit : Non, car même si le MTU est réglé plus bas, une interface ethernet accepte quand même les trames de 1500 octets (voire plus). La commande 'ip link set dev if mtu mtu' tente de régler la MTU pour la couche IP -et- l'interface, qui n'acceptera plus rien au dessus si elle supporte cette MTU en dur. MTU = Maximum *Transmit* Unit, donc en émission. Le MRU en réception ne devrait pas être affecté. Exemple : un de mes pc réglé en 1500 effectue un ping -M do -s 1472 sur un deuxième (mon portable, avec une Marvell 88E8072). Sur ce dernier, le fait de descendre la MTU de l'interface à 1494 l'empêche d'entendre les requêtes d'écho, alors qu'à 1495 il les entend et fragmente ses réponses. Je suis surpris car d'une part car chez moi ça marche, et d'autre part 1495 reste inférieur à la taille du paquet de requête écho (1500) donc ce n'est pas cohérent. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4c56d2c2.2030...@plouf.fr.eu.org
Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
Le Mon, 02 Aug 2010 14:44:20 +0200, Christophe christophe.f...@free.fr a écrit : ... Exemple : un de mes pc réglé en 1500 effectue un ping -M do -s 1472 sur un deuxième (mon portable, avec une Marvell 88E8072). Sur ce dernier, le fait de descendre la MTU de l'interface à 1494 l'empêche d'entendre les requêtes d'écho, alors qu'à 1495 il les entend et fragmente ses réponses. J'abonde dans le sens de Pascal: chez moi aussi ça marche sans PB (avec le temps de réponse qui fait évidemment un bond lors de la fragmentation.) -- -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20100802164422.1d70d...@anubis.defcon1
Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
giggz a écrit : En gros voilà ce que j'ai fait : je me connecte sur mon NAS en ftp -p ensuite je me balade dans mes répertoires et lance un get. rien ne se passe. je fais un ctrl+c et encore un autre. puis bye et voilà. Bon, je ne suis pas le super-expert en analyse de trace TCP/IP, hein. Ce que j'ai relevé comme bizarreries ou anomalies : - Les SYN contiennent le minimum syndical d'options TCP : MSS et c'est tout. Ce n'est pas anormal, mais c'est un peu étonnant pour un Linux qui a normalement un certain nombre d'options TCP activées par défaut : timestamp, selective ACK, window scaling... - Des checksums sont indiqués comme incorrects. Apparemment cela se produit avec les segments émis par le client contenant des données et ayant le flag P (PSH, Push) activé. Dans cette trace tous les segments émis par client avec des données ont le flag P, donc je ne sais pas si c'est la présence de données ou le flag P qui provoque ça. Mais ça n'a pas l'air de gêner la communication puisque le serveur acquitte ces segments. C'est peut-être un faux positif causé par de l'offloading (traitement déporté, par exemple segmentation et calcul du checksum) de TCP dans l'interface réseau à la place du noyau. - Le serveur envoie régulièrement des segments des données avec un offset et une longueur aberrants : longueur des données 1444 au lieu de 1452 conformément au MSS annoncé par le client, et offset largement au-delà de l'offset courant. Cela se produit systématiquement juste après la séquence de synchronisation de la connexion de données lorsque le transfert nécessite plus d'un segment : séquence de synchronisation : 14:25:12 IP (id 17251, proto TCP (6), length 44) client.dat5 serveur.dat5: S, 2994688280:2994688280(0) win 5808 mss 1452 14:25:12 IP (id 0, proto TCP (6), length 44) serveur.dat5 client.dat5: S, 658576691:658576691(0) ack 2994688281 win 5840 mss 1460 14:25:12 IP (id 17252, proto TCP (6), length 40) client.dat5 serveur.dat5: ., ack 1 win 5808 2 segments aberrants : 14:25:12 IP (id 24813, proto TCP (6), length 1484) serveur.dat5 client.dat5: . 1461:2905(1444) ack 1 win 5840 14:25:12 IP (id 17253, proto TCP (6), length 40) client.dat5 serveur.dat5: ., ack 1 win 5808 14:25:12 IP (id 24815, proto TCP (6), length 1484) serveur.dat5 client.dat5: P 4365:5809(1444) ack 1 win 5840 14:25:12 IP (id 17254, proto TCP (6), length 40) client.dat5 serveur.dat5: ., ack 1 win 5808 Le client répond à chaque fois qu'il attend l'offset 1. Après un délai de 3 secondes des segments normaux sont ensuite transmis par le serveur et acquittés par le client : 14:25:15 IP (id 24816, proto TCP (6), length 1492) serveur.dat5 client.dat5: . 1:1453(1452) ack 1 win 5840 14:25:15 IP (id 17255, proto TCP (6), length 40) client.dat5 serveur.dat5: ., ack 1453 win 8712 14:25:15 IP (id 24817, proto TCP (6), length 1492) serveur.dat5 client.dat5: . 1453:2905(1452) ack 1 win 5840 14:25:15 IP (id 17256, proto TCP (6), length 40) client.dat5 serveur.dat5: ., ack 2905 win 11616 14:25:15 IP (id 24818, proto TCP (6), length 1492) serveur.dat5 client.dat5: . 2905:4357(1452) ack 1 win 5840 14:25:15 IP (id 17257, proto TCP (6), length 40) client.dat5 serveur.dat5: ., ack 4357 win 14520 14:25:15 IP (id 24819, proto TCP (6), length 1492) serveur.dat5 client.dat5: P 4357:5809(1452) ack 1 win 5840 14:25:15 IP (id 17258, proto TCP (6), length 40) client.dat5 serveur.dat5: ., ack 5809 win 17424 Puis à nouveau un segment aberrant : 14:25:15 IP (id 24821, proto TCP (6), length 1484) serveur.dat5 client.dat5: . 7269:8713(1444) ack 1 win 5840 14:25:15 IP (id 17259, proto TCP (6), length 40) client.dat5 serveur.dat5: ., ack 5809 win 17424 Après un nouveau délai de 6 secondes cette fois, ça repart : 14:25:21 IP (id 24822, proto TCP (6), length 1492) serveur.dat5 client.dat5: . 5809:7261(1452) ack 1 win 5840 14:25:21 IP (id 17260, proto TCP (6), length 40) client.dat5 serveur.dat5: ., ack 7261 win 20328 14:25:21 IP (id 24823, proto TCP (6), length 1492) serveur.dat5 client.dat5: . 7261:8713(1452) ack 1 win 5840 14:25:21 IP (id 17261, proto TCP (6), length 40) client.dat5 serveur.dat5: ., ack 8713 win 23232 (Ces délais sont responsables de la lenteur de réception de fichiers qui réussissent à passer.) Et ça continue, avec des délais en augmentation jusqu'à ce que le client perde patience et interrompe le transfert. Je n'ai pas d'explication à proposer pour le moment. Il pourrait être intéressant de comparer les traces avec les autres machine/distribution qui marchent. Quelle est la version du noyau de BackTrack ? Quel est le type de l'interface réseau de l'Eee PC ? -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
Le 01/08/2010 23:10, Christophe a écrit : Bonjour, Le samedi 31 juillet 2010 à 15:06 +0200, giggz a écrit : Le 31/07/2010 14:39, Pascal Hambourg a écrit : giggz a écrit : question de NooB : les login/password en ftp sont en clair. si je copie/colle ce que me sort tcpdump, est ce que mon login/password est lisible ? Normalement par défaut tcpdump ne fait pas l'analyse du protocole FTP (wireshark/tshark si en revanche) et n'affiche pas non plus les données des paquets, seulement les champs des en-têtes. Mais ça dépend peut-être des versions. ok. je joins le fichier en question. apparemment je ne vois pas mon mot de passe...c'est déjà ça. dis moi qd même, s'il te plait, si je dois ou non changer mon password ;) En gros voilà ce que j'ai fait : je me connecte sur mon NAS en ftp -p ensuite je me balade dans mes répertoires et lance un get. rien ne se passe. je fais un ctrl+c et encore un autre. puis bye et voilà. Merci d'avance Guillaume Tes deux machines ne semblent pas avoir la même MTU : 1500 pour ton NAS contre 1492 pour ton eeepc. Ca pourrait poser problème si le NAS n'en tient pas compte. Tu peux vérifier sa valeur avec la commande 'ip link show dev eth0', et la régler avec 'ip link set dev eth0 mtu 1500' suivi d'un 'ip route flush cache'. nouveau rebondissement: j'ai remis ma mtu de mon NAS à 1500. et j'ai tapé les commandes de christopĥe ci-dessus sur mon eeepc. je me retrouve donc avec une mtu de 1500 et là ça marche parfaitement... bon la question est maintenant de savoir pourquoi ça marche pas avec une mtu plus basse... -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/i36u25$e8...@dough.gmane.org
Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
Le 02/08/2010 18:14, Pascal Hambourg a écrit : giggz a écrit : En gros voilà ce que j'ai fait : je me connecte sur mon NAS en ftp -p ensuite je me balade dans mes répertoires et lance un get. rien ne se passe. je fais un ctrl+c et encore un autre. puis bye et voilà. Bon, je ne suis pas le super-expert en analyse de trace TCP/IP, hein. Ce que j'ai relevé comme bizarreries ou anomalies : - Les SYN contiennent le minimum syndical d'options TCP : MSS et c'est tout. Ce n'est pas anormal, mais c'est un peu étonnant pour un Linux qui a normalement un certain nombre d'options TCP activées par défaut : timestamp, selective ACK, window scaling... - Des checksums sont indiqués comme incorrects. Apparemment cela se produit avec les segments émis par le client contenant des données et ayant le flag P (PSH, Push) activé. Dans cette trace tous les segments émis par client avec des données ont le flag P, donc je ne sais pas si c'est la présence de données ou le flag P qui provoque ça. Mais ça n'a pas l'air de gêner la communication puisque le serveur acquitte ces segments. C'est peut-être un faux positif causé par de l'offloading (traitement déporté, par exemple segmentation et calcul du checksum) de TCP dans l'interface réseau à la place du noyau. - Le serveur envoie régulièrement des segments des données avec un offset et une longueur aberrants : longueur des données 1444 au lieu de 1452 conformément au MSS annoncé par le client, et offset largement au-delà de l'offset courant. Cela se produit systématiquement juste après la séquence de synchronisation de la connexion de données lorsque le transfert nécessite plus d'un segment : séquence de synchronisation : 14:25:12 IP (id 17251, proto TCP (6), length 44) client.dat5 serveur.dat5: S, 2994688280:2994688280(0) win 5808 mss 1452 14:25:12 IP (id 0, proto TCP (6), length 44) serveur.dat5 client.dat5: S, 658576691:658576691(0) ack 2994688281 win 5840 mss 1460 14:25:12 IP (id 17252, proto TCP (6), length 40) client.dat5 serveur.dat5: ., ack 1 win 5808 2 segments aberrants : 14:25:12 IP (id 24813, proto TCP (6), length 1484) serveur.dat5 client.dat5: . 1461:2905(1444) ack 1 win 5840 14:25:12 IP (id 17253, proto TCP (6), length 40) client.dat5 serveur.dat5: ., ack 1 win 5808 14:25:12 IP (id 24815, proto TCP (6), length 1484) serveur.dat5 client.dat5: P 4365:5809(1444) ack 1 win 5840 14:25:12 IP (id 17254, proto TCP (6), length 40) client.dat5 serveur.dat5: ., ack 1 win 5808 Le client répond à chaque fois qu'il attend l'offset 1. Après un délai de 3 secondes des segments normaux sont ensuite transmis par le serveur et acquittés par le client : 14:25:15 IP (id 24816, proto TCP (6), length 1492) serveur.dat5 client.dat5: . 1:1453(1452) ack 1 win 5840 14:25:15 IP (id 17255, proto TCP (6), length 40) client.dat5 serveur.dat5: ., ack 1453 win 8712 14:25:15 IP (id 24817, proto TCP (6), length 1492) serveur.dat5 client.dat5: . 1453:2905(1452) ack 1 win 5840 14:25:15 IP (id 17256, proto TCP (6), length 40) client.dat5 serveur.dat5: ., ack 2905 win 11616 14:25:15 IP (id 24818, proto TCP (6), length 1492) serveur.dat5 client.dat5: . 2905:4357(1452) ack 1 win 5840 14:25:15 IP (id 17257, proto TCP (6), length 40) client.dat5 serveur.dat5: ., ack 4357 win 14520 14:25:15 IP (id 24819, proto TCP (6), length 1492) serveur.dat5 client.dat5: P 4357:5809(1452) ack 1 win 5840 14:25:15 IP (id 17258, proto TCP (6), length 40) client.dat5 serveur.dat5: ., ack 5809 win 17424 Puis à nouveau un segment aberrant : 14:25:15 IP (id 24821, proto TCP (6), length 1484) serveur.dat5 client.dat5: . 7269:8713(1444) ack 1 win 5840 14:25:15 IP (id 17259, proto TCP (6), length 40) client.dat5 serveur.dat5: ., ack 5809 win 17424 Après un nouveau délai de 6 secondes cette fois, ça repart : 14:25:21 IP (id 24822, proto TCP (6), length 1492) serveur.dat5 client.dat5: . 5809:7261(1452) ack 1 win 5840 14:25:21 IP (id 17260, proto TCP (6), length 40) client.dat5 serveur.dat5: ., ack 7261 win 20328 14:25:21 IP (id 24823, proto TCP (6), length 1492) serveur.dat5 client.dat5: . 7261:8713(1452) ack 1 win 5840 14:25:21 IP (id 17261, proto TCP (6), length 40) client.dat5 serveur.dat5: ., ack 8713 win 23232 (Ces délais sont responsables de la lenteur de réception de fichiers qui réussissent à passer.) Et ça continue, avec des délais en augmentation jusqu'à ce que le client perde patience et interrompe le transfert. Je n'ai pas d'explication à proposer pour le moment. Il pourrait être intéressant de comparer les traces avec les autres machine/distribution qui marchent. Quelle est la version du noyau de BackTrack ? Quel est le type de l'interface réseau de l'Eee PC ? tout d'abord merci de ton analyse! backtrack 4 se base sur Ubuntu et j'ai un noyau 2.6.30.9 sous backtrack qd je boote j'ai aussi une mtu de 1492. mais je n'ai pas de problème
Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
Le 31/07/2010 12:51, giggz a écrit : Bonjour, derrière mon routeur j'ai : un NAS un laptop un eeepc le NAS est configuré pour faire du ftp, du cifs et du NFS vers ces machines. Chaque machine a une ip fixe attribuée par le routeur. je veux récupérer un fichier situé sur mon NAS à partir de mon eeepc sous debian lenny/backport. et ça ne fonctionne pas. Les symptomes sont les suivants : - je peux me connecter sans problème de mon eeepc vers le NAS via ftp, cifs ou NFS. je peux lister et me balader dans mes partages. Par contre dès que j'essaye de récupérer un fichier, le transfert se bloque quelque soit le logiciel utilisé (ftp, gftp, NFS+rsync, cifs+rsync). et il me transfère 12K... :D Voilà ce que j'ai tenté : - j'ai bouté mon eeepc sous w7. aucun problème de transfert via samba. - j'ai bouté mon eeepc sous backtrack. aucun problème de transfert via ftp. - je pensais à une mauvaise configuration du NAS; j'ai donc tenté avec mon autre laptop sous SID. aucun problème. tout marche : ftp, cifs et NFS. - j'ai pensé à un problème de droits: les users sont les mêmes entre mon laptop et mon eeepc...avec les mêmes uid.; j'ai tenté de télécharger dans /tmp...ça ne marche pas. le transfert se bloque toujours après 12K... - j'ai pensé à un problème de parefeu. j'ai désactivé le parefeu. j'ai activé le parefeu en laissant tout ouvert...le problème persiste... bref je n'y comprends plus rien. Si vous avez des idées d'où ça peut venir...et surtout où chercher... j'ai oublié de préciser: j'ai évidemment regarder les logs (messages, syslog, auth, user) et rien de rien... ci joint le fichier obtenu en faisant: tcpdump -nvi eth0 -host 192.168.0.5 -w capture_NAS_tcpdump.log merci d'avance Guillaume Ãò¡ ` çWLà ` 2 ^ÿúÃ? \ e ...@ Ã!è ïÿÿúÃqlÂ,NOTIFY * HTTP/1.1 HOST:239.255.255.250:1900 Cache-CoÃWL$- : : Ã? \à ÃN L¡ E ,...@ @ÂÃè è ÃÃ'%Â%h`°éH ¬ÃWLM. à ÃN L¡Ã? \ E , ...@ @¹rè è '%ÃÃ/eÂÂ%i`ÃTl ´ ÃWLÂ. 6 6 Ã? \à ÃN L¡ E (...@ @ÂÃè è ÃÃ'%Â%i/eÂP°lI ÃWL]ð ` t à ÃN L¡Ã? \ e f...@ @NQè è '%ÃÃ/eÂÂ%iPÃf 220 ProFTPD 1.3.3rc1 Server (NETGEAR ReadyÃWLáð 6 6 Ã? \à ÃN L¡ E (...@ @²è è ÃÃ'%Â%i/eÃP°l ðWLa B B Ã? \à Ãn l¡ e 4...@ @Â¥è è ÃÃ'%Â%i/eÃP°Â USER eeepc ðWLF! à ÃN L¡Ã? \ E (j...@ @NÂè è '%ÃÃ/eÃÂ%uPÃkÃðWL W W à ÃN L¡Ã? \ e i...@ @Nlè è '%ÃÃ/eÃÂ%uPÃwt 331 Password required for eeepc ðWL7 6 6 Ã? \à ÃN L¡ E (...@ @°è è ÃÃ'%Â%u/eòP°kà õWLàG G Ã? \à Ãn l¡ e 9...@ @ÂÂè è ÃÃ'%Â%u/eòP°Â PASS depression õWLà à ÃN L¡Ã? \ E (j...@ @NÂè è '%ÃÃ/eòÂ%ÂPÃkÂõWL¯ P P à ÃN L¡Ã? \ e b...@ @Nqè è '%ÃÃ/eòÂ%ÂPÃÂR 230 User eeepc logged in õWLú 6 6 Ã? \à ÃN L¡ E (...@ @®è è ÃÃ'%Â%Â/f P°k³ õWLp Ã? \à Ãn l¡ e @ @§è è ÃÃ'%Â%Â/f P°Âz SYST õWLT¡ à ÃN L¡Ã? \ E (j...@ @NÂè è '%ÃÃ/f Â%ÂPÃkÂõWL$à I I à ÃN L¡Ã? \ E ;j...@ @Nvè è '%ÃÃ/f Â%ÂPà 215 UNIX Type: L8 õWL¹f 6 6 Ã? \à ÃN L¡ E (...@ @ è ÃÃ'%Â%Â/f P°k ÷WL4 Ã? \à Ãn l¡ e @ @Â¥è è ÃÃ'%Â%Â/f P°Âz PASV ÷WLôD ` f à ÃN L¡Ã? \ e x...@ @NXè è '%ÃÃ/f Â%ÂPÃä 227 Entering Passive Mode (192,168,0,5,39,÷WLRE 6 6 Ã? \à ÃN L¡ E (...@ @ªè è ÃÃ'%Â%Â/fOP°kd ÷WLáE : : Ã? \à ÃN L¡ E ,4...@ @ ;è è æò'?Â}`°cW ¬÷WLÂF à ÃN L¡Ã? \ E , ...@ @¹rè è '?æò/¬Âà Â}`à´ ÷WLÃF 6 6 Ã? \à ÃN L¡ E (4...@ @ Ã¨ è æò'?Â}/¬ÂáP°¯n ÷WLG Ã? \à Ãn l¡ e @ @£è è ÃÃ'%Â%Â/fOP°Âz LIST ÷WLW ` l à ÃN L¡Ã? \ e ^...@ @NQè è '%ÃÃ/fOÂ%ÂPÃzæ 150 Opening ASCII mode data connection for÷WL ` µ à ÃN L¡Ã? \ e §Â...@ @/úè è '?æò/¬ÂáÂ}PûS drwxrwxrwx 2 nobody nogroup 16384 ÷WLø 6 6 Ã? \à ÃN L¡ E (4...@ @ 5è è æò'?Â}/¬Â`P°®ï ÷WLB 6 6 Ã? \à ÃN L¡ E (...@ @¨è è ÃÃ'%Â%Â/f P°k( ÷WL¨ à ÃN L¡Ã? \ E (Â...@ @0xè è '?æò/¬Â`Â}PîÃ÷WL 6 6 Ã? \à ÃN L¡ E (4:@ ...@ 4è è æò'?Â}/¬ÂaP°®à ÷WLS à ÃN L¡Ã?
Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
Le lundi 02 août 2010 à 16:14 +0200, Pascal Hambourg a écrit : Christophe a écrit : Le lundi 02 août 2010 à 13:08 +0200, Pascal Hambourg a écrit : Non, car même si le MTU est réglé plus bas, une interface ethernet accepte quand même les trames de 1500 octets (voire plus). La commande 'ip link set dev if mtu mtu' tente de régler la MTU pour la couche IP -et- l'interface, qui n'acceptera plus rien au dessus si elle supporte cette MTU en dur. Auto-correction, dans le cas de l'interface, il ne s'agit pas d'un réglage de MTU, mais de la taille maximum de trame ethernet. MTU = Maximum *Transmit* Unit, donc en émission. Le MRU en réception ne devrait pas être affecté. Potentiellement, si : les deux sont bridés par notre segment ethernet maximum, qui est paramétré par le pilote en fonction de la MTU choisie (au moins l'option jumbo frame, si elle est présente). Exemple : un de mes pc réglé en 1500 effectue un ping -M do -s 1472 sur un deuxième (mon portable, avec une Marvell 88E8072). Sur ce dernier, le fait de descendre la MTU de l'interface à 1494 l'empêche d'entendre les requêtes d'écho, alors qu'à 1495 il les entend et fragmente ses réponses. Je suis surpris car d'une part car chez moi ça marche, et d'autre part 1495 reste inférieur à la taille du paquet de requête écho (1500) donc ce n'est pas cohérent. Comme le pilote adapte la configuration de la carte en fonction de la MTU choisie, je soupçonnais ma carte d'avoir des valeurs en dessous de 1500 et des poussières... Je viens de faire le test à l'envers et j'ai le même comportement que vous (sur une Realtek cette fois-ci). Il s'agit d'un bug du pilote sky2 (cartes Marvell Yukon) visiblement, à 1494 ou moins il me produit une erreur sky2 eth0: rx length error: status 0x5ea0100 length 1510 dans les messages du noyau. Il doit s'agir d'un problème de gestion des tampons par le pilote ou je ne sais quoi, la longueur indiquée dépend de la valeur de MTU paramétrée, par paliers de 8. Bref, il faut visiblement faire attention à régler tous les MTU de façon identique si l'on a affaire à du Marvell sur le réseau. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/1280773383.2901.216.ca...@hp6830s.herblain.cdjh.info
Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
Bonjour, Le samedi 31 juillet 2010 à 15:06 +0200, giggz a écrit : Le 31/07/2010 14:39, Pascal Hambourg a écrit : giggz a écrit : question de NooB : les login/password en ftp sont en clair. si je copie/colle ce que me sort tcpdump, est ce que mon login/password est lisible ? Normalement par défaut tcpdump ne fait pas l'analyse du protocole FTP (wireshark/tshark si en revanche) et n'affiche pas non plus les données des paquets, seulement les champs des en-têtes. Mais ça dépend peut-être des versions. ok. je joins le fichier en question. apparemment je ne vois pas mon mot de passe...c'est déjà ça. dis moi qd même, s'il te plait, si je dois ou non changer mon password ;) En gros voilà ce que j'ai fait : je me connecte sur mon NAS en ftp -p ensuite je me balade dans mes répertoires et lance un get. rien ne se passe. je fais un ctrl+c et encore un autre. puis bye et voilà. Merci d'avance Guillaume Tes deux machines ne semblent pas avoir la même MTU : 1500 pour ton NAS contre 1492 pour ton eeepc. Ca pourrait poser problème si le NAS n'en tient pas compte. Tu peux vérifier sa valeur avec la commande 'ip link show dev eth0', et la régler avec 'ip link set dev eth0 mtu 1500' suivi d'un 'ip route flush cache'. -- Christophe -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/1280697039.6184.15.ca...@hp6830s.herblain.cdjh.info
Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
Le 01/08/2010 23:10, Christophe a écrit : Bonjour, Le samedi 31 juillet 2010 à 15:06 +0200, giggz a écrit : Le 31/07/2010 14:39, Pascal Hambourg a écrit : giggz a écrit : question de NooB : les login/password en ftp sont en clair. si je copie/colle ce que me sort tcpdump, est ce que mon login/password est lisible ? Normalement par défaut tcpdump ne fait pas l'analyse du protocole FTP (wireshark/tshark si en revanche) et n'affiche pas non plus les données des paquets, seulement les champs des en-têtes. Mais ça dépend peut-être des versions. ok. je joins le fichier en question. apparemment je ne vois pas mon mot de passe...c'est déjà ça. dis moi qd même, s'il te plait, si je dois ou non changer mon password ;) En gros voilà ce que j'ai fait : je me connecte sur mon NAS en ftp -p ensuite je me balade dans mes répertoires et lance un get. rien ne se passe. je fais un ctrl+c et encore un autre. puis bye et voilà. Merci d'avance Guillaume Tes deux machines ne semblent pas avoir la même MTU : 1500 pour ton NAS contre 1492 pour ton eeepc. Ca pourrait poser problème si le NAS n'en tient pas compte. Tu peux vérifier sa valeur avec la commande 'ip link show dev eth0', et la régler avec 'ip link set dev eth0 mtu 1500' suivi d'un 'ip route flush cache'. J'ai mis la valeur de la mtu du NAS à 1492. mais ça ne change rien. De plsu sur mon laptop la valeur est aussi à 1492 et pourtant tout marche très bien entre ce laptop et le NAS. merci! Bye GiGGz -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/i34p4k$os...@dough.gmane.org
Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
Le Sun, 01 Aug 2010 23:32:03 +0200, giggz giggzou...@gmail.com a écrit : ... J'ai mis la valeur de la mtu du NAS à 1492. mais ça ne change rien. De plsu sur mon laptop la valeur est aussi à 1492 et pourtant tout marche très bien entre ce laptop et le NAS. la valeur std pour un LAN est de 1500 bytes. -- Women's Libbers are OK. I just wouldn't want my sister to marry one. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20100801233921.2ef9c...@anubis.defcon1
Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
Le 01/08/2010 23:39, Jean-Yves F. Barbier a écrit : Le Sun, 01 Aug 2010 23:32:03 +0200, giggz giggzou...@gmail.com a écrit : ... J'ai mis la valeur de la mtu du NAS à 1492. mais ça ne change rien. De plsu sur mon laptop la valeur est aussi à 1492 et pourtant tout marche très bien entre ce laptop et le NAS. la valeur std pour un LAN est de 1500 bytes. je sais...mais malheureusement mon routeur force la valeur à 1492 au moment où il y a dialogue avec le serveur dhcp. En gros si je fonctionne en ip fixe je peux forcer la mtu à 1500. mais si je laisse le dhcp faire son travail j'ai tjs une mtu à 1492. bon en même temps c'est po très grave si tout est à 1492, non ? -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/i34pvp$qm...@dough.gmane.org
Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
Le Sun, 01 Aug 2010 23:46:33 +0200, giggz giggzou...@gmail.com a écrit : Le 01/08/2010 23:39, Jean-Yves F. Barbier a écrit : Le Sun, 01 Aug 2010 23:32:03 +0200, giggz giggzou...@gmail.com a écrit : ... J'ai mis la valeur de la mtu du NAS à 1492. mais ça ne change rien. De plsu sur mon laptop la valeur est aussi à 1492 et pourtant tout marche très bien entre ce laptop et le NAS. la valeur std pour un LAN est de 1500 bytes. je sais...mais malheureusement mon routeur force la valeur à 1492 au moment où il y a dialogue avec le serveur dhcp. En gros si je fonctionne en ip fixe je peux forcer la mtu à 1500. mais si je laisse le dhcp faire son travail j'ai tjs une mtu à 1492. bon en même temps c'est po très grave si tout est à 1492, non ? ça dépend à combien est le router du côté WAN. c'est une valeur qu'il fallait souvent forcer il-y-a une dizaine d'année, mais plus maintenant; je me rappelle qu'avec le câble, un déphasage entre 1492 et 1500 pouvait mener jusqu'à -80% de perfs sur le LAN. en gros, c'est plus rapide de fragmenter. -- -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20100801235800.53172...@anubis.defcon1
Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
Salut, giggz a écrit : je veux récupérer un fichier situé sur mon NAS à partir de mon eeepc sous debian lenny/backport. et ça ne fonctionne pas. Les symptomes sont les suivants : - je peux me connecter sans problème de mon eeepc vers le NAS via ftp, cifs ou NFS. je peux lister et me balader dans mes partages. Par contre dès que j'essaye de récupérer un fichier, le transfert se bloque quelque soit le logiciel utilisé (ftp, gftp, NFS+rsync, cifs+rsync). et il me transfère 12K... :D Est-ce que le transfert d'un fichier de moins de 12 ko marche ? Et dans l'autre sens, est-ce que l'envoi d'un fichier de plus de 12 ko marche ? - j'ai bouté mon eeepc sous w7. aucun problème de transfert via samba. - j'ai bouté mon eeepc sous backtrack. aucun problème de transfert via ftp. - je pensais à une mauvaise configuration du NAS; j'ai donc tenté avec mon autre laptop sous SID. aucun problème. tout marche : ftp, cifs et NFS. C'est peut-être un problème réseau, au niveau TCP/IP, comme une option TCP mal gérée d'un côté ou de l'autre. Quelles versions de noyau sur les différentes machines ? Tu pourrais faire une capture de trafic lors d'un transfert (en FTP de préférence, c'est plus simple) quand ça marche et quand ça bloque pour comparer. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4c540800.3030...@plouf.fr.eu.org
Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
Le 31/07/2010 13:24, Pascal Hambourg a écrit : Salut, giggz a écrit : je veux récupérer un fichier situé sur mon NAS à partir de mon eeepc sous debian lenny/backport. et ça ne fonctionne pas. Les symptomes sont les suivants : - je peux me connecter sans problème de mon eeepc vers le NAS via ftp, cifs ou NFS. je peux lister et me balader dans mes partages. Par contre dès que j'essaye de récupérer un fichier, le transfert se bloque quelque soit le logiciel utilisé (ftp, gftp, NFS+rsync, cifs+rsync). et il me transfère 12K... :D Est-ce que le transfert d'un fichier de moins de 12 ko marche ? oui mais c'est très lent. Et dans l'autre sens, est-ce que l'envoi d'un fichier de plus de 12 ko marche ? oui (test avec un fichier de 100Mo) avec un taux de transfert rapide normal pour du 100Mb/s. - j'ai bouté mon eeepc sous w7. aucun problème de transfert via samba. - j'ai bouté mon eeepc sous backtrack. aucun problème de transfert via ftp. - je pensais à une mauvaise configuration du NAS; j'ai donc tenté avec mon autre laptop sous SID. aucun problème. tout marche : ftp, cifs et NFS. C'est peut-être un problème réseau, au niveau TCP/IP, comme une option TCP mal gérée d'un côté ou de l'autre. Quelles versions de noyau sur les différentes machines ? Tu pourrais faire une capture de trafic lors d'un transfert (en FTP de préférence, c'est plus simple) quand ça marche et quand ça bloque pour comparer. sur le eeepc j'ai une debian lenny + backport. J'ai le dernier kernel de backport le : 2.6.32-5 sur le laptop j'ai une debian sid avec un 2.6.34.1 compilé à la main. Pour la capture j'utilise quoi ? tcpdump ou wireshark ? quel est le plus simple à utiliser pour qqn qui n'y connait pas grand chose ? Merci Guillaume -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/i312vp$tj...@dough.gmane.org
Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
giggz a écrit : Pour la capture j'utilise quoi ? tcpdump ou wireshark ? Peu importe, celui que tu sais le mieux utiliser. Il y a aussi tshark, la version console de wireshark. quel est le plus simple à utiliser pour qqn qui n'y connait pas grand chose ? Probablement wireshark, parce que c'est graphique. Mais tcpdump est simple à utiliser pour afficher une trace facile à copier à la souris ou à rediriger dans un fichier : # tcpdump -ni interface host adresse_ip_nas (ctrl+c pour quitter) -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4c54142c.9000...@plouf.fr.eu.org
Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
Pascal Hambourg a écrit : # tcpdump -ni interface host adresse_ip_nas (ctrl+c pour quitter) A la réflexion, l'option -v serait utile pour afficher plus des détails sur les paquets. # tcpdump -nvi interface host adresse_ip_nas -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4c5414bc.9080...@plouf.fr.eu.org
Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
Le 31/07/2010 14:16, Pascal Hambourg a écrit : giggz a écrit : Pour la capture j'utilise quoi ? tcpdump ou wireshark ? Peu importe, celui que tu sais le mieux utiliser. Il y a aussi tshark, la version console de wireshark. quel est le plus simple à utiliser pour qqn qui n'y connait pas grand chose ? Probablement wireshark, parce que c'est graphique. Mais tcpdump est simple à utiliser pour afficher une trace facile à copier à la souris ou à rediriger dans un fichier : # tcpdump -ni interface host adresse_ip_nas (ctrl+c pour quitter) ok. je fais un tcpdump -nvi eth0 host adresse_ip_nas pb_NAS.txt question de NooB : les login/password en ftp sont en clair. si je copie/colle ce que me sort tcpdump, est ce que mon login/password est lisible ? Merci :) Guillaume -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/i314rc$3u...@dough.gmane.org
Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
giggz a écrit : question de NooB : les login/password en ftp sont en clair. si je copie/colle ce que me sort tcpdump, est ce que mon login/password est lisible ? Normalement par défaut tcpdump ne fait pas l'analyse du protocole FTP (wireshark/tshark si en revanche) et n'affiche pas non plus les données des paquets, seulement les champs des en-têtes. Mais ça dépend peut-être des versions. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4c541988.4010...@plouf.fr.eu.org
Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport
Le 31/07/2010 14:39, Pascal Hambourg a écrit : giggz a écrit : question de NooB : les login/password en ftp sont en clair. si je copie/colle ce que me sort tcpdump, est ce que mon login/password est lisible ? Normalement par défaut tcpdump ne fait pas l'analyse du protocole FTP (wireshark/tshark si en revanche) et n'affiche pas non plus les données des paquets, seulement les champs des en-têtes. Mais ça dépend peut-être des versions. ok. je joins le fichier en question. apparemment je ne vois pas mon mot de passe...c'est déjà ça. dis moi qd même, s'il te plait, si je dois ou non changer mon password ;) En gros voilà ce que j'ai fait : je me connecte sur mon NAS en ftp -p ensuite je me balade dans mes répertoires et lance un get. rien ne se passe. je fais un ctrl+c et encore un autre. puis bye et voilà. Merci d'avance Guillaume 14:24:39.874317 IP (tos 0x0, ttl 64, id 46792, offset 0, flags [DF], proto TCP (6), length 44) 192.168.0.4.57933 192.168.0.5.10021: S, cksum 0x1e6a (correct), 2487174152:2487174152(0) win 5808 mss 1452 14:24:39.874537 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 44) 192.168.0.5.10021 192.168.0.4.57933: S, cksum 0x39f4 (correct), 619233108:619233108(0) ack 2487174153 win 5840 mss 1460 14:24:39.874653 IP (tos 0x0, ttl 64, id 46793, offset 0, flags [DF], proto TCP (6), length 40) 192.168.0.4.57933 192.168.0.5.10021: ., cksum 0x51d1 (correct), ack 1 win 5808 14:24:39.913398 IP (tos 0x0, ttl 64, id 54843, offset 0, flags [DF], proto TCP (6), length 102) 192.168.0.5.10021 192.168.0.4.57933: P 1:63(62) ack 1 win 5840 14:24:39.913523 IP (tos 0x10, ttl 64, id 46794, offset 0, flags [DF], proto TCP (6), length 40) 192.168.0.4.57933 192.168.0.5.10021: ., cksum 0x5193 (correct), ack 63 win 5808 14:24:41.039400 IP (tos 0x10, ttl 64, id 46795, offset 0, flags [DF], proto TCP (6), length 52) 192.168.0.4.57933 192.168.0.5.10021: P, cksum 0x8180 (incorrect (- 0xb886), 1:13(12) ack 63 win 5808 14:24:41.039608 IP (tos 0x0, ttl 64, id 54844, offset 0, flags [DF], proto TCP (6), length 40) 192.168.0.5.10021 192.168.0.4.57933: ., cksum 0x5167 (correct), ack 13 win 5840 14:24:41.048400 IP (tos 0x0, ttl 64, id 54845, offset 0, flags [DF], proto TCP (6), length 73) 192.168.0.5.10021 192.168.0.4.57933: P, cksum 0x4201 (correct), 63:96(33) ack 13 win 5840 14:24:41.048513 IP (tos 0x10, ttl 64, id 46796, offset 0, flags [DF], proto TCP (6), length 40) 192.168.0.4.57933 192.168.0.5.10021: ., cksum 0x5166 (correct), ack 96 win 5808 14:24:43.991953 IP (tos 0x10, ttl 64, id 46797, offset 0, flags [DF], proto TCP (6), length 54) 192.168.0.4.57933 192.168.0.5.10021: P, cksum 0x8182 (incorrect (- 0x6891), 13:27(14) ack 96 win 5808 14:24:44.025514 IP (tos 0x0, ttl 64, id 54846, offset 0, flags [DF], proto TCP (6), length 40) 192.168.0.5.10021 192.168.0.4.57933: ., cksum 0x5138 (correct), ack 27 win 5840 14:24:44.085207 IP (tos 0x0, ttl 64, id 54847, offset 0, flags [DF], proto TCP (6), length 66) 192.168.0.5.10021 192.168.0.4.57933: P, cksum 0x70c2 (correct), 96:122(26) ack 27 win 5840 14:24:44.085331 IP (tos 0x10, ttl 64, id 46798, offset 0, flags [DF], proto TCP (6), length 40) 192.168.0.4.57933 192.168.0.5.10021: ., cksum 0x513e (correct), ack 122 win 5808 14:24:44.085444 IP (tos 0x10, ttl 64, id 46799, offset 0, flags [DF], proto TCP (6), length 46) 192.168.0.4.57933 192.168.0.5.10021: P, cksum 0x817a (incorrect (- 0x9d78), 27:33(6) ack 122 win 5808 14:24:44.085624 IP (tos 0x0, ttl 64, id 54848, offset 0, flags [DF], proto TCP (6), length 40) 192.168.0.5.10021 192.168.0.4.57933: ., cksum 0x5118 (correct), ack 33 win 5840 14:24:44.089889 IP (tos 0x0, ttl 64, id 54849, offset 0, flags [DF], proto TCP (6), length 59) 192.168.0.5.10021 192.168.0.4.57933: P, cksum 0xe9ac (correct), 122:141(19) ack 33 win 5840 14:24:44.127296 IP (tos 0x10, ttl 64, id 46800, offset 0, flags [DF], proto TCP (6), length 40) 192.168.0.4.57933 192.168.0.5.10021: ., cksum 0x5125 (correct), ack 141 win 5808 14:24:47.747473 IP (tos 0x10, ttl 64, id 46801, offset 0, flags [DF], proto TCP (6), length 46) 192.168.0.4.57933 192.168.0.5.10021: P, cksum 0x817a (incorrect (- 0xa075), 33:39(6) ack 141 win 5808 14:24:47.755380 IP (tos 0x0, ttl 64, id 54850, offset 0, flags [DF], proto TCP (6), length 89) 192.168.0.5.10021 192.168.0.4.57933: P 141:190(49) ack 39 win 5840 14:24:47.755508 IP (tos 0x10, ttl 64, id 46802, offset 0, flags [DF], proto TCP (6), length 40) 192.168.0.4.57933 192.168.0.5.10021: ., cksum 0x50ee (correct), ack 190 win 5808 14:24:47.755666 IP (tos 0x0, ttl 64, id 13693, offset 0, flags [DF], proto TCP (6), length 44) 192.168.0.4.49548 192.168.0.5.10099: S, cksum 0xac50 (correct), 2613432078:2613432078(0) win 5808 mss 1452 14:24:47.755863 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 44) 192.168.0.5.10099 192.168.0.4.49548: S, cksum 0x5cac (correct), 617753241:617753241(0) ack 2613432079 win 5840 mss
