L'angolo di Ansuel: ricerca e sviluppo su DGA4130 (AGTEF) & DGA4132 (AGTHP)

  • 2281 Risposte
  • 1127064 Visite

0 Utenti e 4 Visitatori stanno visualizzando questo topic.

Offline nclmrc

  • Membro Anziano
  • ***
  • 246
Secondo me la soluzione più pulita è quella di gestire due tabelle di routing separate usando l'opzione route table in quella del voip.

Offline LuKePicci

  • Global Moderator
  • VIP
  • *****
  • 2789
Mi pare che avessimo fatto proprio così, mettendo ip4table a main sulla route statica verso il proxy.

@Marvel sì, Ansuel ha avuto quelli che technicolor chiama sorgenti del firmware 18.3 basato su linux 4.1. In verità quel pacchetto sorgenti è pià o meno inutile, un qualsiasi toolchain configurato sulla stessa libc e stesso kernel avrebbe generato pacchetti compatibili, ma sempre e solo per applicazioni userspace. Alla fin fine, quello che c'è nei loro sorgenti non ci serve., perchè quello che non siamo in grado di fare senza, non possiamo farlo nemmeno avendoli.

Offline nclmrc

  • Membro Anziano
  • ***
  • 246
io usavo due rotte di default in due routing table distinte, una main per i dati e una voip per la voce. e matchavo l'interfaccia voip nell'interface di mmpbx. così da non dover lavorare sulle statiche. poi sono passato ad asterisk e non sono più riuscito ad indicarli quale tabella utilizzare

Offline LuKePicci

  • Global Moderator
  • VIP
  • *****
  • 2789
Pure qui abbiamo due default in due tabelle diverse, ma quelle che dicono dove raggiungere il gateway sono entrambe nella tabella principale, quindi mmpbx selezionando la seconda wan come interfaccia usava la relativa regola di default nella seconda tabella ma nel tentativo di raggiungere il gateway finiva per uscire sulla prima. Se non hai TIM il problema potresti non notarlo perchè non è detto che il gateway dei due ip assegnati sia il medesimo, e quando non lo è le due default route puntano su interfacce diverse senza ambiguità.

Ripropongo le rotte attive (prima di aggiungere la statica) nel caso di @Marvel da cui si vede il problema.
Codice: [Seleziona]
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 main
 

Non si capisce per quale motivo la regola gateway2 ppp la metta in main invece che in main2 come la default2, se fosse possibile istruirlo a fare diversamente forse si risolve.
« Ultima modifica: 03 Febbraio 2020, 20:46 da LuKePicci »

Offline nclmrc

  • Membro Anziano
  • ***
  • 246
io inoltre avevo cambiato il file mwan mettendo al posto di wan l'interfaccia del voip

Offline nclmrc

  • Membro Anziano
  • ***
  • 246
comunque hai ragione, l'avevo notato anche io la rotta del gateway che andava nella stessa tabella di routing main. una soluzione potrebbe essere mettere una metrica più bassa a quella del voip

Offline LuKePicci

  • Global Moderator
  • VIP
  • *****
  • 2789
Puoi creare una policy di mwan che vincoli mmpbxd su una certa default route (impostando la relativa interfaccia) ma non risolvi il problema, per il medesimo motivo.
La metrica più bassa sulla default route non risolve il problema, come vedi main ha già la metrica più bassa (è lì che vogliamo far andare il voip) e infatti lui riusciva a registrarsi e a funzionare normalmente, ma appena quella rotta ha un problema (disconnette wan ad esempio) interviene l'altra, che rimane attiva fino ad un suo problema. La rotta statica che abbiamo aggiunto in main serve ad evitare ad mmpbx l'imbarazzo della scelta, così facendo usa in modo deterministico la prima wan. Se al posto di due wan dati con lo stesso gateway tu hai una wan e una interfaccia voip e vuoi far andare la fonia sulla seconda allora hai due opzioni: tieni due rotte di default in due tabelle diverse, i gateway non sono in comune quindi la selezione dell'interfaccia in mmbpx è sufficiente; l'altra è tenere solo la default route per wan nella tabella main, disabilitare la default route per voip e aggiungerne una statica per la subnet dei proxy voip verso il gateway (se è statico, ad esempio per tiscali e Vodafone lo è). In questo modo hai una specie di default route che prende solo la subnet della rete sip e mmpbx quando decide come raggiungerli va attraverso di esso. Nel firmware tiscali c'è implementata una cosa a metà tra le due, usa la tabella separata ma non ci mette la default route e va con la statica, per me non ha senso. Lo svantaggio di far funzionare il voip sulla seconda tabella è che poi alcune cose non funzionano normalmente, tipo la risoluzione dei nomi con nslookup o il ping fatto da busybox nella shell del router. I setup di mwan che ho visto su firmware TIM e Tiscali non hanno nessun senso, sono inutili e creano solo problemi, ad esempio se vuoi tenere attive due reti sip su due interfacce diverse. Avrebbe senso dirottare il voip tramite mwan se tutte le interfacce avessero una default route su tabelle distinte con gateway diversi, a quel punto da mwan dici quali classi di ip devono essere raggiunte da dove e allora ha senso. Se vuoi vedere un setup di mwan che abbia senso guarda quello Telia con le quattro reti distinte per dati, voip, iptv telegestione.

