La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => 
K-Net => Opérateurs grand public alternatifs => Espace technique internet K-Net => Discussion démarrée par: bolemo le 29 janvier 2022 à 15:15:15
-
Bonjour,
Comme je viens de faire le tutoriel pour quelqu'un d'autre, j'en profite pour le partager ici pour ceux que ça pourrait aider.
ATTENTION, cela nécessite un routeur perso, et un accès à ce routeur, et toute manipulation sur le routeur peut causer des problèmes si les commandes sont mal entrées, ou si les versions sont différentes, etc… Donc à vos risques et périls.
Pourquoi faire cela ?
Dans mon cas, à chaque fois que mon routeur prenait une adresse WAN via DHCP, il relançait son propre serveur DHCP (côté LAN), provoquant une micro interruption et forçant les clients de mon LAN à se reconnecter, etc… Donc micro coupures, nouveaux baux, etc… De plus, mon routeur ne renouvelait pas en demi-bail (2:30 minutes) mais à la fin du bail (5 minutes).
Il est normal pour un client DHCP sur un routeur de lancer un script post-connexion, mais pour des baux courts, ça peut donc créer des problèmes.
Ma parade a été de paramétrer mon routeur en statique (IP fixe), et de créer une tâche répétée (cronjob) pour envoyer la requête DHCP attendue par le relais de l'OI pour maintenir l'autorisation de l'IP (les fameuses ACL).
Pour envoyer la requête, j'utilise le client udhcpc ; comme sur mon routeur la version de base n'est pas très complète et ancienne, j'ai utilisé la version proposée par entware, mais j'aurais probablement pu utiliser la version de base avec moins d'options.
Cela peut se faire avec d'autres clients DHCP, il faut adapter.
La tâche cron doit être ajoutée dans un crontab. Cela varie selon les routeurs (crontab, cru, etc…)
Voici ma tâche cron :
*/3 * * * * udhcpc -q -n -t 17 -T 10 -i [INTERFACE] -s /dev/null -r [ADRESSE IP] >/dev/null 2>&1
*/3 * * * * indique que ça doit être répété toutes les 3 minutes
udhcpc ... c'est la commande lancée par cron toutes les 3 minutes, suivie de ses arguments.
-q pour qu'udhcpc se ferme après avoir fait son job (inutile de le garder en mémoire)
-n pour qu'udhcpc se ferme s'il n'y arrive pas (on ne veut pas qu'il insiste, car comme c'est répété toutes les 3 minutes, on ne veut pas plusieurs exemplaires en même temps).
-t 17 signifie que l'on veut qu'udhcpc essaye 17 fois sans réponse du serveur avant de fermer (ce qu'on demande avec -n)
-T 10 signifie que l'on veut que chaque tentative (les 17) prenne 10 secondes. Donc en cas d'échec des tentatives de connexion (coupure ou DHCP défaillant chez OI/K-Net), udhcpc se fermera au bout d'un peu plus de 170 secondes. Ce qui nous convient puisque 3 minutes c'est 180 secondes et donc la nouvelle instance continuera d'essayer pendant les 170 prochaine secondes…
-i [INTERFACE] indique à udhcpc d'utiliser cette interface ; [INTERFACE] est à remplacer par l'interface WAN (côté ONT) du routeur (brwan chez Netgear, eth0 chez Asus, etc…)
-s /dev/null empêche udhcpc d'utiliser le script de configuration post-connexion (on ne veut surtout pas qu'il lance ce script, puisque le routeur est en IP fixe).
-r [IP] c'est pour demander cette adresse IP spécifiquement… C'est probablement inutile, car de toute façon, le serveur DHCP n'attribuera que celle associée à la MAC, mais ça ne mange pas de pain. Donc [IP] est à remplacer par l'IP fixe publique évidemment.
Enfin >/dev/null 2>&1 c'est pour que la commande ne retourne rien, comme elle est dans un cron, inutile qu'elle retourne quoi que ce soit en message.
Voilà, une fois le cronjob en place, il faut passer le routeur en statique :
Donc côté WAN, au lieu de DHCP c'est fixe ou statique, il faut renseigner l'IP fixe fournie par K-Net, le masque de sous-réseau, et enfin la passerelle. Il faut donc connaître/chercher ces informations avant.
Après, il faut penser que le cron peut ne pas survivre un reboot ou une mise-à-jour du firmware, donc ça demande un peu d'expertise et d'esprit d'aventure, d'où mon avertissement en rouge au début.
Voilà, si ça peut aider…
-
Salut Bolemo,
Beau travail, je vais mettre ca de coté pour quand mon net reviendra, je configurerais un de mes routeurs persos en fixe, mais petite question :
La tache cron et donc la commande doit être absolument exécuté sur le routeur ou on peut la lancer depuis un serveur (debian) qui est sur le LAN (et tout le temps allumé) ? Je pense routeur only mais on sait jamais :)
Merci et bon week end
-
Salut Bolemo,
Beau travail, je vais mettre ca de coté pour quand mon net reviendra, je configurerais un de mes routeurs persos en fixe, mais petite question :
La tache cron et donc la commande doit être absolument exécuté sur le routeur ou on peut la lancer depuis un serveur (debian) qui est sur le LAN (et tout le temps allumé) ? Je pense routeur only mais on sait jamais :)
Merci et bon week end
Oui, routeur only...
Après, ce doit être jouable avec les bonnes règles iptables pour laisser passer la requête à travers le routeur ; elles arrivent en broadcast 255.255.255.255 côté LAN, il faut donc qu'elles soient forwardées sur le WAN, et pour que la réponse soit forwardée au Debian ; ports 67 et 68 (bootps et bootpc). Dans ce cas, il faudrait aussi altérer le message DHCP pour qu'il envoie la MAC WAN du routeur et non celle du serveur Debian...
Sur le serveur, peut-être utiliser alors dhtest qui permet d'envoyer une MAC personnalisée (et bien sûr les règles iptables qu'il faut sur le routeur).
https://github.com/saravana815/dhtest
-
Merci je vais enregistrer le sujet et voir ca à situation rétablie (mon voyant PON). :)
-
Merci je vais enregistrer le sujet et voir ca à situation rétablie (mon voyant PON). :)
Autre solution si tu veux le cron sur le debian, mais pas la commande dhcp : la tâche cron peut être d'exécuter la tâche sur le routeur via ssh/telnet (donc cron sur debian qui lance la requête DHCP depuis le routeur).
-
Je suis en train de repenser mon astuce pour maintenir les ACL, et utiliser dhtest au lieu de udhcpc.
Au lieu d'un cron, je pense à un petit demon (en shell) qui se lancera automatiquement lorsque le routeur démarre.
Voilà mon petit script demon, nommé dhcp-acl.sh
Je ferai l'essai plus tard, en remplacement de ma tâche cron.
Quel intérêt pour moi ?
Dans ma version cron, en cas de coupure de la ligne, ça peut prendre 3 minutes avant que le rétablissement (si le la tâche cron obtient un bail, puis que ça micro-coupe juste après, il faudra attendre le prochain cron pour que ça revienne). Je n'ai jamais eu ce problème depuis que j'utilise cette astuce (2018), mais j'aime bien perfectionner…
Ce script teste toutes les 10 secondes si j'ai bien une connexion à la passerelle (arping vers la passerelle), ce qui doit m'indiquer si les ACL sont OK ou non. C'est aussi le moyen le plus discret de tester, sans impliquer un ping vers 8.8.8.8 ou autre (plus de traffic impliqué), et aussi si le bail/acl est OK mais que la route vers 8.8.8.8 a un problème, cela ferait croire au script que je n'ai pas d'ACL (alors que si).
Ce script génère un petit log, qui s'auto-maintient autour d'un nombre de lignes défini.
Les variables déclarées au début permettent de définir la MAC, la passerelle, l'interface WAN, la délai avant de renouveler l'ACL, et le chemin pour le log et son nombre de lignes.
Autre intérêt : en théorie, il est possible d'utiliser ce script depuis un routeur sans avoir à faire de MAC spoofing… Il suffit de mettre la bonne MAC (celle chez K-Net) dans le script. À vérifier cependant…
Voilà, si vous voulez tenter, il vous faudra installer dhtest, et adapter un peu le script (chemin des binaires, etc…)
#!/bin/sh
MAC='xx:xx:xx:xx:xx:xx' # MAC adress to send
GWIP='XX.XX.XX.XX' # IP of gateway to arping to check connexion is alive
IFACE=brwan # WAN interface
RT=180 # ACL renew time
LF=/var/log/dhcp-acl.log # Log file path
LL=100 # Log file length (approx. nb of lines)
log() echo "$(date '+%F %T') - $1" >>$LF;
trimlog() {
mv $LF "$LF.old"
/opt/bin/tail -n $LL "$LF.old" >$LF
rm -f "$LF.old"
}
cd /tmp
touch $LF
#exec >>$LF 2>&1
while :; do
I=0
trimlog
log "INITIATING DHCP NEGOCIATION TO TRIGGER/MAINTAIN ACL"
/opt/sbin/dhtest -I $IFACE -m $MAC -T 60 >/dev/null 2>&1 || {
log "FAILED TO GET A LEASE, RETRYING"
continue
}
log "DHCP LEASE RECEIVED: ACL SHOULD BE GRANTED"
while :; do
/opt/sbin/arping -qf -c1 -I $IFACE $GWIP || {
log "GATEWAY IN NOT RESPONDING: WE LIKELY LOST CONNECTION"
break
}
sleep 10 && I=$((I+10))
[ $I -ge $RT ] && {
log "RENEWAL TIME REACHED ($I SECONDS)"
break
}
done
done
-
si tu veux que je test sur mon asus rt-ax56u.... à l'occasion
-
si tu veux que je test sur mon asus rt-ax56u.... à l'occasion
Oui, pourquoi pas !
Il faudra voir comment installer dhtest sur l'Asus… Je l'ai compilé sur mon routeur.
Sinon j'ai amélioré mon script qui s'auto demonise, utilise /var/run pour marque son PID, etc…
Je vais l'améliorer demain pour ajouter les arguments start, stop et restart.
-
Dernière version du script, qui accepte les commandes start, stop, restart, status et log :
#!/bin/sh
SCN='dhcp-acl' # This script name
MAC='xx:xx:xx:xx:xx:xx' # MAC adress to send
GWIP='XX.XX.XX.XX' # IP of gateway to arping to check connexion is alive
IFACE=brwan # WAN interface
RTI=180 # ACL renewal time interval (in seconds)
LOG=/var/log/$SCN.log # Log file path
LMN=100 # Log min lines
LMX=150 # Log max lines
PID=/var/run/$SCN.pid # PID file path
is_running() {
[ -e $PID ] && /bin/kill -0 $(cat $PID) >/dev/null 2>&1 && return 0 || return 1
}
info() echo -e "| MAC used: $MAC\n| Gateway IP used: $GWIP\n| Renewal time interval: $RTI";
stop() {
if test -e $PID && /bin/kill -15 $_PID >/dev/null 2>&1; then
I=0
while is_running; do
sleep 1
I=$((I+1))
[ $I -gt 20 ] && { echo "Unable to stop running $SCN with PID $_PID; exiting!"; exit 1; }
done
echo "$SCN stopped $SCN with PID $_PID."
else
echo "$SCN is not running!"
fi
}
_PID="$(cat $PID 2>/dev/null)"
case "$1" in
status)
is_running && echo "$SCN is running with PID $_PID." \
|| echo "$SCN is not running."
R=$?
info
exit $R
;;
start)
is_running && { echo "$SCN is already running with PID $_PID!"; exit 1; }
echo "Starting $SCN."
;;
stop)
is_running && stop || { echo "$SCN is not running!"; exit 1; }
exit 0
;;
restart)
stop
echo "Restarting $SCN."
;;
log)
cat $LOG
exit 0
;;
*)
echo -e "Usage: $0 start|stop|restart|status|log\n"
echo "Log file: $LOG"
exit 0
;;
esac
# Daemonized part
(
_trap() {
/bin/rm -f "$PID" >/dev/null 2>&1
log "EXITING"
exit
}
log() echo "$(date '+%F %T') - $1" >>$LOG;
trimlog() {
[ "$(wc -l <$LOG)" -lt $LMX ] && return
mv $LOG "$LOG.old"
/opt/bin/tail -n $LMN "$LOG.old" >$LOG
/bin/rm -f "$LOG.old"
}
trap "exit" INT TERM; trap _trap EXIT
cd /tmp
touch $LOG
log "STARTING DHCP-ACL DAEMON WITH PID $(cat $PID)"
while :; do
I=0
trimlog
log "INITIATING DHCP NEGOCIATION TO TRIGGER/MAINTAIN ACL"
/opt/bolemo/scripts/dhtest -i $IFACE -m $MAC -T 60 >/dev/null 2>&1 || {
log "FAILED TO GET A LEASE, RETRYING"
continue
}
log "DHCP LEASE RECEIVED: ACL SHOULD BE GRANTED"
while :; do
/opt/sbin/arping -qf -c1 -I $IFACE $GWIP || {
log "GATEWAY IN NOT RESPONDING: WE LIKELY LOST CONNECTION"
break
}
sleep 10 & wait
I=$((I+10))
[ $I -ge $RTI ] && break
done
done
) </dev/null >/dev/null 2>&1 & echo $!>$PID
echo "$SCN started with PID $!."
info
Le script fonctionne. Plus besoin du cron pour garder mes ACL.
J'ai quand même mis un cron toutes les minutes avec "dhcp-acl start >/dev/null" histoire de relancer le script s'il venait à être stoppé.
Si je trouve le temps, je ferais une version en C basée sur dhtest.
-
J'ai quand même mis un cron toutes les minutes avec "dhcp-acl start >/dev/null" histoire de relancer le script s'il venait à être stoppé.
l'autre astuce c'est de mettre le script/programme dans l'inittab et s'il crash il sera automatiquement relancé (comme login/getty...)
-
l'autre astuce c'est de mettre le script/programme dans l'inittab et s'il crash il sera automatiquement relancé (comme login/getty...)
Certes, mais le système du R7800 est très limité… Je ne sais même pas si l'initab accepterait un respawn. Et je voudrais éviter de le scripter et de toucher trop à la partition système (la nand est fragile).
J'ai beaucoup de scripts perso sur mon routeur, mais ils sont tous sur une partition externe (SSD en USB), dont entware et cron.
J'ai bien pensé à transformer mon script en service init.d (sur l'USB /opt/etc/init.d/...), mais ça serait moins portable qu'un simple script.
Le cron qui vérifie toutes les minutes, ça fonctionne bien au cas où…
-
Bonjour,
Sur mon routeur Asus
cru a aclcovage "*/3 * * * * udhcpc -q -n -t 17 -T 10 -i eth0 -s /dev/null -r 1xx.251.1xx.171 "
J'ai supprimé >/dev/null 2>&1 pour voir si le comportement est mieux sans
-
Bonjour,
Sur mon routeur Asus
cru a aclcovage "*/3 * * * * udhcpc -q -n -t 17 -T 10 -i eth0 -s /dev/null -r 1xx.251.1xx.171 "
J'ai supprimé >/dev/null 2>&1 pour voir si le comportement est mieux sans
Tu ne verras probablement toujours rien…
Remplace >/dev/null 2>&1 par >>/tmp/aclcovage.log 2>&1
Et avant de lancer cru, fait ceci : touch /tmp/aclcovage.log (pour créer le fichier).
Ceci enverra la sortie d'udhcpc dans un fichier dans la mémoire de ton routeur, /tmp/aclcovage.log
Puis pour voir ce qu'il se passe en live dans ce fichier : tail -f /tmp/aclcovage.log (ctrl-C pour interrompre) ; à lancer juste après le cru, puis attendre.
-
J'ai cré le log puis
cru a aclcovage "*/3 * * * * udhcpc -q -n -t 17 -T 10 -i eth0 -s /dev/null -r 1xx.xxx.1xx.1xx >/tmp/aclcovage.log 2>&1"
puis fait le tail
admin2@RT-AX56U-9B10:/tmp/home/root# tail -f /tmp/aclcovage.log
udhcpc: started, v1.25.1
udhcpc: sending discover
udhcpc: sending select for 1xx.xx.xxx.xxx
udhcpc: lease of 1xx.xxx.xxx.xxx obtained, lease time 300
-
J'ai cré le log puis
cru a aclcovage "*/3 * * * * udhcpc -q -n -t 17 -T 10 -i eth0 -s /dev/null -r 1xx.xxx.1xx.1xx >/tmp/aclcovage.log 2>&1"
puis fait le tail
admin2@RT-AX56U-9B10:/tmp/home/root# tail -f /tmp/aclcovage.log
udhcpc: started, v1.25.1
udhcpc: sending discover
udhcpc: sending select for 1xx.xx.xxx.xxx
udhcpc: lease of 1xx.xxx.xxx.xxx obtained, lease time 300
Ah, tu as fait la commande avant que j'édite.
Pas grave, mais du coup, tail -f est inutile.
Fais simplement tail (sans le -f) et refais le au bout de 3/4 minutes pour voir ce que retourne udhcpc la deuxième fois.
-
oui j'ai cré le fichier avec touch /tmp/aclcovage.log
au bout de 30mn cela a fait ceci
admin2@RT-AX56U-9B10:/tmp/home/root# tail -f /tmp/aclcovage.log
udhcpc: started, v1.25.1
udhcpc: sending discover
udhcpc: sending select for 1xx.xxx.xxx.xxx
udhcpc: lease of 1xx.xxx.xxx.xxx obtained, lease time 300
udhcpc: started, v1.25.1
udhcpc: sending discover
udhcpc: sending select for 1xx.xxx.xxx.xxx
udhcpc: lease of 1xx.xxx.xxx.xxx obtained, lease time 300
et j'ai envoyé les debits, tu vois quelque chose sur le monitoring?
-
Bon j'ai crié victoire trop tot, coupure après mon message
Dans les logs :
admin2@RT-AX56U-9B10:/tmp/home/root# udhcpc -q -n -t 17 -T 10 -i eth0 -s /dev/nu
ll -r 1xx.xx.xxx.xxx
udhcpc: started, v1.25.1
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
udhcpc: no lease, failing
et ensuite j'ai attendu attendu, j'en ai eu marre j'ai remis en dhcp, toujours pas revenu, j'ai débranché la fibre de l'ont et c'est reparti, je ne l'ai pas débranché electriquement
-
Bon j'ai crié victoire trop tot, coupure après mon message
Dans les logs :
admin2@RT-AX56U-9B10:/tmp/home/root# udhcpc -q -n -t 17 -T 10 -i eth0 -s /dev/nu
ll -r 1xx.xx.xxx.xxx
udhcpc: started, v1.25.1
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
udhcpc: no lease, failing
et ensuite j'ai attendu attendu, j'en ai eu marre j'ai remis en dhcp, toujours pas revenu, j'ai débranché la fibre de l'ont et c'est reparti, je ne l'ai pas débranché electriquement
Apparemment, udhcpc ne reçoit pas de bail ici…
-
c'est bizarre c'est toujours après 30mn !
-
c'est bizarre c'est toujours après 30mn !
L'autorisation ACL doit être de 30 minutes.
udhcpc n'envoie la requête qu'une seule fois (au premier appel, lorsque ça fonctionne), ce qui met l'ACL à 30 minutes.
Ensuite, toutes les 3 minutes, udhcpc n'arrive pas à obtenir de nouveau bail, et il continue jusqu'à ce que les 30 minutes se soient écoulées.
Tu essaye avec cru ou la boucle ?
Dans tous les cas, udhcpc semble ne pas fonctionner plus d'une seule fois, sauf quand tu le lance manuellement à chaque fois (pas avec cron, pas dans une boucle infinie). Je pense que ça vient de cette version de udhcpc et une histoire d'environnement.
-
j'ai essayé avec cru
-
Couin Couin !
Je n'avais pas pensé jusqu'à cette nuit ,que j'avais un routeur WRT54GL 1.1 que j'avais flashé en DD-WRT il y a longtemps.
Comme ma co est encore HS, je l'ai sorti, fait un factory reset (il était précédemment configuré pour se connecter à un wifi et pour redistribuer le net sur du LAN, mais comme j'ai tiré un câble réseau, maintenant, plus besoin de cette fonction).
Dans Administration, il y a Cron en Enabled, et dans la zone de texte, j'ai mis la commande suivante, basée sur l'exemple du post initial :
*/3 * * * * udhcpc -q -n -t 17 -T 10 -i vlan1 -s /dev/null -r MON_IP_PUBLIQUE >/dev/null 2>&1
puis Save et Apply, mais il ne se passe rien (pas de connexion), bien que je ne sais pas si c'est moi qui me plante, ou si c’est lié à la panne que j'ai (box/routeur ne reçoit pas d'IP).
Dans Commands, je fais un (info chopée sur le net) :
stopservice cron && startservice cron
Mais rien de plus.
Je change la tache Cron pour :
*/3 * * * * udhcpc -q -n -t 17 -T 10 -i vlan1 -s /dev/null -r MON_IP_PUBLIQUE >/tmp/picpoc.txt
afin de voir si il se passe quelque chose
tail /tmp/picpoc.txt
Aucun résultat (le fichier ne semble pas être créé).
Je lance en Commands :
udhcpc -q -n -t 17 -T 10 -i vlan1 -s /dev/null -r MON_IP_PUBLIQUE >/tmp/toctoc.txt
Le rond tournant Processing dure un moment.
Là non plus, aucun fichier ne semble être créé, le tail ne donne rien.
Je sais pas trop quoi faire d'autre lol
Une tite idée ?
Merkouin, je vais ronfler (travail de nuit le canard).
-
Il faudrait vérifier si tu as bien les paquets dhcp, par exemple avec wireshark.
DORA
Client :Discover en broadcast
Serveur : Offer
Client : Request
Serveur : Acknoledge
Serveur sur port 67 et client sur port 68
https://fr.m.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#Client_et_serveur_sur_des_segments_diff%C3%A9rents
https://www.wireshark.org/
-
Merkouin :)
J'ai installé le soft mais je ne trouve pas où configurer client, serveur ?
Mais les paquets DHCP, ce n’est pas le routeur (coté WAN) qui doit les envoyer ?
-
C'est ta box / ton routeur perso qui initie le handshake DHCP via un paquet DHCP Discover
-
Euuuh, mais ça c'est coté WAN ?
-
Oui.
Côté Wan la box est cliente dhcp, elle reçoit une ip.
Côté l'an, la box est serveur dhcp, elle fournit les ip aux machine de ton lan.
-
Et wireshark sur le LAN peut voir les requetes DHCP coté WAN ?
-
Non.
-
C'est bien ce qu'il me semblait, du coup je ne comprends pas le role de wireshark ici ?
-
bah ton routeur a peut être tcpdump ou des outils de trace sur les interfaces
EDIT : pour ton openwrt
https://openwrt.org/docs/guide-user/firewall/misc/tcpdump_wireshark
-
Le routeur est en DD-WRT (et non OpenWRT). J'ai regardé, il n'y a pas tcpdump présent, il faut l"installer" (en fait c’est juste mis en RAM donc prochain reboot, a pu), mais pour l'installer, il faut ssh, mais ssh, ah bah enable est grisé, ouais bon, merdes sur merdes quoi...
-
Et wireshark sur le LAN peut voir les requetes DHCP coté WAN ?
Oui si ton routeur ou switch permet le port mirroring et redirige le wan sur une patte du lan.
-
Apparemment il n'a pas l'air, je n'ai pas trouvé cette fonction.
-
Le routeur est en DD-WRT (et non OpenWRT). J'ai regardé, il n'y a pas tcpdump présent, il faut l"installer" (en fait c’est juste mis en RAM donc prochain reboot, a pu), mais pour l'installer, il faut ssh, mais ssh, ah bah enable est grisé, ouais bon, merdes sur merdes quoi...
Dans ce blog le gars y accède via interface graphique
https://bigdanzblog.wordpress.com/2017/09/19/using-tcpdump-with-dd-wrt/
sauf que là tu envoies pas dans un fichier ( -w ) ni l'esperluette pour mettre en tache de fond.
-
dommage que l'on puisse tout simplement pas configurer en ip fixe directement plûtot que cela soit le fai qui envoie via le dhcp l'ip fixe, chez foliateam par exemple je rentre tout en direct...
-
dommage que l'on puisse tout simplement pas configurer en ip fixe directement plûtot que cela soit le fai qui envoie via le dhcp l'ip fixe, chez foliateam par exemple je rentre tout en direct...
Tu peux mettre en fixe, et tirer des requêtes DHCP à blanc derrière pour maintenir ouverte l'access list sur les équipements.
C'est des choix de sécu de l'opérateur ou du FAI pour globalement limiter à une IP et un seul équipement "connu" par foyer.
(Note que ça sert à quel dalle, j'avais récup la livebox d'une voisine pour tester chez un autre voisin, tu recevais les appels phone de l'autre voisin même après remise en place de la livebox d'origine...ah ah ah)
-
dommage que l'on puisse tout simplement pas configurer en ip fixe directement plûtot que cela soit le fai qui envoie via le dhcp l'ip fixe, chez foliateam par exemple je rentre tout en direct...
C'est bien plus pratique pour nous d'avoir un protocole dynamique. Et le DHCP c'est quand même ultra simple, plus que de faire du static.
-
Dans ce blog le gars y accède via interface graphique
https://bigdanzblog.wordpress.com/2017/09/19/using-tcpdump-with-dd-wrt/
J'étais tombé sur ce lien aussi précédemment, mais là aussi, il faut installer tcpdump, je revient au même problème.
Je vais attendre que la co revienne, j'espère que ca va pas mettre une semaine, parce que pfiou, la connexion par le portable , c'est archi miséreux :(
-
Bah tu l'installes par ce truc graphique non ?
-
Mais comment chat "ce truc graphique" ? Je ne comprends pas (pis je t'avoues que ces poupées russes d'emmerdes me saucissonnent la tête, pour l'instant, j'ai remis la box d'origine, au cas où ils -xpfibre et/ou k-net - se décident à réparer).
-
C'est bien plus pratique pour nous d'avoir un protocole dynamique. Et le DHCP c'est quand même ultra simple, plus que de faire du static.
Bon quand j'aurais récupéré ma connexion déjà...
Pratique rien du tout, quand je fais de la synchronisation de nas, si je dépasse les 550mo/s au renouvellement du dhcp cela coupe ! je suis obligé de brider mes synchronisations!
Chez foliateam, synchronisation full 1gb/1gb, ip fixe rentrée en direct, 0 coupure
-
Pratique rien du tout, quand je fais de la synchronisation de nas, si je dépasse les 550mo/s au renouvellement du dhcp cela coupe ! je suis obligé de brider mes synchronisations!
Euh... Lol :)
Un renouvellement DHCP se fait a la moitié du lease et ne coupe pas le routage, c'est pas la faute du protocole...
Et si j'insiste, c'est plus pratique pour tout le monde, opérateurs comme clients.
Chez foliateam, synchronisation full 1gb/1gb, ip fixe rentrée en direct, 0 coupure
Chez nous aussi dans l'Ain ou en collecte Orange, le tout en DHCP ou en PPPoE... comme quoi ;)
Pour le 0 coupure, j'imagine que tu ne mentionnes pas la légère différence de cout entre les deux liens ;D
Le souci c'est pas le protocole, c'est les crétins (opérateurs, fabricants de matos, utilisateurs parfois) qui l'implémentent n'importe comment :)
-
Bon quand j'aurais récupéré ma connexion déjà...
Pratique rien du tout, quand je fais de la synchronisation de nas, si je dépasse les 550mo/s au renouvellement du dhcp cela coupe ! je suis obligé de brider mes synchronisations!
Chez foliateam, synchronisation full 1gb/1gb, ip fixe rentrée en direct, 0 coupure
En DHCP, le renouvellement se fait sans coupure, comme le précise @Hugues.
Après, certains rares clients DHCP mal implémentés provoquent des micro-coupures, surtout avec des baux courts à 5 minutes. C’était le cas de mon ancien routeur qui ne respectait pas le renouvellement à la moitié du bail, et une des raisons qui m’avait motivé à mettre en place la configuration que j’ai partagée au début de ce fil :D
-
En DHCP, le renouvellement se fait sans coupure, comme le précise @Hugues.
Après, certains rares clients DHCP mal implémentés provoquent des micro-coupures, surtout avec des baux courts à 5 minutes. C’était le cas de mon ancien routeur qui ne respectait pas le renouvellement à la moitié du bail, et une des raisons qui m’avait motivé à mettre en place la configuration que j’ai partagée au début de ce fil :D
J'ai un routeur Asus RT-AX4200, j'ai des coupures quand je dépasse les 550mo/s en synchro nas to nas, cela coupe 5mn et ensuite reconnection et si la synchro reprend un full speed cela tient pas longtemps
Tu conseil quoi comme routeur?
Bon K-Net, toujours pas de connexion depuis 2mois, rendez-vous XP Fibre aujourd'hui dans le vent, ils m'ont plantés, je suis furax
-
Pouet !!
La tache CRON dans le DD-WRT était à mettre en root , pour mon WRT54GL :
*/3 * * * * root udhcpc -q -n -t 17 -T 10 -i vlan1 -s /dev/null -r MON_IP_PUBLIQUE >/dev/null 2>&1
Plus qu'à mettre ce routeur en stock secours (oui car bon, en speed test on dépasse pas le 50 Mbps DN/UP lol) On verra ce que ça donnera à la prochaine panne de DHCP/relay DHCP...