[LuKePicci]

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.

[LuKePicci]

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

[gacchu]

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.

[LuKePicci]

Controlla che non ci sia qualche altra tabella di routing oltre quella di default. Invece del semplice route, usa

Codice: [Seleziona]

ip route list table all

[gacchu]

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:

Codice: [Seleziona]

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).

[LuKePicci]

Prova senza custom gui. Questa cosa di mwan mi puzza.

[gacchu]

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.

[milan100]

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?

[gacchu]

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.

[milan100]

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. 

[gacchu]

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.

Codice: [Seleziona]

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

[LuKePicci]

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.

[gacchu]

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)

[LuKePicci]

E' la custom gui che probabilmente la aggiunge.

[FrancYescO]

no, le interfacce nominate voip sono (o forse erano) by tim