Messages récents
#71
K-net en général / Factures
Dernier message par coincoin - 02 Janvier 2026 à 16:42:04Bonjour et bonne année à tous et toutes.
Petite question bête: Payons nous nos factures pour le mois écoulé où pour le mois à venir?
Petite question bête: Payons nous nos factures pour le mois écoulé où pour le mois à venir?
#72
K-net en général / Facture
Dernier message par coincoin - 02 Janvier 2026 à 16:41:01Bonjour et bonne année à tous et toutes.
Petite question bête: Payons nous nos factures pour le mois écoulé où pour le mois à venir?
Petite question bête: Payons nous nos factures pour le mois écoulé où pour le mois à venir?
#73
Internet / Re : Coupures intempestives !
Dernier message par sebdepringy - 26 Décembre 2025 à 00:31:57Bonsoir,
Je ne peux pas faire de tests pour le moment, ce qui est bizarre c'est que cela décroche quand je fais du RSYNC, si je bride le débit à 500Mb pas de décrochage. Cela fait penser que le serveur dhcp est trop occupé pour redonner l'ip fixe mais bon je suis pas FAI.
Ce que je n'explique pas c'est que Foliateam eux peuvent tout voir si j'ai un problème au travail et pourtant j'ai également mes routeurs et pas vous
Merci
Sébastien
Je ne peux pas faire de tests pour le moment, ce qui est bizarre c'est que cela décroche quand je fais du RSYNC, si je bride le débit à 500Mb pas de décrochage. Cela fait penser que le serveur dhcp est trop occupé pour redonner l'ip fixe mais bon je suis pas FAI.
Ce que je n'explique pas c'est que Foliateam eux peuvent tout voir si j'ai un problème au travail et pourtant j'ai également mes routeurs et pas vous
Merci
Sébastien
#74
K-net en général / Bilan de la Sté K-NET en 2025 ...
Dernier message par iracema - 23 Décembre 2025 à 10:22:36Bonjour à l'équipe KNET,
L'année 2025 touche à sa fin, et il me semble intéressant de faire un petit bilan.
Suite au plan de redressement validé par le tribunal fin janvier 2025, et avec la clôture de l'exercice fiscal, je me pose la question :
Êtes-vous globalement dans le respect du plan annoncé ? Les resultats financiers seront ils bons ?
Côté technique, on constate que certaines évolutions ont bien eu lieu, comme prévu, ce qui est positif.
En revanche, concernant les nouveautés dans les offres et pour la refonte graphique de la marque, elles n'ont pas vu le jour cette année.
Merci pour le travail accompli malgré un contexte difficile.
Mais je serais curieux d'avoir vos retours :
Quels sont les points clés que vous retenez de 2025 ?
Quelles perspectives pour 2026 ?
Des améliorations prévues pour les offres ?
Bonne fin d'année à tous !
L'année 2025 touche à sa fin, et il me semble intéressant de faire un petit bilan.
Suite au plan de redressement validé par le tribunal fin janvier 2025, et avec la clôture de l'exercice fiscal, je me pose la question :
Êtes-vous globalement dans le respect du plan annoncé ? Les resultats financiers seront ils bons ?
Côté technique, on constate que certaines évolutions ont bien eu lieu, comme prévu, ce qui est positif.
En revanche, concernant les nouveautés dans les offres et pour la refonte graphique de la marque, elles n'ont pas vu le jour cette année.
Merci pour le travail accompli malgré un contexte difficile.
Mais je serais curieux d'avoir vos retours :
Quels sont les points clés que vous retenez de 2025 ?
Quelles perspectives pour 2026 ?
Des améliorations prévues pour les offres ?
Bonne fin d'année à tous !
#75
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.
#76
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.
#77
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
#78
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.
#79
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 :/
#80
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.