Offline Marvel

  • Membro Anziano
  • ***
  • 200
    • Macoers
@LuKePicci , purtroppo ieri ho fatto un'amara scoperta, a causa di un temporale è andata via la connessione internet e di conseguenza il voip, quando la connessione internet è tornata il voip non si è collegato e nel log ritrovo sempre:
Codice: [Seleziona]
SIP Registration: SIP: +39XXXXXXXXXX : Failure Reason: 403 No Roaming Agreement From Current Network XXXXXXXXXXXXXXXX
SIP Registration: SIP: +39XXXXXXXXXX : Deregiste
[MMRVSIPIMPL::REGTERMOBJ]:E: regTermObjFirewallRuleUpdate:4158 - Unable to retrieve currentDestination from SIP network ..
[MMRVSIPIMPL::REGTERMOBJ]:E: registerStateChanged:1422 - statusCode 403

Ho quindi risimulato la situazione, con internet e voip collegati ho staccato e riattaccato il cavo adsl dal router, nel 90% dei casi ho lo stesso problema. Stessa cosa se riavvio manualmente la rete (/etc/init.d/network restart).  Se invece riavvio il router tutto funziona correttamente.

Facendo un test ripristinando la configurazione originale funziona tutto correttamente.

Secondo te possiamo perfezionare ancora qualcosa?
« Ultima modifica: 05 Febbraio 2020, 12:15 da Marvel »

Offline LuKePicci

  • Global Moderator
  • VIP
  • *****
  • 2789
Ha senso, se mmpbx parte mentre wan1 non è ancora online le rotte che gli abbiamo impostato non portano da nessuna parte e lui torna ad usare quelle su wan2 che in mancanza d'altro rappresentano per lui una scelta possibile. Proviamo a scomodare di nuovo mwan. Nota che così facendo mmpbx non funzionerà più su interfacce diverse da wan. Per te non è un problema perchè non hai il voip su rete dedicata.

Il tuo file mwan attuale dovrebbe essere questo:
Codice: [Seleziona]
config globals 'globals'

config policy 'wan_only'
 option interface 'wan'

config policy 'wan2_only'
 option interface 'wan2'

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

config rule 'lan2_wan2'
 option policy 'wan2_only'
 option src 'lan2'

Aggiungi questo:
Codice: [Seleziona]
config host 'hostvoip'
        option path '/usr/bin/mmpbxd'
        option policy 'wan_only'

Teoricamente queste sezioni "host" sono fatte per regolare traffico generato sull'host, quindi non hanno il problema del passare o meno dall'helper come quelle basate su filtri di rete definite in sezioni "rule". Se questa cosa funziona allora puoi anche rimuovere la route statica verso il proxy.
« Ultima modifica: 05 Febbraio 2020, 18:06 da LuKePicci »

Offline Marvel

  • Membro Anziano
  • ***
  • 200
    • Macoers
Il mio mwan al momento è il seguente:

Codice: [Seleziona]
config globals 'globals'

config policy 'if1_mwan'
        option interface 'wan'

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'

config policy 'wan_only'
        option interface 'wan'

config policy 'wan2_only'
        option interface 'wan2'

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

config rule 'lan2_wan2'
        option policy 'wan2_only'
        option src 'lan2'


Le due rule gw*_wan* le abbiamo rimosse quando abbiamo creato le tabelle separate in /etc/iproute2/rt_tables.

