Auteur Sujet: Reverse Engineering : Nouveau système de génération de l'option 90 DHCP (Lu 218446 fois)

nivek1612 · « **Réponse #300 le:** 18 octobre 2018 à 19:25:14 »

Citation de: kalistyan le 18 octobre 2018 à 18:55:21

J'ai lancé un Wireshark lors d'un renew.

Comment affiner le filtrage ?

Je suis loin d'être un expert en analyse de trafic.

Edit :

Code: [Sélectionner]
Bootstrap Protocol (Discover) Message type: Boot Request (1) Hardware type: Ethernet (0x01) Hardware address length: 6 Hops: 0 Transaction ID: 0x0b08ee55 Seconds elapsed: 55 Bootp flags: 0x0000 (Unicast) Client IP address: 0.0.0.0 Your (client) IP address: 0.0.0.0 Next server IP address: 0.0.0.0 Relay agent IP address: 0.0.0.0 Client MAC address: IntelCor_65:75:08 (00:1b:21:65:75:08) Client hardware address padding: 00000000000000000000 Server host name not given Boot file name not given Magic cookie: DHCP Option: (53) DHCP Message Type (Discover) Length: 1 DHCP: Discover (1) Option: (50) Requested IP Address Length: 4 Requested IP Address: 86.248.192.72 Option: (60) Vendor class identifier Length: 5 Vendor class identifier: sagem Option: (61) Client identifier Length: 7 Hardware type: Ethernet (0x01) Client MAC address: IntelCor_65:75:08 (00:1b:21:65:75:08) Option: (12) Host Name Length: 7 Host Name: pfsense Option: (77) User Class Information Length: 44 Instance of User Class: [0] Option: (255) End Option End: 255
L'@IP demandée 86.248.192.72 correspond à celle que j'avais avant la coupure.

Que souhaitez-vous avoir d'autre comme info ?

Encore merci.

c'est la mauvaise demande dhcp dont vous avez besoin de celle émise sur le VLAN 832. Si c'est sur le VLAN 832, il manque la chaîne d'authentification

utilisez le programme wirehark, il est gratuit et facilite la recherche

nivek1612 · « **Réponse #301 le:** 18 octobre 2018 à 19:38:24 »

Citation de: Catalyst le 18 octobre 2018 à 13:28:35

Cela a été évoqué ces derniers jours dans le forum mais où ?

Suivant la marque de la carte et l'OS, il faut faire un peu de paramétrage dessus pour voir les en-têtes 802.1q dans Wireshark. Par exemple sous Windows avec Intel :

https://www.intel.com/content/www/us/en/support/articles/000005498/network-and-i-o/ethernet-products.html

Le broadcast est bien sûr taggé, comme le reste.

kalistyan · « **Réponse #302 le:** 18 octobre 2018 à 21:13:41 »

Citation de: nivek1612 le 18 octobre 2018 à 19:25:14

c'est la mauvaise demande dhcp dont vous avez besoin de celle émise sur le VLAN 832. Si c'est sur le VLAN 832, il manque la chaîne d'authentification

utilisez le programme wirehark, il est gratuit et facilite la recherche

Il s'agit bien du vlan832.
Mon fichier de conf est paramétré pour envoyer la demande d'option 90 (rfc3118-auth).

N'ayant pas de trace de cette option dans la capture, il doit y avoir une erreur de syntaxe ou autre...

Personne n'utilise pfSense dans le coin ?

Citer

interface "igb0.832" {

send-interface "igb0";
vlan-id 832;
vlan-pcp 6;

# DHCP Protocol Timing Values
timeout 60;
retry 15;
reboot 0;
select-timeout 0;
initial-interval 1;

# DHCP Protocol Options
send dhcp-class-identifier "sagem";
send user-class "+FSVDSL_livebox.Internet.softathome.Livebox3";
send rfc3118-auth 00:00:00:00:00:00:00:00:00:00:00:1a:09:00:00:05:58:01:03:41:01:0d:xx:xx:xx:xx:xx:xx:xx:xx:x:xx:xx:3c:12:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:03:13:zz:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh;
request subnet-mask, broadcast-address, dhcp-lease-time, dhcp-renewal-time, dhcp-rebinding-time, domain-search, routers, domain-name-servers, rfc3118-auth;

script "/sbin/dhclient-script";
}

xavierg · « **Réponse #303 le:** 18 octobre 2018 à 21:18:39 »

Rassure-nous, tu n'as pas laissé les xx, les sa:lt, le zz et les ha:sh ?
Et c'est normal que tu "request" rfc3118-auth ?

kalistyan · « **Réponse #304 le:** 18 octobre 2018 à 21:29:14 »

Citation de: xavierg le 18 octobre 2018 à 21:18:39

