Newsgroup: it.comp.retrocomputing
Titolo: Dialer di IE e provider gratuiti [LUNGO]

Leggo, di tanto in tanto, messaggi che lamentano l'impossibilita` di
spedire la posta quando ci si collega ad un provider gratuito usando
il dialer Shiva fornito con IE 3 e 4 per Windows 3.1X. Penso che possa
essere utile chiarire qual e` la vera natura del problema, se non
altro per evitare che altri perdano ancora tempo in inutili esperimenti.
Fin dai primi collegamenti con Tiscali e Libero ho anch'io constatato
il problema, che pero` per me e` piu` una seccatura che un vero
ostacolo. Infatti non ho alcuna difficolta` a spedire messaggi anche
molto lunghi quando uso Agora`, con cui ho un abbonamento per la sola
e-mail. Questa circostanza (e il fatto che non c'erano mai stati
problemi con IOL, quando usavo gli abbonamenti omaggio del defunto IOL
Magazine) mi ha incuriosito e mi ha spinto ad approfondire la cosa.
Il problema non e` nei programmi di posta e neppure in winsock;
si trova ancora piu` in basso, nello stack TCP/IP, il software che
gestisce direttamente la trasmissione dei dati secondo il protocollo
Internet (lo stack fornito con IE e` PC/TCP della FTP Software).
Un parametro fondamentale del protocollo e` la quantita` massima
di dati che puo` essere trasmessa in un pacchetto, MSS (maximum
segment size). Legato a questo e` un secondo parametro: MTU
(maximum transmission unit) che rappresenta la lunghezza effettiva
del pacchetto; e` uguale ad MSS piu` la lunghezza delle informazioni
di controllo richieste dal protocollo (in pratica e` MSS+40).
Pare che, fino ad un paio di anni fa, il valore di default di MSS fosse
536 (MTU=576) e questo e` il valore che usa PC/TCP. Invece i provider
free hanno deciso di usare MSS=512 (MTU=552); non so le ragioni di
questa scelta, ma non mi stupirebbe affatto scoprire che 512 e`,
guarda caso, il valore di default per Accesso Remoto di Windows 98...
E` chiaro quello che succede. Nella trasmissione da provider a PC
tutto fila liscio: il provider invia pacchetti da 552 byte che non
creano problemi a PC/TCP che si aspetta pacchetti fino a 576 byte. Ma
quando PC/TCP spedisce un pacchetto di 576 byte il software dall'altro
lato semplicemente lo scarta perche' eccede la lunghezza massima;
se il pacchetto e` stato spedito da un programma per la posta,
quest'ultimo non riceve mai risposta dal server SMTP e quindi va in
time-out. Con Agora` non ci sono problemi perche' Agora` usa MTU=576;
altrettanto faceva (e forse fa tuttora) IOL.
Che questa sia la giusta spiegazione e` provato da quello che succede
quando entro in Telnet su Agora` usando la vecchia interfaccia in
emulazione di terminale della BBS. Qualunque sia il provider con cui
faccio il collegamento in PPP, uso quasi sempre questo metodo per
spedire (e scaricare) la posta. Posso mettere tutti i messaggi in
un singolo file (anche di parecchie decine di Kb) e semplicemente
fare l'upload del file.
Quando sono in collegamento PPP con Agora` uso ZMODEM per l'upload
e tutto funziona perfettamente. Ma se sono collegato con Libero
o Tiscali e uso ZMODEM (che spedisce il file in lunghi segmenti)
l'upload fallisce; ZMODEM non riceve conferma del buon esito della
trasmissione e ricomincia a trasmettere il file (a quel punto lo
cancello).
Cosi`, se non sono connesso con Agora`, uso XMODEM CRC per fare
l'upload, che va a buon fine sia pure piu` lentamente. La ragione e`
che XMODEM spezza il file in segmenti di 128 byte e questi riescono a
"passare", sia che partano ognuno per proprio conto, sia che vengano
raggruppati in blocchi (128*4=512).
Individuato il problema, naturalmente ho cercato di trovare il
modo di risolverlo. Ho pensato di essere vicino alla soluzione
quando sono riuscito a localizzare il manuale che descrive i
parametri di PCTCP.INI, il file di inizializzazione di PC/TCP
(si chiama PCTCP.SHV in IE). Il manuale, un malloppo di 260Kb,
e` sul sito della Netmanage, che ha assorbito FTP Software:
http://supportweb.netmanage.com/manuals/param.asp
Il manuale e` interessante e mi ha permesso di scoprire alcuni
importanti dettagli (il quadro della situazione che ho dato sopra
non mi era affatto cosi` chiaro prima che leggessi il manuale).
Purtroppo e` pero` emerso che non esiste alcun parametro che permetta
di cambiare il valore di default di MSS. Questo non e`, in realta`,
un difetto del software e la mancanza di un simile parametro non crea
problemi, in circostanze normali.
Infatti la procedura con cui si stabilisce un collegamento prevede un
fase di "contrattazione" con la quale si determina un valore di MTU
accettabile per entrambe le parti. Per default la contrattazione e`
abilitata in PC/TCP (esiste un parametro 'mtu-discovery=no' proprio per
disabilitarla); evidentemente non lo e` nel software dei provider, che
pare forzi MTU=552.
Non sono un esperto di protocolli e quindi non posso escludere che
ci siano validi motivi tecnici dietro questa scelta. Pero` mi sembra
davvero strano che il software del provider non possa "negoziare",
almeno nei limiti entro cui si negoziava il colore del modello T della
Ford. Il software potrebbe dire: "mi va bene qualunque valore di MSS
purche' sia 512" e non ho dubbi che PC/TCP si adeguerebbe. Ma si sa
come vanno le cose: basta che il software funzioni per Windows 9X...
Tanto per provare, visto che il numero 536 compare una sola volta in
FTPCFG.DLL (che inizializza lo stack), l'ho sostituito con 512, senza
alcun risultato (il programma non e` nemmeno saltato per aria!). Si
vede che il valore e` "cablato" in altre parti del programma. Non provo
nemmeno a scrivere alla Netmanage perche' sarebbe solo una perdita di
tempo: chi si occupa piu` di Windows 3.1X?
In conclusione, per chi vuole usare un provider gratuito con Windows
3.1X ci sono due possibilita`:
- trovare (se esiste) un provider che usi MTU=576. Io ho verificato
  solo Tiscali, Libero e Clubnet. Il modo piu` semplice per reperire
  l'informazione e` leggere le istruzioni del provider per Linux;
