L'angolo di Ansuel: ricerca e sviluppo su DGA4130 (AGTEF) & DGA4132 (AGTHP)

  • 2281 Risposte
  • 1130898 Visite

0 Utenti e 3 Visitatori stanno visualizzando questo topic.

Offline Marvel

  • Membro Anziano
  • ***
  • 200
    • Macoers
Mo veniamo al voip. chi sarebbe il provider? Da quale wan vuoi che funzioni? Mi devi dire qualcosa in più su cosa hai come option interface in /etc/config/mmbpxrvsipnet, quanti e quali helper sip hai attivi in /etc/config/firewall e possibilmente se di default mwan era attivo o meno.

POSTEDIT:

@LuKePicci  aspetta, aspetta come non detto, falso allarme, il voip va, ho solo riavviato un paio di volte mentre facevo un po di test ed ha preso ad andare :-) :-) :-)
Non so prima cosa gli sia successo.

In pratica sembra andare tutto. WAO!!!
« Ultima modifica: 24 Gennaio 2020, 16:47 da Marvel »

Offline Marvel

  • Membro Anziano
  • ***
  • 200
    • Macoers
@LuKePicci , ti disturbo nuovamente, forse sul voip ho cantato vittoria troppo in fretta. Non capisco perché ma riavviando il router a volte va e resta collegato senza problemi ed altre volte si collega e poi si disconnette e dalla gui leggo Registrazione rifiutata e nel log da ssh, logread, vedo:

Codice: [Seleziona]
SIP Registration: SIP: +39XXXXXXXXXX : Failure Reason: 403 No Roaming Agreement From Current Network XXXXXXXXXXXXXXX

basta poi un /etc/init.d/network restart per farlo registrare correttamente ma dopo un poco viene nuovamente disconnesso e con logread ho:
Codice: [Seleziona]
SIP Registration: SIP: 39XXXXXXXXXX : Deregister
[MMRVSIPIMPL::REGTERMOBJ]:E: regTermObjFirewallRuleUpdate:4158 - Unable to retrieve currentDestination from SIP network ..
[MMRVSIPIMPL::REGTERMOBJ]:E: registerStateChanged:1422 - statusCode 403

Rispondo quindi alle domande che mi avevi fatto in precedenza.

Il provider è TIM, e se può servire non utilizzo l'hostname dell outboundProxy, ma il suo indirizzo IP, in modo da poter utilizzare dei DNS differenti da quelli del provider.

Vorrei che funzionasse da wan.

Questo è il mio /etc/config/mmpbxrvsipnet:
Codice: [Seleziona]

config mmpbxrvsipnet 'global'
option trace_level '2'
option radvision_trace_level '0'
option mtf_priority '0'

