nous sommes au moins deux a avoir constaté un phénomène très étrange
avec FreeBSD 6.2 et le firewall pf sur une connexion ADSL FreeBox.
Dans les deux cas :
- la machine FreeBSD est branchée à la freebox et utilise pf pour faire
firewall et NAT.
- le pf.conf est assez simple et n'utilise pas ALTQ.
Nous avons remarqué que sur des requêtes vers
<http://test-debit.free.fr/>, la vitesse de téléchargement est très
inférieure à ce qu'elle devrait être (autour de 140 Ko/s pour moi), mais
qu'on peut cumuler plusieurs téléchargements (3 fichiers simultanément à
120 ko/s par exemple).
Si on désactive pf (soit en déchargeant le module du kernel, soit en
ajoutant "set skip on $ext_if" dans pf.conf), le débit que je constate
atteint 650-700 ko/s pour le même fichier.
Deux choses sont troublantes :
- pf semble faire du throttling tout seul, de manière tout à fait
inappropriée
- pf ne se comporte pas de cette manière avec tous les serveurs ! Dans
certains cas, on constate qu'on atteint bien le taux de transfert
maximum "malgré" pf, alors que test-debit.free.fr va toujours donner un
transfert plus lent que la normale avec pf activé.
J'en suis venu à la conclusion qu'il y a quelque chose qui change dans
la gestion TCP quand pf est activé, et que ce changement induit une
chute de débit quand on interagit avec certains serveurs, dont ceux de
free (mais pas uniquement, malheureusement).
Je n'ai aucun sysctl particuliers, ALTQ n'est pas actif (et qu'il soit
ou non compilé dans le kernel ne change rien au résultat). Nous avons
aussi testé des pf.conf sans "scrub in all" : pas mieux.
Si j'ai le temps, je ferai des tests chez moi ce soir pour voir si le mode bridge ou routeur change quelque chose.
Malheureusement, ça m'a quand même bien l'air lié aux équipements Free et à leur config. Je ne sais pas si l'aide internationale va trouver l'origine du problème...
La question reste quand même de savoir ce que pf modifie par rapport au FreeBSD de base pour que le comportment des équipements de Free change à un ce point...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Wed, 01 Aug 2007 17:49:42 +0200,
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> écrivait (wrote):
j'y crois moyen, mais pour ne rien rater, j'ai mouillé les types de
freebsd-pf ;)
Si j'ai le temps, je ferai des tests chez moi ce soir pour voir si le
mode bridge ou routeur change quelque chose.
Malheureusement, ça m'a quand même bien l'air lié aux équipements Free
et à leur config. Je ne sais pas si l'aide internationale va trouver
l'origine du problème...
La question reste quand même de savoir ce que pf modifie par rapport
au FreeBSD de base pour que le comportment des équipements de Free
change à un ce point...
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Si j'ai le temps, je ferai des tests chez moi ce soir pour voir si le mode bridge ou routeur change quelque chose.
Malheureusement, ça m'a quand même bien l'air lié aux équipements Free et à leur config. Je ne sais pas si l'aide internationale va trouver l'origine du problème...
La question reste quand même de savoir ce que pf modifie par rapport au FreeBSD de base pour que le comportment des équipements de Free change à un ce point...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Thierry Thomas
Mercredi 01 août 2007 à 16:02 GMT, Paul Gaborit a écrit :
Si j'ai le temps, je ferai des tests chez moi ce soir pour voir si le mode bridge ou routeur change quelque chose.
J'ai une config similaire (pf + NAT, boiboîte en bridge), et je n'ai pas de soucis : je récupère le 16384.rnd à 782 kBps, ce qui est tout à fait correct vu mon type de connexion (non dégroupé, à la campagne). -- Th. Thomas.
Mercredi 01 août 2007 à 16:02 GMT, Paul Gaborit a écrit :
Si j'ai le temps, je ferai des tests chez moi ce soir pour voir si le
mode bridge ou routeur change quelque chose.
J'ai une config similaire (pf + NAT, boiboîte en bridge), et je n'ai pas
de soucis : je récupère le 16384.rnd à 782 kBps, ce qui est tout à fait
correct vu mon type de connexion (non dégroupé, à la campagne).
--
Th. Thomas.
Mercredi 01 août 2007 à 16:02 GMT, Paul Gaborit a écrit :
Si j'ai le temps, je ferai des tests chez moi ce soir pour voir si le mode bridge ou routeur change quelque chose.
J'ai une config similaire (pf + NAT, boiboîte en bridge), et je n'ai pas de soucis : je récupère le 16384.rnd à 782 kBps, ce qui est tout à fait correct vu mon type de connexion (non dégroupé, à la campagne). -- Th. Thomas.
j'ai une V5 en mode bridge avec "grossomodo" le même pf.conf (avec des ALTQ) et pas de soucis je suis à 850Ko/s sur l'iso (http://test-debit.free.fr/),
Malheureusement, ça m'a quand même bien l'air lié aux équipements Free et à leur config. à tout hazard cela ne peut'il pas venir de la freebox elle même ?
mauvaise update du firmware , ou simplement une mauvaise config du FastPath (qui peut foutre pas mal de bordel si il est mal reglé) .
j'ai une V5 en mode bridge
avec "grossomodo" le même pf.conf (avec des ALTQ) et pas de soucis je
suis à 850Ko/s sur l'iso (http://test-debit.free.fr/),
Malheureusement, ça m'a quand même bien l'air lié aux équipements Free
et à leur config.
à tout hazard cela ne peut'il pas venir de la freebox elle même ?
mauvaise update du firmware , ou simplement une mauvaise config du
FastPath (qui peut foutre pas mal de bordel si il est mal reglé) .
j'ai une V5 en mode bridge avec "grossomodo" le même pf.conf (avec des ALTQ) et pas de soucis je suis à 850Ko/s sur l'iso (http://test-debit.free.fr/),
Malheureusement, ça m'a quand même bien l'air lié aux équipements Free et à leur config. à tout hazard cela ne peut'il pas venir de la freebox elle même ?
mauvaise update du firmware , ou simplement une mauvaise config du FastPath (qui peut foutre pas mal de bordel si il est mal reglé) .
Kevin Vanier
patpro ~ patrick proniewski
In article <46b0bbe5$0$27846$, kavanier wrote:
Malheureusement, ça m'a quand même bien l'air lié aux équipements Free et à leur config. à tout hazard cela ne peut'il pas venir de la freebox elle même ?
mauvaise update du firmware , ou simplement une mauvaise config du FastPath (qui peut foutre pas mal de bordel si il est mal reglé) .
aucune idée. Comment cela serait vérifiable ? et comment expliquer que je retrouve mon débit quand pf est désactivé ?
patpro
-- http://www.patpro.net/
In article <46b0bbe5$0$27846$426a74cc@news.free.fr>,
kavanier <kavanier@free.fr> wrote:
Malheureusement, ça m'a quand même bien l'air lié aux équipements Free
et à leur config.
à tout hazard cela ne peut'il pas venir de la freebox elle même ?
mauvaise update du firmware , ou simplement une mauvaise config du
FastPath (qui peut foutre pas mal de bordel si il est mal reglé) .
aucune idée. Comment cela serait vérifiable ? et comment expliquer que
je retrouve mon débit quand pf est désactivé ?
Malheureusement, ça m'a quand même bien l'air lié aux équipements Free et à leur config. à tout hazard cela ne peut'il pas venir de la freebox elle même ?
mauvaise update du firmware , ou simplement une mauvaise config du FastPath (qui peut foutre pas mal de bordel si il est mal reglé) .
aucune idée. Comment cela serait vérifiable ? et comment expliquer que je retrouve mon débit quand pf est désactivé ?
patpro
-- http://www.patpro.net/
patpro ~ patrick proniewski
In article , Thierry Thomas wrote:
Mercredi 01 août 2007 à 16:02 GMT, Paul Gaborit a écrit :
Si j'ai le temps, je ferai des tests chez moi ce soir pour voir si le mode bridge ou routeur change quelque chose.
J'ai une config similaire (pf + NAT, boiboîte en bridge), et je n'ai pas de soucis : je récupère le 16384.rnd à 782 kBps, ce qui est tout à fait correct vu mon type de connexion (non dégroupé, à la campagne).
ouin. mais alors qu'est ce qui coince...
patpro
-- http://www.patpro.net/
In article <slrnfb1ef9.u9c.tthomas@graf.pompo.net>,
Thierry Thomas <tthomas@mail.dotcom.fr> wrote:
Mercredi 01 août 2007 à 16:02 GMT, Paul Gaborit a écrit :
Si j'ai le temps, je ferai des tests chez moi ce soir pour voir si le
mode bridge ou routeur change quelque chose.
J'ai une config similaire (pf + NAT, boiboîte en bridge), et je n'ai pas
de soucis : je récupère le 16384.rnd à 782 kBps, ce qui est tout à fait
correct vu mon type de connexion (non dégroupé, à la campagne).
Mercredi 01 août 2007 à 16:02 GMT, Paul Gaborit a écrit :
Si j'ai le temps, je ferai des tests chez moi ce soir pour voir si le mode bridge ou routeur change quelque chose.
J'ai une config similaire (pf + NAT, boiboîte en bridge), et je n'ai pas de soucis : je récupère le 16384.rnd à 782 kBps, ce qui est tout à fait correct vu mon type de connexion (non dégroupé, à la campagne).
ouin. mais alors qu'est ce qui coince...
patpro
-- http://www.patpro.net/
kavanier
aucune idée. Comment cela serait vérifiable ? Vous pouvez faire un hard_reboot :/
et comment expliquer que je retrouve mon débit quand pf est désactivé ? Peut-être le réglage de votre FastPath est trop élevé ,
cela crée des pertes de packets , pf peut s'en rend compte et ainsi fasse tomber la connection .
c'est une idée , peut-être pas la bonne ...
aucune idée. Comment cela serait vérifiable ?
Vous pouvez faire un hard_reboot :/
et comment expliquer que
je retrouve mon débit quand pf est désactivé ?
Peut-être le réglage de votre FastPath est trop élevé ,
cela crée des pertes de packets , pf peut s'en rend compte
et ainsi fasse tomber la connection .
aucune idée. Comment cela serait vérifiable ? Vous pouvez faire un hard_reboot :/
et comment expliquer que je retrouve mon débit quand pf est désactivé ? Peut-être le réglage de votre FastPath est trop élevé ,
cela crée des pertes de packets , pf peut s'en rend compte et ainsi fasse tomber la connection .
c'est une idée , peut-être pas la bonne ...
patpro ~ patrick proniewski
In article <46b122ec$0$18578$, kavanier wrote:
aucune idée. Comment cela serait vérifiable ? Vous pouvez faire un hard_reboot :/
la freebox comme le freebsd ont eu leur lot de reboot
et comment expliquer que je retrouve mon débit quand pf est désactivé ? Peut-être le réglage de votre FastPath est trop élevé ,
cela crée des pertes de packets , pf peut s'en rend compte et ainsi fasse tomber la connection .
c'est une idée , peut-être pas la bonne ...
j'étais en train de faire des tests avec la hotline de free quand je me suis aperçu que sans pf mon débit était bien meilleur, je pense que le tech me l'aurait dit si mon fastpath était problématique, non ?
patpro
-- http://www.patpro.net/
In article <46b122ec$0$18578$426a74cc@news.free.fr>,
kavanier <kavanier@free.fr> wrote:
aucune idée. Comment cela serait vérifiable ?
Vous pouvez faire un hard_reboot :/
la freebox comme le freebsd ont eu leur lot de reboot
et comment expliquer que
je retrouve mon débit quand pf est désactivé ?
Peut-être le réglage de votre FastPath est trop élevé ,
cela crée des pertes de packets , pf peut s'en rend compte
et ainsi fasse tomber la connection .
c'est une idée , peut-être pas la bonne ...
j'étais en train de faire des tests avec la hotline de free quand je me
suis aperçu que sans pf mon débit était bien meilleur, je pense que le
tech me l'aurait dit si mon fastpath était problématique, non ?
aucune idée. Comment cela serait vérifiable ? Vous pouvez faire un hard_reboot :/
la freebox comme le freebsd ont eu leur lot de reboot
et comment expliquer que je retrouve mon débit quand pf est désactivé ? Peut-être le réglage de votre FastPath est trop élevé ,
cela crée des pertes de packets , pf peut s'en rend compte et ainsi fasse tomber la connection .
c'est une idée , peut-être pas la bonne ...
j'étais en train de faire des tests avec la hotline de free quand je me suis aperçu que sans pf mon débit était bien meilleur, je pense que le tech me l'aurait dit si mon fastpath était problématique, non ?
patpro
-- http://www.patpro.net/
Erwan David
patpro ~ patrick proniewski écrivait :
In article , Erwan David wrote:
Tu ne filtrerais pas les ICMP par hasard ?
$ grep -i icmp /etc/pf.conf icmp_types = "echoreq" pass in inet proto icmp all icmp-type $icmp_types keep state pass out on $ext_if proto { udp, icmp } all keep state
je les filtre donc en partie
Mon ruleset est inspiré de <http://www.openbsd.org/faq/pf/example1.html>
Et pour quelle mauvaise raison les filtrer ?
Tu prends l'autoroute en refusant de regarder la signalisation...
-- Erwan
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> écrivait :
In article <87wswffe8a.fsf@nez-casse.depot.rail.eu.org>,
Erwan David <erwan@rail.eu.org> wrote:
Tu ne filtrerais pas les ICMP par hasard ?
$ grep -i icmp /etc/pf.conf
icmp_types = "echoreq"
pass in inet proto icmp all icmp-type $icmp_types keep state
pass out on $ext_if proto { udp, icmp } all keep state
je les filtre donc en partie
Mon ruleset est inspiré de <http://www.openbsd.org/faq/pf/example1.html>
Et pour quelle mauvaise raison les filtrer ?
Tu prends l'autoroute en refusant de regarder la signalisation...
$ grep -i icmp /etc/pf.conf icmp_types = "echoreq" pass in inet proto icmp all icmp-type $icmp_types keep state pass out on $ext_if proto { udp, icmp } all keep state
je les filtre donc en partie
Mon ruleset est inspiré de <http://www.openbsd.org/faq/pf/example1.html>
Et pour quelle mauvaise raison les filtrer ?
Tu prends l'autoroute en refusant de regarder la signalisation...
-- Erwan
patpro ~ patrick proniewski
In article , Erwan David wrote:
patpro ~ patrick proniewski écrivait :
In article , Erwan David wrote:
Tu ne filtrerais pas les ICMP par hasard ?
$ grep -i icmp /etc/pf.conf icmp_types = "echoreq" pass in inet proto icmp all icmp-type $icmp_types keep state pass out on $ext_if proto { udp, icmp } all keep state
je les filtre donc en partie
Mon ruleset est inspiré de <http://www.openbsd.org/faq/pf/example1.html>
Et pour quelle mauvaise raison les filtrer ?
comme je disais plus haut, mon ruleset est inspiré de la doc, j'ai repris cette partie telle quelle.
Tu prends l'autoroute en refusant de regarder la signalisation...
j'ai désactivé le filtrage, en mettant : pass in inet proto icmp all keep state à la place de pass in inet proto icmp all icmp-type $icmp_types keep state sans que cela change quoi que ce soit à mon problème de débit.
patpro
-- http://www.patpro.net/
In article <87y7gutqb4.fsf@nez-casse.depot.rail.eu.org>,
Erwan David <erwan@rail.eu.org> wrote:
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> écrivait :
In article <87wswffe8a.fsf@nez-casse.depot.rail.eu.org>,
Erwan David <erwan@rail.eu.org> wrote:
Tu ne filtrerais pas les ICMP par hasard ?
$ grep -i icmp /etc/pf.conf
icmp_types = "echoreq"
pass in inet proto icmp all icmp-type $icmp_types keep state
pass out on $ext_if proto { udp, icmp } all keep state
je les filtre donc en partie
Mon ruleset est inspiré de <http://www.openbsd.org/faq/pf/example1.html>
Et pour quelle mauvaise raison les filtrer ?
comme je disais plus haut, mon ruleset est inspiré de la doc, j'ai
repris cette partie telle quelle.
Tu prends l'autoroute en refusant de regarder la signalisation...
j'ai désactivé le filtrage, en mettant :
pass in inet proto icmp all keep state
à la place de
pass in inet proto icmp all icmp-type $icmp_types keep state
sans que cela change quoi que ce soit à mon problème de débit.
$ grep -i icmp /etc/pf.conf icmp_types = "echoreq" pass in inet proto icmp all icmp-type $icmp_types keep state pass out on $ext_if proto { udp, icmp } all keep state
je les filtre donc en partie
Mon ruleset est inspiré de <http://www.openbsd.org/faq/pf/example1.html>
Et pour quelle mauvaise raison les filtrer ?
comme je disais plus haut, mon ruleset est inspiré de la doc, j'ai repris cette partie telle quelle.
Tu prends l'autoroute en refusant de regarder la signalisation...
j'ai désactivé le filtrage, en mettant : pass in inet proto icmp all keep state à la place de pass in inet proto icmp all icmp-type $icmp_types keep state sans que cela change quoi que ce soit à mon problème de débit.
patpro
-- http://www.patpro.net/
patpro ~ patrick proniewski
In article , patpro ~ patrick proniewski wrote:
j'y crois moyen, mais pour ne rien rater, j'ai mouillé les types de freebsd-pf ;) Si tu veux jeter un ¦il :
Malheureusement, ça m'a quand même bien l'air lié aux équipements Free et à leur config. Je ne sais pas si l'aide internationale va trouver l'origine du problème...
Bon, J'ai testé une config légère de pf :
ext_if = "fxp0" int_if = "em0" scrub in all nat on $ext_if from 192.168.0.1/24 to any -> $ext_if pass quick log all keep state
et mon problème de débit a disparu, donc ça doit venir de mes règles...
patpro
-- http://www.patpro.net/
In article <patpro-20A253.17494201082007@news-1.proxad.net>,
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> wrote:
j'y crois moyen, mais pour ne rien rater, j'ai mouillé les types de
freebsd-pf ;)
Si tu veux jeter un ¦il :
Malheureusement, ça m'a quand même bien l'air lié aux équipements Free
et à leur config. Je ne sais pas si l'aide internationale va trouver
l'origine du problème...
Bon, J'ai testé une config légère de pf :
ext_if = "fxp0"
int_if = "em0"
scrub in all
nat on $ext_if from 192.168.0.1/24 to any -> $ext_if
pass quick log all keep state
et mon problème de débit a disparu, donc ça doit venir de mes règles...
Malheureusement, ça m'a quand même bien l'air lié aux équipements Free et à leur config. Je ne sais pas si l'aide internationale va trouver l'origine du problème...
Bon, J'ai testé une config légère de pf :
ext_if = "fxp0" int_if = "em0" scrub in all nat on $ext_if from 192.168.0.1/24 to any -> $ext_if pass quick log all keep state
et mon problème de débit a disparu, donc ça doit venir de mes règles...
