[nclmrc]

Sono sicurissimo, il proxy ha un Ip pubblico raggiungibile solo dalla rete privata delle cpe.

edit

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

[LuKePicci]

E' lui, prova a disabilitarlo e vedi se ancora ti si registra. Non dovrebbe.

[nclmrc]

Lo disabilito a mano perché da gui non si può fare

[LuKePicci]

Sì devi mettergli l'option enable '0' che quando manca vale 1 di default. Poi fai il reload del firewall.

[nclmrc]

Fatto adesso non funge, perché mi presento con l'ip pubblico. Io però non l'ho mai toccato l'helper loopback sip.

[LuKePicci]

Si di default è attivo su alcuni firmware. Ora sei in una situazione "normale", dove per dirottare mmpbx hai bisogno di mwan e annessa regola host - ma torno a dire che nel tuo caso è inutile, io opterei per la route statica, niente mwan, niente helper, niente altre tabelle.

[nclmrc]

A me ha sempre funzionato era solo x capire perché ad esempio a @Marvel non funziona. Comunque con mmpbx avevo bisogno dell'hostvoip path, con asterisk funziona senza nemmeno quello.

[LuKePicci]

Lui l'helper ce l'ha spento perchè è una delle prime cose che gli ho fatto spegnere per non uscire pazzi. Lui comunque non ha una rete dedicata al voip, lì c'è necessità di avere la default route su entrambe le interfacce. hostvoip e helper convivono in modo piuttosto bizzarro. Sembra quasi che l'helper sia sfruttato per mettere una pezza laddove il socket wrapper di mwan faccia casini. Il problema di hostvoip è che impedisce ad mmpbx di usare anche altre interfacce quando serve, ad esempio se ti vuoi registrare contemporaneamente su due proxy, uno su vlan voip e uno in internet.

[Marvel]

@Marvel prova a fare così, secondo me ti funziona.

@Marvel ho un'altra idea.

@nclmrc @LuKePicci avete avuto la stessa idea, provato, ma niente, stesso comportamento, se la nuova interfaccia voip è l'ultima a partire allora il voip si registra altrimenti nulla.
Mi basta dare:
ifup voip && ifup wan && ifup wan2
e vedo il voip non registrarsi. Dopodiché mi basta dare ifup voip per farlo registrare. Che cavolo!!!

@LuKePicci , non vorrei veramente abusare della tua pazienza ma potresti darmi la tua opinione in merito al mio quesito di qualche post fa:

...

#POSTEDIT
E proprio ora credo di aver capito il problema, se do ifup voip && ifup wan && ifup wan2 la registrazione del voip fallisce, se invece do i comandi separatamente:
ifup voip
ifup wan
ifup wan2
aspettando che mmpbxd si registri prima di avviare wan w wan 2, allora funziona correttamente.
È come se nell'avvio in sequenza le reti si accavallassero, lui inizia a registrarsi su una che si sta attivando ma poi il processo di avvio gliene fa trovare un'altra e da qui l'errore:

Codice: [Seleziona]

SIP Registration: SIP: +39XXXXXXXXXX : Failure Reason: 403 No Roaming Agreement From Current Network
[MMRVSIPIMPL::REGTERMOBJ]:E: regTermObjFirewallRuleUpdate:4158 - Unable to retrieve currentDestination from SIP network ..
[MMRVSIPIMPL::REGTERMOBJ]:E: registerStateChanged:1422 - statusCode 403
Potrebbe darsi che il problema sia questo?
Se così fosse sarebbe un grave problema poiché durante il processo di boot o su un /etc/init.d/network restart, io purtroppo non credo di poter intervenire in alcun modo.

[LuKePicci]

Fai un

Codice: [Seleziona]

grep -r /rom -e if._mwan e vedi cosa esce. Potrebbe esserci qualche script nel firmware in cui sia hardcodato uno di quei nomi.

[Marvel]

Questo è l'output:

Codice: [Seleziona]

