At 16.12 21/02/2007, Fausto Fornì wrote:
>Ho letto il paragrafo in questione ma non spiega
>l'aspetto mostrato a lezione riguardo il fatto
>che un 802.11/eth bridge non riesce a capire il
>tipo di trama utilizzato (con campo type o length).
>Saprebbe spiegarmi meglio questo aspetto? E il
>fatto che sia stato risolto utilizzato l'incapsulamento?
Il problema non e' CAPIRE il formato della trama.
Questo e' scritto nella trama, ed in particolare
nel campo type se la trama in ingresso e' E2 o nello SNAP se e' RFC1042.
Il problema e' PRESERVARE un incapsulamento
apparentemente illogico all'uscita del tunnel
wireless fatto dal bridging. Perche'
apparentemente illogico? Perche' un bridge
WLAN/ETH che riceve in ingresso sull'interfaccia
WLAN una trama incapsulata SNAP (OBBLIGATORIO)
ovviamente cerchera' di NON usare SNAP
sull'interfaccia ETH, ma cerchera' di usare un
piu' naturale incapsulamento E2 quando possibile.
Poiche' certi protocolli (AARP, etc) IMPONGONO di
avere questop insapculamento "innaturale", c'e'
bisogno di dire all'altro lato del tunnel di
preservare questo incapsulamento. Da cio' la
necessita' di usare un incapsulamento differente
dalL?RFC 1042 nella tratta radio che realizza il tunnel di bridging.
Archivio con motore MhonArc 2.6.16.