Bridge tra due interfaccie di rete

[joe]

Mi collego ad internet con una chiavetta su rete mobile TIM.

Il sistema vede l'interfaccia internet come wwan0, quindi non come una connessione dialup ma una specie di connessione di rete.

Ho una seconda interfaccia sul sistema chiamata usb0 e relativa ad uno smartphone android collegato al PC via USB e su cui ho attivato il tethering USB.

Sto cercando di far navigare il telefono usando la connessione del PC. Ma lasciamo un attimo perdere....

In questo topic volevo solo chiedere come si potrebbero accorpare le due interfaccie creando un bridge.

Qui spiega tutta la faccenda, ma la connessione del PC si ipotizza via ethernet su eth0.
http://blog.mathieu.carbou.me/post/6045 ... android-22

Codice: Seleziona tutto

sudo ifconfig eth0 0.0.0.0
sudo ifconfig usb0 0.0.0.0
sudo brctl addbr br0 
sudo brctl addif br0 eth0
sudo brctl addif br0 usb0
sudo ifconfig br0 up
sudo dhclient br0

Ok , dopo questi passaggi io rilevo unicamente una cosa, non si naviga più, e un ping mi restituisce Destination not reachable.

Ecco le interfaccie:

Codice: Seleziona tutto

wwan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::848a:a0ff:fec6:4e68  prefixlen 64  scopeid 0x20<link>
        ether 86:8a:a0:c6:4e:68  txqueuelen 1000  (Ethernet)
        RX packets 535541  bytes 702254045 (669.7 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 383139  bytes 52762605 (50.3 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

usb0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::64:75ff:fe69:107  prefixlen 64  scopeid 0x20<link>
        ether 02:64:75:69:01:07  txqueuelen 1000  (Ethernet)
        RX packets 411  bytes 49881 (48.7 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 829  bytes 118417 (115.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.42.17  netmask 255.255.255.0  broadcast 192.168.42.255
        inet6 fe80::64:75ff:fe69:107  prefixlen 64  scopeid 0x20<link>
        ether 02:64:75:69:01:07  txqueuelen 0  (Ethernet)
        RX packets 76  bytes 12482 (12.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 109  bytes 15385 (15.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Ed ecco l'instradamento:

Codice: Seleziona tutto

# ip r s
default via 192.168.42.129 dev br0 
127.0.0.0/8 dev lo  scope link 
192.168.42.0/24 dev br0  proto kernel  scope link  src 192.168.42.17 

Secondo voi per quale motivo il ping verso tipo 8.8.8.8 restituisce: "Destination Unreachable"?

[Ansa89]

1) Il bridge lo fai usando una interfaccia che (apparentemente) non esiste: eth0.
2) Usando "dhclient br0" dici al pc che l'interfaccia verso internet è br0 (cosa che nel tuo caso non è vera), pertanto ogni richiesta verso la grande rete non potrà essere soddisfatta.

Se vuoi far navigare il cellulare usando la connessione del pc, devi dire al cellulare di usare il tethering usb come connessione dati, poi configurare il pc in modo che giri le richieste provenienti da usb0 su wwan0.
Un'alternativa potrebbe essere trasformare il pc in un access point con hostapd, ma ti serve un'interfaccia wireless supportata.

[joe]

Hai ragione, quanto avevo riportato lì sopra era testualmente ciò che vi è indicato nella guida dove lui aveva internet sulla eth0.
Nel mio caso avevo invece semplicemente sostituito eth0 con wwan0 che è la mia interfaccia (...di rete al pari della classica di eth0, anche se io non sono su ethernet) verso internet.
Avevo attivato il bridge con i seguenti comandi:

Codice: Seleziona tutto

# cat /tmp/android-tools/adbdir/bridgeon.sh 
#!/bin/sh
ifconfig wwan0 0.0.0.0
ifconfig usb0 0.0.0.0
brctl addbr br0 
brctl addif br0 wwan0
brctl addif br0 usb0
ifconfig br0 up
dhclient br0

Purtroppo con l'esito spiegato, cioè neanche dal PC si riesce più a navigare...
E non capisco dove sta il problema...
Teoricamente dovrebbe essere giusto oppure già in partenza c'è qualcosa di errato?
Grazie della risposta!

[Ansa89]

Che procedura/comandi usi normalmente per connetterti a internet usando la chiavetta?

[joe]

Ciao e grazie di nuovo della disponibilità.

La chiavetta internet che uso è una Huawei E353, se non sbaglio la sigla... e può funzionare via PPP, quindi si può configurare la connessione dialup e poi io di solito lanciavo il comando

Codice: Seleziona tutto

pppd call nome_connessione

dove nome_connessione è il nome dello script per pppd:

Codice: Seleziona tutto

/etc/ppp/peers/nome_connessione

Alla fine in quel modo si otteneva l'interfaccia di rete "ppp0".

Invece è da circa una decina di mesi che sono venuto a conoscenza della possibilità di sfruttare una funzionalità diversa, senza PPP. La chiavetta in questione ha anche la funzionalità WWAN (che immagino stia per wireless wide area network) e mette a disposizione un'interfaccia di comunicazione per gestirla accessibile con le libqmi:

Codice: Seleziona tutto

T:  Bus=02 Lev=03 Prnt=05 Port=01 Cnt=01 Dev#=  9 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=12d1 ProdID=1506 Rev=00.00
S:  Manufacturer=Huawei Technologies
S:  Product=HUAWEI Mobile
C:  #Ifs= 7 Cfg#= 1 Atr=c0 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=option
I:  If#= 1 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=01 Prot=09 Driver=qmi_wwan
I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=08 Driver=qmi_wwan
I:  If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=03 Driver=option
I:  If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=02 Driver=option
I:  If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
I:  If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage

Le due interfaccie usb gestite dal driver qmi_wwan sono appunto utilizzabili per lanciare il comando di connessione, che nello specifico era...
Non mi ricordo perchè avevo fatto uno script che lancio così:

Codice: Seleziona tutto

huawei start

E si connette....
Spetta che cerco... Eccolo qua:

Codice: Seleziona tutto

#!/bin/sh

DEV=/dev/cdc-wdm0
IF=wwan0
case $1 in
        start)
                qmi-network ${DEV} stop && \
                qmi-network ${DEV} start && 
                /etc/rc.d/rc.inet1 ${IF}_restart
                ;;
        stop)
                qmi-network ${DEV} stop && \
                /etc/rc.d/rc.inet1 ${IF}_stop || \
                /etc/rc.d/rc.inet1 ${IF}_stop
                ;;
        *)
                cat <<EOF
Usage:
        `basename $0` [start|stop]
EOF
                ;;
esac

Ecco il comando alla fine è "qmi-network start", che è uno script anche quello in definitiva...
Di preciso viene richiamato qmi-cli che è un'utility delle libqmi e ci collega al provider generando l'interfaccia wwan0:

Codice: Seleziona tutto

"qmicli -d $DEVICE --wds-start-network=$APN $USE_PREVIOUS_CID --client-no-release-cid"

Però poi con questo comando non viene attribuito all'interfaccia associata (che è wwan0) l'indirizzo IP. La chiavetta (e non tutte lo fanno) supporta la funzionalità dhcp, quindi a questo punto, instaurata la connessione, si può richiedere al provider l'id via dhcp. Si può usare dhclient, ma nel mio caso ho preferito (non ricordo più bene perchè) configurare il file rc.init1.conf:

Codice: Seleziona tutto

IFNAME[5]="wwan0"
IPADDR[5]=""
NETMASK[5]=""
USE_DHCP[5]="yes"
DHCP_HOSTNAME[5]=""
DHCP_KEEPRESOLV[5]="yes"
DHCP_KEEPNTP[5]="yes"

E lanciare poi da dentro lo script di connessione mostrato sopra (huawei):

Codice: Seleziona tutto

 /etc/rc.d/rc.inet1 wwan0_restart

Fatto questo ottengo l'interfaccia wwan0 collegata ad internet alla quale è assegnato l'IP che mi dà Tim. Quasi sempre è un IP privato 10.qualcosa...
Ad esempio:

Codice: Seleziona tutto

wwan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.196.76.238  netmask 255.255.255.252  broadcast 10.196.76.239
        inet6 fe80::851:b2ff:fe4d:90d3  prefixlen 64  scopeid 0x20<link>
        ether 0a:51:b2:4d:90:d3  txqueuelen 1000  (Ethernet)
        RX packets 9455  bytes 9403057 (8.9 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 9365  bytes 1178816 (1.1 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

L'instradamento verso internet sembra mettersi apposto da se, non devo fare nulla di particolare, ecco come appare il routing:

Codice: Seleziona tutto

default via 10.196.76.237 dev wwan0  metric 203 
10.196.76.236/30 dev wwan0  proto kernel  scope link  src 10.196.76.238  metric 203 
127.0.0.0/8 dev lo  scope link 

Se da tutto questo puoi dire qualcosa di più benvenga...

[Ansa89]

Per come la vedo io, se vuoi usare la connessione del pc per navigare con il cellulare, ti conviene nattare le richieste dello smartphone con iptables:

Codice: Seleziona tutto

** configuri wwan0 normalmente **
# ifconfig usb0 192.168.20.1 up
# echo 1 > /proc/sys/net/ipv4/ip_forward
# iptables -t nat -A POSTROUTING -o wwan0 -j MASQUERADE

Poi devi configurare il cellulare in modo che comunichi con 192.168.20.1 e lo usi come default gateway (e qui non saprei come aiutarti, dato che non ho mai fatto tethering usb ).


PS: i comandi indicati sopra sono stati pensati per un pc senza firewall preconfigurato.

[joe]

Grazie intanto.
L'indirizzo 192.168.20.1 da assegnare all'interfaccia usb0 è solo un esempio dico bene?

Il problema resta comunque dal lato cellulare, dove se non si hanno i privilegi di root non si riesce ad impostare il default gateway. Penso che il nodo della faccenda si a quello...

Bisognerebbe richiedere a chi sviluppa Android di implementare tale possibilità in modo da poter utilizzare il collegamento usb come default gateway, un po' come avviene col reverse tethering over bluetooth, dove vi è una funzione apposita e non servono privilegi di root.
Non saprei così su due piedi come si potrebbe richiedere tale funzionalità, quali siano i canali di comunicazione da utilizzare per parlare con gli sviluppatori android...
Se avete consigli dite pure...

Dal canto mio mi fermo qui. Credo che la cosa più facile sia acquistare una chiavetta wifi e usare il PC come access point, così il cellulare non dovrebbe fare storie. Dico la verità, cerco sempre di evitare il wifi se possibile perchè non si sa mai... meno reti senza fili si hanno intorno e meglio è, per cui quando ci sono alternative, le preferisco.... In questo caso però mi sa che sia la cosa più semplice. In più lo userei solo occasionalmente e non in pianta stabile...

Quanto proponevi però và un po' fuori tema, nel senso che non si lavora più con un bridge in cui si accorpano due interfaccie (delle quali una dispone della connessione internet, cioè wwan0). LA mia domanda nel presente topic invece voleva essere la seguente:

- al di là della connessione sul cellulare, mettendo in bridge wwan0 e usb0 dovrei comunque ancora poter navigare dal PC. Invece la connessione su slackware non funziona più (vedi dettagli in primo e secondo post).
La domanada è perchè?
Cioè mi sta bene che dal cellulare non si riesca a navigare, ma almeno la connessione attraverso il bridge dovrebbe funzionare dal PC... invece qualcosa non funge...
Era questo che continuo a non capire.



PS.
LA soluzione che proponevi sembra molto simile a quello che ho impostato per configurare il reverse tethering via bluetooth. In quel caso però sul cellulare c'è una spunta da selezionare con scritto: "usa questa connessione per i dati". E in quel modo l'interfaccia sul cellulare collegata al PC via bluetooth viene attivata e usata da android come default gateway. Però è appunto una funzione già presente in android e soprattutto fatta apposta per essere usata da semplice utente.
Il riassunto a grandi linee della situazione bluetooth l'avevo sintetizzato nel seguente post di alcuni mesi fà:
http://slacky.eu/forum/viewtopic.php?f= ... p0#p341800

[Ansa89]

L'indirizzo 192.168.20.1 da assegnare all'interfaccia usb0 è solo un esempio dico bene?

Sì.

Il problema resta comunque dal lato cellulare, dove se non si hanno i privilegi di root non si riesce ad impostare il default gateway. Penso che il nodo della faccenda si a quello...

Sì.

Credo che la cosa più facile sia acquistare una chiavetta wifi e usare il PC come access point, così il cellulare non dovrebbe fare storie.

Molto probabilmente sì, dato che questa possibilità è già prevista all'interno di android.
In questo caso potrebbe diventare un po' complicata la configurazione del pc, ma io aspetterei a fasciarmi la testa.

Quanto proponevi però và un po' fuori tema, nel senso che non si lavora più con un bridge in cui si accorpano due interfaccie (delle quali una dispone della connessione internet, cioè wwan0). LA mia domanda nel presente topic invece voleva essere la seguente:

- al di là della connessione sul cellulare, mettendo in bridge wwan0 e usb0 dovrei comunque ancora poter navigare dal PC. Invece la connessione su slackware non funziona più (vedi dettagli in primo e secondo post).
La domanada è perchè?
Cioè mi sta bene che dal cellulare non si riesca a navigare, ma almeno la connessione attraverso il bridge dovrebbe funzionare dal PC... invece qualcosa non funge...
Era questo che continuo a non capire.

Hai ragione, sono andato OT pensando che il problema fosse connettere il cellulare attraverso il pc.
Il motivo per cui non riesci a navigare con il pc è che eseguendo "ifconfig wwan0 0.0.0.0" togli l'ip che TIM aveva assegnato a wwan0, di conseguenza il pc non sa più come accedere a internet.
Per risolvere puoi provare due cose (una esclude l'altra):
- non modificare l'ip di wwan0 quando crei il bridge (ma non so se le interfacce che compongono un bridge possono avere un ip )
- eseguire su br0 la procedura di connessione che normalmente usi per wwan0 (anche in questo caso non ho idea dei possibili risultati)

[joe]

Eseguire su br0 la procedura che uso per collegare wwan0 non mi pare possibile. Perchè wwan0 è un'interfaccia di rete specificatamente associata al modem 3g /dev/cdc-wdm0, i comandi descritti per connettermi attraverso le qmi-utils coinvolgono quel device che và a lavorare sull'interfaccia wwan0, vi è collegato in qualche modo a livello kernel (grazie ai vari drivers in gioco cdc-wdm, cdc-qmi e roba del genere... sto andando a braccio).
Cosa avresti in mente più di preciso?

Non modificando l'ip di wwan0 quando creo il bridge, mi pare abbia poco senso... se ho ben capito il "bridging" di suo richiede per forza il "flush" delle interfaccie coinvolte ed inseguito l'assegnamento dell'IP alla sola interfaccia bridge (esempio br0).
Questo è forse facile da capire se si parla di una connessione di rete con due interfaccia tipo eth0 ed eth1 (dico forse perchè sono ignorante in materia e può essere che non ci abbia capito granchè:
1- le raso con ifconfig 0.0.0.0 (flush)
2- le aggiungo al bridge
3- richiedo al router che sta dietro per esempio eth0 un nuovo indirizzo IP via dhcp assegnandolo a br0 (dhclient br0).

Ma in questo caso quando deconfiguro wwan0 perdo la connesione remota all'ISP. Quando poi eseguo dhclient su br0 a chi sto richiedendo l'IP?

[joe]

Mentre scrivevo m'è venuta in mente una cosa...

Prima di mettere in piedi il bridge conosco l'IP della wwan0, la sua subnet mask e da "ip r" so anche la situazione gateway ecc...
L'idea potrebbe essere:
- deconfiguro wwan0
- deconfiguro usb0
- creo il bridge e vi aggiungo le due sopra
- configuro il bridge con IP/subnet che aveva in precedenza l'interfaccia internet wwan0
- tiro su tutte le interfaccie e configuro l'instradamento aggiungendo il default gateway com'era prima...

Ho provato e la situazione ha funzionato per qualche minuto, il ping funzionava etc...
dopo un po' il default gateway è scomaprso da "ip r s".
bò....
Ad ogni modo può avere qualche senso l'idea?

[Ansa89]

Cosa avresti in mente più di preciso?

Dato che (come hai detto anche tu) le interfacce vanno deconfigurate quando si crea il bridge, pensavo che rieseguendo la procedura su br0 il pc capisse di instradare i pacchetti attraverso wwan0.
Tuttavia ciò non è possibile.

Quando poi eseguo dhclient su br0 a chi sto richiedendo l'IP?

Vado un tanto al braccio: il bridge manda richieste dhcp su tutte le interfacce fisiche che ha a disposizione e aspetta per una risposta.
Nel tuo caso nè wwan0, nè usb0 portano ad un server dhcp, quindi dhclient va in timeout.

Mentre scrivevo m'è venuta in mente una cosa...

Prima di mettere in piedi il bridge conosco l'IP della wwan0, la sua subnet mask e da "ip r" so anche la situazione gateway ecc...
L'idea potrebbe essere:
- deconfiguro wwan0
- deconfiguro usb0
- creo il bridge e vi aggiungo le due sopra
- configuro il bridge con IP/subnet che aveva in precedenza l'interfaccia internet wwan0
- tiro su tutte le interfaccie e configuro l'instradamento aggiungendo il default gateway com'era prima...

Ho provato e la situazione ha funzionato per qualche minuto, il ping funzionava etc...
dopo un po' il default gateway è scomaprso da "ip r s".
bò....
Ad ogni modo può avere qualche senso l'idea?

Non credo sia una strada percorribile: la tua connessione internet è legata ad una configurazione specifica di wwan0.
Pensala così: se prendi un router normale noti che ha quattro porte lan e una porta wan; al suo interno le porte lan sono raggruppate con un bridge, mentre la porta wan è lasciata a se stessa.
Questo serve per avere due reti diverse (la lan che usa ip privati e la connessione ad internet che usa ip pubblici) che comunicano tra loro.

In parole povere: (a meno di configurazioni esotiche) un bridge è come uno switch dove sono collegati clients che utilizzano la stessa rete (es: 192.168.1.0/24). Per far partecipare alla rete anche il pc che fa da switch, devi assegnare un ip valido all'interfaccia di bridge.

[joe]

Guarda, prima di leggere la tua risposta avevo buttato giù uno script che ricalca l'elenco di improbabili operazioni che ho descritto nel post sopra:

Codice: Seleziona tutto

#!/bin/sh
BR=br0
IF1=wwan0
IF2=usb0
IP=$(ip a s $IF1|grep 'inet '|cut -d' ' -f 6)
GW="$(ip r |grep ^default| cut -d' ' -f 1-4)"

up ()   {
        set -x
                # Deconfigurazione interfaccie
                #
                ip link set $IF1 down
                ip link set $IF2 down
                ip addr add 0.0.0.0 dev $IF1
                ip addr add 0.0.0.0 dev $IF2

                # Creazione bridge
                #
                brctl addbr $BR
                brctl addif $BR $IF1
                brctl addif $BR $IF2

                # Riattivazione interfaccie bridge
                #
                ip link set $BR up
                ip link set $IF1 up
                ip link set $IF2 up

                # Assegnazione IP al bridge e configurazione instradamento
                #
                ip addr add $IP dev $BR
                ip route add $GW $BR
}

down () {
                ip link set $IF1 down
                ip link set $IF2 down
                ip link set $BR down
                brctl delbr $BR
                /etc/rc.d/rc.inet1 ${IF1}_restart
        }

case $1 in
        up)
                up
                ;;
        down)
                down
                ;;
        *)
                echo "Usage:     `basename $0` up|down"
                ;;
esac

Io no so spiegare il perchè, come avrete capito non ho mai avuto a che fare con bridge e roba simile.
Ma nella pratica ottengo un'interfaccia br0 collegata ad internet avente lo stesso ip che aveva wwan0 prima di essere deconfigurata.
Anche l'instradamento è stato ricopiato da wwan0 a br0 usando lo stesso gateway.

Alla fine ho il collegamento ad internet funzionante e passante per br0.

Questo non significa che abbia un bridge funzionante per lo scopo... che, lo ricordo, era quello di accorpare le interfaccie wwan0 e usb0 in modo che usb0 condividesse la connessione ad internet di wwan0.
Non posso testare la cosa perchè usb0 è collegata al mio cellulare nel quale non riesco a gestire l'instradamento verso internet perchè non ho i privilegi di root.
Ad ogni modo riassumendo la situazione è la seguente.
All'inizio ho:

Codice: Seleziona tutto

# ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 412  bytes 51040 (49.8 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 412  bytes 51040 (49.8 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wwan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.196.234.244  netmask 255.255.255.248  broadcast 10.196.234.247
        inet6 fe80::38a2:7eff:fe10:2775  prefixlen 64  scopeid 0x20<link>
        ether 3a:a2:7e:10:27:75  txqueuelen 1000  (Ethernet)
        RX packets 34  bytes 11010 (10.7 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 96  bytes 12307 (12.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Codice: Seleziona tutto

 ip r
default via 10.196.234.241 dev wwan0  metric 204 
10.196.234.240/29 dev wwan0  proto kernel  scope link  src 10.196.234.244  metric 204 
127.0.0.0/8 dev lo  scope link 

Codice: Seleziona tutto

# bridging.sh up
+ ip link set wwan0 down
+ ip link set usb0 down
+ ip addr add 0.0.0.0 dev wwan0
+ ip addr add 0.0.0.0 dev usb0
+ brctl addbr br0
+ brctl addif br0 wwan0
+ brctl addif br0 usb0
+ ip link set br0 up
+ ip link set wwan0 up
+ ip link set usb0 up
+ ip addr add 10.196.234.244/29 dev br0
+ ip route add default via 10.196.234.241 dev br0
[root@darkstar ~]# ifconfig
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.196.234.244  netmask 255.255.255.248  broadcast 0.0.0.0
        inet6 fe80::64:75ff:fe69:107  prefixlen 64  scopeid 0x20<link>
        ether 02:64:75:69:01:07  txqueuelen 0  (Ethernet)
        RX packets 29  bytes 8845 (8.6 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 42  bytes 5105 (4.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 449  bytes 55443 (54.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 449  bytes 55443 (54.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

usb0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::64:75ff:fe69:107  prefixlen 64  scopeid 0x20<link>
        ether 02:64:75:69:01:07  txqueuelen 1000  (Ethernet)
        RX packets 4  bytes 312 (312.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 18  bytes 2546 (2.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wwan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 169.254.142.144  netmask 255.255.0.0  broadcast 169.254.255.255
        inet6 fe80::38a2:7eff:fe10:2775  prefixlen 64  scopeid 0x20<link>
        ether 3a:a2:7e:10:27:75  txqueuelen 1000  (Ethernet)
        RX packets 67  bytes 20015 (19.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 161  bytes 20142 (19.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

# ip r
default via 10.196.234.241 dev br0 
10.196.234.240/29 dev br0  proto kernel  scope link  src 10.196.234.244 
127.0.0.0/8 dev lo  scope link 
169.254.0.0/16 dev wwan0  proto kernel  scope link  src 169.254.142.144  metric 204 

# ping -c8 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=53 time=1192 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=53 time=393 ms
64 bytes from 8.8.8.8: icmp_req=3 ttl=53 time=412 ms
64 bytes from 8.8.8.8: icmp_req=4 ttl=53 time=411 ms
64 bytes from 8.8.8.8: icmp_req=5 ttl=53 time=430 ms
64 bytes from 8.8.8.8: icmp_req=6 ttl=53 time=429 ms
64 bytes from 8.8.8.8: icmp_req=7 ttl=53 time=398 ms
64 bytes from 8.8.8.8: icmp_req=8 ttl=53 time=417 ms

--- 8.8.8.8 ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7006ms
rtt min/avg/max/mdev = 393.661/510.721/1192.908/258.124 ms, pipe 2

# brctl show
bridge name	bridge id		STP enabled	interfaces
br0		8000.026475690107	no		      usb0
							                      wwan0

In questo caso il dhcp su wwan0 è in qualche modo intervenuto ma alla fine le ha attribuito un IP particolare (IP4LL), vedo dai log:

Codice: Seleziona tutto

kernel: [ 2619.463174] device wwan0 entered promiscuous mode
kernel: [ 2618.465530] device usb0 entered promiscuous mode
kernel: [ 2618.466703] IPv6: ADDRCONF(NETDEV_UP): br0: link is not ready
dhcpcd[14193]: wwan0: carrier acquired
kernel: [ 2618.469040] br0: port 1(wwan0) entered forwarding state
kernel: [ 2618.469048] br0: port 1(wwan0) entered forwarding state
kernel: [ 2618.469091] IPv6: ADDRCONF(NETDEV_CHANGE): br0: link becomes ready
kernel: [ 2618.471575] br0: port 2(usb0) entered forwarding state
kernel: [ 2618.471582] br0: port 2(usb0) entered forwarding state
dhcpcd[14193]: wwan0: sending IPv6 Router Solicitation
dhcpcd[14193]: wwan0: rebinding lease of 10.196.234.244
dhcpcd[14193]: wwan0: sending IPv6 Router Solicitation
dhcpcd[14193]: wwan0: broadcasting for a lease
dhcpcd[14193]: wwan0: sending IPv6 Router Solicitation
dhcpcd[14193]: wwan0: sending IPv6 Router Solicitation
dhcpcd[14193]: wwan0: no IPv6 Routers available
dhcpcd[14193]: wwan0: probing for an IPv4LL address
dhcpcd[14193]: wwan0: checking for 169.254.142.144
kernel: [ 2633.504008] br0: port 1(wwan0) entered forwarding state
kernel: [ 2633.504027] br0: port 2(usb0) entered forwarding state
kernel: [ 2618.463174] device wwan0 entered promiscuous mode
kernel: [ 2618.465530] device usb0 entered promiscuous mode
kernel: [ 2618.466703] IPv6: ADDRCONF(NETDEV_UP): br0: link is not ready
dhcpcd[14193]: wwan0: carrier acquired
kernel: [ 2618.469040] br0: port 1(wwan0) entered forwarding state
kernel: [ 2618.469048] br0: port 1(wwan0) entered forwarding state
kernel: [ 2618.469091] IPv6: ADDRCONF(NETDEV_CHANGE): br0: link becomes ready
kernel: [ 2618.471575] br0: port 2(usb0) entered forwarding state
kernel: [ 2618.471582] br0: port 2(usb0) entered forwarding state
dhcpcd[14193]: wwan0: sending IPv6 Router Solicitation
dhcpcd[14193]: wwan0: rebinding lease of 10.196.234.244
dhcpcd[14193]: wwan0: sending IPv6 Router Solicitation
dhcpcd[14193]: wwan0: broadcasting for a lease
dhcpcd[14193]: wwan0: sending IPv6 Router Solicitation
dhcpcd[14193]: wwan0: sending IPv6 Router Solicitation
dhcpcd[14193]: wwan0: no IPv6 Routers available
dhcpcd[14193]: wwan0: probing for an IPv4LL address
dhcpcd[14193]: wwan0: checking for 169.254.142.144
kernel: [ 2633.504008] br0: port 1(wwan0) entered forwarding state
kernel: [ 2633.504027] br0: port 2(usb0) entered forwarding state
dhcpcd[14193]: wwan0: using IPv4LL address 169.254.142.144
dhcpcd[14193]: wwan0: broadcasting for a lease
dhcpcd[14193]: wwan0: using IPv4LL address 169.254.142.157
dhcpcd[14193]: wwan0: broadcasting for a lease

La domanda è, cosa mi rappresenta questa situazione?
Ho messo in piedi un bridge funzionante oppure è solo un pasticcio che fa finta di funzionare?
Qualcuno sa spiegarmelo?

[Ansa89]

Questo non significa che abbia un bridge funzionante per lo scopo... che, lo ricordo, era quello di accorpare le interfaccie wwan0 e usb0 in modo che usb0 condividesse la connessione ad internet di wwan0.

Nel tuo caso un bridge non è la soluzione giusta per condividere la connessione ad internet.

In questo caso il dhcp su wwan0 è in qualche modo intervenuto ma alla fine le ha attribuito un IP particolare (IP4LL)

Significa che la richiesta dhcp di wwan0 è scaduta ed è stato assegnato un ip "falso".

Ho messo in piedi un bridge funzionante oppure è solo un pasticcio che fa finta di funzionare?

IMHO è un pasticcio: se lo scopo è condividere la connessione ad internet, devi usare iptables+nat.

[joe]

Capito...
Domandona, quando il bridge può essere effettivamente utilizzato?

[Ansa89]

Detto in parole molto povere: negli stessi casi in cui useresti uno switch.