config syslog 'syslog'
option registration '1'
option call_signalling '1'
option syslog_priority '6'
option hide_user_identity '0'
option log_sip_message '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 'telecomitalia.it'
option primary_proxy_port '0'
option primary_registrar 'telecomitalia.it'
option primary_registrar_port '5060'
option secondary_proxy_port '0'
option transport_type 'UDP'
option reg_expire '600000'
option reg_expire_T_before '1'
option reg_back_off_timeout_algorithm 'exponential'
option reg_back_off_timeout_max '1920'
option reg_back_off_timeout_min '60'
option reg_back_off_on_500_response '0'
option realm 'digest.telecomitalia.it'
option realm_check '0'
option 401_407_waiting_time '0'
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 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_reject_response '486'
option ingress_media_timeout '1000'
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 realtime_qos_field 'dscp'
option from_anonymous_handling 'withheld'
option sip_over_ipv6 '0'
option rtp_local_port_min '16384'
option rtp_local_port_max '32767'
option user_param_value 'phone'
option include_sip_instance '1'
option feature_tag_value 'urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel'
option waiting_time_for_registration_on_400_or_503_response '60'
option conference_factory_uri_user_part '[email protected]'
option hide_serial_number '1'
option use_domain_in_contact '0'
option use_domain_in_via '0'
option update_support '1'
option sdp_direction_attribute_media_level_only '1'
option stick_to_outbound_proxy '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 switch_back_to_primary_proxy_timer '0'
option conference_release_call_after_transfer '0'
option disconnect_on_bye_response '1'
option cancel_invite_timer '64000'
option dnd_response '486'
option early_media_detection '1'
option hide_userinfo_and_port_in_subscription_request '0'
option tls_support '0'
option tls_port '5061'
option tls_key_type 'rsaprivatekey'
option certificate_depth '5'
option tls_encryption_method 'ssl_v3'
list ca_certificates ''
option assert_tls_connection '0'
option hook_flash_relay '0'
option user_agent 'Technicolor / VBNT-S / AGTHP_2.2.0 / AGTHP_2.2.0'
option realtime_qos_value 'af42'
option secondary_registrar_port '5060'
option reliable_provisional_response 'supported'
option provisional_timer '180'
option reg_back_off_timeout '180'
option call_waiting_provisional_response '182'
option re_registration_mode 'standard'
option forking_mode 'default'
option primary_proxy 'oscurato'
option dtmf_relay 'auto'
option control_qos_value 'ef'
option session_timer 'enabled'

config profile 'sip_profile_0'
option network 'sip_net'
option enabled '1'
option user_name 'oscurato'
option uri 'oscurato'
option password 'oscurato'

config profile 'sip_profile_1'
option network 'sip_net'
option enabled '0'
option uri 'line1'

config profile 'sip_profile_2'
option network 'sip_net'
option enabled '0'
option uri 'line2'

In /config/etc/firewall ho i seguenti helper:
Codice: [Seleziona]
config helper 'ftphelper'
option helper 'ftp'
option dest_port '21'
option proto 'tcp'

config helper 'tftphelper'
option helper 'tftp'
option dest_port '69'
option proto 'udp'

config helper 'snmphelper'
option helper 'snmp'
option family 'ipv4'
option dest_port '161'
option proto 'udp'

config helper 'pptphelper'
option helper 'pptp'
option family 'ipv4'
option dest_port '1723'
option proto 'tcp'

config helper 'siphelper'
option enable '0'
option helper 'sip'
option dest_port '5060'
option proto 'tcpudp'

config helper 'siploopback'
option helper 'sip'
option dest_port '5060'
option proto 'tcpudp'
option intf 'loopback'

config helper 'irchelper'
option helper 'irc'
option family 'ipv4'
option dest_port '6667'
option proto 'tcp'

config helper 'amandahelper'
option helper 'amanda'
option dest_port '10080'
option proto 'udp'

config helper 'rtsphelper'
option helper 'rtsp'
option dest_port '554'
option family 'ipv4'
option proto 'tcp'

Purtroppo non so dirti se di default mwan era attivo, ma credo di si anche perché al suo interno di default c'è:
Codice: [Seleziona]
config globals 'globals'

config policy 'if1_mwan'
        option interface 'wan'

config host 'hostvoip'
        option path '/usr/bin/mmpbxd'
        option policy 'if1_mwan'

config rule 'if1_e'
        option policy 'if1_mwan'
        option dest_port '40000:65000'

config rule 'if1_f'
        option policy 'if1_mwan'
        option dest_port '5060'
« Ultima modifica: 25 Gennaio 2020, 14:49 da Marvel »

Offline natalinux

  • VIP
  • *****
  • 9305
  • Sesso: Maschio
ciao in
 /etc/config/mmpbxrvsipnet:
option reg_expire '600000'
scenderei a 3600
•••─ ─ ─••• •••─ ─ ─••• •••─ ─ ─•••
TG789vac v2Ver. Mint (17.2) gui 9.6.97 (Tim)
AGTHP_2.3.5 ver. Damson (19.4) DGA4132 [DEV]9.6.97(Tim)
ZTE H388X AGZHP_1.2.3
NordVPN