grep -r /rom -e if._mwan
/rom/etc/config/dhcp: option policy 'if1_mwan'
grep: /rom/etc/fstab: No such file or directory
/rom/etc/parameter_conversion/conversion:uci_set mwan.if1_mwan.interface
grep: /rom/etc/snmp/snmpd.conf: No such file or directory
/rom/etc/uci-defaults/tch_5001_LTE_2_Box:uci set mwan.if1_mwan=policy
/rom/etc/uci-defaults/tch_5001_LTE_2_Box:uci set mwan.if1_mwan.interface=wan
/rom/etc/uci-defaults/tch_5001_LTE_2_Box:uci set mwan.hostvoip.policy='if1_mwan'
/rom/etc/uci-defaults/tch_5001_LTE_2_Box:uci set mwan.if1_e.policy=if1_mwan
/rom/etc/uci-defaults/tch_5001_LTE_2_Box:uci set mwan.if1_f.policy=if1_mwan
/rom/etc/wansensing/worker_ethwan.lua: x:set("mwan", "if1_mwan", "interface", "wan")
/rom/etc/wansensing/worker_ethwan.lua: x:set("mwan", "if1_mwan", "interface", "voip")

In /etc/config/dhcp ho:

Codice: [Seleziona]

config dnsrule
        option dnsset 'voip'
        option policy 'if1_mwan'


[LuKePicci]

Bhè direi che ti sei risposto. Come ho spiegato prima a @nclmrc quella regola significa che tutti i server dns ottenuti automaticamente via dhcp/ipcp/altro dalle interfacce in /etc/config/network su cui hai impostato dnsset 'voip' vengono raggiunti attraverso la policy con quel nome.

edit: dnsrule ammette sia l'opzione policy che outpolicy, una dice come vanno raggiungi gli ip dei dns server, l'altra dice in quali casi usare quel dnsset, non sono sicuro quale delle due faccia l'una o l'altra cosa.

edit2:

Potrebbe darsi che il problema sia questo?

Di sicuro, ma lo avevamo già appurato. Se mmpbx apre il socket mentre c'è solo una rotta valida (quella corretta) il problema non si presenta. Se apre il socket e poi le altre rotte valide finiscono nella tabella, allora va in crisi. Se elimini la regola hostvoip, mmpbx viene esonerato dal passare attraverso il wrapper di mwan all'apertura del socket, ma non hai più alcuna garanzia sul fatto che usi l'una o l'altra wan. E' una situazione abbastanza sfigata, perchè lo scenario in cui hai due wan dati ed mmpbx in esecuzione sullo stesso host in cui gira mwan e con l'sip che assegna lo stesso gw a tutte le sessioni è decisamente singolare. Dimmi una cosa, ma a prescindere dall'ordine con cui avvii le interfacce, se lasci che si avviino, poi riavvii mwan e poi riavii mmpbx hai comunque l'errore?

[Marvel]

Bhè direi che ti sei risposto. Come ho spiegato prima a @nclmrc quella regola significa che tutti i server dns ottenuti automaticamente via dhcp/ipcp/altro dalle interfacce in /etc/config/network su cui hai impostato dnsset 'voip' vengono raggiunti attraverso la policy con quel nome.

Ti chiedo scusa ma non ti seguo. Se io ho questo:

Codice: [Seleziona]

config policy 'if1_mwan'
        option interface 'wan'

config rule 'lan_if1'
        option policy 'if1_mwan'
        option src 'lan'

ed in /etc/config/network non ho impostato dnsset 'voip' per l'interfaccia wan, perché il tutto mi manda ko i dns, ossia perché i miei dispositivi nella rete non sono più in grado di utilizzare i dns del router?

mentre funge tutto con:

Codice: [Seleziona]

config policy 'wan_only'
option interface 'wan'

config rule 'lan_wan'
option policy 'wan_only'
option src 'lan'


