# [Abandon] Gentoo et driver BNX2 qui drop des paquets

## Mythy

Bonjour à tous !

Après 2 jours de recherche sur mon problème, j'en arrive à comprendre qu'en faite le driver BNX2 pour Gentoo semble avoir quelques soucis dans son fonctionnement par default.

En faite, la carte réseau fonctionne, mais plein de paquets sont dropés plus ou moins aléatoirement.

Étant donné que c'est pour mettre un OpenVPN dessus, les performances sont juste horribles...

J'ai trouvé quelques infos à ce sujet mais rien de bien concluant pour le moment :/

Une fois de plus je compte sur votre aide pour m'aider à résoudre ce schmilblik  :Smile: 

Voici quelques informations au sujet du dédié et du réseau :

 *Quote:*   

> # lspci
> 
> 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v2/Ivy Bridge DRAM Controller (rev 09)
> 
> 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port (rev 09)
> ...

 

 *Quote:*   

> # ifconfig
> 
> eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
> 
>         ether d4:ae:52:c8:b1:cf  txqueuelen 1000  (Ethernet)
> ...

 

 *Quote:*   

>  # ethtool -k eth0
> 
> Features for eth0:
> 
> rx-checksumming: on
> ...

 

 *Quote:*   

> # ethtool -c eth0
> 
> Coalesce parameters for eth0:
> 
> Adaptive RX: off  TX: off
> ...

 

 *Quote:*   

> # ethtool -g eth0
> 
> Ring parameters for eth0:
> 
> Pre-set maximums:
> ...

 

----------

## StinGer_Uesugi

Heuu juste une question.

Est-ce que ta machine qui fait office de serveur VPN est NATée ? Si c'est le cas, tes clients VPN ont un double NAT à traverser : celui du serveur, puis celui de la passerelle qui relie le serveur VPN à Internet. Typiquement, cela arrive quand c'est une "box" ou une passerelle qui te donne l'accès à Internet et pas un simple modem piloté par le serveur. En gros, quand tu as :

```
client VPN ---> serveur VPN ---> gateway ---> Internet
```

Si tu es dans ce cas, ce qu'il se passe c'est que le double NATage rajoute trop d'overhead dans les paquets réseau, qui dépassent donc le MTU. D'où le drop (à mon avis).

Pour résoudre ce problème, il faut faire du traversial NAT (NAT-T) et diminuer le MTU sur le serveur VPN. On trouve des tutos et des explications sur le pourquoi/comment de tout ça.

Maintenant, si les paquets qui n'ont rien à voir avec le VPN sont perdus (genre en désactivant le VPN et en naviguant simplement sur Internet), tout ce que je viens de dire ne sert à rien et le problème vient d'ailleurs...

----------

## Mythy

Merci pour ton aide et ta réponse rapide  :Wink: 

En faite il 'agit d'une dedibox de chez SAS Online donc il n'y a pas de soucis du genre je pense

J'ai déjà 2 serveurs dédiés chez OVH qui font office de serveur VPN et il n'y a aucun problème avec le même type d'install de Gentoo etc...

La dedibox de chez SAS online (celle qui déconne avec BNX2) a aussi été installé sur le debian proposé par SAS Online, j'y ai ajouté un serveur OpenVPN et ça marche super bien.

Par contre, avec cette dedibox qui marche nickel sur debian, pas moyen de la faire bien marcher sur Gentoo.

Ayant 8 serveurs sur Gentoo, j'aimerais vraiment utiliser que Gentoo, d’où mon besoin de résoudre ce problème de BNX2 sur Gentoo  :Confused: 

Et là pour tester, j'ai lancé un emerge --sync, il perd 4 paquets 

PS: J'adore ta signature

----------

## El_Goretto

 *StinGer_Uesugi wrote:*   

