Voila les commandes :
ifconfig em0_vlan838 vlanpcp 4
ifconfig em0_vlan840 vlanpcp 5

Remplace les interfaces par les tiennes.

A chaque reboot
Par contre moi avec les prio ça fonctionne pas 

Bon avec priorités ça marche pas non plus... je vais tenter avec la version alpha de pfSense pour voir.

Sympa les options dans le nouveau pfSense ceci dit

c'est à dire ? tu as fais des découvertes intéressantes ? tu as aiguisé ma curiosité mais pas suffisamment pour "googler" ou installer un pfsense 2.2

sinon juste pour info, à titre perso depuis que j'ai pfsense j'avais la même IP publique depuis 7j ça vient de changer au bout de 7j d'uptime !
je sais pas si vous avez constatez la même chose ? (enfin ceux qui ont tenu 7j d'uptime ^^)

Premier aperçu des options avancés de pfsense 2.2.
La config DHCP va surement être beaucoup plus simple

Bonjour à tous, et merci à kouakattak pour ce magnifique tuto !
Après quelques jours passés à essayer de faire marcher la TV (sans succès) j'ai décidé de m'inscrire pour partager mon expérience.

J'ai l'offre Zen 100MB et la livebox "blanche", qui demande une configuration légèrement différente pour obtenir un bail DHCP sur le VLAN 838. Les infos qu'elle envoie sont :
Vendor class identifier: "sagem"
Client identifier: 1:< MAC réel de la livebox>
User class: "FSVDSL_livebox.MLTV.sagem.Livebox2"

Détail amusant : le user class fait exactement 34 caractères, ce qui correspond au guillemet (") en code ASCII.
Du coup, problème : comme dhclient n'ajoute pas lui-même la longueur du champ dans ses "send" il faut l'intégrer en début de chaine. Et malgré plusieurs essais je n'ai pas réussi à lui faire gober la longueur correctement (il parse une chaîne vide).

J'ai donc modifié dhclient pour qu'il attende un hex array au lieu d'une string. J'ai attaché cette version, qui supprime également l'ajout automatique du hostname quand il n'est pas spécifié (pas vraiment nécessaire d'envoyer "pfSense" ou autre à Orange). Attention, architecture amd64 !

J'ai donc la config suivante :
interface "bridge0" {
timeout 60;
retry 15;
select-timeout 0;
request subnet-mask, routers, ntp-servers, www-server, classless-routes;
send dhcp-class-identifier "sagem";
send dhcp-client-identifier 01:<MAC livebox>;
send user-class 22:46:53:56:44:53:4c:5f:6c:69:76:65:62:6f:78:2e:4d:4c:54:56:2e:73:61:67:65:6d:2e:4c:69:76:65:62:6f:78:32;
initial-interval 1;
script "/sbin/dhclient-script";
}

Dans mon cas la priorité du VLAN 838 est effectivement requise à 4 pour avoir une réponse du serveur DHCP.

Donc où donc est le problème ? Il se trouve que j'utilise pfSense 2.1.3 sur ESXi 5.5 avec des adaptateurs réseaux virtuels (E1000 ou vmxnet3), et les réponses "DHCP Offer" du serveur distant sur le VLAN 838 arrivent sur l'interface parent, et non sur l'interface VLAN 838 (et donc le bridge).
Le dhclient ne reçoit pas de réponse, et c'est l’échec.
(Je pense que Krome doit avoir le même problème.)

J'ai trouvé le bug suivant : https://redmine.pfsense.org/issues/2613 qui est résolu. Mais je pense qu'il doit rester quelques "trucs étranges" au niveau de la gestion des VLAN couplée aux pilotes virtuels. (Comme dit Krome, le VLAN 835 marche très bien.) Ça mériterait peut-être d'en ouvrir un nouveau.