[LuKePicci]

Anche mwan3 sposta le defaultroute in tabelle distinte, solo che ci pensa lui a crearle con nomi dinamici. Tieniti il workaround.

[Marvel]

Si, ho scritto mwan ma mi riferivo al wiki di mwan3 ed ai suggerimenti in esso presenti:
https://openwrt.org/docs/guide-user/network/wan/multiwan/mwan3

io credo che alla luce degli ultimi test anche con mwan3 non risolverei il problema, tu cosa pensi? Perché se mi suggerisci di fare un tentativo allora provo a compilarlo ed installarlo.

Comunque il mio workaround è realmente molto semplice, nel caso possa interessare a qualcuno:
/etc/hotplug.d/iface/10-wan

Codice: [Seleziona]

if [ "$ACTION" = "ifup" ] && [ "$INTERFACE" = "wan2" ]; then
        ifup wan
fi


[LuKePicci]

mwan3 non supporta la gestione di app in esecuzione sul router, quindi non avresti la possibilità di definire nulla di simile ad "hostvoip" e non avresti come dire ad mmpbx di usare una certa interfaccia. Direi che il workaround è la cosa migliore.

[Marvel]

E la cosa non sarebbe un grande problema dato che al momento la direttiva hostpvoip nel mio mwan non sortisce alcun effetto, presente o meno non sembra cambiare nulla.

Comunque voglio anche provare asterisk, chissà se utilizzando asterisk e mettendoci in cascata mmpbx potrei risolvere questo strano problema. Devo provare quanto prima.

@nclmrc , nel thread che mi hai linkato per asterisk:
https://www.ilpuntotecnico.com/forum/index.php/topic,80658.0.html

leggo:

BUG riscontrati
Nel caso si dovesse disconnettere la linea, il VOIP non riparte in autonomia, bisogna riavviare il mmpbxd

Codice: [Seleziona]

/etc/init.d/mmpbxd restart


me lo confermi?

[LuKePicci]

Se asterisk di suo senza mwan ti fa scegliere su quale interfaccia uscire allora lo risolvi di sicuro.

[Marvel]

Me lo auguro, solo che io non ho mai utilizzato asterisk e so che è un software enorme quindi prima di iniziare a giocarci avrò molto da studiare. Inoltre leggo che anche utilizzando asterisk ci sono problemi con mmpbxd che non riparte in automatico in caso di disconnessioni, tu hai esperienze a riguardo?

Hai qualche consiglio sull'utilizzo di asterisk con questi dispositivi?

[LuKePicci]

no su asterisk non so proprio nulla mi dispiace.

ho un'ultima prova da farti fare. con tre connessioni, wan (tabella main, defaultroute on, metric 10) wan2 (tabella main2, defaultroute on, metric 20) e voip (tabella voip, defaultroute off, metric 5), helper spento, rimuovi/commenta dal file di config di mwan la hostvoip e ogni altra policy riguardante l'interfaccia voip, togli anche la dnsrule dal file dhcp, scegli voip come interfaccia in mmpbx, rimetti la rotta statica che avevamo creato verso l'ip del proxy con table "voip" e destinazione "voip" al posto di "main" e "wan", e dalle metrica 5.

In questo modo mwan non dovrebbe avere più nulla a che fare con mmpbx, che è una cosa che se ben ricordo non hai mai provato.

[nclmrc]

Asterisk purtroppo non ha la gestione dell' interfaccia su cui uscire. Io sinceramente non ho il problema di dover riavviare mmpbx.

[LuKePicci]

Certo, tu sei messo come me su tiscali, abbiamo gw diversi per ogni interfaccia, siamo in situazioni più standard, e tutto funziona normalmente.

[Marvel]

ho un'ultima prova da farti fare. con tre connessioni, wan (tabella main, defaultroute on, metric 10) wan2 (tabella main2, defaultroute on, metric 20) e voip (tabella voip, defaultroute off, metric 5), helper spento, rimuovi/commenta dal file di config di mwan la hostvoip e ogni altra policy riguardante l'interfaccia voip, togli anche la dnsrule dal file dhcp, scegli voip come interfaccia in mmpbx, rimetti la rotta statica che avevamo creato verso l'ip del proxy con table "voip" e destinazione "voip" al posto di "main" e "wan", e dalle metrica 5.

In questo modo mwan non dovrebbe avere più nulla a che fare con mmpbx, che è una cosa che se ben ricordo non hai mai provato.

Avevo già fatto un test simile ma senza toccare il file dhcp.
Ho appena fatto con attenzione tutto, ricontrollando più volte i files e riavviando il router, ma nulla, stesso bizzarro comportamento. Se pppoe-voip è l'ultima interfaccia a partire allora mmpxd si registra, altrimenti mi da il solito errore.
La cosa assurda è che le tre interfacce wan sono attive, funzionano e le rotte sono tutte corrette.
Ad mmpbx gli assegno un'interfaccia che si attiva e funziona regolarmente, anche senza indicare la route statica in network col seguente comando verifico che l'ip del proxy voip viene raggiunto correttamente dall'interfaccia assegnata:

Codice: [Seleziona]

ip route get xx.xx.xx.xx
xx.xx.xx.xx.xx via 192.168.100.1 dev pppoe-voip src yy.yy.yy.yy.yy
    cache

xx.xx.xx.xx = IP proxy Voip
yy.yy.yy.yy = ip pubblico pppoe-voip

E allora cos'è che non va? Realmente il fatto dello stesso gateway per tutte e tre le interfacce? E solo ad mmpbxd non piace sta cosa? Secondo me c'è altro che ancora mi sfugge.

[nclmrc]

@Marvel prova con asterisk

[Marvel]

@nclmrc , si ho intenzione di fare una prova veloce in questo fine settimana o al massimo nel prossimo, se dovesse funzionare allora inizio a studiarmelo per bene. Secondo te, se seguo la guida che mi hai linkato qualche post fa riesco a tirarlo su almeno per provarlo anche se non ho la minima conoscenza di asterisk?

[nclmrc]

@Marvel chiedi a me nel caso. Ho fatto uno script

[nclmrc]

@LuKePicci  cosa fa esattamente il siploopback?

[Marvel]

@nclmrc , ovviamente l'esperto è @LuKePicci , io ti riporto ciò che mi ha spiegato lui qualche post fa:

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

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

Sembra quasi che l'helper sia sfruttato per mettere una pezza laddove il socket wrapper di mwan faccia casini.