Rassure-nous, tu n'as pas laissé les xx, les sa:lt, le zz et les ha:sh ?
Et c'est normal que tu "request" rfc3118-auth ?

Soit rassuré, j'ai bien remplacé les xx, les sa:lt, etc...

La conf a fonctionné pendant 2 ans.

Quant à la demande de "request" rfc3118-auth ?
Pour être honnête, aucune idée... A l'époque, j'ai testé comme ceci et cela fonctionnait.

xavierg · « **Réponse #305 le:** 18 octobre 2018 à 21:38:27 »

Ça devient difficile de deviner ce qui cloche... est-ce que PfSense te fournit la sortie (stdout + stderr) de l'utilitaire dhclient ?

kalistyan · « **Réponse #306 le:** 18 octobre 2018 à 21:44:47 »

Comme tu dis, cela devient complexe.

Je ne pourrais malheureusement pas te répondre, manque de connaissance sur le sujet.

Edit :

Avant :

Citer

send rfc3118-auth 00:00:00:00:00:00:00:00:00:00:00:1a:09:00:00:05:58:01:03:41:01:0d:xx:xx:xx:xx:xx:xx:xx:xx:x:xx:xx:3c:12:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:03:13:zz:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh;

Après

Citer

send option-90 00:00:00:00:00:00:00:00:00:00:00:1a:09:00:00:05:58:01:03:41:01:0d:xx:xx:xx:xx:xx:xx:xx:xx:x:xx:xx:3c:12:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:03:13:zz:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh;

Et cela fonctionne !!!

Code: [Sélectionner]

Option: (90) Authentication
    Length: 70
    Protocol: configuration token (0)
    Algorithm: 0
    Replay Detection Method: Monotonically-increasing counter (0)
    RDM Replay Detection Value: 0x0000000000000000
    Authentication Information: "information floutée"

Un grand merci pour votre réactivité, en espérant être tranquille pour quelques mois...

nivek1612 · « **Réponse #307 le:** 18 octobre 2018 à 22:04:01 »

Maintenant, je pense comprendre le problème. Je pense que pfSense a pris les modifications de code développées par OPNsense pour la prise en charge du VLAN dhclient et l’authentification Orange. C'est bien en tant que vrai source ouverte. OPNsense a implèmenté dhclient en utilisant 'option-90', qui est la syntaxe la plus correcte. pfSense avait utilisé rfc3118-auth pour le binary non officiel. Je soupçonne que vous avez récemment pris une mise à jour de correctif, ce qui explique pourquoi elle a soudainement cessé de fonctionner. Est-ce possible ? Ce qui est également étrange, c’est que OPNsense prenne en charge le paramètre vlan-pcp avec "vlan-parent" spécifiant l’interface d’envoi. Mais pfSense utilisait "send-interface".

xavierg · « **Réponse #308 le:** 18 octobre 2018 à 22:05:36 »

Ah p****n, je croyais que c'était une spécificité du dhclient de FreeBSD qui te dispensait de déclarer le numéro de l'option... J'aurais dû être plus bavard... Bon, c'est bien si c'est réglé

Autre sujet : j'ai eu un feedback de l'ISC sur l'option generate(). Le mainteneur a qualifié la chose d'intéressante addition à la syntaxe de configuration mais a rappelé que la version 4.4.1 était la dernière version à apporter de nouvelles fonctionnalités. Du coup ils verront s'ils intègrent la fonctionnalité ou non dans la future 4.4.2 -- wait & see...

nivek1612 · « **Réponse #309 le:** 18 octobre 2018 à 22:18:39 »

@kalistyan

Quelles sont vos vitesses?
J'ai une théorie selon laquelle s'ils sont pauvres, changez votre option et remplace

send-interface "igb0";
vlan-id 832;
vlan-pcp 6;

à

vlan-parent "igb0";
vlan-id 832;
vlan-pcp 6;

kalistyan · « **Réponse #310 le:** 19 octobre 2018 à 12:43:19 »

@nivek1612

C'est tout à fait possible, car je suis récemment passé de la version 2.4.3 à 2.4.4, mais n'ayant pas eu de coupure sur le coup, je n'ai pas fait le rapprochement.
Chose étrange, après vérification, je n'ai rien trouvé dans le changelog qui correspondrait...

Quant au débit, j'ai une moyenne de 550/250.

computman · « **Réponse #311 le:** 20 octobre 2018 à 03:12:52 »

Hello

Apparemment ce n'est pas nouveau cette chaîne supplèmentaire dans l'option 90

Déjà en Janvier de cette année la LB l'envoyait

https://lafibre.info/remplacer-livebox/tv-sur-le-vlan-840-ne-fonctionne-plus/msg511398/?topicseen#msg511398