- acquistare Trumpet Winsock, che permette di variare MSS e MTU.
Spero che questo lungo e tedioso messaggio possa almeno servire
ad evitare ulteriori frustrazioni a quanti si rifiutano, molto
saggiamente, di usare Windows 9X.
-- 
   Gianfranco Boggio-Togna
   Milano 

    Milano
Bè, mi hai chiarito una questione che quest'estate mi ha fatto impazzire.
Solo che io mi collegavo sia con Tiscali che con Iol, e mi dava comunque il
problema.
Ho risolto poi con Clubnet.
Non ho mai voluto usare il Winsock perchè da quando c'è il PAP è un'impresa
configurarlo e riuscire ad usarlo.
Ciao
Mauro

configurarlo e riuscire ad usarlo.
Credo che con Winsock tu intendessi riferirti al Trumpet: ebbene in
presenza di autenticazione PAP o CHAP la configurazione di Trumpet
diventa addirittura banale,  elementare. Quali sono le difficolta'?
Salvatore (
micr...@tiscalinet.it
)

Salvatore ha scritto:

Avevo la ver. 2.0 che mi era stata fornita da un piccolo provider al quale mi
collegavo tempo fa con un'emulazione di Win 3.x sotto OS2.  Il problema non era
l'emulazione, che andava bene, ma il fatto che i comandi che fino ad allora
avevano funzionato senza la modalità PAP non mi fu più possibile usarli invece
in quella modalità.  Lessi delle istruzioni aggiuntive ma erano complicate, mi
persi subito.
Ciao
Mauro


Non ho sottomano la versione 2.xx, quindi cerco di chiarire la questione
riferendomi alla versione 3.0d.
1) Lancia Trumpet
2) Vai nel menu con alt-dialler/server: cancellare tutto cio' che si
trova in corrispondenza dei campi: username prompt,...., ppp
command,..... 
3) Vai nel menu alt-dialler/modem, cancella i campi in corrispondenza
dell'username e della password, inserisci il numero di telefono.
4) Vai nel menu File/PPP options e inserisci qui username, password,
scegli se usare CHAP o PAP.
5) Vai in File/Setup per completare L'unico parametro che in genere e'
un po' difficile da rintracciare e' la presenza o meno di compressione
VJ; gli altri parametri MTU, etc.. vanno lasciati al loro valore di
default: funzionano bene nella maggior parte dei casi. Seleziona il
protocollo PPP. Se vuoi fare le cose per bene vai a recuperare i valori
incerti nelle pagine di help per i collegamenti sotto Linux.
E' tutto.
Salvatore (
micr...@tiscalinet.it
)