IlPuntoTecnico
Hardware e Software => Connessioni ADSL/VDSL/FTTC => Topic aperto da: mastro1965 - 29 Maggio 2019, 01:55
-
TIM Hub DGA4132 (AGTHP) firmware AGTHP_2.0.0 moddato con Gui Ansuel Versione 9.1.57
parametri voip di vodafone richiesti via 190 e ricevuto autentiche via sms da vodafone
voglio inoltre segnalare che se vi arriva la password con degli spazi sappiate che lo spazio corrisponde al segno + che per un bug nella gestione di vodafone viene trascritto in spazio vuoto .. (infatti la mia aveva lo spazio ..e il router non lo digeriva ,,, sono impazzito una settimana prima di trovare la causa del difetto ..)
la password mia ha 28 caratteri
per autentica parte dati si usa
user = vodafoneadsl
password= vodafoneadsl
vlan id =1036
parametri voip
Registrar primario = ims.vodafone.it
nome dominio = ims.vodafone.it
realm = vuoto
Porta registrar primario = 5060
Proxy primario = voip1.fixed.vodafone.it ( guardate sms )
Porta proxy primario = 0
Porta locale = 0
Scadenza= 3600
nel profilo sip
nome utente = [email protected]
Uri = tuonumerotelefono
password = password da 28 caratteri
ps: i dns devono essere quelli di vodafone sennò non trova i server sip
quindi lasciate nella sezione Accesso internet il Trova automaticamente DNS abilitato senza aggiungerne altri
-
A me li risolve tranquillamente qualsiasi dns
-
Ho usato la configurazione riportata in questo thread senza problemi fino ad ieri, adesso non funziona più e controllando nel log di sistema mi da questo errore (ho sostituito il mio numero con <mio numero>):
**********
Fri Jun 14 14:18:57 2019 user.info mmpbxd[23792]: SIP Registration: SIP: <mio numero> : Deregister
Fri Jun 14 14:18:57 2019 user.debug mmpbxd[23792]: [MMRVSIPIMPL::REGTERMOBJ]:E: regTermObjFirewallRuleUpdate:4075 - Unable to retrieve currentDestination from SIP network ..
Fri Jun 14 14:18:57 2019 user.debug mmpbxd[23792]: [MMRVSIPIMPL::REGTERMOBJ]:E: registerStateChanged:1369 - statusCode 0
**********
Ho provato ovviamente a riavviare e visto che ieri i problemi di Vodafone di ieri pomeriggio erano (anche) di dns, ho provato anche a cambiare dns ma senza riuscire a far farlo funzionare.
Siete al corrente di qualche problema generale o che vci sia necessità di cambiare qualche parametro ?
Ho cercato un po in giro ma non ho trovato niente, presumo che il problema sia solo mio ma dall'errore non riesco a risalire alla causa.
-
io non ho avuto nessun problema ne di rete e ne di fonia .. a venezia ovvio che se ieri vodafone ha avuto grossi problemi di rete la fonia cade e sicuramente non sono rientrati al 100%
secondo me se attendi si sistema tutto da solo
-
Relativamente ai problemi con la registrazione del servizio voip, da questa mattina ho ripreso a funzionare regolarmente. Lo scrivo solo perchè potrebbe essere utile per qualcuno sapere che in certi casi tale tipo di problema non dipende evidentemente dal cliente e dopo un po di tempo (giorni...purtroppo) viene sistemato
-
Ho provato a seguire gli step elencati sopra, ma purtroppo non riesco ad abilitare il VoIP, il mio telefono non mi permette né di effettuare chiamate né di riceverne e lo stato della linea telefonica sul modem appare N/D.
Provando con Zoiper invece tutto funziona. Qualcuno sa come mai ?
Come posso fare a risolvere questo problema?
-
Se lo stato rimane N/D c'è qualche configurazione sbagliata che non fa nemmeno partire il servizio
Alcune volte si becca il valore sbagliato da correggere leggendo i log.. la configurazione l'hai fatta a mano modificando le config?
-
io ho notato che con il firmare 1.1.2 funziona con il 2.0 00 , 2.1.001, 2.1.001 , 2.1002 2.1.003. non va ... solo con ultima beta AGTHP_2.1.0_005_CLOSED ha ricominciato a funzionare il telefono .. credo ci sia qualche inghippo nelle versioni dalla 2.0 /2.1 va sempre in time out
-
La configurazione l'ho fatta a mano, se vuoi posso anche postare le immagini così puoi verificare i parametri che ho inserito.
-
che firmware hai su ? se leggi prima ho scritto che con gli ultimi non funziona ma solo con ultima beta ha ricominciato a funzionare ... poi la password del voip valla a prendere sul sito vodafone fai da te e non da sms
ps ....
i dns lascia quelli di vodafone nella sezione accesso internet
-
Ho appena provato con la versione _2.1.0_005 ma anche così non funziona.
La password l'ho controllata anche sul fai da te ed è la stessa dell'sms di Vodafone.
In accesso Internet ho lasciato il flag su Trova automaticamente i DNS e non ho aggiunto altro.
-
io ho appena aggiornato alla 2.2.0_001.closed e funziona anche con quella ..
edit
unica cosa che mi viene in mente è fare un reset totale del modem e rifare completamente tutta la conf a mano compreso di gui ansuel
-
Posto un'immagine dei parametri che ho configurato?
Così magari puoi vedere se ho inserito qualche dato sbagliato.
-
ok posta che vediamo
-
https://drive.google.com/file/d/1Pa-4PoyKZpdhUJ0VbPgE0-KNu_KNJAUH/view?usp=sharing (https://drive.google.com/file/d/1Pa-4PoyKZpdhUJ0VbPgE0-KNu_KNJAUH/view?usp=sharing)
https://drive.google.com/file/d/1tttt7UVx3iDeidNKlvUUlK4vTcLCjkD1/view?usp=sharing
Ok ci sono riuscito :D
-
ok sembra giusto .. in mappatura ingresso uscita hai messo le spunte su fxs 1in mappatura ingressso e uscita ? ? inoltre nel nome utente hai messo il numero piu @ims.vodafone.it
poi in codec deve essere abilitato su fxs 1 PCMA G729 e G722
-
ma siete sicuri di quel porta proxy primaria e porta locale 0? credo vadano entrambe a 5060... 0 non dovrebbe nemmeno essere ammesso come valore :-\
-
manca la portas locale che deeve essere 5060
-
In mappatura ingresso e uscita ci sono le spunte su fxs 1, nel nome ho inserito @ims.vodafone.it.
I codec non mi fa abilitare il G729 e il G722 perché mi appare la voce si è verificato un errore durante il salvataggio delle modifiche.
-
0 dovrebbe significare che la sceglie random in automatico, Vodafone non cita restrizioni sulla porta di segnalazione in ingresso quindi in teoria dovrebbe funzionare comunque. Tuttavia la Vodafone station usa la 5060, sempre.
-
https://drive.google.com/open?id=1Q8cEK1qneX7lbT5WTScJ85cs_CisgTmh
ecco qui ho messo la conf completa
-
I codec non mi fa abilitare il G729 e il G722 perché mi appare la voce si è verificato un errore durante il salvataggio delle modifiche.
-
a me li modifica ..
cmq ti allego il file mmpbx mio con i codec abilitati cosi lo sostituisci al tuo con winscp nella cartella etc/config e poi riavvi il router
https://drive.google.com/open?id=1xiVl46iCALc5-quvu-udnkYi_nAEOF1F
-
Non sembra andare neanche così
-
ma i codec almeno sono abilitati ora ?
-
no
-
a sto punto io direi di fare un reset completo e lasciare solo il root e poi reinstalli la gui ..dopo di che rifai tutta la conf a mano
-
Quindi clicco su Ripristina Gui originale ?
-
clicca su impostazione predeefinita .. opure ricarichi il firmware con la spunta di solo root
pardon metti solo la spunta su rimuovi configurazione ...non il root
-
Ma direttamente dalle impostazioni del modem? su 192.168.1.1 Impostazioni GUI, Ripristina GUI originale ?
-
no d entro il modem 192.168.1.1 casella modem e poi premi ripristina impostazioni predefinite
-
Ok ripristino fatto
-
dovresti avere tutto sconfigurato ora ... . quindi rifai configurazione per il colegamento e poi il voip ....il resto lo fai per ultimo
-
Devo inserire prima la GUI e poi fare il VoIP ed internet?
-
si esatto :)
-
Ok adesso cancello la configurazione di Tim che è di base e metto quella Vodafone
-
Potresti mettere anche la tua configurazione della linea internet ? Così almeno controllo anche quella
-
https://drive.google.com/open?id=1FQnAX0f9CUnpUBfY05F1fc46M-ZJ9WDn eccola
-
Inserito tutto, riavvio il modem?
-
Spengo e riaccendo il modem?
-
dovrebbe andare anche senza riavviare
-
Al momento non va, provo a riavviare
-
Riavviato il modem internet funziona, il Voip mi dice Registrazione rifiutata
-
strano ..a me funziona come hai potuto vedere dai miei screenshot ..
-
Su stato linea appare questo MMPBX_REG_CLIENT_REASON_TRANSACTION_TIMEOUT
-
fate da ssh un bel cat /etc/config/mmpbx* condividetelo (ovviamente censurate il vostro numero di telefono/password) e confrontate le configurazioni...
-
Io ho anche copiato e incollato il suo file mmpbx in etc/config, ma continua a darmi registrazione rifiutata
-
il mio mmpbxrvsipnet
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 cac '-1'
option transparent_soc_transmission '0'
option interface 'wan'
option local_port '5060'
option primary_proxy_port '0'
option primary_registrar_port '5060'
option secondary_proxy_port '0'
option transport_type 'UDP'
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_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'
option assert_tls_connection '0'
option hook_flash_relay '0'
option user_agent 'Technicolor / VBNT-S / AGTHP_2.2.0_001 / AGTHP_2.2.0_001'
option realtime_qos_value 'af42'
option re_registration_mode 'standard'
option session_timer 'enabled'
option control_qos_value 'ef'
option dtmf_relay 'auto'
option forking_mode 'default'
option call_waiting_provisional_response '182'
option reg_back_off_timeout '180'
option reliable_provisional_response 'supported'
option secondary_registrar_port '5060'
option domain_name 'ims.vodafone.it'
option primary_proxy 'Voip1.fixed.vodafone.it'
list ca_certificates ''
option reg_expire '3600'
option primary_registrar 'ims.vodafone.it'
option provisional_timer '180'
option user_friendly_name 'vodafone'
config profile 'sip_profile_0'
option network 'sip_net'
option display_name '****************'
option user_name '***************@ims.vodafone.it'
option enabled '1'
option uri '+******************'
option password '++++++++++++++++++++++++++++++++++++'
config profile 'sip_profile_1'
option network 'sip_net'
option enabled '0'
option user_name 'line1'
option uri 'line1'
option password 'line1'
config profile 'sip_profile_2'
option network 'sip_net'
option enabled '0'
option user_name 'line2'
option uri 'line2'
option password 'line2'
-
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 cac '-1'
option transparent_soc_transmission '0'
option interface 'wan'
option local_port '5060'
option primary_proxy_port '0'
option primary_registrar_port '5060'
option secondary_proxy_port '0'
option transport_type 'UDP'
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_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'
option assert_tls_connection '0'
option hook_flash_relay '0'
option user_agent 'Technicolor / VBNT-S / AGTHP_2.2.0_001 / AGTHP_2.2.0_001'
option call_waiting_alert_info '0'
option realtime_qos_value 'af42'
option re_registration_mode 'standard'
option session_timer 'enabled'
option dtmf_relay 'auto'
option reliable_provisional_response 'supported'
option forking_mode 'default'
option call_waiting_provisional_response '182'
option user_friendly_name 'vodafone'
option reg_back_off_timeout '180'
option primary_proxy 'Voip3.fixed.vodafone.it'
option domain_name 'ims.vodafone.it'
option secondary_registrar_port '5060'
list ca_certificates ''
option reg_expire '3600'
option control_qos_value 'ef'
option primary_registrar 'ims.vodafone.it'
option provisional_timer '180'
config profile 'sip_profile_0'
option network 'sip_net'
option enabled '1'
option uri '+numeroditelefono'
option password '++++++++++++++++++++++++++++++++++++'
option user_name '[email protected]'
option display_name '+numeroditelefono'
config profile 'sip_profile_1'
option network 'sip_net'
option enabled '0'
option user_name 'line1'
option uri 'line1'
option password 'line1'
config profile 'sip_profile_2'
option network 'sip_net'
option enabled '0'
option user_name 'line2'
option uri 'line2'
option password 'line2'
Ecco il mio mmpbxrvsipnet
-
option call_waiting_alert_info '0' a me manca
option control_qos_value 'ef' a te manca
option reliable_provisional_response 'supported' a me manca
queste le differenze
-
Anche rimuovendo ciò che è in più continua a non andare
-
se non erro avevo letto da qualche parte che il voip3.fixed.vodafone.it era pu ostico rispetto a voip1.fixed.vodafone.it stentavo a crederci .. ma a quanto pare ... è cosi e non so che pesci pigliare .. mi spiace :'(
-
Domani per sicurezza riprovo a fare la procedura da zero, spero che almeno così si risolva, sennò non so cosa fare :'(
-
@mastro1965 a te che funziona hai provato a mettere al posto di voip1, voip2 o voip3.fixed....
Magari è come con Tiscali che vengono assegnati dei server ma sono comunque intercambiabili
E anche se non funziona controlla il codice di errore che ti viene fuori nella pagina statistiche
Un'altro valore che potrebbe influire è quello del nat helper SIP ma se partite entrambi con una configurazione pulita la cosa è davvero strana...
-
allora con voip3.fixed.vodafone.it non mi va piu e da questi errori
Aug 18 10:06:34 user.debug mmpbxd[16045] [MMRVSIPIMPL::REGTERMOBJ]:E: regTermObjFirewallRuleUpdate:4158 - Unable to retrieve currentDestination from SIP network ..
Aug 18 10:06:34 user.debug mmpbxd[16045] [MMRVSIPIMPL::NETWORKOBJ]:C: onStackLogEvent:2052 - TRANSC_CLIE - TranscClientDNSContinue: Transc-client 0x0x1935188 - no failed message. transc-client state - Failed
Aug 18 10:06:34 user.info mmpbxd[16045] SIP Registration: SIP: +************* : Deregister
Aug 18 10:06:34 user.info mmpbxd[16045] SIP Registration: SIP: +************* : Failure Reason: 403 Forbidden
la cosa strana che adesso rimettendo il server giusto non va piu ... adesso devo capire cosa ha cambiato ..
-
@mastro1965 sei riuscito a rimettere a posto il tuo numero di telefono con il VoIP? io provo a rifare tutta la procedura da capo sul mio per vedere se riesco ad impostarlo
Ma se io rimuovo il root dopo posso rifarlo oppure non mi è più consentito?
-
non va ancora .. il root lo puoi rifare se metti il firmware 103
e mi sa che dovro farlo pure io ...
-
ok ora funziona ancora .. ho dovuto resettare tutto e caricare firmware 1.03 tramite tftp per essere sicuro di cancellare tutto
una volta fatto ho rimesso la gui ansuel .. rimesso tutti i parametri a mano senza passare dal wizard ..( fa qualche casino ancora )
la telefonia funziona anche col firmware 1.03 tra un po rimeto ultimo firmware e sono a posto :)
-
@mastro1965 come si fa con tftp ? Io ho rimosso il root ma la versione è ancora la AGTHP _2.2.0_001_
-
cmq 403 significa appunto che con il server voip ci comunica... da quanto vedo invece simo riceve solo timeout il che e' un po diverso, sembra lui abbia proprio qualche problema di routing...
@simosimone97 e' inutile che scomodi tftp, fai lo sblocco normale tenendolo staccato dal doppino, flasha il firmware 1.0.3 da interfaccia e rifai tutta la tiritera per il root e riaggiornare, cmq fare l'unroot e' superfluo basta un reset (non di config ma completo) nella maggior parte dei casi
-
@FrancYescO intendi tramite autoflshgui?
-
no, con i firmware 2.0+, puoi caricare il firmware stesso da interfaccia dopo aver fatto lo sblocco, leggi il topic a riguardo..
-
potresti linkarmi il topic perché non lo trovo
-
@mastro1965 sai come posso tornare al firmware AGTHP_1.0.3_CLOSED.rbi per poi effettuare il root e sbloccare il Tim Hub.
Ora sono senza root , con la versione AGTHP_2.2.0_001 e senza GUI Ansuel ma con quella Tim.
-
ciao ci sono diverse operazioni da fare meglio seguire la guida per non sbagliare
-
resetta il router tramite tastino .. aspetti che finisca senza collegarlo alla rete .. quando riparte dovrebbe comparire un tab di sblocco ..lo fai .. e il modem tim ha la possibilita a sto punto di caricare il firmware che vuoi anche 1.03 .. occhio che facendo questa operazione la password non è piu admin ma quella che c'è stampata nell etichetta modem ..
io intanto ho bricckato il mio .. . e sono ritornato alla revolution :( :( ....
il modem funziona ma non c'è verso di entrare con nessuna password ..bho chissa che è successo
-
@mastro1965 Il tab intendi configurazione estesa?
-
no tab intendo i quadrotti che vedi nella pagina iniziale del tim hub .. dovrebbe comparirne una in piu e deve essere ultima in basso
-
@mastro1965 a me l’ultimo tab in basso nella pagina del Tim Hub è configurazione estesa, non mi appare proprio nessuna voce con il nome sblocco
-
@mastro1965 https://drive.google.com/file/d/12W62Sms4lTBryxxw-xQ4AEfDYyqunzCk/view?usp=sharing (https://drive.google.com/file/d/12W62Sms4lTBryxxw-xQ4AEfDYyqunzCk/view?usp=sharing)
-
ok è quello lo sblocco fallo e dopo potrai mettere il firmware che vuoi
-
Premuto la password ora è quella sotto al modem? L’username invece? @mastro1965
Ok sono entrato
-
admin :P
-
Adesso funziona anche il VOIP @mastro1965
-
@mastro1965 resetta con tastino.
cmq giusto per tornare in argomento per farla breve e' bastato un factory reset con riconfigurazione da 0 per far funzionare anche il voip
-
@FrancYescO si, praticamente, è bastato rimuovere il root e la GUI Ansuel per poi sbloccare il Tim Hub e riconfigurare tutto da zero :D
-
credo che sia con 1.03 di firmware .. occhio a fare upgrade .. xche ogni tatno con loro non va piu ...
e io ho brasato il mio per fare una prova :(
-
@FrancYescO ne ho fatte di tutti i colori caricato 5 versioni di firmware diversi con tftp resettato piu volte con tastino e fatto non so quante volte cambio di banco .. ma nulla non mi prende nessuna password e ne codice stampato sotto.. mi sa che l ho combinata grossa cancellando overlay... strano xche non è la prima volta .. :(
edit..
recuperato ..che stordito... sbagliavo procedura reset da tastino confondendolo con quello del tftp...
ora tutto a posto pure voip :P con ,. 103 dopo riprovo con ultimo firmware 2.2.00
edit2
anche col firmware 2.2.00 il voip funziona facendo reset come ha finito aggiornamento e rimettendo i dati a mano
-
@mastro1965 A me ha funzionato soltanto 1 volta con la 2.1.0 ufficiale e dopo un semplice riavvio modem, non più.
Ho fatto il reset da tastino dietro al modem, impostati i valori a mano prima e dopo la gui, ma il nulla.
Possibile che sia così ramdomica la cosa?
Potete inserire delle schermate con i settaggi precisi?
È necessario tornare per forza alla 1.0.3?
PS: io sono su voip2... ma nel 190 faidate è scritto con la V maiuscola Voip2...
Sto impazzendo.
Grazie a tutti.
AGGIORNAMENTO
Alla fine ci sono riuscito anche io.
I firmware non c'entrano nulla.
Se i settaggi sono stati inseriti correttamente, va semplicemente riavviato il timhub finché non aggancia il voip.
Tutto qui.
Oggi pomeriggio, dopo aver caricato e testato alcuni fw (prima la versione 1.0.3 e poi rimessa la 2.1.0) e dopo reset vari, per ben 2 volte ho preso la linea. Bastava però riavviare il router per avere il voip non funzionante.
Quindi si deve riavviare finché non ristabilisce la connessione voip.
Ciao
-
Credo che il problema più che il riavvio sia l'IP che aggancia il router, ricordo che con la classe di IP 109.x.x.x, e forse anche altre, il VoIP tramite modem libero non funziona correttamente in quanto non riesce a trovare il server.
-
Relativamente al funzionamento del VOIP di vodafone con il Timbub, avete per caso notato discontinuità nel servizio?
A volte provo a chiamare casa e non c'è linea e alcun messaggio di avviso, ma se prendo il cordless la linea c'è e posso effettuare chiamate.
Non è che va configurata qualche altra impostazione del timhub?
Di seguito riporto i miei settaggi:
TELEFONIA - GLOBALE
Registrar primario: ims.vodafone.it
Nome dominio: ims.vodafone.it
Realm: (vuoto)
Porta registrar primario: 5060
Proxy primario: Voip2.fixed.vodafone.it (cambia per tutti e quindi ottenete il vostro dal portale "fai da te" del 190)
Porta proxy primario: 0
Porta locale: 5060
Scadenza: 3600
TELEFONIA - LINEE TELEFONICHE
Nome utente: +39(numero di telefono)@ims.vodafone.it
URI: +39(numero di telefono)
Password: (ottenetela dal portale "fai da te" del 190)
Visualizza nome: +39(numero di telefono)
(il mio profilo è inserito su sip_profile_0)
TELEFONIA - MAPPATURA INGRESSO/USCITA
Mappature in entrata: FXS 1 (selezionato)
Mappature in uscita: FXS 1 (selezionato)
Sono tutte cose già dette, ma questa configurazione la inserivo anche prima e non funzionava...
Come ho già scritto nel post precedente, basta riavviare il modem e dopo 1-2 riavvii dovrebbe finalmente agganciare la linea.
Il secondo contributo che posso dare, visto che ho potuto verificarlo di persona, è questo:
Nella schermata TELEFONIA - LINEE TELEFONICHE, una volta inseriti i parametri della linea, cliccate diverse volte su "Aggiorna dati" e verificate che il led di stato di "REGISTRATO", si illumini anche soltanto una volta (e quindi che il sistema della ricerca del segnale funzioni correttamente).
Se non avviene, dovete resettare il modem tramite tastino dietro all'apparecchio, ricaricare la GUI e inserire di nuovo tutte le impostazioni da zero.
Ho notato che nel fare test, hard reset, firmware update o downgrade, potrebbe "incantarsi" il servizio di ricerca.
Spero di aver fatto cosa gradita.
Saluti
-
"incantarsi" il servizio di ricerca???? a parte problemi di config incasinate che si risolvono con un reset, a me il tutto sembra proprio un problema di IP, a quanto pare non hanno whitelistato tutti i range di IP pubblici che assegnano agli utenti quindi se si capita in quello sbagliato (e potrebbe capitare in seguito a una caduta di connessione o riavvio del modem) il server voip non risponde
-
"whitelistano" dinamicamente solo l'ip corrente (l'ultimo ottenuto, quello a cu punta il loro host dinamico) per quello specifico utente che richiede la registrazione per il suo numero
Se fate la config su vlan dedicata non dovreste avere questo problema - che è anche l'unica possibile se fate più di una pppoe dati, ad esempio dalla playstation
-
se il problema e' il "desync" tra IP di chi si prova a registrare sul server voip e quello di chi ha instaurato la PPP mi aspetto qualcosa tipo un 403 non certo un timeout ora non ricordo il protocollo SIP ma mi pare ci sia un ACK iniziale senza auth ... motivo per il quale consiglio di guardare sempre la pagina stats piuttosto che i pallini che almeno visualizza un errore piu' dettagliato
su VLAN ovviamente il problema non c'e... ma e' da fare tutta a mano toccando direttamente le config
PS. ma quindi ora che l'host-uniq non serve e sono accettate credenziali vodafone generiche si possono instaurare PPP multiple?
-
No, se l'ip non è quello corretto o il numero di telefono non è quello legittimo non arriva alcuna risposta. Così ha implementato Vodafone questo sistema, probabilmente lo fanno in un punto diverso della rete, su qualche firewall logicamente vicino al nodo di uscita pppoe, non sul server sip.
Che l'Host-Uniq custom "non serva" è una inesattezza, serve a quello a cui serviva prima e non si può farne a meno. Puoi non specificarlo e ottenere comunque una connessione dati "per modem generico" che "funziona".
Le pppoe multiple si potevano fare da sempre (a patto che i client supportassero tutti host-uniq customizzato), ora puoi farne senza customizzare quel tag ma solo "l'ultima" (qualsiasi cosa significhi) può raggiungere il proxy sip richiedendo la registrazione del proprio numero.
Le pppoe multiple sulla vlan voce non si possono fare perchè l'ip ottenuto su quella vlan è statico. L'host-uniq custom non serve sulla pppoe voce.
-
@milan100 i dati che ti dicevo di controllare nella Vodafone station non li trovi certo in bella mostra nella pagina di configurazione, non sono 2000 ma 1676 (esclusi quelli delle credenziali, incluso il call log, quindi circa 880 effettivi)
Eccoli qui: https://anonfile.com/Ke70K54an4/vox25_VoiceService_txt
-
@LuKePicci non mi risulta che tu mi abbia detto dove cercare quei dati. Ovviamente non me li aspettavo nell'interfaccia web,ci mancherebbe.
Comunque,invece di fare il saccente di turno,limitati a spiegare in maniera quanto più semplice possibile,i concetti. Se vuoi essere d'aiuto...
edit
Credo di avere risolto,o comunque ampiamente limitato il problema del voip. Ho installato il firmware 2.1.0 stabile con la gui originale,e lì ho notato che rispetto alla gui di ansuel,alla sezione "nat helpers",c'è la voce "SIP". Attivandola,sembra migliorare la situazione.
Comunque i miei test proseguono...
-
@milan100 vediamo di ripassare assieme un paio di punti della nostra Netiquette:
punto 7: evitate il più possibile (...) multi-posting (due o più messaggi consecutivi nella medesima discussione): è preferibile modificare il messaggio originario, se è abbastanza recente
punto 12: sono vietati in qualsiasi loro gradazione e declinazione messaggi volgari, violenti, polemici, provocatori, denigratori, diffamatori e più in generale non improntati a buona educazione e rispetto
@LuKePicci non ha mai dimostrata saccenza e da sempre offre disponibilità sul Forum entro i limiti delle sue conoscenze (ampie...) e del suo tempo, in questa occasione lo invito (ma non credo avrebbe fatto diversamente) a sorvolare sul tuo tono.
-
Dopo svariati giorni di prove,il problema voip risulta ancora presente. Inutile fare copia ed incolla di configurazioni varie con modifiche apposite,in quanto il risultato sarà sempre lo stesso,ovvero pallini verdi ma incoming calls non funzionanti. Non sembra lì il problema. Spero che qualcuno abbia una qualche idea su come procedere,perchè personalmente non so più che pesci prendere.
-
ma in un primo momento funziona tutto giusto? hai già provato a vedere se con logread esce qualcosa quando c'è una chiamata in arrivo fallita? il chiamante sente occupato o qualche errore ?
-
@FrancYescO funziona se modifico un parametro relativo alla telefonia e confermo. Allora si in quei casi riprende a funzionare. Come se si "risvegliasse". Poi dopo un tot di tempo di circa 2 minuti o forse anche meno,se riprovi,non chiama.
Da logread ho questo che è strano...
Fri Sep 6 14:20:29 2019 user.debug mmpbxd[10138]: [MMRVSIPIMPL::NETWORKOBJ]:E
onStackConfig:1861 - SIP network with local address 31.156.230.143 and local port 0 not found in the list
Oppure anche questo che è simile...
Fri Sep 6 14:12:55 2019 user.debug mmpbxd[6751]: [MMRVSIPIMPL::NETWORKOBJ]:E:
onStackConfig:1861 - SIP network with local address 127.0.0.1 and local port 0 not found in the list
No il chiamante non sente nulla,in quanto non riesce nemmeno a farla la chiamata. Cioè non c'è nemmeno una composizione del numero,semplicemente cade dopo un tot di tempo.
-
con "non chiama" intendi non ricevi o anche non chiama proprio? quando non ricevi riesci a chiamare? quandi per chi prova a chiamarti la chiamata resta muta in eterno senza sentire alcun tono? l'unica cosa che mi viene in mente è di abbassare il tempo di scadenza a qualcosa tipo 60secondi ma credo sia una prova che hai gi fatto..
-
Con non chiama intendo che il telefono di casa non squilla e ovviamente non da segni di vita. Dal cellulare parte la chiamata,ma al telefono di casa non arriva alcun input. Dopo qualche secondo la chiamata da cellulare si stacca.
E sì ho provato ad abbassare ma anche alzare quel valore e non cambia nulla.
-
Forse c'è qualcosa che non va col firewall. Disabilità la fonia, avvia un tcpdump sull'interfaccia wan,, mettilo in output su usb per non riempire la flash o la ram, riabilita la fonia, prova subito a chiamare casa dal cellulare, attendi quanto basta per riprodurre il problema, fai un'altra telefonata in cui si la connessione fallisce come descrivi, stoppa tcpdump,, metti la usb nel pc e mandaci il dump. Non so dirti cosa guardare esattamente e censurarlo è impossibile quindi mandamelo in privato.
-
@LuKePicci Adesso provo,e vediamo...
edit: non mi fa salvare il file ne su usb ne su pc. E' premessa una cosa però,che dice " Il 'Download' non sarà valido se non è stato catturato nulla." Devo supporre che ci sia un qualche altro problema ignoto.
Inoltre vorrei fare presente un'altra stranezza,se cambio i parametri della telefonia,o meglio le porte,da quelle di default,posso comunque chiamare dal telefono. E' possibile una roba del genere?
Ma non si può disattivare il firewall,come d'altronde ho fatto per test con la vodafone station,in modo da capire se il problema sta lì?
-
No, il tcpdump devi avviarlo da shell a mano dando l'opportuno comando Prova a studiarti l'help della versione installata di tcpdump e vedi se ne vieni a capo, non mi ricordo a memoria i vari flag da dare ma devi sicuramente selezionare l'interfaccia (wanptm0/ptm0/waneth4/ o che altro, dipende dalla tua config) e il percorso dove salvare al cattura.
Non ho capito quali porte hai cambiato. Tieni presente che in SIP ci sono di mezzo una porta per ogni proxy, una porta per ogni registrar, una porta per ogni endpoint sip locale, e due intervalli di porte RTP, uno per lato tra cui scegliere per ogni conversazione simultanea due porte, una per l'audio in uscita e una per l'audio in ingresso, entrambe da scegliere più o meno random ad ogni telefonata in ingresso/uscita e da sbloccare dinamicamente nel firewall ogni volta che questo accade. Sono tutte porte UDP, quindi senza connessione, e pertanto vanno tenute aperte in qualche modo, per questo esiste l'helper.
Il firewall è un meccanismo che regola tutte le connessioni che il router fa e quelle che lo attraversano, se lo disattivi non funziona più nulla. Se lo disattivi non funziona nemmeno più l'helper incaricato di aprire le porte quando serve, non funziona più nemmeno il forwarding delle porte da rigirare in lan e via dicendo.
Quello che hai disattivato sulla VSR e che li si chiama "Firewall" è in verità un piccolo insieme di regole di protezione che "osservano" ed eventualmente limitano alcuni tipi di connessioni con comportamenti sospetti e che vengono classificate come tentativi di attacco. Queste sicuramente non ti stanno creando alcun problema.
L'helper va tenuto attivo almeno che tu non abbia configurato nel firewall delle regole statiche che acconsentono al passaggio di traffico voip sulle opportune porte che l'helper apre in automatico.
Il tcpdump ti serve per capire esattamente quali porte sta usando il tim hub, da quali porte il proxy Vodafone ti risponde, e quali tenta di usare per il traffico RTP.
Da quello che descrivi non sembrano esserci problemi sulle porte RTP, in quei casi senti il telefono squillare ma la comunicazione ti risulta muta. A naso pare che la porta di segnalazione in ingresso del tim hub non sia quella che Vodafone tenta di contattare, o che per qualche ragione non sia configurata correttamente per restare aperta. Ti si apre quando fai la telefonata in uscita, o registri il numero o quando esegui una qualsiasi altra operazione di segnalazione per quello che ti dicevo prima, e cioè che le porte UDP vengono mantenute aperte finchè al firewall pare opportuno, per poi essere chiuse, mancando una logica di "connessione" che permette di stabilire correttamente quando chiuderle. Queste richieste di segnalazione che il tim hub manda usano questa porta come porta mittente per pacchetti in uscita, il firewall la mantiene aperta (finchè pare a lui) in ingresso per acconsentire all'arrivo delle risposte. L'helper sip del firewall tiene traccia di tutto ciò che accade su una certa porta e fa in modo che il firewall capisca da solo sbirciando il traffico quando è il caso di mantenere quelle porte aperte.
-
tcpdump -i pppoe-wan -w /mnt/usb/USB-A1/dump.pcap
sempre che non si diverta a perdere pacchetti...
-
@LuKePicci
Dunque,ho risolto il problema del tcpdump mettendo una versione dev della GUI ansuel. Fare l'upgradegui non aveva risolto il problema. Il punto é che dalle varie righe,vengono fuori un bel po' di dati altamente sensibili. E sai com'é,fidarsi è bene,non fidarsi é meglio. Eventualmente lo analizzo per bene io che comunque so identificare la parte relativa alla telefonia. Diciamo che c'ho fatto l'occhio tra una prova e l'altra.
Tralasciando il discorso sul firewall, giustissimo e anche verificato sul campo, hai parlato spesso di questo "helper". Ti riferisci a questo?
(https://i.ibb.co/thzDQXJ/Screenshot-20190908-024030.jpg) (https://ibb.co/thzDQXJ)
Se si tratta di questo,c'ho lavorato su giorni fa,e sembrava funzionasse,in realtà non ha risolto nulla. Avevo attivato la porta 5060 ed altre erano già attive di default. Poi documentandomi leggevo che era altamente consigliato tenere disabilitato il tutto perché spesso creano casini.
Piuttosto guardando quest'immagine,mi sapresti dire se trovi qualcosa di coerente con la "causa"?
Ho provato a fare delle prove ma non ho la sicurezza dei dati da inserire. Posso mettere la porta udp 5060,ed aggiungere pure un range di porte. Il problema é che ci vogliono anche degli indirizzi...Magari é utile.
(https://i.ibb.co/pPcR6mk/Screenshot-20190908-024203.jpg) (https://ibb.co/pPcR6mk)
PS @FrancYescO ti ringrazio lo stesso,alla fine come dicevo,ho risolto mettendo l'ultima dev. Nemmeno l'upgradegui aveva risolto il problema.
-
Devi tenere attivi gli helper a meno che non configuri a mano tutte le regole necessarie. Può creare casini solo se usi qualche client voip su altri device connessi ad un proxy sip sulla stessa port a sulla quale l'helper è in funzione. Il primo screen che mi hai mandato non so quali helper elenca, potrebbero comparirvi tutti o forse no. Ad esempio sul mio fastgate e sul router tiscali di helper sip ce ne sono due, uno per il client locale tenuto attivo, ed uno per i client lan tenuto disattivo dato che ormai i client voip fatti per vivere dietro nat fanno traversal in modi diversi. Il secondo screen invece si riferisce alle regole di port forwarding, niente che ti interessi. Le regole attive devi controllarle nel file di configurazione del firewall
Sarebbe meglio che queste prove le facessi senza custom gui, altrimenti non si capisce se il problema è con la gui o meno. Detto questo senza dump e file di configurazione in mano non ho altro da poterti suggerire.
-
@LuKePicci nel frattempo,facendo diverse chiamate,dal tcp dump ho rilevato questi dati che potrebbero esserti utili. Si ripetono nello stesso modo,dopo ogni chiamata fallita.
> 12:13:48.876929 IP 91.80.35.167.domain > net-***.cust.vodafonedsl.it.52789: 34713 ServFail 0/0/0 (46)
> 12:13:48.886578 IP 91.80.35.167.domain > net-***.cust.vodafonedsl.it.38337: 2031 ServFail 0/0/0 (46)
> 12:13:48.888846 IP net-***.cust.vodafonedsl.it.57941 > 91.80.35.167.domain: 9672+ A? ntp-tr069-1.interbusiness.it. (46)
> 12:13:48.889357 IP net-***.cust.vodafonedsl.it.18876 > 91.80.35.167.domain: 34691+ AAAA? ntp-tr069-1.interbusiness.it. (46)
> 12:13:48.986338 IP 91.80.35.167.domain > net-***.cust.vodafonedsl.it.18876: 34691 ServFail 0/0/0 (46)
> 12:13:48.989076 IP 91.80.35.167.domain > net-***.cust.vodafonedsl.it.57941: 9672 ServFail 0/0/0 (46)
> 12:13:48.990227 IP net-***.cust.vodafonedsl.it.58361 > 91.80.35.167.domain: 47304+ A? ntp-tr069-1.interbusiness.it. (46)
> 12:13:48.990828 IP net-***.cust.vodafonedsl.it.59885 > 91.80.35.167.domain: 43685+ AAAA? ntp-tr069-1.interbusiness.it. (46)
> 12:13:49.093364 IP 91.80.35.167.domain > net-***.cust.vodafonedsl.it.59885: 43685 ServFail 0/0/0 (46)
> 12:13:49.097580 IP 91.80.35.167.domain > net-***.cust.vodafonedsl.it.58361: 47304 ServFail 0/0/0 (46)
> 12:13:51.126350 IP 190-173-106-124.speedy.com.ar.48929 > net-***.cust.vodafonedsl.it.telnet: Flags [S], seq 3164153596, win 32761, length 0
> 12:13:51.711545 IP net-***.cust.vodafonedsl.it.31497 > 91.80.35.167.domain: 7041+ PTR? 124.106.173.190.in-addr.arpa. (46)
> 12:13:51.949582 IP net-***.cust.vodafonedsl.it.54610 > 91.80.35.167.domain: 3290+ PTR? 124.106.173.190.in-addr.arpa. (46)
> 12:13:52.042870 IP 91.80.35.167.domain > net-***.cust.vodafonedsl.it.54610: 3290 1/0/0 PTR 190-173-106-124.speedy.com.ar. (89)
> 12:13:52.043033 IP 91.80.35.167.domain > net-***.cust.vodafonedsl.it.31497: 7041 1/0/0 PTR 190-173-106-124.speedy.com.ar. (89)
C'è un range di porte enorme. E il server fallisce.
12:27:07.765925 IP 91.80.35.167.domain > net-***.cust.vodafonedsl.it.45630: 47774 ServFail 0/0/0 (46)
> 12:27:07.766053 IP 91.80.35.167.domain > net-***.cust.vodafonedsl.it.56524: 19109 ServFail 0/0/0 (46)
> 12:27:07.767465 IP net-***.cust.vodafonedsl.it.40159 > 91.80.35.167.domain: 52219+ A? ntp-tr069-2.interbusiness.it. (46)
> 12:27:07.768037 IP net-***.cust.vodafonedsl.it.3342 > 91.80.35.167.domain: 39680+ AAAA? ntp-tr069-2.interbusiness.it. (46)
> 12:27:07.868916 IP 91.80.35.167.domain > net-***.cust.vodafonedsl.it.40159: 52219 ServFail 0/0/0 (46)
> 12:27:07.872422 IP 91.80.35.167.domain > net-***.cust.vodafonedsl.it.3342: 39680 ServFail 0/0/0 (46)
> 12:27:07.874758 IP net-***.cust.vodafonedsl.it.1860 > 91.80.35.167.domain: 22362+ A? ntp-tr069-1.interbusiness.it. (46)
> 12:27:07.875265 IP net-***.cust.vodafonedsl.it.55489 > 91.80.35.167.domain: 9418+ AAAA? ntp-tr069-1.interbusiness.it. (46)
> 12:27:07.970932 IP 91.80.35.167.domain > net-***.cust.vodafonedsl.it.1860: 22362 ServFail 0/0/0 (46)
> 12:27:07.983914 IP 91.80.35.167.domain > net-***.cust.vodafonedsl.it.55489: 9418 ServFail 0/0/0 (46)
> 12:27:07.985057 IP net-***.cust.vodafonedsl.it.9799 > 91.80.35.167.domain: 53883+ A? ntp-tr069-1.interbusiness.it. (46)
> 12:27:07.985591 IP net-***.cust.vodafonedsl.it.37576 > 91.80.35.167.domain: 30463+ AAAA? ntp-tr069-1.interbusiness.it. (46)
> 12:27:08.081667 IP 91.80.35.167.domain > net-***.cust.vodafonedsl.it.9799: 53883 ServFail 0/0/0 (46)
> 12:27:08.087174 IP 91.80.35.167.domain > net-***.cust.vodafonedsl.it.37576: 30463 ServFail 0/0/0 (46)
> 12:27:08.184919 IP 159.65.188.19.59020 > net-***.cust.vodafonedsl.it.60001: Flags [S], seq 1488400042, win 65535, length
-
Non ci vedo alcuna correlazione, sembra fallire la risoluzione di alcuni nomi di dominio di tim. Comunque il dump devi aprirlo in wireshark, leggerlo in forma testuale è decisamente complesso,
-
@FrancYescO potresti fare cortesemente un test della porta 5060,e dirmi se ti risulta aperta?
https://www.spaceclick.com/it/test-delle-porte-aperte-sul-firewall-o-nat/
-
Sul 4130, anche con un account registrato e nat helper sip abilitato risulta stealth
-
@FrancYescO a me spunta la stessa cosa. Se provo ad aprire una porta,come ad esempio quella 8080,mi segna "closed",ma non viene mai aperta. Il che a questo punto mi porta a pensare che il problema VoIP sta proprio qui. Una mancata apertura delle porte. Il firewall al minimo,blocca totalmente le connessioni in ingresso,il port forwading non dá effetti, l'helper sip non si capisce che ci sta a fare se non fa il suo lavoro. Lato software questo modem é preoccupante. E questo con o senza GUI ansuel.
Inoltre modificare il file di configurazione,anche con regole personalizzate,non serve a nulla perché non le prende. Avevo pure forzato il firewall a consentire il traffico in ingresso,ma non va.
-
Questi modem sono nati per funzionare solo come l'ISP li fornisce, e non come "router commerciali general pourpose", portare qualcosa a fare quello per cui non è stata inizialmente pensata è sempre complicato...
comunque mi viene un dubio, nella config del voip l'interfaccia è impostata a wan? (devi guardare i file di configurazione non da interfaccia)
-
@FrancYescO si ricordo bene fosse impostata a wan. Quei file di configurazione li ho spulciati in tutte le salse.
-
Calma, non ha nessun senso aggiungere regole al firewall per poi dire che non "le prende" se non si sa come verificare correttamente la cosa.
I test di "apertura porte" verificano solo che ad un certo indirizzo IP:PORTA ci sia qualcosa che risponde al messaggio sonda. Per cui:
- Se "apri una porta" ovvero acconsenti a traffico entrante da una certa interfaccia verso un'altra con determinate restrizioni su ip e porte di mittente e destinatario stai solo dicendo al firewall che quel tipo di traffico è concesso, ovvero fa eccezione rispetto alla regola di base che è "nega connessioni in ingresso da wan"
- Se tieni una "pota aperta" e dietro quella porta non c'è nulla il test ti dice sempre che è chiusa, quel test non fa un check di apertura porte, fa solo un check di raggiungibilità di un qualsiasi servizio dietro quella porta
- Se la porta è aperta per traffico TCP e dietro c'è un socket TCP aperto allora il check di apertura porte riesce bene perchè al primo pacchetto di connessione ricevuto il servizio risponde col secondo pacchetto dell'handshake di connessione TCP, quindi la porta è data (più o meno inequivocabilmente) come aperta
- Se la porta è aperta per traffico UDP e dietro c'è un socket UDP aperto il check di apertura porte non da risultati concludenti perchè non sa cosa inviare al servizio per far si che esso risponda, un servizio UDP fatto bene resta completamente muto se riceve in ingresso dati che per lui non hanno senso
Se non sai che pesci prendere col firewall ti suggerisco di approfondire sulla documentazione ufficiale: https://openwrt.org/docs/guide-user/firewall/start
-
@LuKePicci darò un'occhiata alla documentazione. Resta il fatto che,in assenza di "opzioni specifiche",come può essere un server stun,il firewall sarà un problema. In questo modem/router,chiaramente.
In ogni caso,sono riuscito dopo l'ennesimo tentativo,a mettere il tim hub in cascata alla vodafone station,cosi almeno in via temporanea,ho un voip funzionante al 100% ed un Tim hub che si occupa di tutto il resto.
-
STUN è una tecnologia del passato, non si usa più tranne che in qualche vecchio device incapace di tecniche di traversal moderne. Va da se che STUN è appunto una tecnica di nat traversal e che quindi non ha nulla a che fare col tuo problema visto che non stai avendo problemi a configurare client sip dietro NAT, perchè il NAT del TIM hub sta sul router tra lan e wan, mentre il suo client sip interno (mmpbx) va direttamente su internet da interfaccia wan senza transitare dal router (e dal NAT). Infatti non trovi mai configurato alcun nat traversal (tantomeno STUN) su qualsiasi configurazione di default di un gateway fornito per essere esso stesso il router il NAT della tua rete. Quindi tutto quello che dirò qui sotto sarà una divagazione non inerente il tuo problema originario.
Se vuoi configurare il voip di Vodafone (o di qualsiasi provider) su un client LAN abbastanza vecchiotto, e questo client non sa come sopravvivere dietro NAT se non con l'aiuto di STUN, allora un qualsiasi server STUN andrà bene allo scopo, non è necessario che sia quello di Vodafone (non credo esista), ce ne sono anche di pubblici a disposizione.
Una panoramica aggiornata delle tecniche di NAT traversal la trovi su wikipedia: https://en.wikipedia.org/wiki/NAT_traversal guardati principalmente hole punching, STUN e ICE
Ti suggerisco in particolare i paragrafi "Introduction" e "Overview" della specifica di ICE che sono un buon recap dello stato dell'arte a riguardo https://tools.ietf.org/html/rfc5245
Di solito l'helper )anche chiamato ALG) per sip non da il meglio di se quando c'è da gestire un client dietro NAT, e per questo di solito si preferisce andare con hole punching (anche chiamato "NAT mapping" nei client sip di cisco/linksys) o al limite STUN se il NAT fa il difficile.
Ma quando si tratta di creare le opportune regole di "allow" per il traffico da interfaccia pubblica destinato a se stesso l'helper funziona bene, crea le eccezioni dinamiche che servono senza mettere mano ai campi di segnalazione e tutti vivono felici e contenti.
-
Salve se a qualcuno potrebbe servire sono riuscito a far funzionare anche la parte Voip con vodafone nel mio tim hub dg4132. Ho installato con la procedura autoflashgui-github-dev con firmware AGTHP_2.0.0_CLOSED.rbi impostando poi i vari parametri come da vostra guida.
Testato e funzionante tutto......
-
Ragazzi qualcuno è riuscito a risolvere il problema che dopo un tot il voip non riceve piu le chiamate? Perche riesco a navigare su internet e a fare le chiamate ma il voip dopo qualche minuto non mi fa ricevere piu le chiamate :( . Ho gia provato con quasi tutti i firmware che ci sono >:(
-
Anche a me si presenta questo problema :'( qualcuno sa come poterlo risolvere?
-
Forse non c'entra nulla ma provate a rimuovere dal file /etc/config/mmpbxrvsipnet la riga option user_param_value 'phone'
(fonte: https://www.ilpuntotecnico.com/forum/index.php/topic,81513.msg256962.html#msg256962)
-
Ciao a tutti. Ho configurato tutto come da guida, la stato della linea resta sempre "unregistered" (pallino grigio). Verificato e riverificato tutti i parametri di configurazione e sono corretti, sembra quasi che non provi neanche a connettersi. Riporto di seguito i parametri che ho utilizzato:
Firmware: 2.2.001 Ansuel
IMPOSTAZIONI SIP:
Globale
Nome: vodafone
Registrar primario: ims.vodafone.it
Nome dominio: ims.vodafone.it
Realm:
Porta registrar primario: 5060
Proxy primario: voip1.fixed.vodafone.it
Porta proxy primario: 0
Porta locale: 0
Scadenza: 3600
Linee Telefoniche:
Profilo SIP: sip_profile_2
Nome utente: +39***@ims.vodafone.it
URI: +39***
Password: Pass di 28 caratteri fornita da Vodafone
Visualizza nome: +39***
Rete SIP: vodafone
Mappatura ingresso/uscita:
abilitato spunte su fx1
Codec attivi su fx1:
PCMA
G729
G722
Nel file di log non sono riuscito neanche ad individuare tentativi di connessione falliti.. ho sbagliato qualcosa nelle configurazioni o devo entrare nel vortice dei reset/reimpostazioni/riavvii?
Grazie in anticipo per l'aiuto
-
Se @gacchu provi a mettere 5060,in porta proxy primario,dovrebbe andare. Ti avviso però che con tutta probabilità,pur funzionando avresti il problema delle chiamate in ingresso. Un problema che pare irrisolvibile per noi che abbiamo Vodafone.
-
Avevo già provato, ma non è cambiato nulla.. nel weekend effettuerò altri tentativi. E' un vero peccato, con la VS avevo una connessione 87/19, con il tim hub 170/26.. valori a parte, la reattività in navigazione è tutta un'altra cosa, il wifi è degno di questo nome e non ho le frequentissime disconnessioni che avevo con la VS dovute all'eccessivo numero di periferiche connesse (una quarantina circa).
Spero di riuscire a far funzionare la connessione SIP, altrimenti mi è impossibile effettuare un debug per capire come risolvere il problema dello sleep della ricezione.
Comunque grazie mille per il supporto
-
Avevo letto di gente a cui effettivamente non si registrava proprio. I dati son quelli,al massimo potresti provare a cambiare il proxy primario con voip2 o 3,a prescindere dai dati che ti hanno fornito. Dopodiché non ti resta che provare con riavvii vari oppure andare di reset. Una soluzione che di solito ha risolto il problema a molti.
Comunque ho fatto tutte le prove possibili ed immaginabili,per settimane. Dopodiché l'ho messo in cascata con la Vodafone station,e buonanotte. Due minuti circa dal riavvio totale del modem,e riesci a ricevere, dopodiché fine. Ma la cosa grave é che sto problema pare irrisolvibile solo con l'operatore Vodafone, perché con gli altri va,e quando non va,la soluzione c'é.
-
La mia VS purtroppo non regge la struttura IOT del mio appartamento, ogni due giorni si inchioda e per la gestione domotica di casa non posso proprio andare avanti così.
Oltre a questo c'è una differenza spaventosa sia sul ping che sulla velocità di connessione, quindi, anche se mettere qualcosa in cascata alla VS alleggerirebbe il carico, non trovo sensato mettere due apparati quando (se si riesce a farlo funzionare) ne basta uno.
Se riesco a far funzionare la connessione SIP con i dati che mi ha fornito Vodafone, comincio a fare un po' di debug e magari una pezza per lo sleep delle chiamate in ingresso si trova.
-
Da ieri sera ho finalmente i servizi SIP autenticati. Naturalmente anche la mia linea soffre dello sleep delle chiamate in ingresso che inizia dopo circa 60 secondi dalla registrazione.
Mi sono documentato e, da quello che ho capito, la causa più probabile è dovuta al fatto che il DGA4132 chiude le porte UDP sulle quali non è presente traffico da oltre 60 secondi.
Nel caso in cui il problema fosse questo, le possibili soluzioni sono le seguenti:
1) Effettuare un NAT statico solo per i servizi legati alle connessioni SIP, strada che non è facilmente percorribile e che non è detto che sia risolutiva
2) Individuare se all'interno del servizio mmpbxd è presente la possibilità di impostare una qualche funzione di NAT Keep Alive. Tale funzione è presente anche nei telefoni VOIP più economici, ed è stata implementata nei FrtizBox proprio per evitare questa tipologia di problema. Purtroppo non ho trovato alcuna documentazione su mmpbxd (temo non esista) e non ha senso mettere mano nei file di configurazione andando "a caso". Se qualcuno ha modo di reperire documentazione al riguardo, magari può condividerla qui nel forum.
3) Trovare il modo per evitare che vengano troncate le connessioni UDP senza traffico. Purtroppo non è detto che tale regola sia decisa dal firewall, comunque ho salvato il listato delle regole impostate in iptables (iptables -L) in un file di testo che mi sono spulciato con santa pazienza, ma non ho individuato niente al riguardo. Purtroppo le regole del firewall sono impostate con "fw3", che ha file di configurazione e bash script legati ai servizi sparsi un po' in tutto il file system, quindi verificare tutto richiederà del tempo che al momento non ho.
Prima di tornare a fare prove, volevo capire una cosa che leggendo tutto questo thread non mi è chiara:
Tutti i possessori del DGA4132 hanno il problema delle incoming call funzionanti per i primi 60 secondi o è un problema solo di alcuni?
-
ciao qual'è questa porta udp che si chiude?
-
Non viene chiusa la porta, viene troncata la connessione UDP sulla porta impostata nella configurazione SIP, nel mio caso la 5060
-
puoi abilitare questa porta dalla card Helper NAT e vedere come va?
-
Posso provare, ma a occhio non serve a niente. L'helper non fa altro che prendere i pacchetti in ingresso e modificarli per "aiutarli" nell'instradamento. Non ho nessun porblema di questo tipo e mettere qualcosa in mezzo che fa rewrite su pacchetti che vengono letti e interpretati bene aggiungerebbe solo una complicazione. Comunque quando torno a casa provvedo ad effettuare la prova, ma solitamente l'utilizzo degli helper in ambito SIP soprattutto con apparati economici è sconsigliato (capita spesso che la procedura di rewrite crei pacchetti corrotti che risultano poi illeggibili dai servizi SIP ai quali sono destinati)
-
un ultima cosa nella card telefonia puoi abbassare la scadenza a 60 e vedere come va?
-
Abbassare la scadenza a 60 è la prima cosa che ho fatto (attualmente è impostata a 60), ma non è lí il problema.. servirebbe un'opzione in più di NAT keep alive che manda pacchetti specifici sulla porta UDP ad intervalli solitamente tra i 15 e i 30 secondi. Comunque alle 12 mi chiama il tecnico Vodafone, sono curioso di sapere cosa dice (sicuramente niente di utile)
-
Per curiosità se da router lanci nc -vu ipdiconnessione:5060 cosa succede?
-
@gacchu Ti dico subito che é un problema che abbiamo tutti gli utenti vodafone. Su questo non ci piove. Sono abbastanza convinto che sia un problema che riguarda le regole del firewall, però non so esattamente cosa aggiungere. Riguardo i file di configurazione del VoIP,ho cambiato e ricambiato praticamente tutti i parametri possibili ed immaginabili,ma non ho mai avuto alcun riscontro positivo.
La cosa più assurda però é che non si trova nulla in giro sulla combo Vodafone/Tim hub,in riferimento alla risoluzione di questa problema,mentre gli altri operatori vanno abbastanza lisci.
-
Per curiosità se da router lanci nc -vu ipdiconnessione:5060 cosa succede?
la porta è aperta
root@modemtim:~# nc -vu wainip:5060
wainip:5060 (wainip:5060) open
Purtroppo non è detto che la chiusura delle connessioni UDP oltre i 60 secondi sia impostata dal FW.. comunque non resta che indagare perché il problema è sicuramente quello.
Diciamo che in ordine le soluzioni "pulite" sono 2:
1) Vodafone la smette di fare la furbina ed effettua una configurazione dei loro server SIP che sia compatibile con la maggior parte dei router in commercio (il problema non lo ha solo il DGA4132 ma più o meno tutti i modem/router fascia medio/bassa)
2) Impostare un Keep Alive su mmpbxd, ma senza documentazione al riguardo è impossibile farlo (e molto probabilmente non è un'opzione disponibile)
Prima di riesumare il DGA4132, avevo una mezza idea di acquistare un FritzBox 7590. Spendere tutti quei soldi per avere un'opzione che "argina " il problema (molti utenti continuano ad avere una sporadica irraggiungibilità per le chiamate in ingresso risolvibile solo con il riavvio del sistema che gestisce la fonia) sinceramente è una cosa che mi lascia perplesso. Da un gestore TELEFONICO mi aspetto che il telefono funzioni, senza che io debba chiamare ogni tanto il mio numero per vedere se è tutto ok.
Purtroppo avevo una connessione TIM su cui dovevo fare una voltura, ma l'unico modo per farla era spendere parecchi soldi (la buona vecchia TIM non applicava promozioni sulle volture, quindi erano 45 euro al mese) oppure cessare la linea (perdendo il numero di telefono) e farne una nuova, opzione neanche considerata. Facendo il cambio con Vodafone ho risolto questo problema, ma devo dire che veramente è un pessimo operatore. La VS che danno non è minimamente adeguata, il servizio che offrono (la nostra situazione lo testimonia) è veramente ridicolo e per di più fanno spesso (odiose) rimodulazioni unilaterali del contratto. Se non dovessi pagare penali/quota rimanente per l'acquisto del modem (anche se ora lo chiamano in maniera diversa), tornerei subito a TIM che, seppur con immensi difetti lato assistenza, per chi sa dove mettere mano offre secondo la mia esperienza un servizio di qualità maggiore.
-
la puoi togliere questa porta di default e impostarne una sopra i 40000 con scadenza a 60 e vedi come va?
-
fatto.. sempre uguale, appena abilito la fonia funziona in ricezione per 60 secondi. Se effettuo una chiamata, da quando riaggancio funziona per altri 60 secondi
-
Mi ha contattato l'assistenza Vodafone, tale Francesco molto cordiale e gentile. L'operatore è entrato in uno dei PC di casa tramite anydesk per verificare la configurazione del router. Ha detto che era la prima volta che si trovava davanti ad un technicolor.. comunque ha girato per i vari menù di configurazione SIP per confermarmi semplicemente che è tutto corretto. Ha passato 5 minuti buoni a cercare quella che lui ha definito "l'opzione presente anche nei Fritz" (AKA keep alive) che non ha naturalmente trovato.
Mi ha dato un altro appuntamento a martedì sera così ha il tempo per confrontarsi con i colleghi.
Vedendo lo storico della mia linea mi ha confermato che la VS aveva frequentissime disconnessioni (che ora non ho più) e che la velocità di connessione è più che raddoppiata ed ha imputato la causa dei problemi di instabilità della VS ad un eccessivo numero di connessioni (ne ho circa 40 con un passaggio di banda medio di 5 kb/s, quasi nullo). Morale, mi ha confermato che la VS è spazzatura e che mettere qualcosa in cascata non migliorerebbe la situazione.
Quando gli ho fatto presente che questo problema del keep alive lo hanno praticamente tutti i router tranne i Fritz (che hanno sviluppato questa funzione da pochissimo soprattutto su input degli utenti Vodafone imbestialiti) e che comunque anche se argina il problema non lo risolve, mi ha detto che il problema è noto e che ci stanno lavorando. Considerando che la delibera sul modem libero è in vigore da poco più di un anno, direi che non ci stanno affatto lavorando.
Detto ciò, cercherò documentazione su come funziona questo keep alive e se il pacchetto che viene mandato non contiene dati particolari (cosa di cui dubito fortemente perché probabilmente deve per forza essere inviato da mmpbxd), proverò a sviluppare un semplice programmino da mettere in esecuzione in crontab ogni 15 secondi.
-
Rimango perplesso sul "é un problema noto". Dopo un anno mi chiedo come sia possibile che non abbiano trovato una soluzione. In ogni caso,a prescindere dal keep alive,la fonia tim,che io sappia,funziona normalmente. Per cui devo pensare che rispetto ad altri operatori usino una struttura tecnologica del VoIP differente. Alla fine il keep alive é una sorta di workaround che risolve più o meno il problema,un po' come girarci attorno. Comunque metterlo in cascata sicuramente non é il top però riesci a sfruttarne un migliore lato routing rispetto alla vsr,con un WiFi nettamente superiore,e soprattutto sempre stabile.
-
Per capire se il problema è il nat e il firewall basta disattivarlo momentaneamente e vedere cosa succede dopo i 60 secondi.
Se il problema è solo sul 4132 potete confrontare le conf dei vari technicolor che sono differenti.
-
Oppure lo configurate su vlan voce come fa la station e vedete se il problema sparisce.
-
Cercherò altri utenti che hanno technicolor e vodafone, per ora non ho trovato nulla. Prima di giocare con il firewall (disabilitando si perdono tutte le regole iptables? se si, così si fanno più danni che altro) sto effettuando delle prove cambiando i parametri di timeout direttamente nelle variabili di sistema.
Per ora ho cambiato:
net.netfilter.nf_conntrack_udp_timeout = 86400 (precedentemente impostata a 60)
net.netfilter.nf_conntrack_udp_timeout_stream = 3000 (precedentemente impostata a 300)
non è cambiato nulla.. più tardi verifico gli altri conntrack sia delle connessioni TCP che di quelle ICMP e provo a cambiare i valori. Anche se si arrivasse ad una soluzione con questa tecnica l'overload sul lungo periodo è praticamente assicurato. Comunque per ora mi serve solo individuare con certezza la causa, finiti questi tentativi comincerò a mettere mano sul firewall e vediamo cosa ne esce
-
Oppure lo configurate su vlan voce come fa la station e vedete se il problema sparisce.
cioè? lo faccio andare non su wan ma su lan?
-
Per disabilitare il nat basta deselezionarlo da accesso internet, per il firewall da ssh /etc/init.d/firewall stop , per riattivarlo /etc/init.d/firewall start o restart . Non si perde nessuna regola visto che non si sono modificate le configurazioni.
-
Ho provato entrambe le cose,già tempo fa. Con il NAT disattivato non cambia nulla,mentre il firewall disattivato crea casini che non fanno funzionare la connessione.
-
No, crei una seconda wan (chiamala voip) sempre pppoe che anziché su vlan 1036 va su 1035 e configuri mmpbx con i relativi parametri. Username e password sono i medesimi, il proxy chiaramente è diverso e devi leggerlo dalle settings della Vodafone station.
-
.
-
Questa è una cosa che effettivamente si potrebbe provare, anche se credo che non cambi assolutamente nulla dato che i server SIP di vodafone saranno impostati tutti nello stesso modo. Tra le interfacce selezionabili nella configurazione di mmpbx ne è già presente una che si chiama "voip" che ho già provato ad usare ma che non aggancia la registrazione.
Purtroppo non ho un accesso SSH alla vodafone station per vedere come è configurata la vlan e non so come vedere a quale proxy si collega (non mi pare che venga mostrato da nessuna parte nell'interfaccia grafica).
Se qualcuno mi guida su come creare una nuova vlan in modo corretto posso anche provare, non saprei andare oltre un "vconfig add voip2 1035"
Riporto di seguito le interfacce già presenti nel router, dove tra l'altro non trovo l'interfaccia "voip" presente nella configurazione di mmpbx:
root@modemtim:/etc# ifconfig
bcmsw Link encap:Ethernet HWaddr A4:91:B1:34:3D:9A
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:192776 errors:0 dropped:0 overruns:0 frame:0
TX packets:1183967 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:23091275 (22.0 MiB) TX bytes:400514012 (381.9 MiB)
Base address:0xffff
br-lan Link encap:Ethernet HWaddr A4:91:B1:34:3D:9A
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::a691:b1ff:fe34:3d9a/64 Scope:Link
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:913805 errors:0 dropped:0 overruns:0 frame:0
TX packets:1415366 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:184067759 (175.5 MiB) TX bytes:1350172263 (1.2 GiB)
eth0 Link encap:Ethernet HWaddr A4:91:B1:34:3D:9A
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:965316 errors:0 dropped:0 overruns:0 frame:0
TX packets:1515406 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:190446420 (181.6 MiB) TX bytes:1387763151 (1.2 GiB)
eth1 Link encap:Ethernet HWaddr A4:91:B1:34:3D:9A
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:88154 errors:0 dropped:0 overruns:0 frame:0
TX packets:453173 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:63249043 (60.3 MiB) TX bytes:125484009 (119.6 MiB)
eth2 Link encap:Ethernet HWaddr A4:91:B1:34:3D:9A
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
eth3 Link encap:Ethernet HWaddr A4:91:B1:34:3D:9A
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
eth4 Link encap:Ethernet HWaddr A4:91:B1:34:3D:9A
inet addr:192.168.10.1 Bcast:192.168.10.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
eth5 Link encap:Ethernet HWaddr A4:91:B1:34:3D:9A
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:28646 errors:0 dropped:10 overruns:0 frame:0
TX packets:400486 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2440912 (2.3 MiB) TX bytes:125797188 (119.9 MiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:8737 errors:0 dropped:0 overruns:0 frame:0
TX packets:8737 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:733087 (715.9 KiB) TX bytes:733087 (715.9 KiB)
pppoe-wan Link encap:Point-to-Point Protocol
inet addr:188.217.107.66 P-t-P:188.217.96.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:1079785 errors:0 dropped:0 overruns:0 frame:0
TX packets:819315 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:1219527474 (1.1 GiB) TX bytes:171765612 (163.8 MiB)
ptm0 Link encap:Ethernet HWaddr A4:91:B1:34:3D:9A
inet6 addr: fe80::a691:b1ff:fe34:3d9a/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1080497 errors:0 dropped:0 overruns:0 frame:0
TX packets:820052 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1251795018 (1.1 GiB) TX bytes:191820152 (182.9 MiB)
wanptm0 Link encap:Ethernet HWaddr A4:91:B1:34:3D:9A
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:37040 errors:0 dropped:0 overruns:0 frame:0
TX packets:38481 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3533928 (3.3 MiB) TX bytes:3495674 (3.3 MiB)
wl0 Link encap:Ethernet HWaddr A4:91:B1:34:3D:9B
inet6 addr: fe80::a691:b1ff:fe34:3d9b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:171918 errors:0 dropped:15 overruns:0 frame:217565
TX packets:269728 errors:246796 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:29752295 (28.3 MiB) TX bytes:73116959 (69.7 MiB)
Interrupt:92
wl0_1 Link encap:Ethernet HWaddr A4:91:B1:34:3D:9B
inet addr:192.168.168.1 Bcast:192.168.168.127 Mask:255.255.255.128
inet6 addr: fe80::a691:b1ff:fe34:3d9b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:217565
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
wl1_1 Link encap:Ethernet HWaddr A4:91:B1:34:3D:9A
inet addr:192.168.168.129 Bcast:192.168.168.255 Mask:255.255.255.128
inet6 addr: fe80::a691:b1ff:fe34:3d9a/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:45 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:6614 (6.4 KiB)
-
Apri il file /etc/config/network, trova la definizione di wan, duplicala e cambiale nome in voip -a meno che non ce ne sia già una. Guarda cosa hai in ifname, trova la definizione di quell'interfaccia, duplicala, cambiale nome e cambia il vid da 1036 a 1035. Torna dove eri prima e metti in ifname il nuovo nome. Cambia l'username sostituendo D- con V-. Salva tutto, riavvia la rete (o il router), e verifica in ifconfig che sia apparsa "pppoe-voip". Vai in mmpbx metti voip come interfaccia al posto di wan. A questo punto ti manca solo da scoprire il proxy. Fai tutto quello che ho detto, poi ti dico come farlo.
-
Ho duplicato wanptm0. Inizialmente avevo lasciato il MAC ADDRESS uguale, ma dato da quello che ho capito due connessioni pppoe non possono avere lo stesso mac (rif. https://gist.github.com/druzn3k/f4cb9ad3fdfdf4d8fee929bbca4a15d9) ho provato semplicemente ad inserire il MA della VSR (non credo che vada bene)
config device 'wanptm0'
option type '8021q'
option name 'wanptm0'
option macaddr 'A4:91:B1:34:3D:9A'
option ifname 'ptm0'
option ipv6 '0'
option vid '1036'
config device 'wanptm1'
option type '8021q'
option name 'wanptm1'
option macaddr 'E4:8F:34:3A:04:24'
option ifname 'ptm1'
option ipv6 '0'
option vid '1035'
successivamente ho duplicato l'interfaccia wan, mettendo sempre il MAC della VSR:
config interface 'wan'
option auto '1'
option proto 'pppoe'
option demand '0'
option macaddr 'A4:91:B1:34:3D:9A'
option ipv6 '0'
option keepalive_adaptive '0'
option dns_metric '0'
option ifname 'wanptm0'
option password 'vodafoneadsl'
option username 'vodafoneadsl'
option keepalive '4,20'
option metric '0'
config interface 'voip2'
option auto '1'
option proto 'pppoe'
option demand '0'
option macaddr 'E4:8F:34:3A:04:24'
option ipv6 '0'
option keepalive_adaptive '0'
option dns_metric '0'
option ifname 'wanptm1'
option password 'Vodafone'
option username 'V-[SNsulretrodellaVSR]'
option keepalive '4,20'
option metric '0'
Il primo tentativo lo ho fatto lasciando il MA delle sezioni uguale, ma al riavvio in ifconfig non ho trovato niente di nuovo. Successivamente ho cambiato il MA, il risultato è stato il medesimo.
Prima di mettere nuovamente mano sulla configurazione delle interfacce, preferisco incollare queste configurazioni, perché magari ho tralasciato qualcosa.
Grazie per il supporto
-
Dice anche di aggiungere alla sezione wan la stringa "host_uniq=583132333435363738393031323334". In cui quei valori corrispondono alla conversione esadecimale del numero seriale della station.
Per quanto riguarda i mac address,basta "falsificarne" uno cambiando magari i due valori finali.
A me non tornano alcuni punti della guida,in quanto fa riferimento a debian. Per esempio dice:
The data PPPoE connection must use the Station serial number prepended with D- as username,
and something in the form of VJ|5.4.8.1.160.12.56.1.28|RA|CGN=1|pw=Vodafone as password, which means:
VJ stands for Vodafone Jungo (now OpenRG, the closed, crappy, monolithic, obsolete software inside the Station)
5.4.8.1.160.12.56.1.28 is the Station software version
RA don't really know
CGN=1 Carrier Grade Nat enabled
pw=Vodafone lol?
For example, in Debian a provider file this in /etc/ppp/peers/data will work:
persist
noauth
defaultroute
ifname pppoe-data
name D-X12345678901234
plugin rp-pppoe.so
host-uniq 583132333435363738393031323334
nic-eth0.1036
and add this line in /etc/ppp/pap-secrets:
D-X12345678901234 * VJ|5.4.8.1.160.12.56.1.28|RA|CGN=1|pw=Vodafone
Tutto chiaro il procedimento ma il corrispettivo openwrt quale sarebbe?
Anche qua fa riferimento a debian...
The voice PPPoE connection must use the Station serial number prepended with V- as username, and vodafone as password.
In your beloved Debian system it can be done by creating /etc/ppp/peers/voice with this content:
nodefaultroute
noauth
ifname pppoe-voice
name V-X12345678901234
plugin rp-pppoe.so
host-uniq 583132333435363738393031323334
nic-eth0.1035
and this entry in /etc/ppp/pap-secrets:
V-X12345678901234 * vodafone
The SIP and RTP server are accessible only via the voice WAN and belong to the 10.0.0.0/8 subnet.
To access them create a script which configures that route every time that the voice WAN brings up,
I used to put this script in /etc/ppp/ip-up.d/0002route:
#!/bin/sh
[ "$PPP_IFACE" = 'pppoe-voice' ] && ip route add 10.0.0.0/8 dev pppoe-voice via $PPP_LOCAL
-
Lascia stare quella guida, l'ho usata come riferimento per capire cosa mettere nello username. Se dovesse servire l'host_uniq non è un problema, si aggiunge. Io per ora sono fermo alla configurazione che ho fatto, usando ifup voip2 non restituisce nessun messaggio di errore (quindi riconosce il nome specificato nel file network) ma non viene messa su nessuna interfaccia. Conviene attendere chi ne sa più di noi e lo ha già fatto per capire come procedere.
-
Non esiste alcun ptm1, il tuo modem è sempre ptm0, quindi puoi avere wanptm0 e voipptm0 ad esempio, ma wanptm1 non ha alcun senso. voip2 deve far riferimento a voipptm0 così come wan deve far riferimento a wanptm0.
E sì. mi ero scordato di dirtelo, il mac address deve essere diverso, basta che fai +1 sul finale o ne usi uno random, l'importante p che sia diverso dall'altro. Vedi che su hwupgrade c'è il mio topic dove tutto ciò è spiegato molto più in dettaglio.
-
Perfetto, tutto chiarissimo. Come prima cosa cerco il tuo post e provo a dedicarmici, tanto la logica di ciò che va fatto è chiara, speriamo che questa cosa sia risolutiva.
Questa la situazione attuale, ho usato come nome voip2 perchè voip era già assegnato:
config device 'voipptm0'
option type '8021q'
option name 'voipptm0'
option macaddr 'E4:8F:34:3A:04:24'
option ifname 'ptm0'
option ipv6 '0'
option vid '1035'
config interface 'voip2'
option auto '1'
option proto 'pppoe'
option demand '0'
option macaddr 'E4:8F:34:3A:04:24'
option ipv6 '0'
option keepalive_adaptive '0'
option dns_metric '0'
option ifname 'voipptm0'
option password 'Vodafone'
option username 'V-[seriale]'
option keepalive '4,20'
option metric '0'
e in ifconfig:
pppoe-voip2 Link encap:Point-to-Point Protocol
inet addr:1.255.160.105 P-t-P:1.255.160.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:3 errors:0 dropped:0 overruns:0 frame:0
TX packets:960 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:54 (54.0 B) TX bytes:66351 (64.7 KiB)
Purtroppo con questa configurazione attiva sembra che la connessione sul vid 1036 smetta di funzionare, il che si traduce in un'assenza di connettività ad internet. Domani provo a dedicarci un po' di tempo e vediamo se riesco a far coesistere le due configurazioni.
Intanto grazie mille per il tempo che stai dedicando a questo problema e complimenti per l'articolo su hwupgrade, è molto esaustivo.
-
L'indirizzo Wan inizia da 1.x.x.x. Senza modifica parte in un altro modo.
-
A quanto pare la tabella di routing è influenzata dall'ordine in cui vengono messe su le connessioni pppoe. Il problema si risolve abbastanza agevolmente inserendo in questo ordine le voci di configurazione:
1) voipptm0
2) voip2
3) wanptm0
4) wan
dando un /etc/init.d/network restart, la tabella di routing è corretta e la navigazione funziona
root@modemtim:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default net-188-217-48- 0.0.0.0 UG 0 0 0 pppoe-wan
1.255.160.1 * 255.255.255.255 UH 0 0 0 pppoe-voip2
188.217.48.1 * 255.255.255.255 UH 0 0 0 pppoe-wan
192.168.1.0 * 255.255.255.0 U 0 0 0 br-lan
192.168.10.0 * 255.255.255.0 U 0 0 0 eth4
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
239.0.0.0 * 255.0.0.0 U 0 0 0 br-lan
Purtroppo l'interfaccia non viene mostrata nella configurazione da interfaccia grafica di mmpbx, non so da dove prenda l'elenco delle interfacce. Volendo si può configurare a mano modificando nel file mmpbxrvsipnet nella sezione "config network 'sip_net'" la voce "option interface", ma preferisco aspettare. Al momento nonostante l'interfaccia sia su, non so se è funzionante (possibile che non bisogna specificare nessuna regola in iptables?) e il fatto che non venga mostrata nell'interfaccia grafica di mmpbx mi insospettisce.
Comunque, per ora ho dato un "ip route add 10.0.0.0/8 dev pppoe-voip2" perché da quello che ho capito bisogna stare su quella classe per comunicare con il server proxy. Stavo cercando informazioni su come reperirne l'indirizzo, ma per ora non ho trovato niente di utile.
-
Ottimo lavoro,vediamo se ne viene fuori finalmente una soluzione. Il server proxy dovrebbe saperlo @LuKePicci come ottenerlo. Così si sta praticamente "emulando" (non nel vero senso della parola) la vsr,ma se non c'è un pacchetto di regole per il firewall,ben specifico,credete che possa andare?
-
Allora, se quando metti su la pppoe voce l'altra va proprio giù e smette di funzionare vuol dire che i due mac non sono distinti correttamente, in altre parole il mac custom lo hai impostato nel posto/nel modo sbagliato. Io su openwrt 15 lo impostavo esattamente come hai fatto tu ma solo su wan e voip, non su wanptm0 e voipptm0 perchè lì le cose funzionavano diversamente. Nel caso, perdebugging, se vuoi vedere che effettivamente stia usando mac diversi per le due sessioni fai un tcpdump su wanptm0 e voipptm0 e verifica il mac dei pacchetti che vedi.
Se invece è solo una questione di regole di routing che si sovrappongono, devi disabilitare la defaultroute (option defaultroute '0') derivante dall'interfaccia voip (altrimenti lui tenta di usare quella) e creare delle rotte statiche verso gli ip dei proxy (in 10.0.0.0/8) come più o meno hai fatto.
Sistema queste cosette, arriva ad avere le due pppoe entrambe up, con internet funzionante. Quando hai fatto dimmelo che passiamo a recuperare il proxy. Dopodiché restano un altro paio di cose da fare prima di poter vedere qualcosa di funzionante (spoiler: eccezione su rebind protection e cambio interface in mmpbxrvsipnet).
-
Ho sistemato tutto, le due connessione sono entrambe su e la navigazione funziona, era solo un problema di routing:
ifconfig
pppoe-voip2 Link encap:Point-to-Point Protocol
inet addr:1.255.160.97 P-t-P:1.255.160.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:3 errors:0 dropped:0 overruns:0 frame:0
TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:54 (54.0 B) TX bytes:54 (54.0 B)
pppoe-wan Link encap:Point-to-Point Protocol
inet addr:188.217.105.202 P-t-P:188.217.96.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:3781901 errors:0 dropped:0 overruns:0 frame:0
TX packets:1419976 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:5272462867 (4.9 GiB) TX bytes:143329820 (136.6 MiB)
route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default net-188-217-96- 0.0.0.0 UG 0 0 0 pppoe-wan
1.255.160.1 * 255.255.255.255 UH 0 0 0 pppoe-voip2
10.0.0.0 * 255.0.0.0 U 0 0 0 pppoe-voip2
188.217.96.1 * 255.255.255.255 UH 0 0 0 pppoe-wan
192.168.1.0 * 255.255.255.0 U 0 0 0 br-lan
192.168.10.0 * 255.255.255.0 U 0 0 0 eth4
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
Temo che il routing della connessione voip2 non sia ancora corretto, ho impostato la regola con "ip route add 10.0.0.0/8 dev pppoe-voip2" e il risultato è quello che ho incollato sopra ma, da quello che ho capito, bisognava aggiungere "via 188.217.105.202".
Dando però il comando, il risultato è il seguente:
root@modemtim:~# ip route add 10.0.0.0/8 dev pppoe-voip2 via 188.217.105.202
RTNETLINK answers: Network is unreachable
-
Non ti funziona perchè in 'via' stai usando l'ip di pppoe-wan mentre lì ci devi mettere il gateway assegnato per pppoe-voip2.
Fai così, riabilita la defaultroute su pppoe-voip2, poi dai il comando 'ip route' dovresti vedere una default route via x.x.x.x, quello è il tuo gateway, quindi disabilita di nuovo la defaultroute poi vai in /etc/config/network e mettici:
config route 'voip_private'
option interface 'voip2'
option netmask '255.0.0.0'
option metric '1'
option target '10.0.0.0/8'
option gateway 'x.x.x.x'
PS comunque non è mica detto che il tuo proxy sia su 10.x.x.x, potrebbe essere su un'altra subnet privata, ho controllato quelli che avevo io in passato ed erano su 172.qualcosa, e avevo creato regole di routing unicast e non per subnet. tu per ora vai avanti così poi quando vediamo i proxy sistemiamo target e netmask in modo opportuno.
-
Perfetto, direi che ci siamo:
root@modemtim:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default net-188-217-96- 0.0.0.0 UG 0 0 0 pppoe-wan
1.255.160.1 * 255.255.255.255 UH 0 0 0 pppoe-voip2
10.0.0.0 1.255.160.1 255.0.0.0 UG 1 0 0 pppoe-voip2
188.217.96.1 * 255.255.255.255 UH 0 0 0 pppoe-wan
192.168.1.0 * 255.255.255.0 U 0 0 0 br-lan
192.168.10.0 * 255.255.255.0 U 0 0 0 eth4
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
-
Ho sistemato tutto, le due connessione sono entrambe su e la navigazione funziona, era solo un problema di routing:
Mi sono un attimo perso proprio in questo punto,dove stà l'errore. Dove devo cercare il defaultroute? In network vedo una stringa in riferimento al voip che era presente già prima delle aggiunte.
-
Come non detto,sono riuscito a risolvere,e vi seguo a ruota. Comunque è tutto molto interessante,e devo ammettere che nonostante abbia delle buonissime conoscenze informatiche,in certi frangenti mi sono un pò trovato in difficoltà a capire certi passaggi.
E' proprio vero,non si finisce mai di imparare!
-
Ora per i proxy, se hai ancora una Vodafone Station 2 o una Vodafone Station Revolution, collegala, assicurati che funzioni la fonia, poi entra nella sua pagina di amministrazione da browser, apri la console javascript su quella tab, incollaci dentro tutto questo blocco e dai invio:
function cwmp_get_names(path) {
var my_soap_obj=new SOAPObject("ParameterPath").val(path);
var my_next_level=new SOAPObject("NextLevel").val("1");
invoke_rpc("cwmp:GetParameterNames", new Array(my_soap_obj,my_next_level), function(xml){console.log(new XMLSerializer().serializeToString(xml))});
}
function cwmp_get_values(target) {
var my_soap_obj=new SOAPObject("ParameterNames").val("<string>"+target+"</string>");
var my_next_level=new SOAPObject("NextLevel").val("1");
invoke_rpc("cwmp:GetParameterValues", new Array(my_soap_obj,my_next_level), function(xml){console.log(new XMLSerializer().serializeToString(xml))});
}
function cwmp_set_value(target, value) {
send_value(target, value, function(x){console.log(new XMLSerializer().serializeToString(x))});
}
cwmp_get_values("InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.")
I proxy, primario e secondario sono (di norma) sotto InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1.SIP.ProxyServer e InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.2.SIP.ProxyServer
Se invece non avete una Vodafone Station o ne avete una più nuova scrivetemi in PM
-
Dovrebbero essere questi...
proxy1-xxxxxxx.proxy.dsl.vodafone.it.
proxy2-xxxxxxx.proxy.dsl.vodafone.it.
-
Bene, ota torna in mmpbxrvsipnet, rimpiazza i proxy pubblici con questi, sotto interface metti il nome dell'interfaccia voip, @gacchu ha usato 'voip2'. Da router, verifica che la risoluzione di quei nomi funzioni correttamente.
-
Inseriti i dati,e riavviato il router,si ritorna al problema iniziale,cioè sembra tutto apposto,ma non c'è connessione. Però mi chiedo anche,devo mettere qualcosa di diverso come registrar primario e nome dominio? Oppure devo semplicemente lasciare i campi vuoti?
-
Devi impostare tutto correttamente ma le cose si fanno un passo alla volta altrimenti non ci troviamo. Prima di guardare le settings del registrar, spiegami che intendi con "non c'è connessione", stiamo parlando della connessione internet dati? Se sì hai sbagliato qualcosa nei passi precedenti, altrimenti è normale non abbiamo mica finito. C'è ancora da impostare correttamente il firewall per la nuova interfaccia. Quando sei sicuro di essere pronto procediamo.
-
Ok,dopo altro riavvio la connessione dati ha iniziato a funzionare correttamente,e facendo un route,sembra tutto apposto. Per quando riguarda la verifica della risoluzione dei nomi,cosa dovrei fare di preciso? Provare a pingare verso i due server? Se è così,l'ho fatto e non ho avuto risposta.
-
No, prova con nslookup. Il ping ai due server non ricordo se funziona o meno, prova con traceroute piuttosto.
Ad ogni modo devi comunque prima configurare il firewall altrimenti non andiamo da nessuna parte. Manda il contenuto del tuo /etc/config/firewall
-
Provato sia traceroute che nslookup e il server non risponde.
Qui trovi il file del firewall
https://gofile.io/?c=tJBCNc
-
Vai sotto config zone 'wan', c'è una serie di list network mettici anche un list network voip (o voip2, a seconda di come l'hai chiamata). Poi vai in fondo ed elimina quelle ultime due sezioni riguardanti if1. Per ora non toccare nient'altro in quel file.
Per i due test che ti ho fatto fare prima, almeno nslookup deve funzionare. Mandami il contenuto di /etc/config/dhcp e dimmi se per caso hai cambiato qualche impostazione relativa ai dns.
-
Settato come? La lan zone ha determinate opzioni,la wan ne ha altre.
config zone 'lan'
option name 'lan'
list network 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
option mtu_fix '1'
option wan '0'
config zone 'wan'
option name 'wan'
list network 'wan'
list network 'wan6'
list network 'wwan'
option input 'DROP'
option output 'ACCEPT'
option forward 'DROP'
option masq '1'
option conntrack '1'
option mtu_fix '1'
option wan '1'
Qua c'è il dhcp
https://gofile.io/?c=FGqJoQ
No,i dns sono quelli di vodafone.
-
Non devi settare nulla, semplicemente aggiungi list network voip2 (o come l'hai chiamata tu) qui dentro in wan così prende le stesse impostazioni delle altre, ed elimina quella roba in fondo come avevo detto prima.
config zone 'wan'
option name 'wan'
list network 'wan'
list network 'wan6'
list network 'wwan'
list network 'voip2'
option input 'DROP'
option output 'ACCEPT'
option forward 'DROP'
option masq '1'
option conntrack '1'
option mtu_fix '1'
option wan '1'
A @gacchu ho fatto fare il contrario, cioè gli ho fatto sistemare quelle ma c'è un problema, quindi a te proviamo in modo diverso. C'è anche un'altra differenza tra te e @gacchu che per ora non evidenzio per non fare confusione.
Per il file dhcp, dobbiamo fare quello di cui parlavo più sopra, cioè sistemare la rebind protection. Ti ho riscritto per riferimento l'intera sezione 'dnsmasq', le opzioni rilevanti che ho cambiato/evidenziato sono quelle 6 righe commentate. @gacchu sistema anche tu alla stessa maniera
config dnsmasq 'dnsmasq'
option domainneeded '1'
option boguspriv '1'
option filterwin2k '0'
option localise_queries '1'
option rebind_protection '1' # attiva
option rebind_localhost '1'
option local '/lan/'
option domain 'homenet.telecomitalia.it'
option expandhosts '1'
option nonegcache '0'
option authoritative '1'
option cachelocal '1' # attiva fondamentale altrimenti mmpbx non usa queste regole
option cachesize '200' # abbastanza grande
option readethers '1'
option leasefile '/tmp/dhcp.leases'
option resolvfile '/tmp/resolv.conf.auto'
option strictorder '1'
option dhcpscript '/lib/dnsmasq/dhcp-event.sh'
list hostname 'dsldevice'
option allservers '1'
option addmac '0'
list server '/proxy.dsl.vodafone.it/91.80.35.167' #risolvi i proxy voip tramite dns vodafone/primario
list server '/proxy.dsl.vodafone.it/91.80.35.134' #risolvi i proxy voip tramite dns vodafone/secondario
list rebind_domain '/proxy.dsl.vodafone.it/' #ammetti rebind per nomi proxy voip
list dhcp_option_force 'tag:cpewan-id,vi-encap:3561,6,"4132"'
list dhcp_option_force 'tag:cpewan-id,vi-encap:3561,5,"CP1735DAMB0"'
list dhcp_option_force 'tag:cpewan-id,vi-encap:3561,4,"101331"'
Fatto questo almeno l'nslookup deve funzionare. Se poi ti funziona anche il traceroute/ping avvertimi.
-
Eccomi qui, ho dedicato una mezz'ora a fare prove per capirci qualcosa di più.
Ho apportato le modifiche al file dhcp, la risoluzione dell'host nel mio caso veniva effettuata correttamente:
nslookup proxy1-VP00181-VMCNVS1.proxy.dsl.vodafone.it
Server: 127.0.0.1
Address 1: 127.0.0.1 localhost.homenet.telecomitalia.it
Name: proxy1-VP00181-VMCNVS1.proxy.dsl.vodafone.it
Address 1: 10.174.0.32
ora invece:
nslookup: can't resolve 'proxy1-VP00181-VMCNVS1.proxy.dsl.vodafone.it': Name or service not known
root@modemtim:~# nslookup proxy1-VP00181-VMCNVS1.proxy.dsl.vodafone.it
Server: 127.0.0.1
Address 1: 127.0.0.1 localhost.homenet.telecomitalia.it
disabilitando il rebind la risoluzione dell'host torna a funzionare
-
Aspetta, che intendi con opportuna eccezione, quelle che ho messo qui sopra non andavano? (hai scrollato il code box fino in fondo vero?)
Comunque tieni la rebind_protection attiva con eccezione, almeno sappiamo cosa sta facendo.
Ho chiesto in giro e mi confermano che il proxy deve comunque rispondere al ping, quindi prima di tornare a toccare mmpbx vediamo di far andare quello. Sistemate gli host_uniq e vediamo se cambia qualcosa.
-
Pardon, ho aggiunto una configurazione "config dhcp 'voip2'" copiandola da quella wan e mi sembrava funzionare, replicato ora e non va, probabilmente avevo semplicemente disabilitato la rebind protection durante le prove. Ho corretto il post di sopra, onde evitare confusione.
Ricontrollato la configurazione, e sistemato una riga tralasciata, la risoluzione dell'host ora funziona correttamente anche con il rebind protection abilitato.
Naturalmente non c'è risposta al ping (ma questo si è capito che vuol dire poco) e il traceroute è identico a quello che si aveva con il rebind protection disabilitato
-
Ottimo, allora dico quello che abbiamo visto su mwan. Dovete controllare di averlo disabilitato/commentato/correttamente configurato. Se in /etc/config/mwan avete delle regole che legano mmpbx a wan, sostituite wan col nome dell'interfaccia voip o (e ve lo raccomando per semplificare un po' le cose) disabilitatele commentandole tutte.
Il ping dobbiamo farlo funzionare, mi hanno confermato che quando tutto è a posto il proxy risponde. Quindi sistemate host_uniq sulla pppoe wan (sì, non voip) e ditemi se così cambia qualcosa.
-
Il
Attualmente io l'ho configurato nel pppoe wan e il proxy non risponde al ping
config interface 'wan'
option auto '1'
option proto 'pppoe'
option demand '0'
option macaddr 'A4:91:B1:34:3D:9A'
option ipv6 '0'
option keepalive_adaptive '0'
option dns_metric '0'
option ifname 'wanptm0'
option host_uniq '<hex SN-VS>'
option username 'D-<SN-VS>'
option password 'vodafone'
option keepalive '4,20'
option metric '0'
questo il contenuto del mio file mwan:
config globals 'globals'
config policy 'if1_mwan'
option interface 'voip2'
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'
-
Ok, mi fai quel test con tcpdump di cui parlavamo l'altro giorno?
ifup wan && ifup voip2 && sleep 10
tcpdump -e -G 30 -U -i wanptm0 ether[0x0c:2] == 0x8863 &
ifdown wan && ifup wan && fg
tcpdump -e -G 30 -U -i voipptm0 ether[0x0c:2] == 0x8863 &
ifdown voip2 && ifup voip2 && fg
-
questo è il risultato:
root@modemtim:~# ifdown wan && ifdown voip2
root@modemtim:~# tcpdump -e -G 30 -U -i wanptm0 ether[0x0c:2] == 0x8863 &
root@modemtim:~# ifup wan && sleep 10 && ifdown wan
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wanptm0, link-type EN10MB (Ethernet), capture size 262144 bytes
23:15:00.463578 a4:91:b1:34:3d:9a (oui Unknown) > e0:24:7f:fa:4e:04 (oui Unknown), ethertype PPPoE D (0x8863), length 39: PPPoE PADT [ses 0x2275] [Host-Uniq "C18060000009263"]
23:15:00.475414 e0:24:7f:fa:4e:04 (oui Unknown) > a4:91:b1:34:3d:9a (oui Unknown), ethertype PPPoE D (0x8863), length 56: PPPoE PADT [ses 0x2275]
23:15:00.783245 a4:91:b1:34:3d:9a (oui Unknown) > Broadcast, ethertype PPPoE D (0x8863), length 43: PPPoE PADI [Service-Name] [Host-Uniq "C18060000009263"]
23:15:00.795861 e0:24:7f:fa:4e:04 (oui Unknown) > a4:91:b1:34:3d:9a (oui Unknown), ethertype PPPoE D (0x8863), length 56: PPPoE PADO [Service-Name] [Host-Uniq "C18060000009263"] [AC-Name "RMBNG016"]
23:15:00.802179 a4:91:b1:34:3d:9a (oui Unknown) > e0:24:7f:fa:4e:04 (oui Unknown), ethertype PPPoE D (0x8863), length 43: PPPoE PADR [Service-Name] [Host-Uniq "C18060000009263"]
23:15:00.817433 e0:24:7f:fa:4e:04 (oui Unknown) > a4:91:b1:34:3d:9a (oui Unknown), ethertype PPPoE D (0x8863), length 56: PPPoE PADS [ses 0x331] [Service-Name] [Host-Uniq "C18060000009263"]
23:15:01.068158 e0:24:7f:fa:4e:04 (oui Unknown) > a4:91:b1:34:3d:9a (oui Unknown), ethertype PPPoE D (0x8863), length 85: PPPoE PAD-d3 [ses 0x331] [TAG-0x112 "provcode=BFF0F58E8553589C,ntp1=91.80.35.171,ntp2=91.80.35.139"]
root@modemtim:~# tcpdump -e -G 30 -U -i voipptm0 ether[0x0c:2] == 0x8863 &
root@modemtim:~# ifup voip2 && sleep 10 && ifdown voip223:15:10.924318 a4:91:b1:34:3d:9a (oui Unknown) > e0:24:7f:fa:4e:04 (oui Unknown), ethertype PPPoE D (0x8863), length 39: PPPoE PADT [ses 0x331] [Host-Uniq "C18060000009263"]
tcpdump: voipptm0: No such device exists
(SIOCGIFHWADDR: No such device)
il device voipptm0 risulta in ifconfig:
voipptm0 Link encap:Ethernet HWaddr E4:8F:34:3A:04:24
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:8 errors:0 dropped:0 overruns:0 frame:0
TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:336 (336.0 B) TX bytes:319 (319.0 B)
-
Riprova, la seconda parte, dai ifup voip2 prima di avviare tcpdump, forse sei stato troppo rapido.
Ho editato il test sopra in modo da evitare questo problema.
-
root@modemtim:~# ifup voip2 && sleep 10 && ifdown voip2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on voipptm0, link-type EN10MB (Ethernet), capture size 262144 bytes
23:42:51.790434 e4:8f:34:3a:04:24 (oui Unknown) > Broadcast, ethertype PPPoE D (0x8863), length 24: PPPoE PADI [Service-Name]
23:42:51.803034 e0:24:7f:fa:4e:04 (oui Unknown) > e4:8f:34:3a:04:24 (oui Unknown), ethertype PPPoE D (0x8863), length 56: PPPoE PADO [Service-Name] [AC-Name "RMBNG016"]
23:42:51.806494 e4:8f:34:3a:04:24 (oui Unknown) > e0:24:7f:fa:4e:04 (oui Unknown), ethertype PPPoE D (0x8863), length 24: PPPoE PADR [Service-Name]
23:42:51.818725 e0:24:7f:fa:4e:04 (oui Unknown) > e4:8f:34:3a:04:24 (oui Unknown), ethertype PPPoE D (0x8863), length 56: PPPoE PADS [ses 0xd3f] [Service-Name]
23:42:51.998721 e0:24:7f:fa:4e:04 (oui Unknown) > e4:8f:34:3a:04:24 (oui Unknown), ethertype PPPoE D (0x8863), length 59: PPPoE PAD-d3 [ses 0xd3f] [TAG-0x112 "ntp1=91.80.35.171,ntp2=91.80.35.139"]
root@modemtim:~# 23:43:01.880533 e4:8f:34:3a:04:24 (oui Unknown) > e0:24:7f:fa:4e:04 (oui Unknown), ethertype PPPoE D (0x8863), length 20: PPPoE PADT [ses 0xd3f]
23:43:01.894451 e0:24:7f:fa:4e:04 (oui Unknown) > e4:8f:34:3a:04:24 (oui Unknown), ethertype PPPoE D (0x8863), length 56: PPPoE PADT [ses 0xd3f]
tcpdump: pcap_loop: The interface went down
7 packets captured
7 packets received by filter
0 packets dropped by kernel
-
Ok, spiegami come hai scelto i due mac address che hai dato/clonato sulle due interfacce. Sono quelli wan e voce della tua station o hai usato quello lan per la wan e hai fatto lan+1 per la voce?
-
quello della wan era già presente (prima configurazione fatta da interfaccia grafica)
quella della sezione voip2 l'ho preso pari pari dalla vodafone station
-
E qui ti volevo. Quale di quelli della Vodafone station hai usato?
Usa questo per voip2: a4:91:b1:34:3d:9b
-
Ho preso il MA scritto dietro alla VS, subito sotto al SN..
Sostituito, ora l'impostazione dell'host_uniq funziona anche sull'interfaccia voip2 e non perde le opzioni route (allucinante, non mi sarei mai posto il problema).
Comunque, ora che ho gli host_uniq impostati su dati e voce, il ping continua a non andare
root@modemtim:~# tcpdump -e -G 30 -U -i voipptm0 ether[0x0c:2] == 0x8863 &
root@modemtim:~# ifdown voip2 && ifup voip2 && fgtcpdump: verbose output suppres sed, use -v or -vv for full protocol decode
listening on voipptm0, link-type EN10MB (Ethernet), capture size 262144 bytes
root@modemtim:~# ifdown voip2 && ifup voip2 && fg
00:20:13.996840 a4:91:b1:34:3d:9b (oui Unknown) > e0:24:7f:fa:4e:04 (oui Unknown), ethertype PPPoE D (0x8863), length 39: PPPoE PADT [ses 0x13cd] [Host-Uniq "C18060000009263"]
00:20:14.001423 e0:24:7f:fa:4e:04 (oui Unknown) > a4:91:b1:34:3d:9b (oui Unknown), ethertype PPPoE D (0x8863), length 56: PPPoE PADT [ses 0x13cd]
tcpdump -e -G 30 -U -i voipptm0 ether[0x0c:2] == 0x8863
tcpdump: pcap_loop: The interface went down
2 packets captured
2 packets received by filter
0 packets dropped by kernel
Direi che per oggi sono arrivato, domani proverò a fare qualche prova, ma il motivo per il quale questo maledetto proxy continui a non essere raggiungibile veramente mi sfugge
-
La Vodafone Station ne ha svariati, una decina, ognuno per una interfaccia differente. Non ricordo esattamente com'era la numerazione (da qualche parte su internet potrei averlo detto con precisione anni fa) ma temo tu possa aver usato quello che lei usa per la wan dati sulla interfaccia voce creata qui sul technicolor. Dobbiamo dare ai vari router il tempo di reagire a questi continui cambi di mac del tuo ip voce che come avrai notato è statico. Il proxy voip potrebbe conoscerti col mac usato dalla station sulla sua interfaccia voce, dobbiamo attendere che si adegui al nuovo, o devo andare a controllare quel era l'offset tra quello sull'etichetta e quello voce della station e fartelo clonare con quello giusto. Il traceroute ti dimostra che la rotta funziona, perchè il gateway remoto su quella vlan ti risponde (forse puoi anche pingarlo). Il lookup dei nomi è definitivamente sistemato, ora anche se cambi dns al router con quelli cloudflare o google lui continuerà ad usare quelli Vodafone per i proxy voip. Ti suggerirei di lasciare tutto up come è ora e vedere se dopo un po' di ore (non chiedermi quante, immagina un tizio Vodafone che inserisce un timeout del genere da qualche parte in qualche config, prova ad immedesimarti e decidi secondo te se sono 8, 24 o 48 ore). tutto inizia magicamente a funzionare. Con Tiscali ho dovuto fare lo stesso e alla fine ha funzionato. In questo lasso di tempo non devi assolutamente collegare la station o siamo punto e da capo. Lascia mmpbx up così che continui a fare tentativi di registrazione.
L'unica cosa che proverei a fare per curiosità è vedere con tcpdump se per caso il gateway ti risponde in qualche modo ai ping falliti verso il proxy con qualche messaggio di errore ICMP.
Infine, una volta che vedrai il ping iniziare a funzionare, tieni presente che puoi anche fare prove configurando un tuo client voip su pc (io usavo x-lite o blink) nel caso avessi qualche perplessità sulla corretta configurazione di mmpbx.
-
Io mi limito ad osservare per il momento perché sto avendo casini con la connessione incomprensibili. Certe volte la connessione dati va ed altre decide di non andare. Però in compenso l'nslookup aveva dato buoni frutti per entrambi i server.
-
Controlla anche tu i mac e i valori di host_uniq, ricorda, se coincidono va prima l'uno poi l'altra a turno. Se sono clonati con qualcosa di errato succedono cose strane come a @gacchu
Cerca di arrivare anche tu ad avere le due connessioni up, il routing sistemato e la risoluzione dei nomi funzionante, così vediamo se anche a te c'è il problema che non pinga o meno.
-
Il punto é che la connessione e il telefono servono anche ad altri membri della famiglia. Per cui devo passare dalla configurazione in cascata alla configurazione normale,molto spesso,lasciando specialmente il telefono inattivo.
Comunque quello che posso dirti è che: ifconfig,routing,e risoluzione dei nomi,danno esito assolutamente positivo. Il ping non va ma questo già lo sapete. Per quanto riguarda le due reti funzionanti dati e voce,credo che sia semplicemente riconducibile al passaggio da setting per cascata a normale. Cioè rimangono "frammenti" di codice sbagliato,nella parte relativa alla wan.
-
@LuKePicci intanto grazie veramente di cuore, ieri ero veramente cotto dopo la giornata lavorativa e ho proceduto in modo dispersivo. E' raro trovare questa disponibilità quando ci sono queste competenze di mezzo.
La VS è stata ricollegata solo nel breve lasso di tempo usato per prendere i proxy e devo dire che, quando l'ho fatto, mi ha stupito vedere che ha impiegato più mezz'ora per far salire la pppoe dati. Forse l'utilizzo del MA wan nella connessione voce ha creato casini anche altrove, o forse è solo la VS ad essere ingestibile.
Il problema così descritto mi è chiaro, ho appena rilanciato mmpbx e non avere il telefono funzionante in casa per qualche giorno non mi causa scompensi. Ormai in qualche modo voglio uscirne fuori, quindi nella peggiore delle ipotesi per togliermi il dubbio, se tra qualche giorno il proxy continua a non rispondere al ping, mi metterò alla ricerca del MA usato sulla connessione voce della VS.
Questa sera dopo le 19 mi chiamerà il reparto tecnico Vodafone, spero non mi chiedano di entrare nuovamente nel router per controllare le configurazioni. Male che va, li ignorerò.
Dopo aver affrontato questo problema comunque, mi sono definitivamente convinto a NON acquistare un router AVM (avevo considerato l'ipotesi all'inizio), avere il controllo di ciò che accade mi rende più tranquillo.
Questa sera controllerò cosa esce fuori dal tcpdump durante il ping, nel frattempo lascio tutto su e incrocio le dita.
@milan100 grazie anche a te, spero che ci siano anche altri utenti che usano router basati su OpenWRT che troveranno utile questo thread
-
In realtà @gacchu sono molto curioso di sapere cosa ti dirà il supporto tecnico per risolvere il problema. La verità é che questa infrastruttura su cui si basa vodafone,sembra cozzare male col concetto di modem libero. Poi magari mi sbaglio...
Comunque ringrazio anche io voi per le competenze e il tempo messo a disposizione fin'ora,nella risoluzione di un problema veramente allucinante.
-
E' il concetto di "modem libero" che cozza male con la realtà su tutti i livelli (tecnico, commerciale, utenza, prodotti disponibili). Queste cose che vi sto dicendo risalgono a ben prima dell'invenzione di quella delibera. Mi sentivo già abbastanza libero prima. Per altro questo tipo di infrastruttura non ha nulla di tecnicamente opinabile. La fonia o l'iptv su vlan dedicata è sicuramente una cosa buona e giusta. La necessità di voler fornire un servizio plug-n-play che non richieda intervento dell'utente per la configurazione è sacrosanta, se per consentirlo esiste un requisito (per altro non fuori standard), tu produttore di apparecchi compatibili investi e ti adegui, non fai partire una crociata contro gli operatori a mezzo agcom. L'esempio corretto di come terminali di vari produttori si connettono alla rete di un operatore ce l'abbiamo, è la rete cellulare. E ovviamente sapete tutti delle necessarie certificazioni e testing di telefoni e firmware da parte dei vari operatori. Che questi dietro il "modem libero" fossero stupidi e populisti si era capito dal nome della campagna, dato che in tutta questa storia i poveri modem non c'entrano un accidente visto che funzionano sempre a prescindere da rete configurazione e credenziali, e non per magia, ma perchè chi li ha progettati sa come si lavora quando si ha a che fare con standard esistenti.
-
Però @LuKePicci c'è anche da dire che sarebbe cosa buona e giusta che gli operatori si adoperassero affinché i loro prodotti siano di ottima qualità. La vsr in primis é un prodotto teoricamente buono dal punto di vista delle caratteristiche ma praticamente scadente, specialmente lato WiFi.
-
Giusto per chiudere l'OT, l'unica cosa che posso dire è che l'unico vero problema degli operatori (un po' tutti) è legato alle politiche commerciali e ai geni del marketing. Qualsiasi operazione regolarizzi e argini il più possibile politiche commerciali ai limiti della correttezza per quanto mi riguarda è benvenuta.
Comunque il supporto tecnico di Vodafone mi ha detto che "i technicolor non sono apparati di qualità", in poche parole per quanto riguarda loro, devo cambiare apparato. Mi ha consigliato "un qualsiasi Fritz o Asus che supporti la fonia". Vabè, informazioni inutili, ma alla fine se non altro ha detto tutto con educazione.
Gli ho accennato alla possibilità di collegarmi sul vlan id 1035 e mi ha sorpreso, mi ha risposto che per quanto riguarda Vodafone è una cosa concessa, ma sulla quale non offrono supporto (mi ha dato l'impressione di sapere di cosa stessi parlando).
Comunque, provato al volo un ping e per ora situazione stabile, dopo cena se reggo verifico con tcpdump cosa accade pingando uno dei proxy.
-
Invece le loro Vodafone Station Revolution made by Huawei sono di qualità eccelsa… immagino.
-
https://youtu.be/kLx5G0xMwH8
-
Riporto il tcpdump fatto direttamente sull'interfaccia voip, senza nessun filtro impostato:
21:11:42.906744 a4:91:b1:34:3d:9b (oui Unknown) > e0:24:7f:fa:4e:04 (oui Unknown), ethertype PPPoE S (0x8864), length 106: PPPoE [ses 0x599d] IP (0x0021), length 86: 1.255.160.20 > 10.174.0.32: ICMP echo request, id 47689, seq 19, length 64
21:11:43.916304 a4:91:b1:34:3d:9b (oui Unknown) > e0:24:7f:fa:4e:04 (oui Unknown), ethertype PPPoE S (0x8864), length 106: PPPoE [ses 0x599d] IP (0x0021), length 86: 1.255.160.20 > 10.174.0.32: ICMP echo request, id 47689, seq 20, length 64
21:11:44.927769 a4:91:b1:34:3d:9b (oui Unknown) > e0:24:7f:fa:4e:04 (oui Unknown), ethertype PPPoE S (0x8864), length 106: PPPoE [ses 0x599d] IP (0x0021), length 86: 1.255.160.20 > 10.174.0.32: ICMP echo request, id 47689, seq 21, length 64
21:11:45.945239 a4:91:b1:34:3d:9b (oui Unknown) > e0:24:7f:fa:4e:04 (oui Unknown), ethertype PPPoE S (0x8864), length 106: PPPoE [ses 0x599d] IP (0x0021), length 86: 1.255.160.20 > 10.174.0.32: ICMP echo request, id 47689, seq 22, length 64
21:11:54.744703 a4:91:b1:34:3d:9b (oui Unknown) > e0:24:7f:fa:4e:04 (oui Unknown), ethertype PPPoE S (0x8864), length 30: PPPoE [ses 0x599d] LCP (0xc021), length 10: LCP, Echo-Request (0x09), id 54, length 10
21:11:54.759168 e0:24:7f:fa:4e:04 (oui Unknown) > a4:91:b1:34:3d:9b (oui Unknown), ethertype PPPoE S (0x8864), length 56: PPPoE [ses 0x599d] LCP (0xc021), length 10: LCP, Echo-Reply (0x0a), id 54, length 10
21:11:54.889661 e0:24:7f:fa:4e:04 (oui Unknown) > a4:91:b1:34:3d:9b (oui Unknown), ethertype PPPoE S (0x8864), length 56: PPPoE [ses 0x599d] LCP (0xc021), length 10: LCP, Echo-Request (0x09), id 36, length 10
21:11:54.897470 a4:91:b1:34:3d:9b (oui Unknown) > e0:24:7f:fa:4e:04 (oui Unknown), ethertype PPPoE S (0x8864), length 30: PPPoE [ses 0x599d] LCP (0xc021), length 10: LCP, Echo-Reply (0x0a), id 36, length 10
21:12:14.771311 a4:91:b1:34:3d:9b (oui Unknown) > e0:24:7f:fa:4e:04 (oui Unknown), ethertype PPPoE S (0x8864), length 30: PPPoE [ses 0x599d] LCP (0xc021), length 10: LCP, Echo-Request (0x09), id 55, length 10
21:12:14.785776 e0:24:7f:fa:4e:04 (oui Unknown) > a4:91:b1:34:3d:9b (oui Unknown), ethertype PPPoE S (0x8864), length 56: PPPoE [ses 0x599d] LCP (0xc021), length 10: LCP, Echo-Reply (0x0a), id 55, length 10
21:12:24.890138 e0:24:7f:fa:4e:04 (oui Unknown) > a4:91:b1:34:3d:9b (oui Unknown), ethertype PPPoE S (0x8864), length 56: PPPoE [ses 0x599d] LCP (0xc021), length 10: LCP, Echo-Request (0x09), id 37, length 10
21:12:24.898501 a4:91:b1:34:3d:9b (oui Unknown) > e0:24:7f:fa:4e:04 (oui Unknown), ethertype PPPoE S (0x8864), length 30: PPPoE [ses 0x599d] LCP (0xc021), length 10: LCP, Echo-Reply (0x0a), id 37, length 10
21:19:16.791033 a4:91:b1:34:3d:9b (oui Unknown) > e0:24:7f:fa:4e:04 (oui Unknown), ethertype PPPoE S (0x8864), length 804: PPPoE [ses 0x599d] IP (0x0021), length 784: 1.255.160.20.sip > 10.174.0.32.sip: SIP: REGISTER sip:proxy1-VP00181-VMCNVS1.proxy.dsl.vodafone.it;user=phone SIP/2.0
21:19:20.800052 a4:91:b1:34:3d:9b (oui Unknown) > e0:24:7f:fa:4e:04 (oui Unknown), ethertype PPPoE S (0x8864), length 804: PPPoE [ses 0x599d] IP (0x0021), length 784: 1.255.160.20.sip > 10.174.0.32.sip: SIP: REGISTER sip:proxy1-VP00181-VMCNVS1.proxy.dsl.vodafone.it;user=phone SIP/2.0
21:19:22.789931 a4:91:b1:34:3d:9b (oui Unknown) > e0:24:7f:fa:4e:04 (oui Unknown), ethertype PPPoE S (0x8864), length 809: PPPoE [ses 0x599d] IP (0x0021), length 789: 1.255.160.20.sip > 10.207.161.174.sip: SIP: REGISTER sip:proxy1-VP00181-VMCNVS1.proxy.dsl.vodafone.it;user=phone SIP/2.0
21:19:23.292051 a4:91:b1:34:3d:9b (oui Unknown) > e0:24:7f:fa:4e:04 (oui Unknown), ethertype PPPoE S (0x8864), length 809: PPPoE [ses 0x599d] IP (0x0021), length 789: 1.255.160.20.sip > 10.207.161.174.sip: SIP: REGISTER sip:proxy1-VP00181-VMCNVS1.proxy.dsl.vodafone.it;user=phone SIP/2.0
21:19:24.296881 a4:91:b1:34:3d:9b (oui Unknown) > e0:24:7f:fa:4e:04 (oui Unknown), ethertype PPPoE S (0x8864), length 809: PPPoE [ses 0x599d] IP (0x0021), length 789: 1.255.160.20.sip > 10.207.161.174.sip: SIP: REGISTER sip:proxy1-VP00181-VMCNVS1.proxy.dsl.vodafone.it;user=phone SIP/2.
Nessun tipo di reply ai miei ping, ho incollato il resto del dump perché sembra invece esserci passaggio dati slegato da mmpbx (da riga 5 a riga 12), niente di utile comunque, LCP, roba legata alla connessione pppoe messa su immagino
-
Domanda da un milione di dollari...Se avessi un telefono cordless ethernet,si riuscirebbe a bypassare il problema?
-
Risolveresti eventuali incompatibilità con mmpbx ma non con la questione del ping.
-
No un attimo,io intendevo senza la configurazione delle due VLAN ma mettendo i dati standard forniti da Vodafone,con l'introduzione del modem libero.
-
Mettiamo in chiaro che quella fornita da Vodafone per la configurazione di apparati alternativi non è la soluzione "standard" ma quella "speciale" alternativa creata per quei quattro gatti che vogliono cambiarsi router. Nel design originale della loro rete, era previsto che tutta la fonia viaggiasse esclusivamente in VoPI (intranet).
Riguardo il possibile workaround, dipende da cosa causava il problema, Se dipendeva da mmpbx allora si, altrimenti nada. Bada che per fare una cosa del genere ti tocca attraversare un NAT in più, quello dell'HUB.
-
se tra qualche giorno il proxy continua a non rispondere al ping, mi metterò alla ricerca del MA usato sulla connessione voce della VS
Ho recuperato un vecchio capture della mia vecchia VSR. I MAC sono organizzati in questo modo (quelli che riporto sono offset rispetto al MAC LAN):
00 lan
06 wan dati
07 wan voce
08 wifi 2.4
09 lan ospiti
0A wifi community 2.4
0C wifi 5
0E wifi community 5
(mancano quelli delle due wifi ospiti)
Non mi ricordo quale di questi fosse sull'etichetta, probabilmente il primo. Se e4:8f:34:3a:04:24 corrisponde a quello che hai indicato come Indirizzo MAC della "Rete LAN" nella pagina di stato dellla VSR, allora il tuo mac voce dovrebbe essere e4:8f:34:3a:04:2b
-
L'indirizzo era quello riportato su un'etichetta posta nella parte posteriore della VSR, non ho controllato all'interno dell'interfaccia grafica (cosa che farò a breve per essere sicuri che sia quello LAN). Ho provato a mettere il MA :2b ma continuo a non raggiungere il proxy.
Non essendo cambiata la situazione in questi giorni, comincio a pensare che il problema risieda altrove.
Ho fatto altre prove per eliminare il contenuto del file mwan dalla configurazione attuale, ma quando vado a disabilitare la policy "if1_mwan" (quella originariamente legata al voip e che successivamente ho legato all'interfaccia voip2), per qualche motivo smette di funzionare anche la navigazione (provato in tutte le salse, sia restartando i servizi di firewall / network che con un reboot). Dando un'occhiata veloce alla configurazione del firewall non ho trovato niente che possa causare questa cosa, comunque dopo cena mi controllo per bene il file di configurazione, magari spunta fuori qualcosa che che può causare la non operativa della classe della rete voce.
-
Controlla che non ci sia qualche altra tabella di routing oltre quella di default. Invece del semplice route, usa
ip route list table all
-
Ho verificato nella VSR, e4:8f:34:3a:04:24 corrisponde alla MA LAN, quindi nella configurazione per ora lascio il 2b.
La tabella di routing sembra essere ok:
root@modemtim:~# ip route list table all
local default dev lo table tod scope host
default via 188.217.48.1 dev pppoe-wan proto static
1.109.0.1 dev pppoe-voip2 proto kernel scope link src 1.109.18.231
188.217.48.1 dev pppoe-wan proto kernel scope link src 188.217.49.85
192.168.1.0/24 dev br-lan proto kernel scope link src 192.168.1.1
192.168.10.0/24 dev eth4 proto kernel scope link src 192.168.10.1
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
local 1.109.18.231 dev pppoe-voip2 table local proto kernel scope host src 1.109.18.231
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
local 188.217.49.85 dev pppoe-wan table local proto kernel scope host src 188.217.49.85
broadcast 192.168.1.0 dev br-lan table local proto kernel scope link src 192.168.1.1
local 192.168.1.1 dev br-lan table local proto kernel scope host src 192.168.1.1
broadcast 192.168.1.255 dev br-lan table local proto kernel scope link src 192.168.1.1
broadcast 192.168.10.0 dev eth4 table local proto kernel scope link src 192.168.10.1
local 192.168.10.1 dev eth4 table local proto kernel scope host src 192.168.10.1
broadcast 192.168.10.255 dev eth4 table local proto kernel scope link src 192.168.10.1
broadcast 192.168.168.0 dev wl0_1 table local proto kernel scope link src 192.168.168.1
local 192.168.168.1 dev wl0_1 table local proto kernel scope host src 192.168.168.1
broadcast 192.168.168.127 dev wl0_1 table local proto kernel scope link src 192.168.168.1
broadcast 192.168.168.128 dev wl1_1 table local proto kernel scope link src 192.168.168.129
local 192.168.168.129 dev wl1_1 table local proto kernel scope host src 192.168.168.129
broadcast 192.168.168.255 dev wl1_1 table local proto kernel scope link src 192.168.168.129
fe80::/64 dev wl0 proto kernel metric 256 pref medium
fe80::/64 dev br-lan proto kernel metric 256 pref medium
fe80::/64 dev ptm0 proto kernel metric 256 pref medium
fe80::/64 dev wl1_1 proto kernel metric 256 pref medium
fe80::/64 dev wl0_1 proto kernel metric 256 pref medium
unreachable default dev lo proto kernel metric 4294967295 error -101 pref medium
local ::1 dev lo table local proto unspec metric 0 pref medium
local fe80:: dev lo table local proto unspec metric 0 pref medium
local fe80:: dev lo table local proto unspec metric 0 pref medium
local fe80:: dev lo table local proto unspec metric 0 pref medium
local fe80::a691:b1ff:fe34:3d9a dev lo table local proto unspec metric 0 pref medium
local fe80::a691:b1ff:fe34:3d9a dev lo table local proto unspec metric 0 pref medium
local fe80::a691:b1ff:fe34:3d9a dev lo table local proto unspec metric 0 pref medium
local fe80::a691:b1ff:fe34:3d9b dev lo table local proto unspec metric 0 pref medium
local fe80::a691:b1ff:fe34:3d9b dev lo table local proto unspec metric 0 pref medium
ff00::/8 dev wl0 table local metric 256 pref medium
ff00::/8 dev br-lan table local metric 256 pref medium
ff00::/8 dev ptm0 table local metric 256 pref medium
ff00::/8 dev wl1_1 table local metric 256 pref medium
ff00::/8 dev wl0_1 table local metric 256 pref medium
unreachable default dev lo proto kernel metric 4294967295 error -101 pref medium
multicast 239.255.255.250/32 from 192.168.1.80/32 table default proto 17
root@modemtim:~# ip route list table all |grep voip
1.109.0.1 dev pppoe-voip2 proto kernel scope link src 1.109.18.231
local 1.109.18.231 dev pppoe-voip2 table local proto kernel scope host src 1.109.18.231
Ho controllato per bene il firewall, non ho trovato niente di strano, le regole sono relativamente poche (il comportamento delle regole nel file mwan resta un mistero). Ho controllato anche direttamente con un "iptables -L", non ho visto niente di sospetto.
Direi che con calma provo a cambiare firmware, attualmente sto usando un Ansuel AGTHP_2.2.0_002, proverò con il 2.1, sia mai che abbiano cambiato qualcosa nel pppoe che ha creato casini (improbabile).
-
Prova senza custom gui. Questa cosa di mwan mi puzza.
-
Ho messo il Firmware v. 2.2.0 (stabile), non versione ansuel ed effettivamente la rebind protection era abilitata di default (a differenza dell'ultima versione del firmware ansuel).
Comunque, non ho messo l'interfaccia moddata e mi sono fatto tutte le configurazioni. Il file mwan continua ad avere lo stesso comportamento, commentando tutto, niente navigazione.
Dopo aver fatto nuovamente tutte le configurazioni, ho notato un comportamento strano: quando inserivo l'host_uniq nella connessione voip, non mi prendeva la regola di route, eliminandolo la prendeva.
Gira che ti rigira che cosa è uscito fuori? Che specificando l'host_uniq nella connessione voip, all'interfaccia viene assegnato un altro indirizzo IP su una classe molto simile ma differente e, naturalmente, cambia il gateway! Ho inserito il nuovo gateway prima con il comando route per vedere se funzionava (e funzionava), dopo nel file di configurazione network.
I proxy hanno cominciato a rispondere al ping (quindi a quanto pare specificare l'host_uniq è necessario) e la configurazione manuale di mmpbx funziona alla grande. Telefonate in ingresso e in uscita perfette e problema di timeout scomparso.
Grazie infinite @LuKePicci , direi che previo periodo di test e con un po' di tempo a disposizione, scriverò un post riepilogativo con tutti i passaggi per mettere un po' d'ordine in questo marasma.
-
Questa é una svolta epocale!!! C'é un attimo da capire però quale mac address mettere e come trovare precisamente l'host_uniq,in quanto ho fatto la conversione in esadecimale del seriale della vsr ma a vederlo é sbagliato.
Ah inoltre nella configurazione VoIP da interfaccia grafica,cosa hai messo?
-
Il Mac address non dovrebbe influire minimamente a questo punto. L'host_uniq è l'esadecimale del numero di serie della VSR, in che senso a occhio è sbagliato?
Da interfaccia grafica non ho fatto nulla, tutti i file di configurazione, compreso quello di mmpbx, li ho modificati direttamente con vi (se stai più comodo mi pare che winscp abbia un editor), anche perché con l'interfaccia non moddata puoi cambiare poco o niente. I dati da inserire sono quelli che LukePicci ha scritto nei post precedenti, tranne naturalmente i dati di autenticazione che ti ha inviato Vodafone (quelli puoi metterli anche da interfaccia grafica, poco cambia).
Comunque mmpbx è l'ultimo dei problemi, arriva nella situazione in cui i proxy rispondono al ping, il resto al limite si vede dopo.
-
Se mi fai la cortesia di postare il codice dal file network di wan e voip2,con le ovvie omissioni,risparmio casini vari. Diciamo che è il fulcro di tutto il funzionamento. Per il resto non dovrei avere alcun problema.
Diciamo che stupidamente ho resettato tutto senza salvare i file,ed ora mi ritrovo a dovere ripartire da zero quando avrei praticamente finito pure io. :D
-
Naturalmente, do per scontato che hai già fatto le modifiche nel file /etc/config/dhcp (e che quindi l'nslookup funziona), che in /etc/config/firewall hai inserito voip2 nella "config zone 'wan'" e che hai modificato il file /etc/config/mwan inserendo come interfaccia voip2.
config device 'voipptm0'
option type '8021q'
option name 'voipptm0'
option macaddr 'mac_address' # inserisci il MA che vuoi
option ifname 'ptm0'
option ipv6 '0'
option vid '1035'
config interface 'voip2'
option auto '1'
option proto 'pppoe'
option demand '0'
option macaddr 'mac_address' # inserisci lo stesso MA di voipptm0
option ipv6 '0'
option keepalive_adaptive '0'
option ifname 'voipptm0'
option password 'vodafone'
option username 'V-SNVSR' # al posto di SNVSR inserisci il seriale della tua VSR (il mio comincia per C18...)
option host_uniq 'HU' # al posto di HU inserisci l'host uniq del seriale della VSR
option keepalive '4,20'
option defaultroute '0'
config device 'wanptm0'
option type '8021q'
option name 'wanptm0'
option macaddr 'mac address' # lascia quello che mette di base durante la prima configurazione
option ifname 'ptm0'
option ipv6 '0'
option vid '1036'
config interface 'wan'
option auto '1'
option proto 'pppoe'
option demand '0'
option macaddr 'mac address' # lascia quello che mette di base durante la prima configurazione (lo stesso di wanptm0)
option ipv6 '0'
option peerdns '1'
option reqopts '1 3 6 15 26 33 42 51 121 249'
option keepalive_adaptive '0'
option dns_metric '0'
option ifname 'wanptm0'
option password 'vodafone'
option username 'D-SNVSR' # al posto di SNVSR inserisci il seriale della tua VSR
option host_uniq 'HU' # al posto di HU inserisci l'host uniq del seriale della VSR
config route 'voip2_private'
option interface 'voip2'
option netmask '255.0.0.0'
option metric '1'
option target '10.0.0.0/8'
option gateway 'GW' # al posto di GW inserisci l'indirizzo del gateway
Per trovare l'indirizzo del gateway, basta che commenti defaultroute '0' da voip2 e la metti su wan (naturalmente non ti funziona più la navigazione). Commenta anche tutta la sezione "config route ...".
In SSH dando un "route", esce fuori l'indirizzo del gateway (dovrebbe finire per .1).
Rimetti il defaultroute '0' su voip2, compili la sezione config route con il GW giusto e dovresti aver finito
-
Riguardo il MAC, potete metterci quello che vi pare ma deve essere diverso da quello wan, quindi dovete comunque fare attenzione a questo aspetto quando ne scegliete uno a piacere. Riguardo l'host_uniq, c'è un certo margine di flessibilità, può anche non corrispondere esattamente a quello di una vera VS ma ci deve assomigliare, ad esempio se al posto delle ultime tre cifre ascii ci mettete "_42" funziona lo stesso.
@gacchu Ti suggerisco di editare il riepilogo usando "voip" al posto di "voip2", puoi tranquillamente sostituire quella definita di default. Non dimenticare di aggiungere nel riepilogo la config di dnsmasq con le eccezioni alla rebind_protection.
-
In questa versione del firmware in realtà non ho nessuna sezione voip definita nelle regole del firewall, quindi non è un problema (se non per chi vorrà seguire la guida e si ritrova una voce con lo stesso nome già definita)
-
E' la custom gui che probabilmente la aggiunge.
-
no, le interfacce nominate voip sono (o forse erano) by tim
-
La prima volta che ho installato la custom gui ho (stupidamente) seguito la configurazione guidata. Ho specificato "operatore generico" e non ho messo nessuna opzione per la fonia. Sono abbastanza sicuro che in quel momento sia stata creata la voce "VoIP" nel firewall. Ora ho installato nuovamente la custom gui e non ha apportato modifiche nè al firewall nè alle interfacce
-
si io parlo di eventuali interfacce/modifiche inserite forzatamente durante l'installazione, non escludo di eventuali accrocchi che si possano generare toccando le varie impostazioni (anche se mi pare strano lo faccia il wizard..)
so di per certo che stesso negli script di init/restart di mmpbxd vengono toccate cose sul firewall (ma mi pare direttamente su iptables, le config non le tocca)
-
Ed mwan chi te lo ha abilitato? Chi ti ha associato l'interfaccia voip alla policy mwan?
-
Ok il ping al server lo fa. Il problema è la parte di configurazione voip. Nel registrar primario,nel nome dominio,cosa devo mettere? Infine ci sarebbe il nome utente che con la configurazione alternativa vodafone fa [email protected]. Nel nostro caso cosa devo mettere?
Poi @gacchu ma a te pinga entrambi i server? Perchè a me funziona solo il primo.
-
nella sezione "config network 'sip_net'" (il mio di default si chiamava così, non so come si chiama il tuo), fai queste variazioni:
option interface 'voip2'
option local_port '5060'
option primary_registrar_port '5060'
option secondary_proxy_port '5060'
option transport_type 'UDP'
option primary_registrar 'proxy1-*****.vodafone.it'
option primary_proxy 'proxy1-*****.vodafone.it'
tutte queste voci dovrebbero essere già presenti, devi solo (eventualmente) modificarle
queste voci devi invece aggiungerle:
option secondary_proxy 'proxy2-*****.vodafone.it'
option secondary_registrar 'proxy2-*****.vodafone.it'
option secondary_registrar_port '5060'
Per quanto riguarda la configurazione delle linee telefoniche, puoi farla anche da interfaccia web, è identica a quella che hai fatto per il proxy su vlan id 1036.
Se vuoi farla da file di configurazione, ecco il mio (option network deve riportare il nome della option interface della sezione precedente):
config profile 'sip_profile_0'
option network 'sip_net'
option user_name '[email protected]'
option uri '+39tuonumero'
option display_name '+39tuonumero'
option enabled '1'
option password 'tuapassword'
Da interfaccia grafica verifica su "Mappatura ingresso / uscita" che FXS 1 sia abilitata, verifica che nella sezione "Codec" sia tutto a posto e tutto dovrebbe funzionare.
A me il ping va su entrambi i server, mi sembra strano che ne vada uno sì e uno no
Mi raccomando, NON aggiungere un nuovo provider SIP nella sezione "Globale" e NON aggiungere nuovi profili SIP nella sezione "Linee telefoniche", modifica sempre ciò che già trovi
-
No ora pinga...probabilmente non pingava perchè la porta stava a 0 invece di 5060. Comunque ho fatto le modifiche da file,però nell'interfaccia grafica ho robe e riferimenti a tim. Ed ho pure riavviato.
-
L'unico riferimento che dovresti avere da interfaccia grafica è su "Realm", dovrebbe contenere "digest.telecomitalia.it", se vuoi puoi anche eliminarlo.
Per il resto dovresti avere:
Nome: SIP network (o il nome che hai scelto)
Registrar primario: proxy1.*****.vodafone.it
Nome dominio: ims.vodafone.it
Realm: digest.telecomitalia.it
Porta registrar primario: 5600
Proxy primario: proxy1.*****.vodafone.it
Porta proxy primario: 5060
Porta locale: 5060
Scadenza: 3600
Interfaccia: voip2
Per il ping sul secondo proxy, queste configurazioni non c'entrano nulla, probabilmente hai digitato male l'host da pingare o magari in quel momento il server non ti ha risposto per qualche altro motivo
Altra differenza rispetto alla situazione precedente è che l'interfaccia voip2 ora è presente anche nell'elenco delle interfacce di mmpbx da gui
-
edit: come non detto non ho risposta dal server. La rete dati è perfetta ma non va quella voce. Ero convinto che pingasse,perchè su putty sembrava effettivamente comunicare,ma usando il tool da interfaccia grafica,mi segnava errore. Il traceroute lo fa però.
route.
root@modemtim:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default net-5-89-180-1. 0.0.0.0 UG 0 0 0 pppoe-wan
1.255.241.1 * 255.255.255.255 UH 0 0 0 pppoe-voip2
5.89.180.1 * 255.255.255.255 UH 0 0 0 pppoe-wan
10.0.0.0 1.255.241.1 255.0.0.0 UG 1 0 0 pppoe-voip2
192.168.3.0 * 255.255.255.0 U 0 0 0 br-lan
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
root@modemtim:~#
ifconfig.
pppoe-voip2 Link encap:Point-to-Point Protocol
inet addr:1.255.241.164 P-t-P:1.255.241.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:12 errors:0 dropped:0 overruns:0 frame:0
TX packets:360 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:558 (558.0 B) TX bytes:70832 (69.1 KiB)
pppoe-wan Link encap:Point-to-Point Protocol
inet addr:5.89.180.50 P-t-P:5.89.180.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:19642 errors:0 dropped:0 overruns:0 frame:0
TX packets:17163 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:8463289 (8.0 MiB) TX bytes:2744752 (2.6 MiB)
ptm0 Link encap:Ethernet HWaddr 10:13:31:C0:3D:98
inet6 addr: fe80::1213:31ff:fec0:3d98/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:33509 errors:0 dropped:0 overruns:0 frame:0
TX packets:29532 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:17811242 (16.9 MiB) TX bytes:5467521 (5.2 MiB)
voipptm0 Link encap:Ethernet HWaddr 90:35:6E:C4:AF:CB
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:127 errors:0 dropped:0 overruns:0 frame:0
TX packets:474 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:5544 (5.4 KiB) TX bytes:82219 (80.2 KiB)
Vedete problemi?
Nella conversione in esadecimale,quanti valori hai? Perchè mi sà che l'errore sta lì.
-
Hai messo l'host_uniq sia in in wan che in voip2?
Dire se sono corretti è difficile dato che gli IP cambiano se viene passato o meno l'host_uniq, ma a occhio sono errati.
Senza host_uniq avevo come ip assegnato all'interfaccia 1.255.160.97 e come gateway 1.255.160.1
Con host_uniq ho invece come ip 1.109.18.231 e come gateway 1.109.0.1
A occhio i valori che hai riportato sono sulla classe 1.255, quindi secondo me non stai passando l'host_uniq (oppure lo stai passando ma non gli piace)
L'host_uniq che ho generato ha 30 caratteri. A quanto pare esistono convertitori hex anche online, ho provato a generare un codice e corrisponde con quello che ho inserito io, puoi andare su questo link: https://codebeautify.org/string-hex-converter (https://codebeautify.org/string-hex-converter)
Io l'ho generato da linux con il seguente comando:
echo -n SNVSR |xxd -ps
-
30 caratteri che io non ho. Ok mi diresti come hai fatto la conversione?
Edit: grazie, gentilissimo. Ora é ok. Vediamo che ne viene fuori...
-
Non è una conversione decimale-esadecimale ma una codifica stringa-ascii di cui prendi il dump dei singoli byte rappresentati in esadecimale
-
Effettivamente avrei fatto meglio a specificare String2Hex dall'inizio, lo avevo dato per scontato dato che il seriale non è composto solo da numeri..
Comunque quando hai parlato di 4 gatti che vogliono usare il proprio router, non ci sei andato troppo lontano.. dato che qui dentro pare che siamo solo in 3.
-
Funziona alla grande!!! Nessun time out anomalo. Un grazie a @LuKePicci e @gacchu per l'impegno e per le competenze dimostrate. Quello del telefono era un problema serio e finalmente è stato risolto.
Si gacchu io facevo la conversione in esadecimale,lasciando la lettera iniziale,anche se effettivamente mi era venuto il dubbio...Una cosa in più imparata. Comunque no se vai a ritroso vedrai diversa gente con questo tipo di problemi,solo che molti c'hanno perso le speranze o hanno direttamente cambiato modem. Vedrai che qualcuno spunterà...
In ogni caso,finalmente mi sono liberato di quella specie di modem della vodafone. :D
ps si potrebbe fare una guida ma è una cosa molto complessa,non tanto da spiegare,quanto da far eseguire nei minimi termini. In quanto ci vogliono anche i proxy da "prendere" nella vsr,con lo script condiviso da LuKePicci e altre cose abbastanza complesse.
-
Bene, son contento! Ottimo modo per festeggiare il tuo centesimo messaggio in questo forum :clap:
Ora che siamo in due, vediamo come va a livello qualitativo, sicuramente ci sarà qualcosa da sistemare.. purtroppo il telefono fisso lo uso poco e niente, ma è stato interessante sbatterci un po' la testa
Per la guida in realtà le cose da fare sono poche, per quanto mi riguarda è doverosa dato il marasma che ho contribuito a creare. Meglio avere tutto raccolto in un unico post, dopo al limite se uno ha problemi si va a leggere tutto ciò che abbiamo scritto
-
Io non ho mai usato un mio router al posto della VSR, quando ero in ftth li avevo connessi in parallelo perché openwrt (sul netgear che usavo) non era adeguato alle velocità della fibra. Dove ora ho ancora Vodafone. in fttc, ho ancora la VSR. Sul thread di hwupgrade è pieno di gente che ha usato il setup con host-uniq con la sola parte dati. Quasi nessuno usava anche il voip perché ottenere le credenziali era difficile. Ora che esiste il setup alternativo nessuno più si chiede come riuscirci ma in realtà l'unico che funziona bene e non crea problemi è ancora quello standard, senza contare che con quello alternativo non si possono registrare numeri di altre linee.
-
Magari la soluzione alternativa con il tempo comincerà a funzionare meglio, anche se a giudicare da ciò che si trova scritto in giro c'è da dubitarne..
Ora, l'ultimo sfizio che mi voglio togliere con questo router, è far funzionare la SIM dati che mi hanno dato come linea di backup (mai usata). Ho visto che nel firmware è presente la gestione della SIM, immagino serva soltanto informarsi su quale dongle USB 3g/4g funzioni senza problemi su OperWRT. Se anche con la SIM il router è in grado di mettere su la vlan per il voip, la cosa si fa interessante.
-
La SIM dati io l'ho usata sul 789vac v2. Il dongle compatibile dipende dalla versione del kernel (altrimenti non risolvibile) e secondariamente da mobiled (risolvibile, a seconda del tipo di interfaccia mibm, qmi, cdc_ether, ppp, hilink,...). LA vlan voce che io sappia non è raggiungibile da sim (apn webdsl). mmpbxd funziona regolarmente tramite dongle 3g, ma l'ho provato con eutelia, non vodafone. Il setup alternativo non può funzionare su sim dati.
-
Per chiunque fosse interessato ad una guida riassuntiva per la configurazione del voip su vlan id 1035, può consultare il seguente link: https://www.ilpuntotecnico.com/forum/index.php/topic,82347 (https://www.ilpuntotecnico.com/forum/index.php/topic,82347)
-
Ho configurato senza grandi problemi un dongle K5160 con una SIM dati Vodafone. La connessione funziona, ma confermo che la vlan voce purtroppo non è raggiungibile.. peccato
-
Buongiorno, sto vedendo che questo tim hub viene acquistato per sostituire il router di Vodafone, io ho una fibra 1000, e' consigliato? ci sono migliorie nel wifi 5GHZ?
Si deve sostituire un FW con uno mod? perdonate, ma rileggendo un po il topic mi sembra di capire questo
Grazie
-
@maxking rispetto ad una VSR secondo la mia esperienza c'è una differenza abissale, sia sulla stabilità/qualità di connessione che sulla parte Wi-Fi. Non so se questo apparato viene acquistato appositamente da chi ha una linea Vodafone per sostituire il loro router, ho i miei dubbi dato che la configurazione del voip non è proprio semplice (guarda il link riportato alla discussione pochi post fa).
Se il tuo punto di partenza è individuare un nuovo apparato per sostituire la Vodafone Station senza troppe complicazioni, ti conviene orientarti verso router AVM, il modello di FritzBox lo scegli in base alle tue esigenze/tasche.
Se invece vuoi avere il controllo totale di tutto, sempre nel link riportato qualche post fa trovi come configurare parte telefonica e parte dati su router basati su OpenWRT (come il timhub), ma naturalmente vuol dire perdere un po' di tempo sulle configurazioni ed avere un minimo di dimestichezza con gli ambienti da utilizzare (da interfaccia grafica si fa poco e niente, soprattutto per la parte telefonica).
-
@gacchu gentilissimo per la tua delucidazione, si mi piacierebbe metterci mano, il problema dopo aver fatto una bella lettura, ho capito che non sempre le chiamate arrivano? leggevo di 60 secondi dopo l'accensione puo' capitare questo? se con FW recenti e' cambiato qualcosa chiedo Venia
Grazie ancora
-
Al momento le chiamate in ingresso utilizzando la soluzione proposta da Vodafone per il modem alternativo non funzionano con il TimHub, probabilmente per un problema dovuto ad una incompatibilità tra mmpbxd (il servizio che gestisce il voip su OpenWRT) e la configurazione dei server SIP di Vodafone.
La cosa si risolve comunque, è tutto descritto in questa guida: https://www.ilpuntotecnico.com/forum/index.php/topic,82347
L'importante è che tu abbia ciò che è richiesto nel "cosa serve":
1) Un router con accesso root Homeware >= 16.3 o OpenWRT >= 15.05 (il TimHub va bene)
2) I dati di autenticazione VOIP (sono consultabili nell’area personale oppure è possibile richiederli direttamente a Vodafone)
3) I proxy a cui collegarsi utilizzati dalla Vodafone Station (devi avere una Vodafone Station 2 o una Vodafone Station Revolution per poterli estrarre)
4) Il seriale della Vodafone Station (è riportato su un'etichetta posta sul retro)
-
Ciao, chiedo ai più esperti come siamo messi nel 2021 per gestire correttamente il voip della linea vodafone su TIM Hub, bisogna ancora rootare per forza (e seguire questa guida https://www.ilpuntotecnico.com/forum/index.php/topic,82347 )? oppure si può fare più velocemente anche solo col TIM Hub "sbloccato" come modem generico (con i parametri specificati nel primo post)? grazie
-
eehm, scusate ho fatto un pò di ricerche e mi sono letto quasi tutto, so che è un pò datato ma io avendo il dga4130 non vedo topics simili.....
escludendo questo https://www.ilpuntotecnico.com/forum/index.php/topic,82347 che è estremamente complesso (ma se serve dovrò farlo per forza) , ad oggi pur inserendo i parametri vodafone delle prime pagine, la fonia con i router TIM è preclusa del tutto ? Perchè a me, pur avendo inserito tutti i parametri delle prime pagine, andando in statistiche>Informazioni telefonia> continua a dare timeout registrazione .... Riavviando il router la linea VOIP entra in funzione ma non riceve.
P.S. Confermo che la linea VOIP funziona correttamente solo per un breve periodo, poi va in timeout e non riceve chiamate. Comunque, nel mio caso i dati da SMS sono corretti e sto usando Voip3.fixed.vodafone.it .
-
Attualmente, per avere la fonia perfettamente funzionante, l'unico modo è seguire la guida su https://www.ilpuntotecnico.com/forum/index.php/topic,82347
Se si è alla ricerca di una soluzione semplice, sul mercato esistono apparati in grado di funzionare direttamente con i dati forniti da Vodafone, come i modem/router della AVM.
Personalmente, penso che valga la pena dedicare del tempo per far funzionare degli apparati che tutt'ora restano molto validi, soprattutto se paragonati alla VS fornita da Vodafone.
-
Scusate eh ma ci deve essere a forza qualche altro parametro che non va (tempo di reregistrazione? Anche qui mwan che fa cose strane?) mica chi vuole usare il “modem libero” deve a forza spippolare per usare i parametri che riguardano la VLAN interna
-
Buonasera ragazzi, gentilmente mi potreste aiutare a configurare il timhub per linea Vodafone FTTC.. sia linea internet che fonda.. sto impazzando. Se qualcuno già la possiede potrebbe inviarla?? Grazie a tutti in anticipo