Offline LuKePicci

  • Global Moderator
  • VIP
  • *****
  • 2789
1) Non c'è motivo per cui mwan dovesse intervenire sul voip prima di creare la nostra seconda wan, e continua a non esserci nemmeno ora perchè mmpbxd è in grado di scegliere per proprio conto la propria interfaccia.

2) Dovresti verificare che l'ip del proxy sia il medesimo sia quando passi da wan che quando passi da wan2, altrimenti dobbiamo tornare a risolvere il dns del proxy voip. Potrai comunque usare i tuoi dns, quello di usare il suo ip è un trucco stupido.

3) mwan non gestisce il traffico generato dal router almeno che non passi attraverso il nat, per cui esiste quell'helper loopback per sip attivo.

Cosa farei: rimuoverei/commenterei via da mwan le 4 sezioni relative al voip preesistenti, metterei option enabled '0' sull'helper sip in loopback. Se già così ci siamo la cosa dell'ip hardcodato ce la teniamo buona con naso un po' storto.

Offline Marvel

  • Membro Anziano
  • ***
  • 200
    • Macoers
ciao in
 /etc/config/mmpbxrvsipnet:
option reg_expire '600000'
scenderei a 3600

Il valore impostato è quello di default, che vantaggio avrei nel diminuirlo a 3600?

1) Non c'è motivo per cui mwan dovesse intervenire sul voip prima di creare la nostra seconda wan, e continua a non esserci nemmeno ora perchè mmpbxd è in grado di scegliere per proprio conto la propria interfaccia.

Infatti mi sono molto meravigliato quando ho avuto il problema.

2) Dovresti verificare che l'ip del proxy sia il medesimo sia quando passi da wan che quando passi da wan2, altrimenti dobbiamo tornare a risolvere il dns del proxy voip. Potrai comunque usare i tuoi dns, quello di usare il suo ip è un trucco stupido.

Ho reimpostato il dns invece dell'ip ma il problema è ancora presente. Probabilmente non è lui la causa di tutto ciò.

3) mwan non gestisce il traffico generato dal router almeno che non passi attraverso il nat, per cui esiste quell'helper loopback per sip attivo.

Cosa farei: rimuoverei/commenterei via da mwan le 4 sezioni relative al voip preesistenti, metterei option enabled '0' sull'helper sip in loopback. Se già così ci siamo la cosa dell'ip hardcodato ce la teniamo buona con naso un po' storto.

Cosa faccio? Procedo lo stesso nonostante ho verificato che il problema non è l'IP hardcodato?

Ho fatto un test, ho semplicemente rimosso option ip4table 'main' da wan ed option ip4table 'main2' da wan2 e il voip ha ripreso ad andare. Ora ovviamente sono al punto di prima, non mi funzionano le due connessioni.
« Ultima modifica: 24 Gennaio 2020, 21:18 da Marvel »

Offline LuKePicci

  • Global Moderator
  • VIP
  • *****
  • 2789
Fai queste due cose:
Cosa farei: rimuoverei/commenterei via da mwan le 4 sezioni relative al voip preesistenti, metterei option enabled '0' sull'helper sip in loopback.

e rimetti a posto le tabelle ovviamente

Offline Marvel

  • Membro Anziano
  • ***
  • 200
    • Macoers
Niente da fare, ho appena provato ma purtroppo il voip continua a non andare.

In questo caso il log è il seguente:
Codice: [Seleziona]
[MMRVSIPIMPL::NETWORKOBJ]:C: onStackLogEvent:2052 - TRANSACTION  - TransactionTransportTrxStateChangeEv - pTransc=0x0xb4c3f638: Message failed to be sent (rv=0:OK)
SIP Registration: SIP: +39XXXXXXXXXX : Deregister
[MMRVSIPIMPL::REGTERMOBJ]:E: regTermObjFirewallRuleUpdate:4158 - Unable to retrieve currentDestination from SIP network
[MMRVSIPIMPL::REGTERMOBJ]:E: registerStateChanged:1422 - statusCode 0
« Ultima modifica: 25 Gennaio 2020, 14:41 da Marvel »

