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.
On 2 août, 07:30, patpro ~ patrick proniewski wrote:
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
Attention le "hard_reboot" s'effectue en débranchant et rebranchant 4 fois de suite la freeboite. Ainsi elle retourne en paramètres usine et télécharge le firmware. Il faut ensuite la rebooter une fois de plus pour qu'elle repasse en mode routeur.
Autre piste (mais j'en doute au vu des différences sensibles avec et sans PF):
J'ai eu des problèmes de débit lors des pics de traffic (gros download ou gros upload) avec ma freebox v4. Il s'est avéré que l'alimentation de la box était défectueuse et chauffait pas mal. Le plus sournois c'est que la freebox semble dans ce cas là toujours bien alimentée (pas de baisse de luminosité ou autre).
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 ?
Il ne faut pas surestimer la hotline de free (surtout le premier niveau). Cette même hotline ne m'avais pas suggéré de vérifier l'al im, alors que selon certains forums, cet un problème assez courant.
Peut-être peut-tu essayer les groupe usenet de free, ils ont la réputation d'être bien plus calés que la hotline téléphonique.
-- Laurent C.
On 2 août, 07:30, patpro ~ patrick proniewski
<pat...@boleskine.patpro.net> wrote:
In article <46b122ec$0$18578$426a7...@news.free.fr>,
kavanier <kavan...@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
Attention le "hard_reboot" s'effectue en débranchant et rebranchant 4
fois de suite la freeboite. Ainsi elle retourne en paramètres usine et
télécharge le firmware. Il faut ensuite la rebooter une fois de plus
pour qu'elle repasse en mode routeur.
Autre piste (mais j'en doute au vu des différences sensibles avec et
sans PF):
J'ai eu des problèmes de débit lors des pics de traffic (gros download
ou gros upload) avec ma freebox v4. Il s'est avéré que l'alimentation
de la box était défectueuse et chauffait pas mal. Le plus sournois
c'est que la freebox semble dans ce cas là toujours bien alimentée
(pas de baisse de luminosité ou autre).
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 ?
Il ne faut pas surestimer la hotline de free (surtout le premier
niveau). Cette même hotline ne m'avais pas suggéré de vérifier l'al im,
alors que selon certains forums, cet un problème assez courant.
Peut-être peut-tu essayer les groupe usenet de free, ils ont la
réputation d'être bien plus calés que la hotline téléphonique.
On 2 août, 07:30, patpro ~ patrick proniewski wrote:
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
Attention le "hard_reboot" s'effectue en débranchant et rebranchant 4 fois de suite la freeboite. Ainsi elle retourne en paramètres usine et télécharge le firmware. Il faut ensuite la rebooter une fois de plus pour qu'elle repasse en mode routeur.
Autre piste (mais j'en doute au vu des différences sensibles avec et sans PF):
J'ai eu des problèmes de débit lors des pics de traffic (gros download ou gros upload) avec ma freebox v4. Il s'est avéré que l'alimentation de la box était défectueuse et chauffait pas mal. Le plus sournois c'est que la freebox semble dans ce cas là toujours bien alimentée (pas de baisse de luminosité ou autre).
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 ?
Il ne faut pas surestimer la hotline de free (surtout le premier niveau). Cette même hotline ne m'avais pas suggéré de vérifier l'al im, alors que selon certains forums, cet un problème assez courant.
Peut-être peut-tu essayer les groupe usenet de free, ils ont la réputation d'être bien plus calés que la hotline téléphonique.
-- Laurent C.
Erwan David
patpro ~ patrick proniewski écrivait :
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.
Donc ce n'était sans doute pas un problème de PATH MTU discovery. Une hypothèse en moins.
-- Erwan
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> écrivait :
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.
Donc ce n'était sans doute pas un problème de PATH MTU discovery. Une
hypothèse en moins.
$ 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.
Donc ce n'était sans doute pas un problème de PATH MTU discovery. Une hypothèse en moins.
-- Erwan
patpro ~ patrick proniewski
In article , patpro ~ Patrick Proniewski wrote:
Bonjour,
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.
J'ai trouvé. J'ai eu un peu de temps pour tester différentes parties de mon pf.conf, et à force de commenter/décommenter des règles, j'ai mis la main sur la fautive :
pass out on $ext_if proto tcp all modulate state flags S/SA
J'ai remplacé cette dernière par :
pass out on $ext_if proto tcp all flags S/SA keep state
et maintenant mon débit est revenu à la normale ! Ouf. Moralité, le réseau de Free (ou freebsd 6.2) n'aime pas "modulate state"
patpro
-- http://www.patpro.net/
In article <patpro-75DDA1.12081501082007@localhost>,
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> wrote:
Bonjour,
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.
J'ai trouvé. J'ai eu un peu de temps pour tester différentes parties de
mon pf.conf, et à force de commenter/décommenter des règles, j'ai mis la
main sur la fautive :
pass out on $ext_if proto tcp all modulate state flags S/SA
J'ai remplacé cette dernière par :
pass out on $ext_if proto tcp all flags S/SA keep state
et maintenant mon débit est revenu à la normale !
Ouf.
Moralité, le réseau de Free (ou freebsd 6.2) n'aime pas "modulate state"
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.
J'ai trouvé. J'ai eu un peu de temps pour tester différentes parties de mon pf.conf, et à force de commenter/décommenter des règles, j'ai mis la main sur la fautive :
pass out on $ext_if proto tcp all modulate state flags S/SA
J'ai remplacé cette dernière par :
pass out on $ext_if proto tcp all flags S/SA keep state
et maintenant mon débit est revenu à la normale ! Ouf. Moralité, le réseau de Free (ou freebsd 6.2) n'aime pas "modulate state"