edit2:Di sicuro, ma lo avevamo già appurato. Se mmpbx apre il socket mentre c'è solo una rotta valida (quella corretta) il problema non si presenta. Se apre il socket e poi le altre rotte valide finiscono nella tabella, allora va in crisi. Se elimini la regola hostvoip, mmpbx viene esonerato dal passare attraverso il wrapper di mwan all'apertura del socket, ma non hai più alcuna garanzia sul fatto che usi l'una o l'altra wan. E' una situazione abbastanza sfigata, perchè lo scenario in cui hai due wan dati ed mmpbx in esecuzione sullo stesso host in cui gira mwan e con l'sip che assegna lo stesso gw a tutte le sessioni è decisamente singolare. Dimmi una cosa, ma a prescindere dall'ordine con cui avvii le interfacce, se lasci che si avviino, poi riavvii mwan e poi riavii mmpbx hai comunque l'errore?

Si, in effetti prima ho detto una grande fesseria, nei giorni scorsi avevo appurato che se ad esempio do in ordine i seguenti comandi aspettando che ogni interfaccia si avvii correttamente:
ifup wan
ifup wan2
e po do:
/etc/init.d/mmpbxd reload

allora il voip non si registra lo stesso.
Ho anche appena verificato la rotta:

Codice: [Seleziona]

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

xx.xx.xx.xx = IP proxy Voip
yy.yy.yy.yy = ip pubblico wan
che è corretta, perché quindi non vuole andare? -.-"
Hai qualche idea di come verificare che combina mmpbx e perché si ubriaca? O credi che mi convenga lasciar perdere ed accontentarmi del mio workaround?

#POSTEDIT
Ho anche appena provato come mi hai suggerito, quindi:
ifup wan
ifup wan2
/etc/init.d/mwan restart
/etc/init.d/mmpbxd reload

ed anche in questo caso il voip non si registra.

[LuKePicci]

Se il workaround regge io mi terrei quello.

La storia dei dns è semplice, tu parti da config/mwan, in cui ha detto che i device in lan devono usare una determinata policy, che a quella policy sia abbinata l'interfaccia wan è irrilevante. In config/dhcp hai detto che il traffico a cui è applicata la policy con quel nome deve usare i dns taggati col dnsset "voip". In config/network non hai nessuna interfaccia i cui dns vengano taggati con dnsset "voip", ergo non hai dns utili per risolvere i nomi, da cui il ko.

Per curiosità, riattiva l'helper per loopback, mantieni la regola hostvoip in mwan e rifai l'ultima prova.

[Marvel]

Se il workaround regge io mi terrei quello.

Il workaround regge alla grande, se wan parte prima di wan2, allora riavvia nuovamente wan ed il voip si registra sempre.
Ci avrei tenuto a sistemare meglio il tutto giusto per una questione di corretta configurazione.

La storia dei dns è semplice, tu parti da config/mwan, in cui ha detto che i device in lan devono usare una determinata policy, che a quella policy sia abbinata l'interfaccia wan è irrilevante. In config/dhcp hai detto che il traffico a cui è applicata la policy con quel nome deve usare i dns taggati col dnsset "voip". In config/network non hai nessuna interfaccia i cui dns vengano taggati con dnsset "voip", ergo non hai dns utili per risolvere i nomi, da cui il ko.

Ok, ok, tutto chiaro.

Per curiosità, riattiva l'helper per loopback, mantieni la regola hostvoip in mwan e rifai l'ultima prova.

Già provato stamattina, ho provato tutte le possibili combinazioni, ma nulla da fare.

Mi sono anche portato nella stessa identica situazione riportata sul wiki di mwan eliminando seconda tabella di routing e regole mwan, manipolando le rotte con uno script ip-up.d ho ottenuto l'equivalente di questo:

Codice: [Seleziona]

# ip route show
default via 10.0.3.2 dev eth1  proto static  src 10.0.3.15  metric 10
default via 10.0.4.2 dev eth2  proto static  src 10.0.4.15  metric 20


Codice: [Seleziona]

# ip route show
default via 192.168.100.1 dev pppoe-wan proto static src $public_ip_wan metric 10
default via 192.168.100.1 dev pppoe-wan2 proto static src $public_ip_wan2 metric 20

In questa condizione sul wiki mwan viene indicato di testare il funzionamento di entrambe le interfacce, nel mio caso funziona solo quella che si avvia per ultima. Noi abbiamo risolto il problema utilizzando la doppia tabella di routing (main e main2) ma la sensazione è che a mmpbx la cosa continua a non piacere.