Offline LuKePicci

  • Global Moderator
  • VIP
  • *****
  • 2789
riaggiungi le sezioni in mwan, tieni l'helper spendo e vedi che succede

se non dovesse funzionare, riattiva l'helper (sempre quello di loopback) e cambia interface da wan a lan in mmpbxrvsipnet

come ultima chance, rimetti wan come interface, spegni l'helper, togli le regole voip da mwan e aggiungi una route statica verso l'ip/subnet del proxy nella tabella main, deve essere una regola con un match più lungo rispetto a quelle di default (di cui ne abbiamo due).
« Ultima modifica: 25 Gennaio 2020, 17:00 da LuKePicci »

Offline Marvel

  • Membro Anziano
  • ***
  • 200
    • Macoers
riaggiungi le sezioni in mwan, tieni l'helper spendo e vedi che succede

se non dovesse funzionare, riattiva l'helper (sempre quello di loopback) e cambia interface da wan a lan in mmpbxrvsipnet

Provato, purtroppo ancora niente da fare.

come ultima chance, rimetti wan come interface, spegni l'helper, togli le regole voip da mwan e aggiungi una route statica verso l'ip/subnet del proxy nella tabella main, deve essere una regola con un match più lungo rispetto a quelle di default (di cui ne abbiamo due).

Puoi darmi un aiuto a realizzare la route statica verso l'ip del proxy, non ho capito come devo fare.

Offline LuKePicci

  • Global Moderator
  • VIP
  • *****
  • 2789
Codice: [Seleziona]
config route 'voip_tim'
        option interface 'wan'
        option table 'main'
        option netmask '255.255.255.255'
        option metric '10'
        option target '_ipProxy_/32'
        option gateway '192.168.100.1'

Offline Marvel

  • Membro Anziano
  • ***
  • 200
    • Macoers
Sei un grande, con la rotta statica ha ripreso a funzionare senza problemi anche il voip, ho riavviato più volte e sembra non ci siano problemi.
Proprio non capisco però perché senza questa rotta il voip si comporta in modo bizzarro, senza questa rotta la maggior parte delle volte non funziona proprio perché non riesce a registrarsi, altre volte invece si registra ma dopo poco si disconnette, altre volte ancora si registra e riesce a funzionare. Bo.
Comunque con la rotta sembra non esserci problemi e funziona la vlan, la wan2 ed il voip.
Grazie.

Offline LuKePicci

  • Global Moderator
  • VIP
  • *****
  • 2789
E' un mix di cose a cui io stesso faccio fatica a star dietro. Per prima cosa mwan3 (e di riflesso anche mwan credo) ha problemi a dirottare sulle diverse interfacce il traffico generato dall'interno del router. Per dirottare mmpbx su una interfaccia wan specifica (tipico in vari isp) quelli di technicolor hanno attivato un helper sip per il traffico sip generato dal router, che interviene sui messaggi in uscita a prescindere da quale interfaccia mmpbxd usi in ascolto. Il tuo problema era palesemente dovuto al fatto che nonostante mwan costringesse mmpbx a usare wan per un determinato tipo di traffico,  e nonostante il fatto che mmpbxd fosse in ascolto sulla medesima, passando dall'lhelper l'effetto di mwan in output veniva neutralizzato, e i pacchetti uscivano dall'uno o l'atra interfaccia wan poiché entrambe disponevano di rotte valide. Dunque, da quanto ho capito:
- con l'helper loopback attivo, mwan attivato, interfaccia mmpbx settata a su wan: mmpbx si mette in ascolto su wan e passa in ingresso al router attraverso mwan,  l'helper uccide il tracking fatto da mwan che non riconosce più il traffico ritoccato dall'helper, in uscita il traffico trova quidni due rotte valide, va dove gli pare, a prescindere da dove mmpbx sia in ascolto
- senza helper attivo e con mwan attivato: mmpbx non passa attraverso l'input di mwan che quindi non interviene, il traffico uscente trova due rotte valide, va dove gli pare, a prescindere da dove mmpbx sia in ascolto
- con l'helper loopback attivo, mwan attivato, interfaccia mmpbx settata su lan: mmpbx si mette in ascolto su lan e passa in ingresso al router attraverso mwan,  l'helper gestisce la traduzione dei messaggi sip contenenti indirizzi lan ma uccide nuovamente il tracking fatto da mwan, in uscita il traffico trova due rotte valide, va dove gli pare, resta un mistero su quale delle due l'helper metta mmpbx in ascolto
- con la rotta statica: il dubbio su quale rotta di default seguire svanisce, le rotte con match più lungo prendono la priorità su quelle di default, impostando mmpbx su wan lui si mette in ascolto sulla medesima, non sorge il bisogno di farlo passare da mwan e quindi anche l'helper diventa inutile per traffico generato dall'interno del router, ma di fatto questa rotta risolverebbe anche il non funzionamento dei casi precedenti.