> Heuu juste une question.
> 
> Est-ce que ta machine qui fait office de serveur VPN est NATée ? Si c'est le cas, tes clients VPN ont un double NAT à traverser : celui du serveur, puis celui de la passerelle qui relie le serveur VPN à Internet. Typiquement, cela arrive quand c'est une "box" ou une passerelle qui te donne l'accès à Internet et pas un simple modem piloté par le serveur. En gros, quand tu as :
> 
> ```
> ...

 

Si j'en conviens, le coup de la MTU est un bonne idée, j'ai comme l'impression que le reste est un peu flou (en tout cas pour moi  :Wink: ). Le coup du NAT-T, ça ne concerne pas OpenVPN. C'est une technique liée à IPsec, si je ne m'abuse. Ensuite, le fait d'avoir des équipements qui routent successivement les paquets ne signifie pas que "plus il y en a, et plus il faut baisser la MTU".

Ceci dit, j'ai peut être mal compris ce que tu voulais dire  :Smile: 

Autre piste, il y a parfois des firmwares qui vont avec les puces broadcom. Il n'est pas inenvisageable que charger le firmware à jour corrige un bug hardware (c'est du microcode pour le matériel, après tout).

----------

## Mythy

En faite sur Debian TOUT est nickel, avec MTU à 1500 (comme sur Gentoo)

 *Quote:*   

> DEBIAN eth0      Link encap:Ethernet  HWaddr d4:ae:52:c8:b1:cf
> 
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> 
>           RX packets:5366 errors:0 dropped:0 overruns:0 frame:0
> ...

 

J'entame le 4e jour de recherche et je vous avoue que les résultats sont impressionnants (mais pas dans le bon sens), j'ai testé une 15aine de conf/kernel/driver différents (réglages ethtool, disable_msi, copie de driver, etc...) et y'a rien à faire oO

Encore là je viens de réinstaller en mettant bnx2 et bnx2x, il me fait un truc en plus avec bnx2x mais ça change rien :/

 *Quote:*   

> sd-51340 ~ # cat /var/log/messages | grep -a bnx2
> 
> Oct 24 10:43:41 sd-51340 kernel: [    9.505232] bnx2x: Broadcom NetXtreme II 5771x/578xx 10/20-Gigabit Ethernet Driver bnx2x 1.78.17-0 (2013/04/11)
> 
> Oct 24 10:59:54 sd-51340 kernel: [    9.505049] bnx2: Broadcom NetXtreme II Gigabit Ethernet Driver bnx2 v2.2.3 (June 27, 2012)
> ...

 

La seule différence que je vois pour le moment, c'est Debian qui utilise un ancien driver par rapport à Gentoo :

 *Quote:*   

> GENTOO sd-51340 ~ # ethtool -i eth0
> 
> driver: bnx2
> 
> version: 2.2.3
> ...

 

 *Quote:*   

> DEBIAN root@sd-51340:~# ethtool -i eth0
> 
> driver: bnx2
> 
> version: 2.1.11
> ...

 

----------

## Mythy

 *El_Goretto wrote:*   

> Autre piste, il y a parfois des firmwares qui vont avec les puces broadcom. Il n'est pas inenvisageable que charger le firmware à jour corrige un bug hardware (c'est du microcode pour le matériel, après tout).

 

Tu pourrais m'en dire plus ? ^^

----------

## El_Goretto

 *Mythy wrote:*   

>  *El_Goretto wrote:*   Autre piste, il y a parfois des firmwares qui vont avec les puces broadcom. Il n'est pas inenvisageable que charger le firmware à jour corrige un bug hardware (c'est du microcode pour le matériel, après tout). 
> 
> Tu pourrais m'en dire plus ? ^^

 

 :Smile: 

```

[I] sys-kernel/linux-firmware

     Available versions:  20130421 ~20130530 ~20130711 20130728 **99999999 {savedconfig}

     Installed versions:  20130728(17:16:23 21/10/2013)(-savedconfig)

     Homepage:            http://git.kernel.org/?p=linux/kernel/git/firmware/linux-firmware.git

     Description:         Linux firmware files

# ls /lib/firmware/bnx2*

/lib/firmware/bnx2x-e1-4.8.53.0.fw  /lib/firmware/bnx2x-e1-5.2.7.0.fw    /lib/firmware/bnx2x-e1h-5.2.13.0.fw

/lib/firmware/bnx2x-e1-5.2.13.0.fw  /lib/firmware/bnx2x-e1h-4.8.53.0.fw  /lib/firmware/bnx2x-e1h-5.2.7.0.fw

/lib/firmware/bnx2:

bnx2-mips-06-4.6.16.fw    bnx2-mips-06-6.2.3.fw      bnx2-mips-09-6.0.17.fw  bnx2-rv2p-06-5.0.0.j3.fw   bnx2-rv2p-09-6.0.17.fw

bnx2-mips-06-5.0.0.j3.fw  bnx2-mips-09-4.6.17.fw     bnx2-mips-09-6.2.1a.fw  bnx2-rv2p-06-6.0.15.fw     bnx2-rv2p-09ax-5.0.0.j10.fw

bnx2-mips-06-5.0.0.j6.fw  bnx2-mips-09-5.0.0.j15.fw  bnx2-mips-09-6.2.1b.fw  bnx2-rv2p-09-4.6.15.fw     bnx2-rv2p-09ax-5.0.0.j3.fw

bnx2-mips-06-6.0.15.fw    bnx2-mips-09-5.0.0.j3.fw   bnx2-mips-09-6.2.1.fw   bnx2-rv2p-09-5.0.0.j10.fw  bnx2-rv2p-09ax-6.0.17.fw

