Tutto questo dalla scorsa estate, in precedenza la funzionalit� era totale.
E' chiaro che non esiste altra soluzione che la disdetta, ma sinceramente
questo atteggiamento di Fastweb � semplicemente vergognoso !!!
Chi volesse abbonarsi tenga conto di questa problematica. A che serve andare a
10 mega in download se non si pu� usare l'FTP con alcuni (fondamentali) siti ?
Ora non mi resta che cercare un gestore telefonico alternativo .. che palle.
--
Ciao
Spin
> Allora dopo aver parlato per l'ennesima volta con Fastweb appare chiaro che
> non esiste la volont� a risolvere il problema della connessione FTP verso
> alcuni provider, nel mio caso Register.it, e di fatto Fastweb impedisce
> l'operativit� FTP (tipicamente la gestione del proprio sito on line).
>
> Ora non mi resta che cercare un gestore telefonico alternativo .. che palle.
Perche' non usi l'IP pubblico?
> Si ma la motivazione addotta dal provider per cui non avviene piu' lo
> scambio ftp con fw si sa ?
Ho scritto a register qualche mese fa. Loro hanno incolpato Fastweb che non
adotta non ricordo pi� quale modalit� standard.
Sta di fatto che Fastweb si limita a non rispondere sostenendo che la linea �
a posto .. si ma per il resto non per FTP ..
Ho dovuto aggiornarmi il sito da chiavetta usb mobile .. roba da chiodi.
--
Ciao
Spin
> Perche' non usi l'IP pubblico?
Perch� non cambia niente.. non va uguale identico.
--
Ciao
Spin
>> Perche' non usi l'IP pubblico?
>
> Perch� non cambia niente.. non va uguale identico.
Devi fare delle prove perche' se e' cosi' significa che l'architettura non
standard di Fastweb introduce delle limitazioni anche nelle sessioni IPPD.
Il che sarebbe doppiamente vergognoso :-(
> Devi fare delle prove perche' se e' cosi' significa che l'architettura non
> standard di Fastweb introduce delle limitazioni anche nelle sessioni IPPD.
> Il che sarebbe doppiamente vergognoso :-(
Ho provato tutto.. � appunto vergognoso. Visto che posso uasre altre
conessioni ora mi organizzaet� con calma per certace una soluzione idonea
abbandonando questo gestore incompatibile con settori della rete internet
comune.
--
Ciao
Spin
SpinneR ha scritto:
>
> Perch� non cambia niente.. non va uguale identico.
Il problema in effetti pare indipendente dall'architettura di 'uscita
dalla rete' (NAT many-to-many NO Overload DPPU / NAT 1:1 bidirezionale
IPPD).
In base alle segnalazioni effettuate su Usenet & ad alcune mie prove
iniziali risulta infatti che i KO si verificano 'a macchia di leopardo'
evidentemente in virtu' di configurazioni HW/SW diverse a livello del
POP/Minipop di attestazione della linea.
Ad esempio ho appena effettuato un test con 2 linee Fibra sulla MAN di
Milano, vicine per ubicazione geografica ma con diversa attestazione
POP/Minipop :
==
- POP-0109 / IP MAN 1.60.*.*
- POP-0102 / IP MAN 1.80.*.*
Usando come server di test il seguente di Register :
==
- Indirizzo IP : 195.110.124.188
- Tipologia ...: Linux Shared Hosting
==
non ho rilevato nessun problema sulla linea attestata nel POP-0109,
indipendentemente dal client FTP usato -> invece per quella del POP-0201
c'era solo l'imbarazzo della scelta tra l'errore immediato di Connection
Reset e l'accesso effettuato, ma con successive assenze di attivita' a
livello delle trasmissioni sul Data Channel, che portavano poi al
timeout.
Qualche parziale miglioramento e' stato riscontrato, usando FileZilla
come client & tarando le relative impostazioni anti-timeout / retry
della connessione = cio' ha consentito di effettuare i trasferimenti, ma
con una serie di disconnessioni/riconnessioni intermedie effettuate in
automatico dal client.
> mi organizzaet� con calma per certace una soluzione idonea
> abbandonando questo gestore
Indipendentemente dal fatto che si provveda all'invio della raccomandata
di reclamo, piuttosto che al passaggio ad un altro operatore, nel
frattempo un possibile workaround sarebbe far effettuare le sessioni FTP
a WebClient FTP remoti, e.g. http://www.net2ftp.com/index.php .
In tal caso chi disponesse di un proprio server su IP pubblico esterno
alla rete FW con supporto PHP e pieni privilegi amministrativi potrebbe
anche installarlo direttamente, evitando di usare la versione pubblica.
--
|� \/� | /�\ /�__/�__|<|> *FAX/Mail Server : +39 - 02700426582 <|
|�|\/|�|/�_�\|(__\__ \<|> *Casella Vocale : +39 - 0230312251 <|
|_| |_/_/ \_\___|___/<|> *FAQ ITGF http://plany.fasthosting.it <|
|>- RST - Plany/MACS -<|> *FAQ GCN http://faq.news.nic.it/ ____<|
> a WebClient FTP remoti, e.g. http://www.net2ftp.com/index.php .
Far� una prova con questo. Ma comemai fastweb non vuole risolvere questro
strano problema ?
--
Ciao
Spin
>> Devi fare delle prove perche' se e' cosi' significa che l'architettura non
>> standard di Fastweb introduce delle limitazioni anche nelle sessioni IPPD.
>> Il che sarebbe doppiamente vergognoso :-(
>
> Ho provato tutto.. � appunto vergognoso. Visto che posso uasre altre
> conessioni ora mi organizzaet� con calma per certace una soluzione idonea
> abbandonando questo gestore incompatibile con settori della rete internet
> comune.
La mia utenza pare non impattata: anche con l'IP privato entro e
trasferisco a razzo. Ho utilizzato come test l'host indicato da Macs.
SpinneR ha scritto:
>
> Far� una prova con questo. Ma comemai fastweb non vuole risolvere
> questro strano problema ?
Non e' propriamente una questione di volonta' = per molti versi la
situazione e' analoga al vecchio problema con la gestione del load
balancing, che si trascino' da Giugno 2002 a Settembre 2003, impattando
nei vari periodi differenti MAN/POP -> vedansi p.es. i riferimenti su :
==
Thread Subject ...: Re: FASTWEB e callcenter..... (Vergogna FASTWEB !!)
Data 1� Post .....: 18-Feb-2003
Message-ID 1�Post : Gmp4a.18734$uA5.4...@tornado.FASTWEBnet.it
Messaggi Thread ..: 30 articoli
GoogleGroups Link : http://tinyurl.com/yc2lux3
Uno dei problemi con tale situazione - come tu stesso avevi sperimentato
a suo tempo - fu proprio 'persuadere' l'assistenza tecnica che ci fosse
effettivamente un problema, dato che :
==
------------------------------------------------------------------------
1. Il disservizio infatti 'andava e veniva' su POP diversi, alternando
mesi di KO con mesi OK, a seconda di come FW interveniva a livello di
configurazione su POP/Minipop = il problema - come poi confermarono i
caveat Cisco dell'epoca - era dovuto ad un 'baco' su una tipologia
di configurazione mirata a ridurre il livello di carico sui router
FW presso i POP/Minipop con criticita' di traffico.
Tutto cio' si protrasse appunto per il tempo, che servi' a FW per
sviluppare & implementare una nuova configurazione, che riducesse
il carico senza comportare questioni a livello di load-balancing.
2. Ci volle tempo perche' l'assistenza tecnica diretta agli utenti
inquadrasse la situazione = per ragioni anche comprensibili non era
stata subito informata dai reparti piu' alti Rete/IP, e quindi non le
era certo facile correlare le segnalazioni, visto che provenivano
all'inizio da non molte utenze attestate peraltro su MAN/POP
differenti, e che le descrizioni non concordavano.
Tant'e' che pure su questo stesso newsgroup alcuni utenti non furono
inizialmente granche' convinti che si trattasse di un problema reale
a livello di rete FW, dato che non ne erano impattati = servirono
varie segnalazioni con annesso KO nel test Fineco per rendere la
situazione piu' evidente.
------------------------------------------------------------------------
Stavolta le segnalazioni sono ancora di meno, ma perlomeno (da quanto
ho potuto apprendere dopo l'inoltro dei dettagli delle prime prove)
sarebbero gia' in corso gli interventi correttivi su alcuni POP.
> sarebbero gia' in corso gli interventi correttivi su alcuni POP.
Ricordo il problema di Fineco, ma solo perch� me lo hai ricordato. Speriamo a
questo punto che stiano provedendo nella direzione che hai prospettato.
Ormai appunto � da settembre 2009 che ho questa disfunzione.
--
Ciao
Spin
Scusa ma...
##########################
FireFTP 1.0.7 'Human Being' created by Mime C(uvalo
220 FTP Server ready.
USER ***
331 Password required for ***
PASS (password not shown)
230 User *** logged in
FEAT
211-Features:
MDTM
MFMT
MFF modify;UNIX.group;UNIX.mode;
MLST modify*;perm*;size*;type*;unique*;UNIX.group*;UNIX.mode*;UNIX.owner*;
REST STREAM
SIZE
211 End
PWD
257 "/" is the current directory
TYPE A
200 Type set to A
PASV
227 Entering Passive Mode (195,110,124,133,148,1)
LIST
150 Opening ASCII mode data connection for file list
226 Transfer complete
###############
A me Register.it funziona benissimo.
Fastewb DSL Roma.
--
_____________________________________
---- Mechmaniac'77 (31, 144, RM) ----
---- 156 1.8ts + Monster600 dark ----
----- Lenco Lover -- JBL Abuser -----
http://blog.granderaccordoanulare.net
> A me Register.it funziona benissimo.
> Fastewb DSL Roma.
Ad alcuni. Mi hanno appena confermato ufficialmente che si tratta di blocchi
imposti da sistemi anti hakers che su alcuni nodi bloccano, oltre ad altro,
il traffico da register verso fastweb. Quindi register riceve le richieste
ma le risposte tendono a non passare e quindi la comunicazione non funziona.
Io sono sotto uno di questi nodi bloccati. Non possono fare nulla in quanto
tali blocchi pare siano imposti da una regolamentazione.
In pratica esistono due soluzioni: abbandonare l'uno o l' altro provider.
Non tutti i nodo di Fastweb hanno questo blocco, evidentemente perch� non
sotto attacco.
--
Ciao
Spin
>Ad alcuni. Mi hanno appena confermato ufficialmente che si tratta di blocchi
>imposti da sistemi anti hakers che su alcuni nodi bloccano, oltre ad altro,
>il traffico da register verso fastweb. Quindi register riceve le richieste
>ma le risposte tendono a non passare e quindi la comunicazione non funziona.
>
>Io sono sotto uno di questi nodi bloccati. Non possono fare nulla in quanto
>tali blocchi pare siano imposti da una regolamentazione.
Quello che affermi mi pare molto vicino alla fantascienza...
--
ciao,
Marco
> Quello che affermi mi pare molto vicino alla fantascienza...
E' quello che un tecnico di fastweb mi ha dettagliatamente riferito al
telefono. Mi ha chiamato lui.
Sta di fatto che la connessione non va ed i problemi riscontrati confermano la
versione. Mi diceva che le risposte dal server di register venivano rigettate
dal nodo di fastweb perch� considerati attacchi.
--
Ciao
Spin
SpinneR ha scritto:
>
> Mi diceva che le risposte dal server di register venivano rigettate
> dal nodo di fastweb perch� considerati attacchi.
Come hanno confermato le verifiche, presso i POP impattati vi e' un
problema di configurazione, per cui si riscontrano tali KO verso
specifiche appliance di server FTP = non dipendono da rete/range di
appartenenza dell'indirizzo IP associato all'host remoto su cui 'gira'
l'appliance server FTP.
Infatti, se cosi' fosse, non basterebbe 'giocare' con variazioni delle
impostazioni lato client FTP e/o del client stesso in uso per variare
stato/tipologia di KO = cio' e' confermato non solo dalle prove svolte
dal sottoscritto, ma p.es. anche da questo post di Pantagru (attestato
sulla MAN di Milano 1/8 POP0113) :
==
- Newsgroups ..: it.tlc.gestori.fastweb
- Subject .....: Re: Accesso FTP ... problemi continui ..
- Date ........: Mon, 15 Feb 2010 08:27:00 (UTC)
- Message-ID ..:
<f814bdf9-6608-41ca...@k41g2000yqm.googlegroups.com>
- GoogleGroups : http://tinyurl.com/yb8u34s
Ecco perche' Marco d'Itri ha ritenuto vicino alla fantascienza quanto
hai riportato nel tuo precedente post, soprattutto (suppongo) alla
luce del seguente passaggio :
==
"Non possono fare nulla in quanto tali blocchi pare siano imposti da una
regolamentazione"
Per il resto, visto che il disservizio perdura da Settembre, immagino
che tu abbia anche formalizzato a suo tempo un reclamo ufficiale tramite
FAX + Raccomandata A.R. [1] con richiesta di indennizzo/rimborso [2].
In caso contrario (cioe' avessi effettuato solo segnalazioni semplici
per telefono e/o tramite modulo 192.193 online) sarebbe il caso di farlo
- indipendentemente dalle decisioni sul mantenimento (o meno) della
linea FW.
[1] Recapiti per reclami ufficiali utenze Residenziali e SOHO
---------------------------------------------------------
FAX 02-45455677
C.P. n.126 - 20092 Cinisello Balsamo (MI)
[2] Art. 6.1 della Carta Servizi FW :
==
- http://www.fastweb.it/downloads/PDF/famiglia/CDS_fissa.pdf
> Ecco perche' Marco d'Itri ha ritenuto vicino alla fantascienza quanto
> hai riportato nel tuo precedente post, soprattutto (suppongo) alla
> luce del seguente passaggio :
> ==
> "Non possono fare nulla in quanto tali blocchi pare siano imposti da una
> regolamentazione"
Ennesima dimostrazione di che razza di gente lavora a Fastweb e di che
razza di azienda e' Fastweb che assume e forma codesti individui.
Solo fastweb aderisce a questa "normativa" ??? Tra l'altro quale
regolamentazione ? Non ne sappiamo nulla ...
> "Non possono fare nulla in quanto tali blocchi pare siano imposti da una
> regolamentazione"
Tale � stata la comunicazione: essendoci dei blocchi obbligatori per normativa
per impedire attacchi dagli hakers non possiamo fare nulla per risolvere la
situazione che � immodificabile.
Condivido il fatto che la cosa sia poco credibile, ma questo � stato
sostenuto.
> Per il resto, visto che il disservizio perdura da Settembre, immagino
> che tu abbia anche formalizzato a suo tempo un reclamo ufficiale tramite
> FAX + Raccomandata A.R. [1] con richiesta di indennizzo/rimborso [2].
>
> In caso contrario (cioe' avessi effettuato solo segnalazioni semplici
> per telefono e/o tramite modulo 192.193 online) sarebbe il caso di farlo
> - indipendentemente dalle decisioni sul mantenimento (o meno) della
> linea FW.
Effettivamente � una cosa da fare. Ma secondo te come mai non riescono a
sistemare il problema che ben conoscono ?
--
Ciao
Spin
SpinneR ha scritto:
>
> Tale � stata la comunicazione: essendoci dei blocchi obbligatori per
> normativa per impedire attacchi dagli hakers non possiamo fare nulla
> per risolvere la situazione che � immodificabile.
>
> Condivido il fatto che la cosa sia poco credibile, ma questo � stato
> sostenuto.
'Poco credibile' non rende bene l'idea = trovo che a tale comunicazione
si addica di piu' un'espressione usata in un film del 1976 diretto da
Luciano Salce [*].
> Ma secondo te come mai non riescono a sistemare il problema che ben
> conoscono ?
Non e' che non vi riescano, bensi' IMHO & in spiccioli :
==
1. Hanno altri interventi prioritari da effettuare sulla rete
2. L'intervento correttivo non deve innescare altri/nuovi 'casini'
3. Per ora pochi notano il problema, e non tutti lo segnalano
4. Ancora meno sono quelli, che poi procedono con reclami ufficiali
[*] http://www.youtube.com/watch?gl=IT&v=2a_ajsIVxyU
>Tale ᅵ stata la comunicazione: essendoci dei blocchi obbligatori per normativa
>per impedire attacchi dagli hakers non possiamo fare nulla per risolvere la
>situazione che ᅵ immodificabile.
>
>Condivido il fatto che la cosa sia poco credibile, ma questo ᅵ stato
>sostenuto.
Ritengo di essere ben informato sulle normative rilevanti per gli ISP e
mi sento di dire con la massima sicurezza che ti hanno raccontato una
grandiosa cazzata.
>Effettivamente ᅵ una cosa da fare. Ma secondo te come mai non riescono a
>sistemare il problema che ben conoscono ?
Ci possono essere tanti motivi.
--
ciao,
Marco