Alcune cose di quelle che ho appena detto, riguardo il non funzionamento di alcune combo, potrebbero dipendere dal fatto che i due gateway delle due wan coincidono. Non escluderei anche che con una configurazione di mwan più attenta il traffico passante per l'helper potesse comunque essere tracciato correttamente.
 Se ti venisse in mente di registrare un altro account sip con altro provider in mmpbx, il cui ip non fosse statico o riconducibile ad una subnet ristretta, e quindi non routabile staticamente, allora saresti nei guai, e dovresti rimettere mano a questa faccenda e trovare il modo di far funzionare mwan sul traffico passante attraverso l'helper.
La route statica è in main, quindi i client su vlan 2 (correttamente gestiti da mwan) dovrebbero non avere problemi a ragiungere il proxy voip da wan2. Verifica che le telefonate funzionino correttamente, e che entrambi gli interlocutori sentano l'audio e che le chiamate non cadano dopo pochi minuti.

Offline Marvel

  • Membro Anziano
  • ***
  • 200
    • Macoers
Brutte notizie, oggi ho semplicemente riavviato ed il voip non si registra più. Da ieri non ho toccato nulla.
Credo mi convenga rinunciare.

Se può servire, come route ho questo:
Codice: [Seleziona]
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.100.1   0.0.0.0         UG    10     0        0 pppoe-wan
xx.xx.xx.xx   192.168.100.1   255.255.255.255 UGH   10     0        0 pppoe-wan
192.168.0.0     *               255.255.255.0   U     0      0        0 br-lan2
192.168.1.0     *               255.255.255.0   U     0      0        0 br-lan
192.168.100.1   *               255.255.255.255 UH    0      0        0 pppoe-wan2
192.168.100.1   *               255.255.255.255 UH    0      0        0 pppoe-wan
192.168.168.0   *               255.255.255.128 U     0      0        0 wl0_1
192.168.168.128 *               255.255.255.128 U     0      0        0 wl1_1

e come ip route show table all:
Codice: [Seleziona]
default via 192.168.100.1 dev pppoe-wan2 table main2 proto static metric 20
local default dev lo table tod scope host
default via 192.168.100.1 dev pppoe-wan proto static metric 10
xx.xx.xx.xx via 192.168.100.1 dev pppoe-wan proto static metric 10
192.168.0.0/24 dev br-lan2 proto kernel scope link src 192.168.0.1
192.168.1.0/24 dev br-lan proto kernel scope link src 192.168.1.1
192.168.100.1 dev pppoe-wan2 proto kernel scope link src xx.xx.xx.xx
192.168.100.1 dev pppoe-wan proto kernel scope link src xx.xx.xx.xx
192.168.168.0/25 dev wl0_1 proto kernel scope link src 192.168.168.1
192.168.168.128/25 dev wl1_1 proto kernel scope link src 192.168.168.129

