Messages récents
#41
K-net en général / Re : [Infra] - remplacement ro...
Dernier message par K-net TEAM - D.M. - 20 Décembre 2025 à 05:16:53Petit retour à chaud de cette opération dont les objectifs fixés sont atteints.
Cela se traduit par une meilleur utilisation des ressources. On mesure une augmentation significative des volumes échangés aux heures de pointe et une utilisation bien plus qualitative des ressources dont nous disposons.
Il s'agit de l'analyse de notre point de vue, n'hésitez pas à partager vos retours.
On suspend nos travaux sur l'infra jusqu'au 12 janvier 2026.
D.M.
Cela se traduit par une meilleur utilisation des ressources. On mesure une augmentation significative des volumes échangés aux heures de pointe et une utilisation bien plus qualitative des ressources dont nous disposons.
Il s'agit de l'analyse de notre point de vue, n'hésitez pas à partager vos retours.
On suspend nos travaux sur l'infra jusqu'au 12 janvier 2026.
D.M.
#42
Internet / Re : Coupures intempestives !
Dernier message par K-net TEAM - D.M. - 20 Décembre 2025 à 04:51:53Bonsoir oui on clôture les tickets.
Dans le volume des tickets traités, malheureusement sur le segment FTTH plus de 90% sont des problèmes de coupure physique de la liaison une fois le problème signalé, le client est réparé. On pourrait presque clôturer après signalement.
Rarement les clients appellent pour dire c'est réparé, bisous !
S'agissant de ce dossier, une capture de paquets couvrant une période où le problème se présente permettra de suivre les demandes DHCP du routeur et les réponses du serveur DHCP. Normalement, on devrait voir le routeur dire, s'il a une réponse, je ne veux pas de cette réponse parce que !
S'il n'a pas de réponse on devrait le voir demander encore et encore.
Avec le Pfsense évoqué plus haut, vous pouvez faire cette capture, avec les autres je ne sais pas !
Idéalement faut tout capturer et filtrer ensuite.
Sur le segment FTTH nous utilisons le DHCP, sur d'autres segments on peut vous fournir un bloc IP dédié du /30 au /22, une passerelle dédiée...
Voici le conseil de "CHAT GPT" pour une capture ciblée :
Pour diagnostiquer un problème DHCP avec tcpdump, l'objectif est de capturer les échanges entre le client et le serveur DHCP, qui utilisent UDP ports 67 (serveur) et 68 (client).
Commande de base (recommandée)
sudo tcpdump -i eth0 -n -vvv -s 0 -w dhcp_debug.pcap port 67 or port 68
Explication des options
-i eth0 : interface réseau (remplacer par la bonne interface, ex. ens192, wlan0)
-n : pas de résolution DNS (plus lisible, plus rapide)
-vvv : niveau de verbosité élevé (utile pour DHCP)
-s 0 : capture complète des paquets (important pour DHCP options)
-w dhcp_debug.pcap : écriture dans un fichier lisible avec Wireshark
port 67 or port 68 : filtre DHCP
Capture en clair (sans fichier)
Si tu veux simplement voir les échanges en temps réel :
sudo tcpdump -i eth0 -n -vvv port 67 or port 68
Capture côté client uniquement
Pour vérifier si le client envoie bien ses requêtes :
sudo tcpdump -i eth0 -n -vvv udp and src port 68
Capture côté serveur uniquement
Pour vérifier les réponses du serveur :
Sudo tcpdump -i eth0 -n -vvv udp and src port 67
Points clés à observer
Lors de l'analyse, tu dois voir la séquence DHCP classique :
DHCPDISCOVER
DHCPOFFER
DHCPREQUEST
DHCPACK
Si un message manque, cela oriente directement le diagnostic (pare-feu, relais DHCP, VLAN, etc.).
Dans la commande il y a le filtre, si pas d'anomalie DHCP, alors il suffit d'enlever le filtre Sans supplément, on peut même faire ça !
Oui. Si tu me fournis une capture non filtrée (pcap), je peux analyser le flux et identifier toutes les anomalies susceptibles d'entraîner la perte d'une adresse IP DHCP, de manière structurée et exhaustive.
Ce que je peux analyser précisément dans un pcap DHCP
1. Cycle DHCP complet
Vérification de la conformité et de l'ordre des messages :
DHCPDISCOVER
DHCPOFFER
DHCPREQUEST
DHCPACK / DHCPNAK
Détection de :
ACK manquant
OFFER multiples (serveurs concurrents)
NAK tardif ou inattendu
2. Durée de bail et renouvellement
Valeurs T1 / T2 / Lease Time
Tentatives de renouvellement (unicast vs broadcast)
Absence de réponse serveur lors du renew
Expiration du bail sans fallback valide
3. Conflits DHCP
Plusieurs serveurs DHCP répondant
Incohérence des Server Identifier
Changements d'IP serveur entre OFFER et ACK
4. Problèmes réseau sous-jacents
Pertes de paquets DHCP (DISCOVER sans OFFER)
Fragmentation ou MTU anormal
Réémissions excessives
Latence anormale entre messages
5. Relais DHCP / Option 82
Présence et cohérence de l'Option 82
Modification ou suppression par un équipement intermédiaire
Réponses rejetées par le serveur à cause de l'Option 82
6. Anomalies client
Reboot ou reset stack réseau
Envoi de DHCPDECLINE
Changement de MAC / Client-ID
Passage en APIPA (169.254.0.0/16)
7. Sécurité / filtrage
DHCP Snooping (ACK bloqués)
Firewall bloquant UDP 67/68
Réécritures de broadcast → unicast
8. Comportements non standards
ACK sans OFFER préalable
REQUEST pour une IP hors pool
Renouvellement vers un serveur incorrect
Incohérences dans les options DHCP (router, subnet, DNS)
Format attendu
Idéalement :
Fichier .pcap ou .pcapng
Indication du contexte :
Client OS (Linux, Windows, embedded, VM, etc.)
IP perdue immédiatement ou après un certain temps
Présence de VLAN, firewall, relais DHCP
Moment exact du symptôme si connu
Limites à connaître
Je détecte les anomalies visibles dans le trafic
Je ne peux pas inférer :
un bug interne du client sans manifestation réseau
une action locale hors réseau (script, agent, etc.)
Pourquoi se priver d'une capture ? la capture c'est la prise de sang du flux réseau !
A dispo pour trouver !
D.M.
Dans le volume des tickets traités, malheureusement sur le segment FTTH plus de 90% sont des problèmes de coupure physique de la liaison une fois le problème signalé, le client est réparé. On pourrait presque clôturer après signalement.
Rarement les clients appellent pour dire c'est réparé, bisous !
S'agissant de ce dossier, une capture de paquets couvrant une période où le problème se présente permettra de suivre les demandes DHCP du routeur et les réponses du serveur DHCP. Normalement, on devrait voir le routeur dire, s'il a une réponse, je ne veux pas de cette réponse parce que !
S'il n'a pas de réponse on devrait le voir demander encore et encore.
Avec le Pfsense évoqué plus haut, vous pouvez faire cette capture, avec les autres je ne sais pas !
Idéalement faut tout capturer et filtrer ensuite.
Sur le segment FTTH nous utilisons le DHCP, sur d'autres segments on peut vous fournir un bloc IP dédié du /30 au /22, une passerelle dédiée...
Voici le conseil de "CHAT GPT" pour une capture ciblée :
Pour diagnostiquer un problème DHCP avec tcpdump, l'objectif est de capturer les échanges entre le client et le serveur DHCP, qui utilisent UDP ports 67 (serveur) et 68 (client).
Commande de base (recommandée)
sudo tcpdump -i eth0 -n -vvv -s 0 -w dhcp_debug.pcap port 67 or port 68
Explication des options
-i eth0 : interface réseau (remplacer par la bonne interface, ex. ens192, wlan0)
-n : pas de résolution DNS (plus lisible, plus rapide)
-vvv : niveau de verbosité élevé (utile pour DHCP)
-s 0 : capture complète des paquets (important pour DHCP options)
-w dhcp_debug.pcap : écriture dans un fichier lisible avec Wireshark
port 67 or port 68 : filtre DHCP
Capture en clair (sans fichier)
Si tu veux simplement voir les échanges en temps réel :
sudo tcpdump -i eth0 -n -vvv port 67 or port 68
Capture côté client uniquement
Pour vérifier si le client envoie bien ses requêtes :
sudo tcpdump -i eth0 -n -vvv udp and src port 68
Capture côté serveur uniquement
Pour vérifier les réponses du serveur :
Sudo tcpdump -i eth0 -n -vvv udp and src port 67
Points clés à observer
Lors de l'analyse, tu dois voir la séquence DHCP classique :
DHCPDISCOVER
DHCPOFFER
DHCPREQUEST
DHCPACK
Si un message manque, cela oriente directement le diagnostic (pare-feu, relais DHCP, VLAN, etc.).
Dans la commande il y a le filtre, si pas d'anomalie DHCP, alors il suffit d'enlever le filtre Sans supplément, on peut même faire ça !
Oui. Si tu me fournis une capture non filtrée (pcap), je peux analyser le flux et identifier toutes les anomalies susceptibles d'entraîner la perte d'une adresse IP DHCP, de manière structurée et exhaustive.
Ce que je peux analyser précisément dans un pcap DHCP
1. Cycle DHCP complet
Vérification de la conformité et de l'ordre des messages :
DHCPDISCOVER
DHCPOFFER
DHCPREQUEST
DHCPACK / DHCPNAK
Détection de :
ACK manquant
OFFER multiples (serveurs concurrents)
NAK tardif ou inattendu
2. Durée de bail et renouvellement
Valeurs T1 / T2 / Lease Time
Tentatives de renouvellement (unicast vs broadcast)
Absence de réponse serveur lors du renew
Expiration du bail sans fallback valide
3. Conflits DHCP
Plusieurs serveurs DHCP répondant
Incohérence des Server Identifier
Changements d'IP serveur entre OFFER et ACK
4. Problèmes réseau sous-jacents
Pertes de paquets DHCP (DISCOVER sans OFFER)
Fragmentation ou MTU anormal
Réémissions excessives
Latence anormale entre messages
5. Relais DHCP / Option 82
Présence et cohérence de l'Option 82
Modification ou suppression par un équipement intermédiaire
Réponses rejetées par le serveur à cause de l'Option 82
6. Anomalies client
Reboot ou reset stack réseau
Envoi de DHCPDECLINE
Changement de MAC / Client-ID
Passage en APIPA (169.254.0.0/16)
7. Sécurité / filtrage
DHCP Snooping (ACK bloqués)
Firewall bloquant UDP 67/68
Réécritures de broadcast → unicast
8. Comportements non standards
ACK sans OFFER préalable
REQUEST pour une IP hors pool
Renouvellement vers un serveur incorrect
Incohérences dans les options DHCP (router, subnet, DNS)
Format attendu
Idéalement :
Fichier .pcap ou .pcapng
Indication du contexte :
Client OS (Linux, Windows, embedded, VM, etc.)
IP perdue immédiatement ou après un certain temps
Présence de VLAN, firewall, relais DHCP
Moment exact du symptôme si connu
Limites à connaître
Je détecte les anomalies visibles dans le trafic
Je ne peux pas inférer :
un bug interne du client sans manifestation réseau
une action locale hors réseau (script, agent, etc.)
Pourquoi se priver d'une capture ? la capture c'est la prise de sang du flux réseau !
A dispo pour trouver !
D.M.
#43
Internet / Re : Coupures intempestives !
Dernier message par sebdepringy - 19 Décembre 2025 à 22:03:05Bon visiblement knet clos plus vite les tickets plutôt que de les résoudre
#44
K-net en général / Re : La compta de K-Net (Ras l...
Dernier message par K-net TEAM - D.M. - 19 Décembre 2025 à 18:37:26Bonsoir,
je comprends votre agacement, c'est tout a fait normal.
Pour compléter, il y a eu deux doubles prélèvements :
En novembre 2023 suite au remplacement à la migration du S.I.
En Mai 2024 suite à une erreur de l'intermédiaire bancaire dont les API renvoyaient des données incohérentes et non documentées.
La relance automatique se base sur des données d'état du compte client après synchronisation des flux de banque.
Un algo fait le rapprochement des flux.
La brique de relance a fait ce pour quoi elle est faite, relancer les impayés sur la base des données dont elle dispose.
Données incomplètes dans votre cas. Comme évoqué juste au dessus, nous travaillons sur la qualité et la fiabilisation de la donnée.
Merci de votre confiance.
je comprends votre agacement, c'est tout a fait normal.
Pour compléter, il y a eu deux doubles prélèvements :
En novembre 2023 suite au remplacement à la migration du S.I.
En Mai 2024 suite à une erreur de l'intermédiaire bancaire dont les API renvoyaient des données incohérentes et non documentées.
La relance automatique se base sur des données d'état du compte client après synchronisation des flux de banque.
Un algo fait le rapprochement des flux.
La brique de relance a fait ce pour quoi elle est faite, relancer les impayés sur la base des données dont elle dispose.
Données incomplètes dans votre cas. Comme évoqué juste au dessus, nous travaillons sur la qualité et la fiabilisation de la donnée.
Merci de votre confiance.
#45
K-net en général / Re : La compta de K-Net (Ras l...
Dernier message par Couin - 19 Décembre 2025 à 15:31:08Je n'étais pas allé voir dans l'espace client. A l'instant présent elles sont marqués payées.
Encore heureux que je ne suis pas prélevé en double, j'ai bloqué les prélèvement déjà à cause de ça et je vois qu'il n'est toujours pas possible de faire confiance et de réautoriser, 2 ans après, donc je me fait chier tous les mois à faire un virement...
Un problème, ça peut arriver, mais octobre et novembre 2024, mai 2025 et là encore pour novembre 2025... Ça devient récurrent...
Mais surtout, avant de relancer, on doit s'assurer que le paiement n'a pas été fait, et encore plus quand on relance une deuxième fois pour la même facture alors qu'à la première relance on a déjà envoyé le mail de confirmation de la banque de l'ordre de virement. C'est donner le bâton pour se faire battre :/
Encore heureux que je ne suis pas prélevé en double, j'ai bloqué les prélèvement déjà à cause de ça et je vois qu'il n'est toujours pas possible de faire confiance et de réautoriser, 2 ans après, donc je me fait chier tous les mois à faire un virement...
Un problème, ça peut arriver, mais octobre et novembre 2024, mai 2025 et là encore pour novembre 2025... Ça devient récurrent...
Mais surtout, avant de relancer, on doit s'assurer que le paiement n'a pas été fait, et encore plus quand on relance une deuxième fois pour la même facture alors qu'à la première relance on a déjà envoyé le mail de confirmation de la banque de l'ordre de virement. C'est donner le bâton pour se faire battre :/
#46
K-net en général / Re : La compta de K-Net (Ras l...
Dernier message par K-net TEAM - D.M. - 19 Décembre 2025 à 10:14:14Bonjour,
L'équipe ADV et comptable travaille ardûment à la qualité des chiffres dans nos outils.
Plusieurs abonnés ont sollicité le support concernant des relances.
Expertise en cours.
La piste retenue serait un problème d'import du flux bancaire vers le 24 novembre 2025.
D.M. (de la part de comptabilité)
Joyeux noël à toutes et à tous.
L'équipe ADV et comptable travaille ardûment à la qualité des chiffres dans nos outils.
Plusieurs abonnés ont sollicité le support concernant des relances.
Expertise en cours.
La piste retenue serait un problème d'import du flux bancaire vers le 24 novembre 2025.
D.M. (de la part de comptabilité)
Joyeux noël à toutes et à tous.
#47
K-net en général / Re : La compta de K-Net (Ras l...
Dernier message par Steph - 19 Décembre 2025 à 09:38:49Bah, tant qu'il ne prélève pas en double. 
Toutes mes factures apparaissent payées dans l'espace client.
Pas les tiennes?
Toutes mes factures apparaissent payées dans l'espace client.
Pas les tiennes?
#48
K-net en général / Re : La compta de K-Net (Ras l...
Dernier message par Couin - 19 Décembre 2025 à 08:01:02Bonjour,
Et ça continue (encore et encore, comme le chantait Cabrel)...
Vous (k-net) relancez pour des factures impayées malgré virement effectué... ce n'est pas la première fois...
Plus de 2 ans que c'est bancal le truc...
Ça va être mis au point un jour ou vous faites tout pour que les clients même fidèles en aient ras l'cul ?
Et ça continue (encore et encore, comme le chantait Cabrel)...
Vous (k-net) relancez pour des factures impayées malgré virement effectué... ce n'est pas la première fois...
Plus de 2 ans que c'est bancal le truc...
Ça va être mis au point un jour ou vous faites tout pour que les clients même fidèles en aient ras l'cul ?
#49
K-net en général / Re : [Infra] - remplacement ro...
Dernier message par K-net TEAM - D.M. - 19 Décembre 2025 à 00:26:11Cher Vivien,
La suite du chantier V6 c'est de rétablir la majorité des services en IPv6. Comme ce forum par exemple.
Après je peux juste te dire que l'on va le faire porte de collecte par porte de collecte, mais que l'ordre n'a pas encore été choisi ? On avancera O.I. par O.I. en fonction des obstacles et des dispos des uns et des autres ça ira plus ou moins vite.
En tout cas nos sessions BGP V6 sont opérationnelles sur nos transitaires, nos IXPs et même K-SYS.
D.M.
La suite du chantier V6 c'est de rétablir la majorité des services en IPv6. Comme ce forum par exemple.
Après je peux juste te dire que l'on va le faire porte de collecte par porte de collecte, mais que l'ordre n'a pas encore été choisi ? On avancera O.I. par O.I. en fonction des obstacles et des dispos des uns et des autres ça ira plus ou moins vite.
En tout cas nos sessions BGP V6 sont opérationnelles sur nos transitaires, nos IXPs et même K-SYS.
D.M.
#50
K-net en général / Re : [Infra] - remplacement ro...
Dernier message par vivien - 18 Décembre 2025 à 14:52:00Félicitations pour la migration.
Il sera intéressant d'indiquer quelles collectes bénéficieront de l'IPv6. J'ai par exemple des doutes pour l'arrivée de l'IPv6 sur les zones XpFibre (mais faite moi mentir).
Citation de: K-net TEAM - D.M. le 17 Décembre 2025 à 17:59:04Prochaine étape le retour de l'IPV6.Merci de penser à l'IPv6.
Il sera intéressant d'indiquer quelles collectes bénéficieront de l'IPv6. J'ai par exemple des doutes pour l'arrivée de l'IPv6 sur les zones XpFibre (mais faite moi mentir).