.
Dernière modification par sambapati (01-03-2023 12:20:27)
Hors ligne
Ok compris.
Je croyais que tu montais un load balancing avec 2 modem, avec bascule sur l'autre ligne en cas de problème...lol
En fait "Backup" dans le sens modem de secours si le 1er venait à ne plus fonctionner. Tu es prévoyant et tu n'as pas tord car c'est pas dis qu'on en retrouve dans les prochains mois/années, et vu le potentiel de la machine trouver un équivalent, même chipset, rootable, openwrt etc...et à 39€
Dernière modification par shdf (22-10-2017 14:53:26)
Hors ligne
En plus on est sans support du fabricant, ou presque, avec des jouets neufs et des firmwares jeunes, webui beta, bugs à gogo, pas d'accès au code source etc.
C'est "terra incognita". Pas pour M. Tout-le-monde.
Mais ça marche car ce matin le dga_n1 a donné le même bug (dnsmaq mort), avec perte de lan. Mais je savais déjà quoi faire donc pas de problèmes.
Le système marche comme prévu.
Un bug ou un crash suite à une mise à jour, je peux me le permettre. J'aurai toujours acces à la web et aux infos/sources pour résoudre le problème avec l'autre dga.
Comme tu l'as bien dit, avec ce prix il faut en avoir deux.
Si puis on fait une comparaison avec ce qui est dispo sur le marché (et les prix), grâce à la politique de terre-brulée des FAI...
Si seulement la grume se réveillait un peu...
Mais l’impression est que ça va de pire en pire.
Dernière modification par sambapati (22-10-2017 15:22:04)
Hors ligne
Du coup on a perdu la téléphonie dans cette histoire, as-tu songé à passer sur une offre type OVH à 1,19€/mois ? je vois qu'il y a la portabilité du numéro en plus. "Sans engagement et sans frais d'installation, Portabilité offerte"
https://www.ovhtelecom.fr/telephonie/voip/
Inclus vers 99 numéros différents par ligne et par mois, au-delà les appels sont facturés à la seconde (voir les tarifs). Dans la limite de 60 minutes de communication par appel, au-delà le temps de communication supplémentaire est facturé à la seconde (voir les tarifs). Appels inclus vers : Allemagne, Argentine, Australie, Autriche, Belgique, Brésil, Canada, Chili, Chine, Chypre, Colombie, Danemark, Espagne, France métropolitaine, Royaume Uni, Grèce, Hong-Kong, Hongrie, Irlande, Israël, Italie, Kazakhstan, Luxembourg, Malaisie, Mexique, Norvège, Nouvelle Zélande, Panama, Pays Bas, Pologne, Portugal, Pérou, Russie, Singapour, Slovaquie, Suisse, Suède, Taïwan, Thaïlande, USA, Vénézuela.
Aucune idée de comment ca fonctionne (techniquement) d'ailleurs...le téléphone se branche sur un port rj45 ? du coup il faut paramétrer une redirection de port ? bref je n'ai pas trouvé d'infos pour le moment.
Dernière modification par shdf (22-10-2017 15:33:44)
Hors ligne
Ce que tu mentionnes est une solution intéressante.
Je l’avais un peu recherchée en mars 2017, voir ici aux post #14 et #15.
Pour le moment je n’en ai pas besoin mais à une certaine date on sera forcés de basculer sur une solution de ce type.
EDIT: Qui sait, peut-être qu'on pourra utiliser les deux sorties tél du DGA ?
Dernière modification par sambapati (22-10-2017 18:03:20)
Hors ligne
Bonjour,
quelqu'un dans cette discussion a pris un forfait SIP, sans téléphone, et installé une application sur son smartphone, du coup ses appels "fixes" arrivent sur son mobile, ce qui évite de prendre un téléphone sous caution, donc pas mal pour tester le mécanisme un mois ou deux avant de prendre un téléphone dédié (si nécessaire).
https://community.ovh.com/t/sip-ovh-sur-android/3188/15
sambapati a écrit:
EDIT: Qui sait, peut-être qu'on pourra utiliser les deux sorties tél du DGA ?
En prenant un compte SIP ovh seul (sans tel), qu'on paramètre dans le DGA4130, et en branchant son téléphone analogique sur le port tel...j’essaierais bien sans faire pour le moment le transfert de mon n°...
il me semble qu'Ansuel avait fait des modifs pour permettre des opérateurs externes ?
Dernière modification par shdf (23-10-2017 14:09:30)
Hors ligne
Je viens de prendre un un forfait SIP sans matériel à 1.19€ TTC/mois, on va voir si c'est possible de l'associer au DGA...
Edit:
reçu mes identifiants SIP, après 15 minutes
J'ai réussi à m’appeler en configurant le logiciel Linphone
Par contre dans le DGA, je ne vois pas trop ou vont les parametres, pourtant il n'y en a que 4:
Login / User name : 0033xxxxxxxxx
Mot de passe : xxxxxxxx
Authorization user name : 0033xxxxxxxxx
Domain / Registrar : sip3.ovh.fr
EDIT:
J'y suis arrivé !!!
il a fallu bidouiller 2 bricoles dans le fichier /etc/config/mmpbxrvsipnet mais pas sur que ce soit indispensable.
config mmpbxrvsipnet 'global' option trace_level '2' option radvision_trace_level '0' config syslog 'syslog' option registration '1' option call_signalling '1' option syslog_priority '6' option hide_user_identity '0' config network 'sip_net' option user_friendly_name 'SIP network' option cac '-1' option transparent_soc_transmission '0' option interface 'wan' option local_port '5060' option domain_name 'sip3.ovh.fr' option primary_registrar_port '5060' option secondary_proxy_port '0' option transport_type 'UDP' option reg_expire '3600' option reg_expire_T_before '1' option reg_back_off_timeout '60' option reg_back_off_timeout_algorithm 'fixed' option reg_back_off_timeout_max '900' option reg_back_off_timeout_min '600' option re_registration_mode 'ims' option realm 'sip3.ovh.fr' option realm_check '1' option 401_407_waiting_time '0' option dtmf_relay 'rfc2833' option dtmf_relay_translation '0' option timer_T1 '500' option timer_T2 '4000' option timer_T4 '5000' option timer_B '32000' option timer_D '50000' option timer_F '32000' option timer_J '32000' option provisional_timer '1200' option remote_hold_tone_enabled '0' option sdp_direction_call_hold 'sendonly' option sdp_direction_call_hold_answer 'recvonly' option uri_clir_format 'standard' option privacy_handling 'apply' option rejection_response '486' option no_answer_response '480' option call_waiting_provisional_response '180' option call_waiting_reject_response '486' option reliable_provisional_response 'when_supported' option forking_mode 'replace' option ingress_media_timeout '1000' option session_timer 'disabled' option min_session_expires '90' option session_expires '180' option fail_behaviour 'stop' option min_period_proxy_redundancy '0' option escape_hash '1' option escape_star '0' option control_qos_field 'dscp' option control_qos_value '40' option realtime_qos_field 'dscp' option realtime_qos_value '40' option from_anonymous_handling 'withheld' option sip_over_ipv6 '0' option rtp_local_port_min '32000' option rtp_local_port_max '39999' option user_param_value 'phone' option include_sip_instance '1' option waiting_time_for_registration_on_400_or_503_response '60' option hide_serial_number '0' option use_domain_in_contact '1' option use_domain_in_via '0' option update_support '1' option sdp_direction_attribute_media_level_only '1' option registration_delay '5' option enable_re_register_on_cancel_timeout '1' option rport_in_via '1' option optimized_authentication '1' option repeat_ringing_interval '0' option re_register_on_403 '0' option check_ttl_for_dns_record '1' option dns_query_timeout '5000' option sip_message_max_size '4096' option conference_release_call_after_transfer '0' option disconnect_on_bye_response '1' option cancel_invite_timer '64000' option early_media_detection '0' option user_agent 'Technicolor / VBNT-K / AGTEF_1.0.3 / AGTEF_1.0.3' option primary_registrar 'sip3.ovh.fr' option primary_proxy_port '5060' option primary_proxy 'sip3.ovh.fr' config profile 'sip_profile_0' option network 'sip_net' option password 'xxxxxxxx' option uri '0033xxxxxxxxx' option enabled '1' option user_name '0033xxxxxxxxx'
Dernière modification par shdf (23-10-2017 22:30:16)
Hors ligne
Pour arrêter la pollution des logs par igmpproxy, dans /etc/config/igmpproxy :
option trace '0' oufff y en avait marre...
Hors ligne
Bonsoir.
Bravo shdf pour le tél/sip!
Mes logs sont noyés depuis aujourd’hui vers 16h01 par le message
kern.warn kernel: SIOCGMIIPHY : Invalid swPort: 16
au rythme d’un message tous les trois secondes.
Est-ce que ça te dit quelque chose ?
Avant ça il y a eu un checkver démarré par crond à 16h00:00 suivi par d’autres erreurs:
Mon Oct 23 16:00:00 2017 cron.info crond[10934]: USER root pid 15797 cmd /usr/share/transformer/scripts/checkver.sh
Mon Oct 23 16:00:04 2017 daemon.err procd: Failed to removed pidfile: /var/run/transformer.pid: 2 - No such file or directory
Mon Oct 23 16:00:05 2017 daemon.err transformer: [/etc/smartcontrol/enable] open failed: /etc/smartcontrol/enable: No such file or directory
Mon Oct 23 16:00:05 2017 daemon.err transformer: /usr/share/transformer/mappings/clash/Command.Showinfo.map ignored (/usr/lib/lua/transformer/mapper/command.lua:42: assertion failed!)
Mon Oct 23 16:00:05 2017 daemon.err transformer: /usr/share/transformer/mappings/device2/DHCPv4.Server.Pool.Option.map ignored (/usr/lib/lua/transformer/typestore.lua:76: 'Device.DHCPv4.Server.Pool.{i}.Option.{i}.' is already registered!)
Mon Oct 23 16:00:05 2017 daemon.err transformer: /usr/share/transformer/mappings/device2/DSL.Channel.Stats.CurrentDay.map ignored (/usr/lib/lua/transformer/typestore.lua:76: 'Device.DSL.Channel.{i}.Stats.CurrentDay.' is already registered!)
Mon Oct 23 16:00:05 2017 daemon.err transformer: /usr/share/transformer/mappings/device2/DSL.Channel.Stats.LastShowtime.map ignored (/usr/lib/lua/transformer/typestore.lua:76: 'Device.DSL.Channel.{i}.Stats.LastShowtime.' is already registered!)
Mon Oct 23 16:00:05 2017 daemon.err transformer: /usr/share/transformer/mappings/device2/DSL.Channel.Stats.QuarterHour.map ignored (/usr/lib/lua/transformer/typestore.lua:76: 'Device.DSL.Channel.{i}.Stats.QuarterHour.' is already registered!)
Mon Oct 23 16:00:05 2017 daemon.err transformer: /usr/share/transformer/mappings/device2/DSL.Channel.Stats.Showtime.map ignored (/usr/lib/lua/transformer/typestore.lua:76: 'Device.DSL.Channel.{i}.Stats.Showtime.' is already registered!)
Mon Oct 23 16:00:05 2017 daemon.err transformer: /usr/share/transformer/mappings/device2/DSL.Channel.Stats.Total.map ignored (/usr/lib/lua/transformer/typestore.lua:76: 'Device.DSL.Channel.{i}.Stats.Total.' is already registered!)
Mon Oct 23 16:00:05 2017 daemon.err transformer: /usr/share/transformer/mappings/device2/DSL.Line.Stats.CurrentDay.map ignored (/usr/lib/lua/transformer/typestore.lua:76: 'Device.DSL.Line.{i}.Stats.CurrentDay.' is already registered!)
Mon Oct 23 16:00:05 2017 daemon.err transformer: /usr/share/transformer/mappings/device2/DSL.Line.Stats.LastShowtime.map ignored (/usr/lib/lua/transformer/typestore.lua:76: 'Device.DSL.Line.{i}.Stats.LastShowtime.' is already registered!)
Mon Oct 23 16:00:05 2017 daemon.err transformer: /usr/share/transformer/mappings/device2/DSL.Line.Stats.QuarterHour.map ignored (/usr/lib/lua/transformer/typestore.lua:76: 'Device.DSL.Line.{i}.Stats.QuarterHour.' is already registered!)
Mon Oct 23 16:00:05 2017 daemon.err transformer: /usr/share/transformer/mappings/device2/DSL.Line.Stats.Showtime.map ignored (/usr/lib/lua/transformer/typestore.lua:76: 'Device.DSL.Line.{i}.Stats.Showtime.' is already registered!)
Mon Oct 23 16:00:05 2017 daemon.err transformer: /usr/share/transformer/mappings/device2/DSL.Line.Stats.Total.map ignored (/usr/lib/lua/transformer/typestore.lua:76: 'Device.DSL.Line.{i}.Stats.Total.' is already registered!)
Mon Oct 23 16:00:07 2017 daemon.err transformer: /usr/share/transformer/mappings/device2/ManagementServer.InformParameter.map ignored (/usr/lib/lua/transformer/typestore.lua:76: 'Device.ManagementServer.InformParameter.{i}.' is already registered!)
Mon Oct 23 16:00:07 2017 daemon.err transformer: /usr/share/transformer/mappings/device2/ManagementServer.ManageableDevice.map ignored (/usr/lib/lua/transformer/typestore.lua:76: 'Device.ManagementServer.ManageableDevice.{i}.' is already registered!)
Mon Oct 23 16:00:07 2017 daemon.err transformer: /usr/share/transformer/mappings/device2/UserInterface.map ignored (/usr/lib/lua/transformer/typestore.lua:76: 'Device.UserInterface.' is already registered!)
Mon Oct 23 16:00:07 2017 daemon.err transformer: /usr/share/transformer/mappings/rpc/pumadocsis.map ignored (/usr/share/transformer/mappings/rpc/pumadocsis.map:23: Not able to locate the ubus daemon)
Mon Oct 23 16:00:08 2017 daemon.err transformer: Set failed on network.config.nil = config: lua-uci: Invalid argument
A part ça rien d’autre d’anormal.
Les deux choses seraient-elles liées ?
Dernière modification par sambapati (24-10-2017 10:58:27)
Hors ligne
non ca ne me dit rien...mais sur google je trouve 2 liens:
https://dflund.se/~triad/krad/routers/
[ 17.974000] Loading PCM shim driver
[ 20.249000] SIOCGMIIPHY : Invalid swPort: 16
[ 20.281000] SIOCGMIIPHY : Invalid swPort: 16
[ 20.307000] ETHSETSPOWERDOWN : Invalid swPort: 16
[ 28.878000] Energy Efficient Ethernet: Enabled
[ 28.913000] SIOCGMIIPHY : Invalid swPort: 16
[ 28.977000] SIOCGMIIPHY : Invalid swPort: 16
[ 29.037000] ETHSETSPOWERDOWN : Invalid swPort: 16
un rapport avec un passage en veille ? Dans la GUI, dans GATEWAY tout en bas il y a des paramettres d'economies d'energie "Eco Settings". peut-etre un rapport ?
http://wiki.iopsys.se/index.php5/Releases_Notes
le lien a l'air d'être mort mais google nous montre un peu des choses:
17 juil. 2017 - Refs # 4077 Type Bugg>SIOCGMIIPHY : Invalid swPort: 16. Fixed by patching snmp deamon it was accessing a broadcom device in that ...
un rapport avec snmp ? un imprimante branchée ?
Hors ligne
Pour le crond et le transformer j'ai moi aussi ces erreurs, en fait c'est quand on navigue dans la GUI pour le transformer ?
Hors ligne
Je verrai un peu demain mais c'est plutôt troublant.
Bonne nuit.
Hors ligne
Bonjour.
Ah zut, c’est de ma faute, je pense avoir trouvé.
Je pense avoir fait une mauvaise manip, j’ai voulu faire vite et j’ai oublié un paramètre et j’ai fait une faute, je pense avoir lancé snmpd sans m’en apercevoir.
Donc ton post (…un rapport avec snmp ? …) m’a aiguillé bien, dans la juste direction.
Mais quand-même le système est plutôt "foolproof" car tout marchait impec, seulement les logs étaient gonflés par le message de warning du kernel (noyau).
Maintenant après un reboot depuis la webui 3.16 tout semble ok.
Jusqu’à ma prochaine bêtise… .
Merci shdf !
Hors ligne
Sure. Everything’s fine, running sweet and smooth. No sweat!
Hors ligne
Bonsoir.
shdf a écrit:
Pour info, depuis la version 3.2 il y a dans /etc/init.d/rootdevice
transfer_bank() {
if [ -d /overlay/bank_1 ]
then
rm -r /overlay/bank_1
fi
mkdir /overlay/bank_1
cp -r /overlay/bank_2/* /overlay/bank_1
if [ -f /overlay/bank_1/etc/init.d/rootdevice ]
then
mtd erase /dev/mtd3
mtd write /dev/mtd4 /dev/mtd3
fi
activeversion=$( cat /proc/banktable/activeversion )
passiveversion=$( cat /proc/banktable/passiveversion )
if [ "$activeversion" == "$passiveversion" ]
then
echo bank_1 > /proc/banktable/active
reboot
fi
}
check_bank() {
bank_check=$( uci -q get env.var.bank_check )
bootedbank=$( cat /proc/banktable/booted )
if [ ! $bank_check ]
then
uci set env.var.bank_check="1"
fi
if [ $bootedbank == "bank_2" ] && [ $bank_check == "1" ]
then
transfer_bank
else
echo " Firmware in Bank_1... Not transfering..." > /dev/console
fi
}Le contenu de bank2 est dupliqué sur la bank1, et bank1 devient la bank active.
Mettre la bank1 active permet en cas de catastrophe de rattraper le coup par TFTPD.
Si j'ai bien compris un flash par TFTPD va toujours se faire sur la bank1, donc si elle n'est pas active c'est foutu car ca bootera sur la bank2.
J’ai essayé la commande switchover depuis ssh et ça a marché. Mais puis je n’arrive pas à revenir en arrière. Le switchover depuis webui 3.16 fait un reboot mais ne change pas les banks. Pareil pour la commande switchover depuis ssh.
Donc maintenant j’ai la bank_2 active (inactive = bank_1), activeversion = "Unknown", booted=bank_1, et comme passiveversion = 16.3.7498-2781009-20170130093747-9ee1bc10d48945a9c338014d0cab3db1d5fdab92.
Bizarre.
Comment revenir sur bank_1 active et booted ?
Dois-je refaire un "/etc/init.d/rootdevice force"?
Hors ligne
heuuu oualala tu aimes bien jouer avec le feu
je dirais que oui il vaut mieux commencer par un rootdevice force.
sinon :
echo bank_1 > /proc/banktable/active
ceci devrait inscrire la bank1 comme active.
Si tu fais un rootdevice force, enlève bien les > /dev/console pour bien voir ce qu'il fait...c'est moins angoissant que d'attendre sans savoir ce qu'il se passe.
Dernière modification par shdf (24-10-2017 19:31:05)
Hors ligne
shdf a écrit:
heuuu oualala tu aimes bien jouer avec le feu
...
Non, pas vraiment.
Mais en absence de doc comment faire pour comprendre le fonctionnement ? Surtout en vue du passage au firmware 1.0.3.
Et puis, dans mon univers, deux switchover ça veut dire retour à la situation de départ. Mais non, ce switchover est différent.
Dernière modification par sambapati (26-10-2017 12:36:30)
Hors ligne
il me semblait que la commande switchover faisait passer sur la version passive. Donc tu peux l’exécuter 20 fois de suite elle fera toujours la même chose...il faut faire un reboot pour que la passive devienne active, et c'est la qu'un switchover suivi d'un reboot refait un cycle.
C'est comme ça que je le vois, peut-être que je me trompe...
Dernière modification par shdf (24-10-2017 21:23:14)
Hors ligne
Oui, probablement t'as raison.
En creusant un peu, je trouve que le switchover fait ça
# switch
cat /proc/banktable/notbooted >/proc/banktable/active
En ce moment j’ai
/proc/banktable/notbooted = bank_2.
Donc il va remplacer bank_2 dans le fichier /proc/banktable/active.
Mais comme j’y ai déjà bank_2 dedans
cat /proc/banktable/active
bank_2
au final rien ne change dans mon cas avec ce " switchover" en ce moment.
Hors ligne
oui donc comme je le dis plus haut, la bonne commande me semble être : echo bank_1 > /proc/banktable/active pour écrire bank_1 dans /proc/banktable/active
et du coup pas besoin de rebooter.
Par contre si tu reboot avant d'avoir fait ca tu te retrouveras sur la bank_2 au prochain reboot, et dans cette bank j'imagine que tu repars a zero sans tes réglages. Sauf si tu as fait un rootdevice force depuis la webui 3.16 qui a du te dupliquer ta bank_1 sur la 2, et donc tes paramettres de config.
Hors ligne
Sambapati, si tu es toujours sur Firmware 1.0.2 peux-tu me dire si tu arrives à avoir le wifi 2.4Ghz @300Mbps dans la GUI ?
Je viens de recevoir celui que j'ai commandé pour le boulot, avec le firmware 1.0.2, et celui-ci me donne bien un wifi @300Mbps alors qu'a 10 cm le mien en firmware 1.0.3 ne parvient pas a faire mieux que 144Mbps.
Dans l'analyser 2.4Ghz, le mien détecte 7 wifi dans mon secteur. Celui que je viens de recevoir en detecte seulement 2...ce qui pourrait expliquer le passage en mode 40Mhz, alors que le mien reste tout le temps en 20Mhz et refuse de passer à 40Mhz. J'avais lu que c'était plus ou moins lié à la présence d'autres wifi, pour limiter les perturbations. Une exigence du consortium wifi pour être "wifi certified".
Dernière modification par shdf (25-10-2017 13:55:21)
Hors ligne
Bonjour.
shdf a écrit:
...
Sauf si tu as fait un rootdevice force depuis la webui 3.16 qui a du te dupliquer ta bank_1 sur la 2, et donc tes paramettres de config.
Sur cela j'ai des doutes dans mon état, car la transfer_bank est lancé dans la partie "check_bank" si la booted_bank est bank_2. Mais dans mon état la booted_bank est (et a toujours été) bank_1:
check_bank() {
bank_check=$( uci -q get env.var.bank_check )
bootedbank=$( cat /proc/banktable/booted )
if [ ! $bank_check ]
then
uci set env.var.bank_check="1"
fi
if [ $bootedbank == "bank_2" ] && [ $bank_check == "1" ]
then
transfer_bank
else
echo " Firmware in Bank_1... Not transfering..." > /dev/console
fi
}
Comme le fmw est sur la bank_1 il n'y aura pas de transfert.
Pour le wifi, il est strictement éteint et desactivé.
Mais pour toi je vais essayer de l'allumer et voir un peu.
Dernière modification par sambapati (25-10-2017 17:05:40)
Hors ligne
Laisse tombé le wifi, une fois le DGA démarré au boulot, il s'est mis @144Mbps alors qu'il n'y a aucun wifi à proximité, et pas moyen de le passer à 300. c'est a n'y rien comprendre.
Pour ton problème, j'ai trouvé comment faire suite à une grosse galère avec ce nouveau DGA...
Dans la GUI, dans le cadre "System Extra" clique sur le bouton switchover. Ca te fera tout le boulot: Copie de la bank1 sur 2 + bank active sur bank1 + reboot.
J'espère que tu n'auras pas le même probleme que moi, j'ai galéré pour passer du firm 1.0.2 au 1.0.3
au reboot j'etais tout le temps sur la mauvaise bank et donc toujours en 1.0.2
flahshage par la GUI 2.10 ou 3.16 ou en ligne de commande, c'etait idem. J'ai perdu le root, j'ai eu nginx qui ne m'affichait plus de gui mais error 500...bref autant je n'ai eu aucun soucis avec le précédent, que là c'était la totale.
Finalement le switchover par la GUI m'a permis d'être enfin sur bank1 active avec firm 1.0.3
Dernière modification par shdf (25-10-2017 16:55:15)
Hors ligne