xx.xx.xx.xx songo ovviamente gli ip del server voip e quelli pubblici

POSTEDIT:
Non chiedetemi come ma al posto dell'ip dell'outboundProxy mi sono ritrovato il suo hostname e ovviamente il voip non si registrava a causa dei DNS differenti da quelli di TIM. Sono sicuro al 100% di non averlo messo io ed infatti fino a prima del riavvio il voip era registrato con i custom dns. Inoltre la telegestione e l'assistenza remota sono ambedue disattivate. Non so proprio cosa possa essere successo.

Inserendo nuovamente l'ip al posto dell'hostname tutto ha ripreso a funzionare. Terrò sotto controllo questa cosa per cercare di capire cosa possa essere successo.

Intanto @LuKePicci  ti chiedo scusa per il falso allarme e ti ringrazio per la minuziosa spiegazione.
« Ultima modifica: 27 Gennaio 2020, 21:10 da Marvel »

Offline Francynox

  • Nuovo Iscritto
  • *
  • 6
Buongiorno a tutti,

Volevo chiedere il vostro aiuto riguardo la  configurazione del voip tim.
Il problema che si presenta è la non funzionalità delle chiamate, anche quando la linea risulta correttamente registrata.

Questa è la modifica che ho recentemente fatto al modem, ho smanettato un po' con le interfacce e i file config del voip in modo che il modem facesse solo "ppp realy" e che il voip passasse dall'interfaccia lan, configurata per collegarsi ad internet attraverso un pc con PfSense che fa da router. Ovviamente nel proxy del voip ho messo l'indirizzo ip ricavato dalla procedura trovata qui sul forum per usare dns non di tim.

Prima di questa modifica che ho fatto, PfSense e il modem avevano due indirizzi ip pubblici differenti e il voip passava per l'interfaccia wan. Capitava comunque che a caso il voip non si registrasse più costringendomi a spegnere la wan su PfSense, riavviare la wan sul modem, aspettare che il telefono si registrasse per poi riattivare la wan su PfSense (Per qualche motivo che non so questo era l'unico modo per far ripartire il voip). Questo succedeva 2/3 volte a settimana.

Dopo la modifica il voip riesce sempre a registrarsi, ma le chiamate funzionano solamente per 10 minuti circa:
  • Quando provo a chiamare dal telefono fisso, una volta composto il numero, cade la linea
  • Se provo invece a chiamare il numero del telefono fisso dal cellulare, quest ultimo prova a chiamare, senza far sentire però il tipico suono di quando si prova ad effettuare una chiamata, infatti dopo una trentina di secondi riattacca.
Se non riavvio la telefonia dalle schede o tramite comando "/etc/init.d/mmpbxd restart" le chiamate non funzionano, o magari riprendono a funzionare dopo ore

Offline Marvel

  • Membro Anziano
  • ***
  • 200
    • Macoers
Ciao ragazzi, ho letto con estremo interesse l'intera discussione sul forum openwrt circa Technicolor che non vuole rilasciare il codice sorgente:
https://forum.openwrt.org/t/technicolor-gpl-source-code-request/16233

ho notato che siete intervenuti in molti di voi. Avevo letto che in passato Technicolor inviava il codice a chi scriveva ad un determinato indirizzo email che ho trovato su questo forum, ma invece sul forum openwrt leggo che neanche @Ansuel è riuscito ad avere i sorgenti del firmware 4.1, ci sono poi state novità a riguardo?

Ho inoltre notato che Ansuel ha anche messo a disposizione un toolchain per compilare i pacchetti per il firmware 4.1:
https://github.com/Ansuel/GUI_ipk

Nei prossimi giorni voglio vedere se riesco a compilarmi qualche pacchetto. Qualcuno c'ha già provato? È molto complicato?

@LuKePicci , intanto a distanza di una settimana e dopo moltissimi riavvii ti informo che la doppia wan ed il voip funzionano magnificamente bene.