bnx2-mips-06-6.2.1.fw     bnx2-mips-09-5.0.0.j9.fw   bnx2-rv2p-06-4.6.16.fw  bnx2-rv2p-09-5.0.0.j3.fw

/lib/firmware/bnx2x:

bnx2x-e1-6.0.34.0.fw  bnx2x-e1-7.0.29.0.fw  bnx2x-e1h-6.0.34.0.fw  bnx2x-e1h-7.0.29.0.fw  bnx2x-e2-6.0.34.0.fw  bnx2x-e2-7.0.29.0.fw

bnx2x-e1-6.2.5.0.fw   bnx2x-e1-7.2.16.0.fw  bnx2x-e1h-6.2.5.0.fw   bnx2x-e1h-7.2.16.0.fw  bnx2x-e2-6.2.5.0.fw   bnx2x-e2-7.2.16.0.fw

bnx2x-e1-6.2.9.0.fw   bnx2x-e1-7.2.51.0.fw  bnx2x-e1h-6.2.9.0.fw   bnx2x-e1h-7.2.51.0.fw  bnx2x-e2-6.2.9.0.fw   bnx2x-e2-7.2.51.0.fw

bnx2x-e1-7.0.20.0.fw  bnx2x-e1-7.8.17.0.fw  bnx2x-e1h-7.0.20.0.fw  bnx2x-e1h-7.8.17.0.fw  bnx2x-e2-7.0.20.0.fw  bnx2x-e2-7.8.17.0.fw

bnx2x-e1-7.0.23.0.fw  bnx2x-e1-7.8.2.0.fw   bnx2x-e1h-7.0.23.0.fw  bnx2x-e1h-7.8.2.0.fw   bnx2x-e2-7.0.23.0.fw  bnx2x-e2-7.8.2.0.fw

```

Normalement chargé par le driver au boot de la machine.

----------

## Mythy

Oui si je dis pas de bêtises il charge bnx2-mips-09-6.2.1b.fw

Mais comment je peux dire au kernel d'en charger un autre ? 

(J'ai mis le driver dans le kernel, pas en module)

----------

## El_Goretto

Je ne saurais pas te dire comment spécifier explicitement un firmware plutôt qu'un autre, car en général, il n'y en a pas plusieurs mais un seul qui convient.

Exemple pour le driver broadcom tg3:

```
# ls /lib/firmware/tigon/

 tg3.bin  tg3_tso5.bin  tg3_tso.bin
```

Pour bnx2, c'est super bizarre, on dirait qu'il y en a plusieurs versions (noms des fichiers? on dirait du <driver>-<archi chip>-<ID chip>-<version>.fw). Et bizarrement, sous debian wheezy c'est pareil:

```
$ ls /lib/firmware/bnx2/

bnx2-mips-06-5.0.0.j3.fw  bnx2-mips-06-6.2.3.fw     bnx2-mips-09-6.2.1a.fw  bnx2-rv2p-06-5.0.0.j3.fw  bnx2-rv2p-09-5.0.0.j3.fw  bnx2-rv2p-09ax-5.0.0.j3.fw

