porta udp 5060 in uscita
Trip65
traffico upd da un pc in rete fastweb verso un server (quindi porta in
uscita) SIP siano cappate/menomate se non addirittura bloccate ?
MarcoGE
ha scritto su it.tlc.gestori.fastweb :
> Qualcuno ha effettuato test e prove che porterebbero a concludere che il
> traffico upd da un pc in rete fastweb verso un server (quindi porta in
> uscita) SIP siano cappate/menomate se non addirittura bloccate ?
cioè vuoi sapere se si possono usare telefoni IP od ATA SIP con
FastWeb?
Ho capito bene?
--
Un'importante *precisazione* sui tagli di ricarica Vodafone
su http://marcoge.splinder.com
Trip65
> *Trip65* <trip65#leva#@wappi.com> il giovedì 10/01/2008 alle 14.31.04 ha
> scritto su it.tlc.gestori.fastweb :
>
>> Qualcuno ha effettuato test e prove che porterebbero a concludere che
>> il traffico upd da un pc in rete fastweb verso un server (quindi porta
>> in uscita) SIP siano cappate/menomate se non addirittura bloccate ?
>
> cioè vuoi sapere se si possono usare telefoni IP od ATA SIP con FastWeb?
> Ho capito bene?
>
Non esattamente . Semplicemente noto che utilizzando un particolare
telefono ip con connettività fastweb fibra , il comportamento dello
stesso cambia a seconda di :
1) Se collegato direttamente alla cpe/hag (no audio in tx)
2) Se collegato tramite ulteriore NAT (funzionamento impeccabile)
3) Perchè il medesimo apparato, che presenta problematiche sulle
chiamate in uscita (audio muto), quando collegato direttamente alla cpe
quando chiama un SIP sulla 5060 , scompaiono e tutto va bene quando
chiamano un fornitore SIP che da' il servizio sulla 5061.
MarcoGE
16.08.49 ha scritto su it.tlc.gestori.fastweb :
> Non esattamente . Semplicemente noto che utilizzando un particolare telefono
> ip con connettività fastweb fibra , il comportamento dello stesso cambia a
> seconda di :
> 1) Se collegato direttamente alla cpe/hag (no audio in tx)
> 2) Se collegato tramite ulteriore NAT (funzionamento impeccabile)
> 3) Perchè il medesimo apparato, che presenta problematiche sulle chiamate in
> uscita (audio muto), quando collegato direttamente alla cpe quando chiama un
> SIP sulla 5060 , scompaiono e tutto va bene quando chiamano un fornitore SIP
> che da' il servizio sulla 5061.
Boh, io ho un ATA (PAP2) sulla 5060 (e così pure il softphone) e tutto
va bene (GE, ADSL 6Mb -alla faccia di MS-)
Trip65
>
> Boh, io ho un ATA (PAP2) sulla 5060 (e così pure il softphone) e tutto
> va bene (GE, ADSL 6Mb -alla faccia di MS-)
Confermi la che l'ATA è collegato direttamente alla cpe e ha un ip
fastweb nel tuo caso 5.x.x.x ?
>
MarcoGE
confermo, ha IP 5.XXX.XX.X33 (ho pure creato un collegamento sul
desktop per eventuali modifiche degli account)
Trip65
> confermo, ha IP 5.XXX.XX.X33 (ho pure creato un collegamento sul desktop
> per eventuali modifiche degli account)
>
A questo punto mi dici marca e modello cosi' do' un'occhiata al manuale
e ai settaggi vari che ha ?
MarcoGE
> A questo punto mi dici marca e modello cosi' do' un'occhiata al manuale e ai
> settaggi vari che ha ?
Linksys PAP2 configurato con due account EuteliaVoip (in passato ho
usato anche sipdiscount ma non con gran soddisfazione):
http://tinyurl.com/3xj4fq
Trip65
> Linksys PAP2 configurato con due account EuteliaVoip (in passato ho
> usato anche sipdiscount ma non con gran soddisfazione):
> http://tinyurl.com/3xj4fq
Setaggi piu' o meno identici a quelli da me utilizzati sull'ip phone..
Non mi rimane che andare di tcpdump e fare confronti quando uso il
softphone e l'ip phone
Putroppo non è possibile spoofare il mac mannaggia, sarebbe stato
interessante
massimo
> Putroppo non è possibile spoofare il mac mannaggia
Perchè no?!
Trip65
> Trip65 <trip65#ver#@superspam.net> wrote:
>
>> Putroppo non è possibile spoofare il mac mannaggia
>
> Perchè no?!
Intendo che non è possibile cambiare mac al telefono , ovviamente posso
fare il contrario , assegnarlo al pc e vedere se il difetto si rigira.
Bisogna partire dal concetto : perchè se natto il telefono va tutto,
cosa cambia oltre al mascheramento (ininfluente) dell'ip ?
lorenzodes
> Intendo che non è possibile cambiare mac al telefono , ovviamente posso
> fare il contrario , assegnarlo al pc e vedere se il difetto si rigira.
> Bisogna partire dal concetto : perchè se natto il telefono va tutto,
> cosa cambia oltre al mascheramento (ininfluente) dell'ip ?
Se hai un linux box, settalo in modalità bridge piuttosto che in NAT e
sniffa il traffico del telefono.
Marc Serafino
>> Non esattamente . Semplicemente noto che utilizzando un particolare telefono
>> ip con connettività fastweb fibra , il comportamento dello stesso cambia a
>> seconda di :
>> 1) Se collegato direttamente alla cpe/hag (no audio in tx)
>> 2) Se collegato tramite ulteriore NAT (funzionamento impeccabile)
>> 3) Perchè il medesimo apparato, che presenta problematiche sulle chiamate in
>> uscita (audio muto), quando collegato direttamente alla cpe quando chiama un
>> SIP sulla 5060 , scompaiono e tutto va bene quando chiamano un fornitore SIP
>> che da' il servizio sulla 5061.
>
> Boh, io ho un ATA (PAP2) sulla 5060 (e così pure il softphone) e tutto
> va bene (GE, ADSL 6Mb -alla faccia di MS-)
Alla faccia mia? Sai che ne ne frega a me visto che Fastweb non e' il mio
unico provider e che per altro il VOIP con Fastweb a me funziona
perfettamente. Solo non ho ancora provato a connettere l'IP301 o un PAP
direttamente alla CPE.
Marc Serafino
Guarda Trip che un PAP non e' esattamente come un telefono. Ha un IP e uno
strato di NAT pure lui. Quindi ovvio che vada.
Trip65
Guarda Trip che un PAP non e' esattamente come un telefono. Ha un IP e uno
> strato di NAT pure lui. Quindi ovvio che vada.
Ma lui dice che ha preso un ip 5.x.x.x della rete Genovese Fastweb ,
esattamente come succederebbe al telefono 301 (che per altro ha anche
lui la parte lan con nat ).
Visto che pare tu lo abbia, quando ti capita , collegalo alla cpe e
prova a chiamare : vedrai che il telefono del corrispondente suona , ma
tu non senti nulla, neanche il segnale di libero.
Trip65
Sto provando ma ho delle difficoltà senza scompigliare la lan.
Nel frattempo basta google : ip-301+fastweb+eutelia .
Non si puo' a questo punto negare che il problema non esista e dire che
va tutto bene.
MarcoGE
ha scritto su it.tlc.gestori.fastweb :
> Ma lui dice
http://img27.picoodle.com/img/img27/4/1/11/f_pap2m_2bac661.jpg
MarcoGE
23.18.51 ha scritto su it.tlc.gestori.fastweb :
> Alla faccia mia? Sai che ne ne frega a me
vista la crociata personale che svolgi contro FastWeb...
Onestamente io non comprendo nè chi difende un gestore/negozio/servizio
ad ogni costo ma neppure chi, al contrario, si fa in quattro per
denigrarlo.
Io con FW mi trovo bene *ora*, se la situazione muterà cambierò
gestore.
Non inondo it.economia.banche nè con messaggi di lode per la mia
attuale banca nè con crociate contro la precedente (che peraltro mi
spennava in un modo feroce)
quaqo
> Ma lui dice che ha preso un ip 5.x.x.x della rete Genovese Fastweb ,
> esattamente come succederebbe al telefono 301 (che per altro ha anche
> lui la parte lan con nat ).
> Visto che pare tu lo abbia, quando ti capita , collegalo alla cpe e
> prova a chiamare : vedrai che il telefono del corrispondente suona , ma
> tu non senti nulla, neanche il segnale di libero.
Stai usando uno STUN ?
--
Saluti, Federico
http://www.quaqo.org
lorenzodes
> Sto provando ma ho delle difficoltà senza scompigliare la lan.
> Nel frattempo basta google : ip-301+fastweb+eutelia .
> Non si puo' a questo punto negare che il problema non esista e dire che
> va tutto bene.
Dalla tua descrizione del problema non mi pare che si possa trattare
di un semplice caso di "porta chiusa". Mi pare più probabile qualche
giochino sul MAC address (cosa ancora più "sporca" e scorretta IMHO).
Conte Frobenius
Il SIP dietro NAT ha bisogno semplicemente di alcuni workaround per
sapere qual è il suo indirizzo pubblico e fare hole-punching del firewall
(tipicamente lo stun server risolve tutto).
Ma tutto sta se il telefono si accorge di averne bisogno o no. Magari il
tuo telefono con IP 192.168.x.x capisce al volo che è NAT-tato, mentre
con IP di MAN di Fastweb "pensa" stupidamente di essere in rete e non usa
lo stun. Puoi dumpare il traffico?
Comunque non sono i telefoni SIP che hanno questo problema del "non
funziona sull'HAG ma funziona se c'è un secondo NAT di mezzo". Anche
giochi online come PES 2008 su Playstation 3 hanno gli stessi sintomi.
La prova del nove è cambiare il DHCP (lato LAN ovviamente) del tuo router
e fare assegnare indirizzi con classe tipo 1.x.x.x. Vedi se cambia
qualcosa o no.
--
Conte Frobenius
Trip65
"quaqo" <ntp_at_q...@quaqo.invalid> ha scritto nel messaggio
news:2058366.b...@quaqo.org...
Allora , lo stun è impostato , quanto ad non usarlo o usarlo , devo fare un
dump del traffico.
Forse appunto non viene usato quando il telefono trova un ip non idoneo per
le reti private.
Questa cosa unita al fatto, che , ad alcuni funziona , potrebbe essere un
indizio.
Trip65
> e fare assegnare indirizzi con classe tipo 1.x.x.x. Vedi se cambia
> qualcosa o no.
> --
> Conte Frobenius
Bingo !!! Non va !!!
Non piacciono questi ip fastweb al telefono in questione.
Ecco perchè il softphone va e anche altri telefoni
Ed è probabile che non abiliti lo stun , l'effetto è il medesimo qualora
dietro nat lo disattivassi.
Trip65
"lorenzodes" <loren...@fastwebnet.it> ha scritto nel messaggio
news:kcak55x...@news.nixstation.ltd...
No, ho usato quel mac sul softphone e va, ma forse adesso abbiamo centrato
il problema.
Quel firmware non attiva lo stun se il telefono ha un ip di una classe
ritenuta pubblica e non lan .
Ecco cosa succede ad usare ip illeciti....
Trip65
sono problemi, forse lo stun qua non serve , si vede che qualche malefatta
sulla 5060 la fanno comunque evidentemente
Conte Frobenius
>> La prova del nove cambiare il DHCP (lato LAN ovviamente) del tuo
>> router e fare assegnare indirizzi con classe tipo 1.x.x.x. Vedi se
>> cambia qualcosa o no.
>> --
>> Conte Frobenius
>
>
> Bingo !!! Non va !!!
> Non piacciono questi ip fastweb al telefono in questione. Ecco perch il
> softphone va e anche altri telefoni Ed probabile che non abiliti lo
> stun , l'effetto il medesimo qualora dietro nat lo disattivassi.
Benissimo, hai appena verificato che si tratta di un bel bug software del
telefono, comunque.
--
Conte Frobenius
Conte Frobenius
5061 non è una porta standard, quindi può darsi che sia un altro
"suggerimento" che il telefono interpreta come "c'è qualcosa di strano in
questa rete dove sono attaccato, meglio ricorrere allo STUN!". Da degli
idioti che hanno programmato un software che si affida alla classe
dell'IP per fare una scelta del genere, non possiamo dare nulla per
scontato! :P
In questo caso, la prova finale la ottieni solo dumpando il traffico;
penso che il sistema più facile sia procurarsi uno switch ethernet di
quelli piccolini a 4-8 porte, attaccarci telefono, router, e PC, e poi
dumpare il traffico usando la modalità promiscua.
--
Conte Frobenius
Marc Serafino
>> Bingo !!! Non va !!!
>> Non piacciono questi ip fastweb al telefono in questione. Ecco perch il
>> softphone va e anche altri telefoni Ed probabile che non abiliti lo
>> stun , l'effetto il medesimo qualora dietro nat lo disattivassi.
>
> Benissimo, hai appena verificato che si tratta di un bel bug software del
> telefono, comunque.
Veramente si tratta di abuso da parte di Fastweb nell'utilizzo di subnet
non assegnategli dal RIPE che il telefono rietiene _giustamente_ pubbliche.
Marc Serafino
Sono le conseguenze all'utilizzo di IP ritenuti pubblici e mai assegnati
dal RIPE che il telefono correttamente interpreta come indirizzi Internet e
non locali non attivando lo STUN.
Conte Frobenius
Sì è vero. Se Fastweb avesse rispettato le classi "ufficiali" sicuramente
questo problema non ci sarebbe stato.
Ma questo non rende il telefono meno colpevole neppure dell'uno per mille
Il protocollo del NAT ovviamente non parla di convenzioni di assegnamento
di classi di IP decise dall'ICANN per la rete Internet. Un software che
implementa i protocolli non dovrebbe basarsi anche su convenzioni
(seppure a livello mondiale) perché starebbe travisando i livelli di
definizione.
Ti faccio un esempio: io posso costruire un intera Intranet totalmente
scollegata da Internet (al 100%). Molte aziende business hanno reti del
genere. All'interno di questa rete (che chiamo Intranet perché basata su
protocolli IP e TCP), posso assegnare gli indirizzi IP come meglio mi
pare, perché non devo rispettare le assegnazioni ICANN per interoperare
con Internet. E all'interno di questa rete, un software che assume che
"essere dietro NAT" vuol dire avere una classe di IP tipo "192.168.x.x.",
sicuramente avrà problemi.
Quindi riassumendo: il software è buggato perché dà per vera una
convenzione che comunque Fastweb non avrebbe dovuto violare.
--
Conte Frobenius
Blak
> Sì è vero. Se Fastweb avesse rispettato le classi "ufficiali" sicuramente
> questo problema non ci sarebbe stato.
ah ecco... <eg>
> Ma questo non rende il telefono meno colpevole neppure dell'uno per mille
> Il protocollo del NAT ovviamente non parla di convenzioni di assegnamento
> di classi di IP decise dall'ICANN per la rete Internet. Un software che
> implementa i protocolli non dovrebbe basarsi anche su convenzioni
> (seppure a livello mondiale)
rfc... banali convenzioni a livello mondiale. O forse intendi usarlo sulla
luna?
> Ti faccio un esempio: io posso costruire un intera Intranet totalmente
> scollegata da Internet (al 100%). Molte aziende business hanno reti del
> genere. All'interno di questa rete (che chiamo Intranet perché basata su
> protocolli IP e TCP), posso assegnare gli indirizzi IP come meglio mi
> pare, perché non devo rispettare le assegnazioni ICANN per interoperare
> con Internet. E all'interno di questa rete, un software che assume che
> "essere dietro NAT" vuol dire avere una classe di IP tipo "192.168.x.x.",
> sicuramente avrà problemi.
Peccato che la rete Fastweb sia connessa ad Internet
> Quindi riassumendo: il software è buggato
se fosse buggato sarebbe appunto difettoso, ovvero avrebbe comportamenti
diversi da quelli previsti. Semmai è la mancanza di una feature il
problema.
Blak
>> Ti faccio un esempio: io posso costruire un intera Intranet totalmente
>> scollegata da Internet (al 100%). Molte aziende business hanno reti del
>> genere. All'interno di questa rete (che chiamo Intranet perché basata su
>> protocolli IP e TCP), posso assegnare gli indirizzi IP come meglio mi
>> pare, perché non devo rispettare le assegnazioni ICANN per interoperare
>> con Internet. E all'interno di questa rete, un software che assume che
>> "essere dietro NAT" vuol dire avere una classe di IP tipo "192.168.x.x.",
>> sicuramente avrà problemi.
>
> Peccato che la rete Fastweb sia connessa ad Internet
Ma soprattutto un NAT in una rete come quella descritta da te non ha motivo
di esistere.
Conte Frobenius
>> Quindi riassumendo: il software è buggato
>
> se fosse buggato sarebbe appunto difettoso, ovvero avrebbe comportamenti
> diversi da quelli previsti. Semmai è la mancanza di una feature il
> problema.
Chiamalo come ti pare, ma il telefono ha colpa tanto quanto Fastweb. A me
non sarebbe passato neppure per l'anticamera del cervello di scrivere del
codice tanto stupido che guarda la classe di IP per capire che succede.
E' segno di grossa incompetenza comunque.
--
Conte Frobenius
Blak
> On Sat, 12 Jan 2008 16:46:52 +0100, Blak wrote:
>
>> se fosse buggato sarebbe appunto difettoso, ovvero avrebbe comportamenti
>> diversi da quelli previsti. Semmai è la mancanza di una feature il
>> problema.
>
> Chiamalo come ti pare,
Non lo chiamo come mi pare, non chiamo il mio cane "gatto" e il mio gatto
"cane", così come non ti chiamo "scemo" se intendo dire che sei
intelligente "intelligente" (o era il contrario?!). Questo non tanto per
far polemica gratuita ma per dire che "chiamalo come ti pare" non è
un'argomentazione.
> ma il telefono ha colpa tanto quanto Fastweb.
Nella peggiore delle ipotesi si, siamo d'accordo, ma dipende dai punti di
vista.
> A me
> non sarebbe passato neppure per l'anticamera del cervello di scrivere del
> codice tanto stupido che guarda la classe di IP per capire che succede.
> E' segno di grossa incompetenza comunque.
Questa frase è segno di grossa incompetenza. E' una scelta progettuale,
condivisibile o meno, così come lo è quella di fastweb (perchè secondo il
tuo modo di pensare allora anche la rete fastweb è "buggata" e fatta da
incompetenti).
PS per Trip: hai appena verificato che si tratta di un bel bug di fastweb,
comunque. (semicit.)
Conte Frobenius
>> A me
>> non sarebbe passato neppure per l'anticamera del cervello di scrivere
>> del codice tanto stupido che guarda la classe di IP per capire che
>> succede. E' segno di grossa incompetenza comunque.
>
> Questa frase è segno di grossa incompetenza. E' una scelta progettuale,
> condivisibile o meno, così come lo è quella di fastweb (perchè secondo
> il tuo modo di pensare allora anche la rete fastweb è "buggata" e fatta
> da incompetenti).
E' una scelta progettuale non basata esclusivamente sulla definizione dei
protocolli sui quali si appoggia (NAT, STUN, o SIP), ma anche su
un'assunzione esterna storica che potrebbe essere modificata (cioè
l'assegnazione corrente di IP stabilito dall'ICANN).
Ti faccio una domanda: supponi che domani, per un qualunque motivo,
l'ICANN decide che la classe 2.x.x.x (non assegnata) deve diventare una
classe dedicata alle rete locali come la 192.168.x.x. E' nel suo potere
farlo (e ci sono state in questo senso anche mozioni da gruppi di ISP che
si basano su NAT che hanno bisogno di più classi di IP). Ecco che il
software del nostro telefono, per come è stato progettato non funzionerà
correttamente con quella classe.
Ogni volta che l'ICANN compierà una scelta su una classe non assegnata,
Fastweb dovrà correre ai ripari (colpa loro) e i programmatori di quel
telefono dovranno fare altrettanto (colpa loro).
Io non ci vedo molte differenze. Assumere che il caso di NAT è limitato a
10.x.x.x o 192.168.x.x. è sbagliato esattamente come usare per il NAT
classi reserved. E' lo stesso errore dall'altra parte dello specchio.
Sulle classi non assegnati non si può assumere nulla proprio perché sono
non assegnate.
--
Conte Frobenius
Blak
> Ti faccio una domanda: supponi che domani, per un qualunque motivo,
> l'ICANN decide che la classe 2.x.x.x (non assegnata) deve diventare una
> classe dedicata alle rete locali come la 192.168.x.x.
supponiamo che gli asini volino...
> E' nel suo potere
> farlo
Sicuramente. Perchè dovrebbe ha invece una risposta molto più difficile da
trovare.
> (e ci sono state in questo senso anche mozioni da gruppi di ISP che
> si basano su NAT che hanno bisogno di più classi di IP).
ISP che hanno queste necessità farebbe meglio a dedicarsi a qualcos'altro.
> Ecco che il
> software del nostro telefono, per come è stato progettato non funzionerà
> correttamente con quella classe.
Nell'ingegneria la parola d'ordine è ragionevolezza. Non è una soluzione
particolarmente brillante, ma ragionevole in un mondo reale e non fatto di
ipotesi fantasiose. Poi c'è fastweb, che va oltre ogni immaginazione.
> Ogni volta che l'ICANN compierà una scelta su una classe non assegnata,
> Fastweb dovrà correre ai ripari (colpa loro) e i programmatori di quel
> telefono dovranno fare altrettanto (colpa loro).
Si ma con due grosse differenze:
- la probabilità che l'ICANN rilasci una nuova classe ad uso privato è
tendente a 0 mentre la probabilità che IANA assegni le ultime classi
rimaste ai RIR tende a 1.
- con le scelte fatte la probabilità che chi ha comprato il telefono non
riesca ad usarlo per colpa di queste, in tutto il mondo, è bassa, molto
bassa. Approssimando: funziona.
Se poi vogliamo parlare di congiunzioni astrali ti lascio continuare da
solo.
Conte Frobenius
>> Ogni volta che l'ICANN compierà una scelta su una classe non assegnata,
>> Fastweb dovrà correre ai ripari (colpa loro) e i programmatori di quel
>> telefono dovranno fare altrettanto (colpa loro).
>
> Si ma con due grosse differenze:
> - la probabilità che l'ICANN rilasci una nuova classe ad uso privato è
> tendente a 0 mentre la probabilità che IANA assegni le ultime classi
> rimaste ai RIR tende a 1.
> - con le scelte fatte la probabilità che chi ha comprato il telefono non
> riesca ad usarlo per colpa di queste, in tutto il mondo, è bassa, molto
> bassa. Approssimando: funziona.
Uhm sì, ripensandoci penso di aver preso un granchio. Alla fine non è una
scelta così sbagliata come mi sembrava all'inizio. Grazie per aver
insistito! :P
--
Conte Frobenius
Trip65
> Veramente si tratta di abuso da parte di Fastweb nell'utilizzo di subnet
> non assegnategli dal RIPE che il telefono rietiene _giustamente_
pubbliche.
E qui , ancora una volta , vuoi per colpa di un bug , di una feature mancata
, per qualsiasi cosa tu voglia , HAI UN PROBLEMA a causa di questa
architettura fastweb..
Perchè siamo d'accordo che tutte le volte che ci sono delle "complicazioni"
si va sempre a sbattere li ??
E stavolta non è un nerd che sta avendo un problema : è la casalinga di
Voghera che ha comperato via internet un apparato in offerta che funziona
senza problemi su tutte le adsl senza bisogno di alcuna cfg particolare
(sino a che non hai fastweb) e si aspetti che funzioni.
Casomai è vero il contarario : il nat non costituisce problemi al nerd di
turno che si arrangia sempre alla meglio , ma è disturbante per un normale
utente sprovveduto che non sa nulla .
Trip65
Se io barro la casella "attiva stun" lui lo deve fare senza discutere, non
deve ragionare , no non lo attivo perchè secondo me su un ip annunciabile
non è necessario.
Altrimenti non mettevano manco la possibilità di intervenire.
Tu mi dirai : come fa a capire se sei dietro nat ? appunto non lo deve
capire , deve comportarsi come l'utente lo ha configurato ovvero uso lo stun
se lo dichiaro abilitato , non lo deve usare se non lo abilito.
Conte Frobenius
> E qui , ancora una volta , vuoi per colpa di un bug , di una feature
> mancata , per qualsiasi cosa tu voglia , HAI UN PROBLEMA a causa di
> questa architettura fastweb..
> Perch siamo d'accordo che tutte le volte che ci sono delle
> "complicazioni" si va sempre a sbattere li ??
Sì, almeno, io sono d'accordo :)
> E stavolta non un nerd che sta avendo un problema : la casalinga di
> Voghera che ha comperato via internet un apparato in offerta che
> funziona senza problemi su tutte le adsl senza bisogno di alcuna cfg
> particolare (sino a che non hai fastweb) e si aspetti che funzioni.
> Casomai vero il contarario : il nat non costituisce problemi al nerd di
> turno che si arrangia sempre alla meglio , ma disturbante per un
> normale utente sprovveduto che non sa nulla .
Secondo me a questo punto sarebbe meglio che Fastweb configurasse gli HAG
per fare da NAT ad una ulteriore rete interna (con configurazione almeno
dei port forwarding dall'indirizzo MAN alle rete interna). Così
diventerebbe inutile comprare i router in cascata per il 90% delle
persona, e si risolverebbe anche questo tipo di problemi.
--
Conte Frobenius
Blak
>> Si ma con due grosse differenze:
>> - la probabilità che l'ICANN rilasci una nuova classe ad uso privato è
>> tendente a 0 mentre la probabilità che IANA assegni le ultime classi
>> rimaste ai RIR tende a 1.
>> - con le scelte fatte la probabilità che chi ha comprato il telefono non
>> riesca ad usarlo per colpa di queste, in tutto il mondo, è bassa, molto
>> bassa. Approssimando: funziona.
>
> Uhm sì, ripensandoci penso di aver preso un granchio.
Scusa per il tono ma non capivo l'insistenza.
Comunque, tra parentesi, anche nei sistemi operativi Windows viene
applicato lo stesso metodo per creare automaticamente un tunnel 6to4: se
l'interfaccia ha un IPv4 unicast globale viene creata l'interfaccia
virtuale 6to4, altrimenti no.
Blak
> Il telefono è bacato punto..
> Se io barro la casella "attiva stun" lui lo deve fare senza discutere, non
> deve ragionare
Allora non ho capito, pensavo che non ci fosse la possibilità di attivare o
meno, pensavo facesse tutto lui. Se tu chiedi di attivare lo stun e non lo
fa allora si, concordo.
> Altrimenti non mettevano manco la possibilità di intervenire.
> Tu mi dirai : come fa a capire se sei dietro nat ? appunto non lo deve
> capire , deve comportarsi come l'utente lo ha configurato ovvero uso lo stun
> se lo dichiaro abilitato , non lo deve usare se non lo abilito.
Ok, pensavo fosse semplicemente "autosensing", rendendo più semplice la
configurazione.
Rimane comunque quanto detto su fastweb.
Blak
> Secondo me a questo punto sarebbe meglio che Fastweb configurasse gli HAG
> per fare da NAT ad una ulteriore rete interna
Questa è un'idea pessima che si agiunge alla già pessima idea del NAT
fastweb.
Trip65
> per fare da NAT ad una ulteriore rete interna (con configurazione almeno
> dei port forwarding dall'indirizzo MAN alle rete interna). Così
> diventerebbe inutile comprare i router in cascata per il 90% delle
> persona, e si risolverebbe anche questo tipo di problemi.
> --
> Conte Frobenius
poi come fanno a limitare l'uso a 3 pc a quelli che vanno a consumo ,
sperando sempre , e lo trovano , l'allocco che fa tre attivazioni
contemporanee provocando tripla fatturazione ?
Guarda che non scherzo , vai sul forum e vedi quanta gente attiva due volte
perchè il fratello sta usando un pc ..
Manco il wi-fi ti fanno personalizzare, figurati se ammettessero , secondo
sempre una mentalità demente , che l'utente smanetti nella cpe , cpe che
sono certo che possa essere configurata con nat su indirizzi 192.168.0.0 .
Conta anche i casini che creerebbe l'attivazione di ippd , altro gingillo
fatto per spillare quattrini ..Concedere l'uso della videostation nattata
rendendola trasportabile e flessibile ? Ma scherzi non si puo' fatturare il
servizio "aggiuntivo".A meno che : videostation wi-fi con gestione del
flusso UDP dietro nat : 10 euro per l'attivazione !!
E sarebbe una idea : configurare la cpe con il nat ? Due euro una tantum e
lo puoi fare...
Non vuoi piu' il nat ? Raccomandata con rr per disdire la cosa ,
naturalmente dopo 60 gg si riconfigura in bridge se se lo vuoi prima penale
di 5 euro ... :)
Ah... il vile denaro ....
Conte Frobenius
>> Secondo me a questo punto sarebbe meglio che Fastweb configurasse gli
>> HAG per fare da NAT ad una ulteriore rete interna
>
> Questa è un'idea pessima che si agiunge alla già pessima idea del NAT
> fastweb.
E' come fanno tutti gli altri provider quando ti forniscono un router
wifi in comodato d'uso. La differenza è che dietro ai comunque il NAT di
Fastweb, ma questo non cambia nulla rispetto alla situazione precedente;
mentre invece sembra che avere una macchina direttamente nel NAT di
Fastweb crei i problemi di compatibilità di cui abbiamo discusso in
questo thread.
--
Conte Frobenius
lorenzodes
> E' come fanno tutti gli altri provider quando ti forniscono un router
> wifi in comodato d'uso. La differenza è che dietro ai comunque il NAT di
> Fastweb, ma questo non cambia nulla rispetto alla situazione precedente;
> mentre invece sembra che avere una macchina direttamente nel NAT di
> Fastweb crei i problemi di compatibilità di cui abbiamo discusso in
> questo thread.
Gli altri provider ti permettono però di agire sulle impostazioni del router:
aprire porte, fare forwarding... magari usarlo anche in modalità bridge.
Il motto di FW, in relazione a tutti i suoi apparati, è "guardare ma non
toccare".
Conte Frobenius
Sì certo, in questo caso pensavo ad uno scenario nel quale l'HAG fa da
vero router con NAT *e* le configurazioni di questo tipo sono a
disposizione dell'utente.
--
Conte Frobenius
Blak
> On Sun, 13 Jan 2008 15:53:50 +0100, Blak wrote:
>
>> Questa è un'idea pessima che si agiunge alla già pessima idea del NAT
>> fastweb.
>
> E' come fanno tutti gli altri provider
No
> quando ti forniscono un router
> wifi in comodato d'uso.
Beh alla fine anche fastweb ti fornisce, sostanzialmente, un router in
comodato d'uso.
> La differenza è che dietro ai comunque il NAT di
> Fastweb,
Ti sembra poco?
> ma questo non cambia nulla rispetto alla situazione precedente;
Però cambia (in peggo) moltissime altre cose.
> mentre invece sembra che avere una macchina direttamente nel NAT di
> Fastweb crei i problemi di compatibilità di cui abbiamo discusso in
> questo thread.
Sul fatto che il NAT crei problemi in generale non c'è dubbio.
In questo caso specifico sono gli indirizzi IANA Reserved il problema, non
il NAT.
Conte Frobenius
>> mentre invece sembra che avere una macchina direttamente nel NAT di
>> Fastweb crei i problemi di compatibilità di cui abbiamo discusso in
>> questo thread.
>
> Sul fatto che il NAT crei problemi in generale non c'è dubbio. In questo
> caso specifico sono gli indirizzi IANA Reserved il problema, non il NAT.
Problemi che sarebbero aggirati se l'HAG facesse un NAT controllabile
dall'utente, invece che essere costretti ad aggirarli comprando un
secondo router in cascata. Cioè quello che stavo dicendo.
--
Conte Frobenius
lorenzodes
> Sì certo, in questo caso pensavo ad uno scenario nel quale l'HAG fa da
> vero router con NAT *e* le configurazioni di questo tipo sono a
> disposizione dell'utente.
Guarda, il NAT, quando si parla di Fastweb, non è la soluzione, ma il
problema.
Anche al lavoro, abbonamento aziendale in fibra, mi ritrovo un bel
Cisco1700 su cui è inibita ogni possibilità di intervento lato utente.
Per carità, mai avuto un down, la connessione funziona bene ed è
veloce, ma o ti accontenti di come è impostato, oppure acquisti uno
dei tanti pacchetti commerciali aggiuntivi che FW ti fornisce con
grande piacere.
In ufficio, pertanto, noi abbiamo un doppio NAT. Quello classico di
FW, e quello ulteriore impostato sul Cisco1700. Lo scopo di
quest'ultimo NON è proteggere l'utente dai worm che bazzicano la MAN
(il commerciale aveva tentato, invero con scarso successo, di
vendercela in quel modo), né di mitigare potenziali criticità
dell'altra NAT, ma di imporre al cliente di dover ricorrere a mamma FW
per ogni esigenza particolare. Questo secondo NAT è un ulteriore
limite rispetto a quelli già noti e propri delle connessioni residenziali.
La nostra fortuna è che, almeno per ora, non abbiamo esigenze
particolari che mal si conciliano con i vincoli di cui sopra.
Questo lungo discorso solo per dire che FW sul NAT, inteso come limite
nei confronti dell'utenza, basa tutta la sua politica commerciale, per
cui cambiamenti di rotta mi sembrano alquanto improbabili.
massimo
> Conte Frobenius wrote:
>
> > Sì certo, in questo caso pensavo ad uno scenario nel quale l'HAG fa da
> > vero router con NAT *e* le configurazioni di questo tipo sono a
> > disposizione dell'utente.
>
> Guarda, il NAT, quando si parla di Fastweb, non è la soluzione, ma il
> problema.
Diciamo pure che, per fastweb, è grasso che cola. ;)
[...]
> Per carità, mai avuto un down, la connessione funziona bene ed è
> veloce, ma o ti accontenti di come è impostato, oppure acquisti uno
> dei tanti pacchetti commerciali aggiuntivi che FW ti fornisce con
> grande piacere.
E che che ingrassa le quotazioni in borsa. ;-)
I costi al commento N° 10 in questo forum: http://urlin.it/e35b
>
> In ufficio, pertanto, noi abbiamo un doppio NAT. Quello classico di
> FW, e quello ulteriore impostato sul Cisco1700. Lo scopo di
> quest'ultimo NON è proteggere l'utente dai worm che bazzicano la MAN
> (il commerciale aveva tentato, invero con scarso successo, di
> vendercela in quel modo), [...]
Ma la prima direttiva dei commerciali fastweb è quella di credere che
tutti gli utenti siano casalinghe di Voghera.
[...]
> Questo lungo discorso solo per dire che FW sul NAT, inteso come limite
> nei confronti dell'utenza, basa tutta la sua politica commerciale, per
> cui cambiamenti di rotta mi sembrano alquanto improbabili.
Anche perchè il protocollo di assegnazione IPv4 è saturo (che tra
l'altro sono di tipo C, compreso IP pubblico di fastweb), e IPv6 stenta
a decollare.
BTW i nostri vicini UE viaggiano sull'ordine dei Giga, e da quando in
Italia abbiamo ottenuto la fibra, noi non ci siamo spostati dai 10Mb.
Bah.
Blak
> Ma la prima direttiva dei commerciali fastweb è quella di credere che
> tutti gli utenti siano casalinghe di Voghera.
Perchè, almeno per la connettività residenziale, è così.
>> Questo lungo discorso solo per dire che FW sul NAT, inteso come limite
>> nei confronti dell'utenza, basa tutta la sua politica commerciale, per
>> cui cambiamenti di rotta mi sembrano alquanto improbabili.
> Anche perchè il protocollo di assegnazione IPv4 è saturo
IPv4 non è un protocollo di assegnazione, non scrivere cose a caso. Il
problema non è che è (al momento) saturo ma che è comunque in un vicolo
cieco. Allora, tanto vale passare già ad IPv6, che è anche superiore
tecnologicamente parlando.
> (che tra
> l'altro sono di tipo C,
Non si usano più le classi da quel dì.
> compreso IP pubblico di fastweb), e IPv6 stenta
> a decollare.
Per IPv6 è tutto pronto (o quasi), dalle applicazioni ai root DNS, il
problema è suscitare l'interesse della gente per arrivare ad un deplyment
vasto per quanto riguarda gli utenti finali. La stragrande maggior parte
dell'utenza, domestica e non, a stento conosce IPv4, figuriamoci IPv6, e
difficilmente se ne interesseranno a meno che non possano trarre un forte
vantaggio da questo. Dall'altro lato per gli ISP non è visto,
commercialmente parlando, come qualcosa di fruttifero quindi sono
attualmente in pochi a proporlo. Pian piano IPv6 si diffonderà, ma al
momento non c'è ancora un qualcosa di trainante.
> BTW i nostri vicini UE viaggiano sull'ordine dei Giga,
Come no...
Comunque all'estero, oltre ad esserci un mercato diverso, c'è una cultura
diversa.
Blak
> On Sun, 13 Jan 2008 22:17:57 +0100, Blak wrote:
>
>> Sul fatto che il NAT crei problemi in generale non c'è dubbio. In questo
>> caso specifico sono gli indirizzi IANA Reserved il problema, non il NAT.
>
> Problemi che sarebbero aggirati se
- Se Fastweb usasse indirizzi RFC compliant
- Se Fastweb togliesse il NAT.
> l'HAG facesse un NAT controllabile
> dall'utente,
Questa è una cosa inutile.
Conte Frobenius
>> Sì certo, in questo caso pensavo ad uno scenario nel quale l'HAG fa da
>> vero router con NAT *e* le configurazioni di questo tipo sono a
>> disposizione dell'utente.
>
> Guarda, il NAT, quando si parla di Fastweb, non è la soluzione, ma il
> problema.
Probabilmente mi sto spiegando male io. Provo a ripetermi.
Sono arci-convinto che il NAT sia un grosso problema di Fastweb e che
impone agli utenti limitazioni varie, aggirabili è vero, ma molte solo
tramite buone competenze tecnice ed estrema difficoltà per utenti meno
competenti.
Appurato questo, abbiamo anche appena verificato sperimentalmente (in
questo thread) come un secondo NAT paradossalmente renda la situazione
migliore perché risolve alcuni problemi di compatibilità dovuti all'uso
di Fastweb di classi di IP non assegnate. Non dico: "rende la situazione
perfetta". Dico: "rende la situazione *migliore*".
Di conseguenza, se l'HAG facesse NAT (sotto *completo* controllo
dell'utente), forse globalmente ci sarebbero meno problemi. Sempre di più
che se non ci fosse del tutto il NAT (siamo d'accordo), ma meno di ora.
> Anche al lavoro, abbonamento aziendale in fibra, mi ritrovo un bel
> Cisco1700 su cui è inibita ogni possibilità di intervento lato utente.
> Per carità, mai avuto un down, la connessione funziona bene ed è veloce,
> ma o ti accontenti di come è impostato, oppure acquisti uno dei tanti
> pacchetti commerciali aggiuntivi che FW ti fornisce con grande piacere.
Sì, ho familiarità con questi contratti.
> In ufficio, pertanto, noi abbiamo un doppio NAT. Quello classico di FW,
> e quello ulteriore impostato sul Cisco1700. Lo scopo di quest'ultimo NON
> è proteggere l'utente dai worm che bazzicano la MAN (il commerciale
> aveva tentato, invero con scarso successo, di vendercela in quel modo),
> né di mitigare potenziali criticità dell'altra NAT, ma di imporre al
> cliente di dover ricorrere a mamma FW per ogni esigenza particolare.
> Questo secondo NAT è un ulteriore limite rispetto a quelli già noti e
> propri delle connessioni residenziali.
Sono d'accordo. Infatti alcune aziende con cui collaboro si fanno
delegare le subnet di IP pubblici sul Cisco (es: 4 IP, di cui 1 rimane
utilizzabile), e poi fanno NAT dietro i loro server. In pratica il Cisco
diventa il default gateway della DMZ, ma non fa da NAT.
--
Conte Frobenius
Conte Frobenius
>> l'HAG facesse un NAT controllabile
>> dall'utente,
>
> Questa è una cosa inutile.
Questo thread ha appena verificato sperimentalmente il contrario. L'hai
letto?
--
Conte Frobenius
Blak
> Probabilmente mi sto spiegando male io. Provo a ripetermi.
Non è necessario, sbagli. Proponi una "soluzione" che crea più problemi di
quelli che risolve ==> non è una soluzione. Anche perchè in questo caso
specifco il problema è l'uso di IP riservati per una rete comunque connessa
ad Internet, quindi la soluzione sarebbe rinumerare (cosa che non avverrà
mai, come anche la tua soluzione).
Conte Frobenius
>> Probabilmente mi sto spiegando male io. Provo a ripetermi.
>
> Non è necessario, sbagli. Proponi una "soluzione" che crea più problemi
> di quelli che risolve ==> non è una soluzione.
Capisco che ti piace scrivere un sacco di affermazioni forti e sprezzanti
senza addurre spiegazioni, ma non hai ancora spiegato quali sono i "più
problemi" che crea.
> Anche perchè in questo
> caso specifco il problema è l'uso di IP riservati per una rete comunque
> connessa ad Internet, quindi la soluzione sarebbe rinumerare (cosa che
> non avverrà mai, come anche la tua soluzione).
So perfettamente quale sarebbe la soluzione perfetta, ma non stiamo
discutendo di quella.
--
Conte Frobenius
Blak
>> Non è necessario, sbagli. Proponi una "soluzione" che crea più problemi
>> di quelli che risolve ==> non è una soluzione.
>
> Capisco che ti piace scrivere un sacco di affermazioni forti e sprezzanti
No, mi piace scrivere cose corrette e sensate.
> senza addurre spiegazioni,
Non c'è nulla da spiegare, se sai cosa significa l'acronimo NAT sai anche
cosa comporta e perchè non è la soluzione. Nè per gli utenti nè per
fastweb.
> So perfettamente quale sarebbe la soluzione perfetta, ma non stiamo
> discutendo di quella.
Che senso ha discutere su:
- qualcosa che è peggiorativo
- qualcosa che non avverrà mai
- qualcosa che non è l'origine dei problemi con fastweb?
Conte Frobenius
>> So perfettamente quale sarebbe la soluzione perfetta, ma non stiamo
>> discutendo di quella.
>
> Che senso ha discutere su:
> - qualcosa che è peggiorativo
Non hai ancora spiegato perché. Questo thread ha dimostrato che un router
che fa NAT in cascata all'HAG porta un miglioramento nell'uso di alcuni
software che altrimenti non sono in grado di funzionare correttamente.
Non vedo dunque perché l'idea di un HAG con NAT configurabile dovrebbe
essere "pessima".
> - qualcosa che non avverrà mai
Se vuoi illustrarmi il perché di questa profezia, sarò felice di
ascoltarti.
> - qualcosa che non è l'origine dei problemi con fastweb?
Perché non sempre (purtroppo) l'unica cosa di cui ha senso ragionare è
come si risolvono tutti i problemi alla radice. Spesso non è possibile
risolvere i problemi alla radice, ma ha comunque senso documentarsi su
possibili soluzioni parziali, workaround o alternative.
--
Conte Frobenius
Blak
> On Tue, 15 Jan 2008 23:25:50 +0100, Blak wrote:
>
>> Che senso ha discutere su:
>> - qualcosa che è peggiorativo
>
> Non hai ancora spiegato perché.
Quale sarebbe il vantaggio di un secondo NAT? Nessuno.
Quali sarebbero le complicazioni dovute ad un secondo NAT? Una sua
configurazione, quando possibile, ulteriori complicazioni quando la cosa
non è così semplice.
> Questo thread ha dimostrato che un router
> che fa NAT in cascata all'HAG porta un miglioramento nell'uso di alcuni
> software
Un telefono. Uno. Fine.
> che altrimenti non sono in grado di funzionare correttamente.
Per altri motivi che conosci benissimo.
> Non vedo dunque perché l'idea di un HAG con NAT configurabile dovrebbe
> essere "pessima".
Perchè te l'ho già detto: è stupida, è peggiorativa per Fastweb e i
clienti.
>> - qualcosa che non avverrà mai
>
> Se vuoi illustrarmi il perché di questa profezia, sarò felice di
> ascoltarti.
Perchè fastweb non ne trarrebbe nessun vantaggio, nè tecnico nè commerciale
(anzi...) ==> quindi non si fa. Fine.
>> - qualcosa che non è l'origine dei problemi con fastweb?
>
> Perché non sempre (purtroppo) l'unica cosa di cui ha senso ragionare è
> come si risolvono tutti i problemi alla radice. Spesso non è possibile
> risolvere i problemi alla radice, ma ha comunque senso documentarsi su
> possibili soluzioni parziali, workaround o alternative.
Ti ho già risposto anche a questo: non è una soluzione, non è un
workaround, inutile stare a parlarne.
Conte Frobenius
>> Questo thread ha dimostrato che un router che fa NAT in cascata all'HAG
>> porta un miglioramento nell'uso di alcuni software
>
> Un telefono. Uno. Fine.
Molto di più che così: ci sono altri post di altri problemi legati a SIP
simili a questo che probabilmente erano dovuti alla stessa ragione. E ci
sono giochi online (come PES 2008) che hanno ancora una volta lo stesso
problema.
>>> - qualcosa che non avverrà mai
>>
>> Se vuoi illustrarmi il perché di questa profezia, sarò felice di
>> ascoltarti.
>
> Perchè fastweb non ne trarrebbe nessun vantaggio, nè tecnico nè
> commerciale (anzi...) ==> quindi non si fa. Fine.
Molti provider offrono router che fanno NAT con wi-fi integrato in
comodato d'uso gratuito. Anche loro non ne traggono nessun vantaggio?
--
Conte Frobenius
Blak
> On Thu, 17 Jan 2008 21:32:29 +0100, Blak wrote:
>
>> Un telefono. Uno. Fine.
>
> Molto di più che così: ci sono altri post di altri problemi legati a SIP
> simili a questo che probabilmente erano dovuti alla stessa ragione.
Probabilmente? E anche fosse?
> E ci
> sono giochi online (come PES 2008) che hanno ancora una volta lo stesso
> problema.
E quindi?
Stai dicendo che fastweb dovrebbe cambiare le proprie politiche perchè un
bambino non riesce a giocare a PES? Sei serio o stai scherzando?
>> Perchè fastweb non ne trarrebbe nessun vantaggio, nè tecnico nè
>> commerciale (anzi...) ==> quindi non si fa. Fine.
>
> Molti provider offrono router che fanno NAT con wi-fi integrato in
> comodato d'uso gratuito.
E un chissene? Cosa fanno gli altri (per altro in un contesto molto
diverso) importa poco, se non conviene e non porta alcun vantaggio non si
fa.
> Anche loro non ne traggono nessun vantaggio?
A farti pagare un oggetto in comodato? Certo.
Peccato che fastweb ti dia già l'opportunità di collegare più computer
quindi non deve darti niente di più di quello che già ti fornisce.
Comunque guarda, ti do ragione, così la finiamo qua e siamo tutti contenti.
Sapere 3-4 cose non vuol dire automaticamente averle capite e saperle
utilizzare.
Blak
> Molti provider offrono router che fanno NAT con wi-fi integrato in
> comodato d'uso gratuito
E aggiungo: molti provider (o meglio, praticamente la totalità) portano a
casa dell'utente un IP pubblico. Allora, sulla base del tuo ragionamento,
mi aspetto che fastweb si adegui e tolga il NAT (il vero problema).
Fammi un fischio quando avverrà, ok?
Conte Frobenius
> Comunque guarda, ti do ragione, così la finiamo qua e siamo tutti
> contenti. Sapere 3-4 cose non vuol dire automaticamente averle capite e
> saperle utilizzare.
Mi dispiace che tu debba ricorrere alle offese per chiudere un thread.
Anche se non siamo d'accordo, non c'è bisogno di supporre che l'altro sia
uno che non ci arriva.
--
Conte Frobenius
Conte Frobenius
> Il 18 Jan 2008 00:05:08 GMT, Conte Frobenius ha scritto:
>
>> Molti provider offrono router che fanno NAT con wi-fi integrato in
>> comodato d'uso gratuito
>
> E aggiungo: molti provider (o meglio, praticamente la totalità) portano
> a casa dell'utente un IP pubblico. Allora, sulla base del tuo
> ragionamento, mi aspetto che fastweb si adegui e tolga il NAT (il vero
> problema). Fammi un fischio quando avverrà, ok?
Qui stai proprio esagerando.
Il mio ragionamento non era certo "Fastweb dovrebbe adattarsi a quello
che gli altri provider fanno". Non hai letto con abbastanza attenzione o
voglia di capire.
--
Conte Frobenius
lorenzodes
> Probabilmente mi sto spiegando male io. Provo a ripetermi.
Ti sei spiegato benissimo e io ti ho capito, ma ribadisco quanto
detto: il NAT, quando si parla di FW, non è la soluzione, ma il problema.
> Appurato questo, abbiamo anche appena verificato sperimentalmente (in
> questo thread) come un secondo NAT paradossalmente renda la situazione
> migliore perché risolve alcuni problemi di compatibilità dovuti all'uso
> di Fastweb di classi di IP non assegnate. Non dico: "rende la situazione
> perfetta". Dico: "rende la situazione *migliore*".
Non sarò certo io a negarlo: Trip riesce a far funzionare quel
telefono solo dietro NAT. E' un dato di fatto.
> Di conseguenza, se l'HAG facesse NAT (sotto *completo* controllo
> dell'utente), forse globalmente ci sarebbero meno problemi. Sempre di più
> che se non ci fosse del tutto il NAT (siamo d'accordo), ma meno di ora.
E qui invece il tuo ragionamento è fallato. Il secondo NAT, per quanto
riguarda le utenze residenziali, a FW non conviene, perché
azzopperebbe la famosa rete interna. Quanto a dare all'utente il
controllo sul NAT... suvvia, gli HAG fastweb sono sacri ed inviolabili
ed è già tanto che ti permettono di spolverare il tuo ogni tanto. Non
ti danno neppure quel minimo accesso necessario a verificare i
parametri ADSL e lo stato della linea, figuriamoci il pieno controllo
su un ipotetico NAT!
Blak
> On Fri, 18 Jan 2008 12:52:08 +0100, Blak wrote:
>
>> PS: nessuno ti vieta di attaccare un router all'HAG ottenendo
>> l'architettura che vorresti. Allora ti chiedo, una volta per tutte:
>> perchè fastweb dovrebbe farlo per te, quando ti offre già un pool di IP
>> (e la sua rete ormai è quella)? O hai una risposta che sia
>> sufficientemente intelligente o possiamo chiudere qua.
>
> Per dare dei vantaggi di compatibilità ai clienti,
Si, certo... come no.
> e diminuire
> contemporaneamente l'utilizzo di IP in classi non permesse
Peccato che, soprattutto in origine, lo scopo fosse quello di avere un
indirizzamento "geografico".
> La ristrutturazione della rete, nel
> tempo, andrà comunque fatta,
Si, bisogna vedere secondo quali criteri/scopi e quando (potrebbe essere
anche tra 5-6 anni)
> visto che stanno liberando le classi (come
> si notava altrove).
Topografia e indirizzamento sono due cose diverse anche se normalmente
coerenti: a loro basterebbe rinumerare mantenendo l'architettura attuale.
> La mia intelligenza è sufficiente per te?
Hai scritto ancora una volta un sacco di inesattezze e cose prive di senso.
Ti consiglio di lasciar pedere, sul serio.
Conte Frobenius
>> La mia intelligenza è sufficiente per te?
>
> Hai scritto ancora una volta un sacco di inesattezze e cose prive di
> senso. Ti consiglio di lasciar pedere, sul serio.
Già. Per fortuna che ci sei tu ad illimunarci con le tue risposte!
--
Conte Frobenius