Ok, allora comincia a rimuovere la rotta rivelatasi inutile, serviva a risolvere un problema che a quanto pare non sussiste.
Da questo momento do per scontato che la regola hostvoip in mwan non sia impostata, quindi da qui in avanti mwan non c'entra nulla col problema del voip.
Per usare lan e lan2 in mmpbx ti riserverebbe l'helper sip per loopback, ma è un tentativo che non porta da nessuna parte.
Il nocciolo della questione, come avevo spiegato a
@nclmrc è che nella stessa tabella main tu hai due regole gateway1 e gateway2 fatte così:
default via 192.168.100.1 dev pppoe-wan2 table main2 proto static metric 20 #default2 tabella main2
local default dev lo table tod scope host
default via 192.168.100.1 dev pppoe-wan proto static metric 10 #default1 tabella main
192.168.0.0/24 dev br-lan2 proto kernel scope link src 192.168.0.1
192.168.1.0/24 dev br-lan proto kernel scope link src 192.168.1.1
192.168.100.1 dev pppoe-wan2 proto kernel scope link src xx.xx.xx.20 #gateway2 tabella main (!!)
192.168.100.1 dev pppoe-wan proto kernel scope link src xx.xx.xx.10 #gateway1 tabella mainQuelle due regole sono nella stessa tabella, portano dalla stessa parte, da due strade diverse, ed hanno la stessa metrica.
Se scendi l'A1 in auto ad un certo punto puoi andare a Roma tramite la panoramica o la direttissima, la gente prende la seconda perchè c'è un cartello segnaletico sul quale è scritto che con quella ci si mette meno tempo. Se la metrica delle due direzioni fosse la stessa, tu avresti il problema di stabilire dal quale passare.
Se io su tiscali tiro su due pppoe diverse su due AC diversi ottengo due gateway diversi, quindi ciascuna delle due default route punta su un gateway distinto, e questo imbarazzo della scelta non sussiste. TIM invece usa lo stesso gateway epr tutte le connessioni, quindi hai due rotte valide nella stessa tabella verso 192.168.100.1
Ho il leggero presentimento che se netifd e l'upscript di ppp impostassero anche quella regola sulla giusta tabella questo problema non si verificherebbe. Siccome questa cosa richiederebbe qualche patch poco confortevole, torniamo al workaround della doppia config di mmpbx
Prendi il file mmpbxrvsipnet, dovresti già avere la definizione parziale di una seconda network, se così non fosse dimmelo che dobbiamo sistemare prima altro. Segnati come si chiama questa seconda, sip_net_1 forse, buttala, duplica di sana pianta la prima sip_net, rinominala con lo stesso nome di quella che hai buttato, mettile come interfaccia wan2, mantieni wan sulla prima, duplica di sana pianta anche il profilo col numero tim chiamato sip_profile_0, rinominalo il duplicato in sip_profile_1 e cancella il sip_profile_1 eventualmente pre-esistente. In teoria una delle due si registrerà sempre, a quel punto dobbiamocontrollare il mapping tra profili e porte FXS.