#POSTEDIT:
Allora mi sembra di aver capito che tutto dipende dall'ordine in cui si avviano le interfacce.
Controllando con 'logread | grep mwna', quando si avviano con questo ordine, wan come ultima:
Codice: [Seleziona]
Wed Feb  5 16:24:39 2020 user.notice mwan: ifup interface loopback (lo) <string_matching_support enabled>
Wed Feb  5 16:24:46 2020 user.notice mwan: ifup interface wlnet_b_24 (wl0_1) <string_matching_support enabled>
Wed Feb  5 16:24:53 2020 user.notice mwan: ifup interface lan (br-lan) <string_matching_support enabled>
Wed Feb  5 16:24:57 2020 user.notice mwan: ifup interface public_lan (br-lan) <string_matching_support enabled>
Wed Feb  5 16:25:02 2020 user.notice mwan: ifup interface lan2 (br-lan2) <string_matching_support enabled>
Wed Feb  5 16:25:06 2020 user.notice mwan: ifup interface wlnet_b_5 (wl1_1) <string_matching_support enabled>
Wed Feb  5 16:25:10 2020 user.notice mwan: ifup interface wan2 (pppoe-wan2) <string_matching_support enabled>
Wed Feb  5 16:25:15 2020 user.notice mwan: ifup interface wan (pppoe-wan) <string_matching_support enabled
Allora il voip si registra correttamente.

Se si avviano invece con questo ordine, wan2 come ultima:
Codice: [Seleziona]
Wed Feb  5 16:25:53 2020 user.notice mwan: ifup interface loopback (lo) <string_matching_support enabled>
Wed Feb  5 16:26:00 2020 user.notice mwan: ifup interface wlnet_b_24 (wl0_1) <string_matching_support enabled>
Wed Feb  5 16:26:05 2020 user.notice mwan: ifup interface lan (br-lan) <string_matching_support enabled>
Wed Feb  5 16:26:11 2020 user.notice mwan: ifup interface public_lan (br-lan) <string_matching_support enabled>
Wed Feb  5 16:26:15 2020 user.notice mwan: ifup interface lan2 (br-lan2) <string_matching_support enabled>
Wed Feb  5 16:26:20 2020 user.notice mwan: ifup interface wlnet_b_5 (wl1_1) <string_matching_support enabled>
Wed Feb  5 16:26:25 2020 user.notice mwan: ifup interface wan (pppoe-wan) <string_matching_support enabled>
Wed Feb  5 16:26:29 2020 user.notice mwan: ifup interface wan2 (pppoe-wan2) <string_matching_support enabled>
Allora il voip ha problemi a registrarsi.

Ho anche provato a riordinale le interfacce in /etc/config/mwan ed in /etc/config/network, ma non cambia nulla, l'ordine d'avvio è pressocché casuale.

#POSTEDIT2
Si, è sicuro dipende dall'ordine di avvio. Ho provato anche ad impostare mwan come mi hai consigliato ma non cambia nulla.
Qual'è il legame tra mwan e le interfacce in networks? Che pacchetto è l'mwan installato su questo dispositivo? C'è documentazione? Si tratta di un pacchetto standard di openwrt?