bnx2-mips-06-6.2.1.fw     bnx2-mips-09-5.0.0.j3.fw  bnx2-mips-09-6.2.1b.fw  bnx2-rv2p-06-6.0.15.fw    bnx2-rv2p-09-6.0.17.fw    bnx2-rv2p-09ax-6.0.17.fw
```

--

edit: peut être une explication: http://packages.debian.org/wheezy/firmware-bnx2

Il semble que les firmwares ne soient pas retrocompatibles, donc à chaque version noyau correspond une certaine version du firmware. Mais normalement, le driver devrait prendre le bon au chargement.

----------

## StinGer_Uesugi

Totalement hors du sujet, désolé.   :Embarassed:  

 *El_Goretto wrote:*   

> Si j'en conviens, le coup de la MTU est un bonne idée, j'ai comme l'impression que le reste est un peu flou (en tout cas pour moi ). Le coup du NAT-T, ça ne concerne pas OpenVPN. C'est une technique liée à IPsec, si je ne m'abuse.

 

Oui j'y ai pensé après, je me suis mélangé entre OpenVPN et OpenSwan. 

 *El_Goretto wrote:*   

> Ensuite, le fait d'avoir des équipements qui routent successivement les paquets ne signifie pas que "plus il y en a, et plus il faut baisser la MTU".
> 
> Ceci dit, j'ai peut être mal compris ce que tu voulais dire 

 

Non, pas du tout, sauf quand tu fais du IPSec, pour des raisons que j'ai un peu oubliées, dès que tu fais 2 NAT, il faut réduire le MTU. Je crois déjà que ce n'est vrai qu'en mode transport où le payload seulement est crypté mais où un NAT/PAT causerait une modification du hash. Du coup, encapsulation dans un autre paquet, overhead NAT-T et si le paquet encapsulé faisait déjà 1500 octets -> pan t'es mort parce que le paquet final déborde.

Mais honnêtement, j'ai oublié les détails donc je peux totalement me planter.

Et sinon pour en revenir au sujet, j'aurais jamais pensé aux blob binaires... Mais du coup, en renommant les fichiers/versions que tu ne veux pas, ça ne pourrait pas le faire ? C'est saaaaaaaaaaale je le reconnais, mais comme j'ai aucune idée non plus de comment spécifier au kernel quel firmware prendre exactement...

PS @Mythy : je précise que quand je parle de "smoke and fly", je fais référence à ça. Nan parce que sinon on va me prendre pour un drogué.   :Smile:  

----------

## Mythy

Merci pour m'avoir lu et répondu

Mais malheureusement ça ne m'aide pas des masses à résoudre ce problème avec mes connaissances :/

J'ai donc abandonné l'idée de mettre le serveur VPN sur ce dédié Classic + Gen2

----------

## El_Goretto

Pour ma culture, tu as dit avoir fait des tests avec des kernels, (c'est peut être idiot) mais tu as pu booter la gentoo en utilisant le kernel debian ("qui marche")? C'est pour savoir si c'est lié à la configuration le l'OS ou au matériel/drivers.

----------

## Mythy

Non je ne l'ai pas fais vu que je ne savais pas que c'était possible  :Smile: 

Mais ça me semble une piste intéressante !

Tu pourrais me dire cmt je retrouve le kernel en place depuis Debian ?

----------

## El_Goretto

Ah, j'imaginais que tu étais en dual  boot sur cette machine.

Ben l'idée est de prendre le noyau et l'initrd de la debian (que tu rapportes avoir validé sur ce matériel), et de "merger" la config des bootloaders (grub?): partir de la conf débian mais en spécifiant les partitions/disques correspondant à ceux contenant la gentoo (visible dans la conf du bootloader en charge de la gentoo).

C'est peut être une grosse bêtise, ceci dit, je ne l'ai jamais fait moi-même  :Smile: 

Mais là, comme çà, je ne vois pas ce qui pourrait bloquer techniquement.

----------

## Mythy

Pas de soucis mais je ne suis qu'en dédié même en local  :Wink: 

Par contre j'utilise grub:0 et je n'utilise pas d'initrd etc...

Sur la Debian dans /boot j'ai ça :

config-3.2.0-4-amd64  grub  initrd.img-3.2.0-4-amd64  lost+found  System.map-3.2.0-4-amd64  vmlinuz-3.2.0-4-amd64

Et sur Gentoo dans /boot j'ai que le kernel en un fichier

Comment je peux faire du coup ?  :Confused:  Il y a moyen de récupérer le .config de la debian qq part ?

----------

## El_Goretto

Je ne vais pas avoir le temps de te détailler tout point par point (de toutes façons, un peu de recherche, c'est bon pour ta culture aussi  :Wink: ), mais pour debian, c'est une config grub 2 qui est générée et visible sous /boot/grub/grub.cfg (je prends des raccourcis, pas taper ceux qui connaissent debian et grub2).

Pour gentoo, c'est du grub 1, et c'est /boot/grub/menu.lst (de tête).

Comme je disais, debian utilise un noyau ( vmlinuz-3.2.0-4-amd64 ) et un initrd (initrd.img-3.2.0-4-amd64) qu'il te faut prendre en compte dans la configuration de grub 1 que tu vas écrire (pour cela, je te renvois à la doc gentoo sur les bootloader, prends le cas ou tu as kernel+initrd.)

----------

## Mythy

Sans grand espoir j'ai testé ça : 

Copier le contenu de config-3.2.0-4-amd64 dans le .config sur Gentoo et compiler

C'est une config 3.2 et sur Gentoo je suis en 3.10.7, ça a bien compilé et installé

Par contre ça boot pas (pas de /var/log/messages), mais laissez tombé ça me gonfle ct'histoire ^_^'

Merci quand même pour votre aide  :Smile: 

----------

## xaviermiller

Logique : tu dois d'abord faire un make oldconfig, puis vérifier la configuration avec make menuconfig : des trucs ont changé de nom, ont été restructurés, et il faut vérifier à la main. Ou prendre la même version de noyau, ce qui est plus sage pour commencer  :Wink: 

----------

## El_Goretto

Surtout, recompiler un noyau gentoo à partir d'une une config kernel debian est moins pertinent que prendre le noyau debian direct: en effet, on n'est pas à l'abri d'un patchset différent (probablement le cas d'ailleurs).

Donc si ça déconne toujours, on ne peut pas en conclure grand chose. :/

----------

## Mythy

Oui certes mais bon après 5 jours @ 10heures/jour la dessus

Une pause s'impose  :Smile: 

----------