#POSTEDIT3
La cosa strana è che se riavvio il router, l'ultima interfaccia a partire è sempre wan e quindi il voip si registra sempre correttamente:
Codice: [Seleziona]
root@DGA4132:~# logread | grep mwan
Wed Feb  5 16:59:38 2020 user.notice mwan: Booting mwan
Wed Feb  5 16:59:45 2020 user.notice mwan: Starting mwan
Wed Feb  5 16:59:49 2020 user.notice mwan: ifdown interface wan () <string_matching_support enabled>
Wed Feb  5 16:59:51 2020 user.notice mwan: ifdown interface wan () <string_matching_support enabled>
Wed Feb  5 16:59:51 2020 daemon.notice procd: /etc/rc.d/S21mwan:    16   966 CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0            CONNMARK restore mask 0xf0000000
Wed Feb  5 16:59:51 2020 daemon.notice procd: /etc/rc.d/S21mwan:     0     0 CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0            mark match ! 0x0/0xf0000000 CONNMARK save mask 0xf0000000
Wed Feb  5 16:59:51 2020 daemon.notice procd: /etc/rc.d/S21mwan:    16   966 mwan_pre   all  --  *      *       0.0.0.0/0            0.0.0.0/0
Wed Feb  5 16:59:51 2020 daemon.notice procd: /etc/rc.d/S21mwan:     2   129 mwan_output  all  --  *      *       0.0.0.0/0            0.0.0.0/0
Wed Feb  5 16:59:51 2020 daemon.notice procd: /etc/rc.d/S21mwan:     0     0 CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctdir ORIGINAL connmark match ! 0x0/0xf0000000 CONNMARK restore mask 0xf0000000
Wed Feb  5 16:59:52 2020 user.notice mwan: ifdown interface wan2 () <string_matching_support enabled>
Wed Feb  5 16:59:52 2020 daemon.notice procd: /etc/rc.d/S21mwan:    21  1556 CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0            CONNMARK restore mask 0xf0000000
Wed Feb  5 16:59:52 2020 daemon.notice procd: /etc/rc.d/S21mwan:     3   474 CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0            mark match ! 0x0/0xf0000000 CONNMARK save mask 0xf0000000
Wed Feb  5 16:59:52 2020 daemon.notice procd: /etc/rc.d/S21mwan:    21  1556 mwan_pre   all  --  *      *       0.0.0.0/0            0.0.0.0/0
Wed Feb  5 16:59:52 2020 daemon.notice procd: /etc/rc.d/S21mwan:     5   332 mwan_output  all  --  *      *       0.0.0.0/0            0.0.0.0/0
Wed Feb  5 16:59:52 2020 daemon.notice procd: /etc/rc.d/S21mwan:     0     0 CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctdir ORIGINAL connmark match ! 0x0/0xf0000000 CONNMARK restore mask 0xf0000000
Wed Feb  5 16:59:53 2020 user.notice mwan: ifup interface loopback (lo) <string_matching_support enabled>
Wed Feb  5 17:00:06 2020 user.notice mwan: ifup interface lan (br-lan) <string_matching_support enabled>
Wed Feb  5 17:00:21 2020 user.notice mwan: ifup interface public_lan (br-lan) <string_matching_support enabled>
Wed Feb  5 17:00:37 2020 user.notice mwan: ifup interface lan2 (br-lan2) <string_matching_support enabled>
Wed Feb  5 17:00:44 2020 user.notice mwan: ifup interface wlnet_b_24 (wl0_1) <string_matching_support enabled>
Wed Feb  5 17:00:48 2020 user.notice mwan: ifup interface wlnet_b_5 (wl1_1) <string_matching_support enabled>
Wed Feb  5 17:00:55 2020 user.notice mwan: ifup interface wan2 (pppoe-wan2) <string_matching_support enabled>
Wed Feb  5 17:08:43 2020 user.notice mwan: ifup interface wan (pppoe-wan) <string_matching_support enabled>

Se invece riavvio la rete (/etc/init.d/network restart) o simulo una perdita di connessione staccando e riattaccando il cavo di rete, allora l'ordine di avvio è casuale e quando l'ultima interfaccia ad avviarsi è wan2 allora il voip non si registra.
So che questa differenza di comportamento è strana, ma è così.
« Ultima modifica: 05 Febbraio 2020, 17:23 da Marvel »

Offline LuKePicci

  • Global Moderator
  • VIP
  • *****
  • 2789
Alt, le regole gw è vero le avevamo rimosse, ma le altre perchè ce le avevi ancora?

Tieni in mwan tutto quello che ha ora meno le due regole if1_e ed if1_f, non c'entrano niente con quello che stiamo facendo, dirottano su wan il traffico non proveniente dal router destinato a quelle porte. La sezione hostvoip ce l'hai già quindi tienitela buona, fai delle prove con e senza e vedi se togliendola anche dopo il riavvio funziona in modo casuale.

La documentazione di mwan non esiste, è un pacchetto proprietario di tch ma è fatto di script quindi puoi esaminarlo, non è molto diverso da mwan3.

Offline Marvel

  • Membro Anziano
  • ***
  • 200
    • Macoers
Dalle prove fatte avevamo visto che le due regole if1_e ed if1_f,  né ci aiutavano, né ci danneggiavano.
Ho comunque già provato a rimuoverle ed ho testato con e senza la sezione hostvoip, ma il risultato non cambia. Se l'ultima interfaccia ad avviarsi e wan allora il voip si registra, altrimenti non riesce e mi da l'errore che ho riportato prima.
Se solo riuscissi ad alterare e fissare l'ordine di boot delle interfacce allora avrei risolto.

Oltre alle metriche, qui si parla anche di peso:
https://github.com/bertrandmartel/openwrt-mwan-config/blob/master/README.md
ma da quanto ho capito serve per il balancer, ho infatti effettuato qualche test e per ciò che serve a me il peso sembra inutile.

Offline Edoardo396

  • Nuovo Iscritto
  • *
  • 8
Salve, qualcuno è riuscito / ha notizie sull'ipv6 per AGTEF? ho visto che è comparsa l'impostazione nella sezione relativa al PPP ma se l'attivo la linea non funziona.
Ho anche provato a impostare sul PPP username e passwd di TIm ma nulla.
Qualcuno ha notizie?

Offline Marvel

  • Membro Anziano
  • ***
  • 200
    • Macoers
Salve, qualcuno è riuscito / ha notizie sull'ipv6 per AGTEF? ho visto che è comparsa l'impostazione nella sezione relativa al PPP ma se l'attivo la linea non funziona.
Ho anche provato a impostare sul PPP username e passwd di TIm ma nulla.
Qualcuno ha notizie?
Non mi sembra ci siano novità, al momento non funziona. Se non sbaglio su github puoi trovare più informazioni.

Alt, le regole gw è vero le avevamo rimosse, ma le altre perchè ce le avevi ancora?

Tieni in mwan tutto quello che ha ora meno le due regole if1_e ed if1_f, non c'entrano niente con quello che stiamo facendo, dirottano su wan il traffico non proveniente dal router destinato a quelle porte. La sezione hostvoip ce l'hai già quindi tienitela buona, fai delle prove con e senza e vedi se togliendola anche dopo il riavvio funziona in modo casuale.

La documentazione di mwan non esiste, è un pacchetto proprietario di tch ma è fatto di script quindi puoi esaminarlo, non è molto diverso da mwan3.
Rettifico quanto detto prima, dopo molti test anche con un riavvio del router può capitare che wan2 sia l'ultima a partire e quando questo accade il voip non si registra.
Sembra quindi che la regola in /etc/config/networks non funzioni:
Codice: [Seleziona]
config route 'voip_tim'
        option interface 'wan'
        option table 'main'
        option netmask '255.255.255.255'
        option metric '10'
        option target '85.38.239.101'
        option gateway 'IP_DEL_GATEWAY_VOIP'

Inoltre ho notato che durante il processo di avvio delle interfacce, quando wan2 parte per ultima, vedo:
Codice: [Seleziona]
netdev path : ppp0 -> wanptm0 -> ptm0
pppoe-wan2: renamed from ppp0
netdev path : ppp1 -> wanptm0 -> ptm0
pppoe-wan: renamed from ppp1
ed in questo caso non funziona il voip.
Quando invece l'ultima a partire è wan, ho:
Codice: [Seleziona]
netdev path : ppp1 -> wanptm0 -> ptm0
pppoe-wan2: renamed from ppp1
netdev path : ppp0 -> wanptm0 -> ptm0
pppoe-wan: renamed from ppp0
Non credo di poter far nulla per alterare questo comportamento, non credo c'entri mwan.

Offline LuKePicci

  • Global Moderator
  • VIP
  • *****
  • 2789
La route statica serve ad evitare che una volta entrato in condizione funzionante smetta di farlo, nell'ipotesi che senza disconnessioni ad un tratto passasse ad usare l'altra route verso il gateway, che è anch'essa nella tabella principale. Non mi è chiaro però se l'altra volta quando mi hai detto che smetteva di funzionare era per via di disconnessioni o meno. Nel primo caso quella route allora forse è del tutto inutile.

Stavo invece pensando ad un modo di aggirare totalmente il problema. Se lasciassimo che mmpbx tenti di registrare simultaneamente lo stesso numero su wan e wan2 in teoria a seconda di quale interfaccia parte per prima una volta funziona solo la prima, l'altra funziona solo la seconda. Di sicuro quella regola hostvoip e il fatto di aver scelto wan come interfaccia in mmpbx stanno impedendo ad mmpbx di funzionare su wan2, da qui l'errore che vedi riguardo la "current destination from SIP network", vuol dire semplicemente che sta cercando di raggiungere il proxy da un'interfaccia che mwan non gli consente di usare.

L'altra cosa da provare è spostare quella route onlink che finisce nella tabella sbagliata nella seconda tabella. La causa pare sia il mancato supporto in netifd alla gestione del parametro ip4table, o meglio, netifd ne tiene conto ma non offre all'upscript di ppp la possibilità di farlo. https://patchwork.ozlabs.org/patch/523296/