Network FAQ

Network FAQ
a cura di Massimiliano Crippa

Questa pagina vuole essere un aiuto a chi, superato il primo impatto con Windows 95, vuole cominciare a conoscere più a fondo questo sistema operativo, in particolare il suo supporto TCP/IP sia per il collegamento a Internet via modem che via rete locale (o entrambe le cose). Si tratta di una sintesi in italiano di quello che ho potuto trovare nelle Windows 95 Networking FAQ e nei newsgroup relativi a reti e Windows 95, presenti sul news server di Italia Online:

comp.os.ms-windows.networking.misc
comp.os.ms-windows.networking.ras
comp.os.ms-windows.networking.tcp-ip
comp.os.ms-windows.networking.win95
comp.os.ms-windows.networking.windows
microsoft.public.win95.dialupnetworking
microsoft.public.win95.networking

Anche la Knowledge Base di Microsoft è una fonte preziosa di infromazioni. Le parole chiavi più significative per le ricerche sono: kbnetwork, kbprb, 3rdPartyNet, win95 e network not kbnetwork. Nel Windows 95 Resource Kit che trovate sulla versione cdrom di Windows 95 (nella directory Admin\Reskit\Helpfile) o presso il sito Microsoft, troverete informazioni su come configurare il protocollo TCP/IP: nella finestra dei contenuti digitate tcp, poi scegliete Configuring, poi Display e infine premete il bottone >> sei volte fino alla pagina chiamata TCP/IP Registry Entries in the MSTCP Subkey. Si tratta comunque di informazioni per utenti esperti.

Kernel32 Update

Il Kernel32 Update dell'11 Aprile 1996 risolve il problema di perdita di memoria che avviene quando si apre o chiude una socket, usando le Windows Sockets API, causato dal kernel di Windows 95 (Kernel32.dll, versione 4.00.950).

Senza questo update, usando applicazioni di connessione a Internet, le vostre risorse si ridurranno progressivamente. Lo swapfile potrebbe crescere di molto, diminuendo le performance e la stabilità del sistema.

Esiste una versione italiana di questa patch, reperibile sempre presso la Microsoft.

Impostare MTU (MSS) e RWIN

MTU e RWIN sono nascosti in due posizioni differenti all'interno del Registro. MTU può essere impostato differentemente per ogni accoppiata (binding) scheda-protocollo; RWIN è impostato globalmente. Windows 95 usa di default il più grande valore possibile per MTU.

Per MTU, aprite il Registro alla voce:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\NetTrans\
Dovete capire quale chiave (cioè una delle sottodirectory nominate 000n) si riferisce all'accoppiata che vi interessa, leggendo le stringhe e i valori sottostanti, quindi aprirla. Qui dentro create una nuova stringa, configurata come segue:

MaxMTU = (numero a 16 bit)
Il valore deve essere raccomandato dal provider. 1500 è il valore di default; a volte alcuni server sembrano lavorare meglio con il valore 1002; il valore più basso che potete mettere è 552. In generale, usate il più alto MTU che la vostra macchina può supportare senza andare in overrun. Il problema è che la linea si adatta sul più piccolo valore MTU lungo tutto il link fino al server da voi richiesto, cioè sul valore MTU del sito più lento tra quelli dove passano i vostri dati. Se state aspettando da parecchio tempo l'arrivo della vostra pagina da Netscape e premendo il pulsante Stop la pagina viene visualizzata, dovete abbassare un parametro nel setup del winsock, MTU. Provate addirittura a dimezzarlo.
Per quanto è possibile sapere, non c'è modo di impostare il parametro MSS, ma siccome si suppone che questo corrisponda a MTU-40, Windows 95 dovrebbe derivare automaticamente il suo valore dal parametro MTU.

Per RWIN, aprite il Registro alla voce:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP\
Create una nuova stringa, configurata come segue:

DefaultRcvWindow = (numero a 16 bit)
Il valore deve essere pari a 4 volte la somma MTU+24. Il valore sarà raccomandato dal provider, in accordo con i valori degli altri parametri, in particolare MSS. Il valore di default 8192 funziona ma spesso fa rallentare la connessione e può portare anche ad una situazione di stallo. Tutti i valori compresi tra 8192 e 4096 non funzionano. Il valore 4096 funziona bene senza portare a situazioni di stallo. Provate anche 2048 o 1024 e vedete quale sembra funzionare meglio.

Potete utilizzare due file già pronti per modificare i parametri MTU e RWIN, file disponibili presso Windows 95 Internet Headquarters. Per introdurre queste modifiche nel Registro scegliete la voce Installa col tasto destro del mouse oppure cliccate due volte su ogni file .reg. Ovviamente prima di installarli potete modificare i valori che contengono.

Un bug di Netscape

Netscape 1.2N e seguenti, nelle versioni a 32 bit, non si mette in pausa quando riceve i messaggi TCP RESET e ICMP unreachable; continua a ritrasmettere all'infinito, senza timeout. Mentre si è su una connessione via modem (dial-up), questo bug causa delle fastidiose situazioni di stallo che inducono l'utente a premere prima il tasto Stop e poi Reload un sacco di volte, ma può causare la distruzione di pacchetti di dati quando si è su una rete Ethernet o altri link a larga banda. Consultate in proposito un articolo delle Network FAQ. Potete provare a sperimentare la situazione di cui sopra con questi due indirizzi:

http://ftp.netscape.com
http://36.36.0.10

Al primo indirizzo corrisponde un TCP RESET, mentre al secondo (che non esiste) corrisponde un ICMP unreachable.

Netscape 2.x cerca di aggirare il problema andando in timeout, ma questo non sempre funziona. Sembra inoltre che caricare più sessioni faccia andare in stallo il caricamento di alcune pagine, costringendo al solito Stop o Reload. Se accade spesso, settate il numero massimo di connessioni simultanee a 1 nelle Network Preferences. Questa può essere una soluzione pratica per le connessioni dial-up, ma diventa dispendioso (un inutile rallentamento nel caricamento delle pagine) per le connessioni via LAN. Questo secondo problema sembra dovuto però a un bug nello stack TCP/IP di Windows 95, non a Netscape. L'Internet Explorer aggira il problema, ma la Microsoft non ha fornito le informazioni che possono permettere agli altri di fare altrettanto.

TTL bug

Alcuni siti risultano irraggiungibili con Windows 95 perchè il TTL è impostato a 32 hops. Siccome Internet è cresciuta, l'indicazione dei router include spesso più di 32 hops, dovete perciò aprire il Registro alla voce:

Hkey_Local_Machine\System\CurrentControlSet\Services\VxD\MSTCP
Create una stringa chiamata DefaultTTL con un valore più alto, magari 128.

Stefano Barni, ci ha scritto quanto segue:

Esiste un problema che ha un effetto analogo al TTL bug, ma una causa diversa.

Talvolta capita di non riuscire a raggiungere un host: il browser risponde che il server non ha una DNS entry: è un modo criptico per dire che il servizio DNS (Domain Name Search) non è riuscito a risolvere il nome del server in un indirizzo IP.
Se si è sicuri di avere scritto correttamente il nome del sito a cui ci si vuole connettere, è probabile che uno dei server DNS tra noi e il server remoto abbia problemi (è down, o semplicemente busy). In questi casi è possibile aggirare il problema sostituendo al nome del server il suo indirizzo IP.
In generale, l'utilizzo dell'indirizzo numerico è più efficiente dell'indirizzamento per nome, almeno alla prima connessione col sito, perché viene evitata la trasformazione del nome nell'indirizzo stesso. Una verifica può essere fatta col comando ping, il quale consente di verificare se il nodo all'indirizzo specificato è vivo.

Come fare a conoscere l'indirizzo di un server? Windows 95 implementa il protocollo ARP (Address Resolution Protocol), che può essere sfruttato allo scopo. Il comando

arp -a
fornisce tutti gli indirizzi IP nella arp cache, cioè gli indirizzi delle macchine che il protocollo tcp/ip ricorda di avere contattato di recente. Quindi basta connettersi ad un sito, ad esempio mediante Netscape, aprire una finestra dos e dare il comando visto sopra per conoscere l'indirizzo IP del server che ospita quel sito.

L'indirizzo può essere memorizzato nel file C:\WINDOWS\HOSTS (la cui sintassi è descritta nel file C:\WINDOWS\HOSTS.SAM) per fare in modo che sia disponibile in modo permanente. Modificando la priorità di risoluzione dei nomi (come descritto altrove in questo documento) in modo che Windows 95 esamini per primo il file HOSTS si può evitare che il problema si ripresenti.

Inutili rallentamenti

Può aiutare disabilitare la compressione nel vostro modem; consultate il manuale del vostro modem e inserite la stringa appropriata nelle proprietà della vostra connessione di accesso remoto sotto Modem | Advanced Properties | Extra Settings.

Potete anche tenere disabilitata l'opzione Attiva compressione sotto Accesso Remoto | Proprietà | Tipi di server | Opzioni avanzate.

Problemi di path

Se le vostre applicazioni a 32 bit funzionano solo fornendo un indirizzo IP (non con l'indirizzo DNS), può darsi che il file wsock32.dll sia giustamente nella path, ma risulti errata la seguente chiave nel Registro:

Hkey_local_machine\System\CurrentControlSet\Services... ...\VxD\MSTCP\ServiceProvider
Il valore normale è %WINDIR%\SYSTEM\WSOCK32.DLL. Potete spostare wsock32.dll nella vostra directory WINDOWS\SYSTEM oppure specificare la giusta posizione nel Registro. A volte il Registro sbaglia e va a cercare la directory C:\SYSTEM, in questo caso potete risolvere creando questa directory e mettendo qui il file wsock32.dll.

Come risolve il nome di un sito

L'ordine di default per la ricerca del nome di un sito è: broadcast - WINS - DNS - LMHOSTS. In molti casi questa non è la soluzione migliore, anzi l'opposto sembra quasi perfetto. Andiamo alla seguente chiave del Registro:

Hkey_Local_Machine\System\CurrentControlSet\Services... ...\VxD\MSTCP\ServiceProvider
Le voci seguenti specificano le varie priorità. Un valore basso significa alta priorità. I valori riportati sono quelli di default.

LocalPriority = 499
HostsPriority = 500
DNSPriority = 2000
NetbtPriority = 2001

DNS lookup timeout

Questo timeout è ridicolmente lungo. Molte applicazione bloccano la macchina durante un DNS lookup, la cosa è già abbastanza scocciante ma a questo si aggiunge il lungo timeout, specialmente con alcuni DNS Server. Il parametro NameSrvQueryTimeout del Registro sembra riguardare solo i WINS Server di Microsoft, non i DNS Server standard su Internet.

Parametri del protocollo TCP/IP

Aprite il Registro alla voce:

Hkey_Local_Machine\System\CurrentControlSet\Services\VxD\MSTCP
e modificate se necessario queste chiavi:

BroadcastAddress = (esadecimale)

Specifica l'indirizzo da usare per il name query broadcasts su NetBIOS. Il valore di default è basato sull'IP address e la subnet mask.

BcastNameQueryCount = (decimale)

Specifica il numero di volte che il sistema deve ritentare il name query broadcasts su NetBIOS. Il valore di default è 3.

BcastQueryTimeout = (millisecondi)

Specifica il periodo di tempo che il sistema aspetterà prima di andare in timeout sulle broadcast name queries. Il valore minimo è 100. Il valore di default è 750.

BSDUrgent = 0 o 1

Se la variabile ha valore 1, il TCP/IP tratterà i dati urgenti come su alcune macchine Unix (con un massimo di 1 byte di dati urgenti). Se il valore è 0, lo stack tratterà i dati urgenti secondo le specifiche RFC 1122. Il valore di default è 1.

CacheTimeout = (millisecondi)

Specifica per quanto tempo sono tenuti in cache i nomi NetBIOS. Il minimo è 60000 millisecondi (1 minuto). Il valore di default è 360000 millisecondi (6 minuti).

DeadGWDetect = 0 o 1

Specifica se il TCP/IP deve usare un altro gateway quando quello corrente sembra essere down. Il valore di default è 1.

DefaultRcvWindow = (numero a 16 bit)

Specifica la DefaultReceiveWindow. Il valore di default è 8192.

DefaultTOS = (numero a 8 bit)

Specifica il tipo di servizio di default per i pacchetti IP avviati dal TCP/IP. Il valore di default è 0.

DefaultTTL = (numero a 8 bit)

Specifica il tempo di latenza (TimeToLive) per i pacchetti IP. Il valore di default è 32.

DnsServerPort = (porta)

Specifica quale porta del server DNS deve essere usata per inviare le query per la risoluzione dei nomi. Il valore di default è 53.

EnableProxy = 0 o 1

Il valore 1 specifica che il computer è un WINS proxy agent. Il valore di default è 0.

EnableRouting = 0 o 1

Specifica se è abilitato lo static routing. Il TCP/IP di Microsoft non fornisce un protocollo di routing, così tutte le table entries per il routing devono essere immesse usando il comando route. Il valore di default è 0.

IGMPLevel = 0, 1, o 2

Specifica il tipo di supporto per l'IP multicast, per maggiori informazioni vedere il documento RFC 1112. Il valore di default è 2.

InitialRefreshT.O. = (millisecondi)

Specifica l'intervallo ogni quanto viene contattato il server WINS per l'aggiornamento dei nomi. Il valore minimo è 16 minuti, quello massimo circa 50 giorni (0xFFFFFFFF). Il valore di default è quello minimo (960000 millisecondi).

KeepAliveTime = (numero a 32 bit)

Specifica l'idle time per la connessione (in millisecondi) prima che il TCP/IP inizi a mandare segnali di keepalives, se questa opzione è abilitata. Il valore di default è 2 ore (7200000).

KeepAliveInterval = (numero a 32 bit)

Specifica il tempo in millisecondi tra due trasmissioni del segnale di keepalives, una volta che il valore di KeepAliveTime è trascorso.
Le trasmissioni avvengono fino a quando si riceve una risposta, fino ad un numero massimo di volte specificato dalla variabile MaxDataRetries dopodiche' la connessione viene interrotta. Il valore di default è 1 secondo (1000).

LmhostsTimeout = (millisecondi)

Specifica il periodo di tempo che il sistema aspetterà prima di andare in timeout quando cerca in LMHOSTS la risoluzione di un nome. Il valore minimo è 1000 (1 secondo). Il valore di default è 10000 (10 secondi).

MaxConnections = (numero a 32 bit)

Specifica il massimo numero di connessioni contemporanee. Il valore di default è 100.

MaxConnectRetries = (numero a 32 bit)

Specifica il numero di volte che un tentativo di connessione (SYN) verrà ritrasmesso prima di abortire. Il timeout iniziale è 3 secondi, che viene poi raddoppiato ogni volta fino ad un massimo di 2 minuti. Il valore di default è 3.

MaxDataRetries = (numero a 32 bit)

Specifica il massimo numero di volte che un segmento di dati o un FIN verrà ritrasmesso prima che la connessione sia abortita.
Il timeout stesso è adattivo e varierà in accordo con le condizioni della connessione. Il valore di default è 5.

NameServerPort = (porta)

Specifica la porta UDP sul name server alla quale mandare le query o le registrazioni. Il valore di default è 137.

NameSrvQueryCount = (numero intero)

Specifica il numero di volte che il sistema tenterà di contattare il server WINS per la risoluzione dei nomi su NetBIOS. Il valore di default è 3.

NameSrvQueryTimeout = (millisecondi)

Specifica per quanto tempo il sistema aspetterà prima di andare in timeout su una query al name server. Il valore minimo è 100.
Il valore di default è 750.

NameTableSize = (numero intero)

Specifica il massimo numero di nomi nella tabella dei nomi NetBIOS. Il valore minimo possibile è 1 e quello massimo 255. Il valore di default è 17.

NodeType = 1, 2, 4, o 8

Specifica il modo di risoluzione dei nomi NetBIOS usato da NetBIOS sopra TCP/IP, dove 1 = b-node, 2 = p-node, 4 = m-node, e 8 = h-node.
Questo valore può essere configurato usando DHCP. Il valore di default è 1 (b-node), se nessun valore è specificato; se un server WINS è specificato e NodeType non lo è, allora il valore di default è 8 (h-node).

PMTUBlackHoleDetect = 0 o 1

Specifica se lo stack cercherà di stabilire il Maximum Transmission Unit (MTU) dei routers che non rimandano i messaggi ICMP relativi alla frammentazione.
Impostare questo parametro quando non è necessario può causare un decadimento delle prestazioni. Il valore di default è 0.
Se però non riuscite a mandare mail o articoli nei newsgroup che siano più lunghi di 10 righe circa, o se non potete fare degli upload tramite FTP, allora dovete modificare questa stringa, impostando come valore 1.
Può essere utile modificare anche la stringa seguente. Purtroppo Microsoft è piuttosto confusa su questo punto. Nella Knowledge Base si dice di assegnare a questa variabile valore 1, ma così facendo non cambia nulla.
Dovete assegnarle valore 0. Impostare MTU a un valore ridicolmente basso è un altro modo per risolvere il problema, ma va a scapito della performance, eccetto che nei collegamenti dialup dove un valore MTU di 576 potrebbe essere una buona idea con modem non molto performanti.

PMTUDiscovery = 0 o 1

Specifica se il TCP/IP tenterà un path MTU discovery, come specificato nel documento RFC 1191. Il valore di default è 1.

RandomAdapter = 0 o 1

Per un computer con più schede di rete, specifica se rispondere con un indirizzo IP selezionato casualmente dal set disponibile o ritornare l'indirizzo IP della scheda da cui viene la richiesta. Il valore di default è 0 (non casuale).

RoutingBufSize = (numero a 32 bit)

Specifica l'ammonatare del buffer per allocare i pacchetti per il routing. Questo parametro è ignorato se EnableRouting=0. Il valore di default è 73216.

RoutingPackets = (numero a 32 bit)

Specifica il numero massimo di pacchetti che possono essere ruotati simultaneamente. Questo parametro è ignorato se EnableRouting=0. Il valore di default è 50.

SessionKeepAlive = (millisecondi)

Specifica ogni quanto mandare i pacchetti keepalive nella sessione attiva. Il valore minimo è 60 secondi. Il valore di default è 3600 secondi (1 ora).

SessionTableSize = (numero intero)

Specifica il numero massimo di sessioni per la tabella delle sessioni NetBIOS. Il valore minimo possibile è 1 mentre il massimo è 255. Il valore di default è 255.

SingleResponse = 0 o 1

Per un computer con più schede di rete, specifica se mandare tutti gli indirizzi IP in risposta ad una query su server WINS.
Se questo valore è 1, il sistema manderà un indirizzo per ogni risposta alla query; se è 0, ritornerà tutti gli indirizzi delle schede. Il valore di default è 0.

Size/Small/Medium/Large = 1, 2, o 3

Specifica quanti buffer di vario tipo verranno preallocati e il massimo numero che può essere preallocato, dove 1 = small, 2 = medium, e 3 = large. Il valore di default è 1 ma diventa 3 se un proxy WINS è attivo.

Disabilitare il DNS per la risoluzione WINS

Windows for Workgroup e Windows NT hanno l'opzione Enable DNS for WINS resolution che è disabilitata di default. In Windows 95 questa opzione è abilitata di default e non c'è la possibilità di disabilitarla.
C'è però una voce nel Registro per questo: EnableDNS. Se la disattivate, il DNS sarà ancora abilitato; semplicemente non sarà usato per la risoluzione WINS (NetBIOS).
Questo è il motivo per cui definiamo Windows 95 intuitivo. Nell'articolo Q137368 della Microsoft Knowledge Base leggiamo che la chiave incriminata si trova sotto:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP
e dobbiamo impostarla a 0.

Windows 95 supporta l'IP Multicast

Secondo Microsoft, c'è una voce nel Registro per stabilire il livello di supporto di questa funzione.
Tuttavia non si conosce una sola applicazione che si avvantaggi di questo. Il supporto per l'IP multicast, che dovrebbe essere lo stesso su Windows 95 e Windows NT, è descritto in un documento presente sul sito ftp della Microsoft (ndr: faccio notare che sono 211 KB). Bob Quinn ha scritto altre interessanti informazioni.

Come ottenere il nome DNS via DHCP

Dovete configurare le proprietà del TCP/IP su Disattiva DNS. Questo non disattiva il DNS; semplicemente dice a Windows 95 di usare l'hostname, il DNS server e il dominio ottenuti dalla risposta del server DHCP. Anche la voce Enable DNS del Registro è piuttosto ambiguo.

Timeout sull'assegnazione dell'indirizzo IP da un server DHCP

L'implementazione del DHCP in Windows 95 non sembra essere standard. Il client DHCP dovrebbe aspettare di ricevere dal server un indirizzo per un tempo ragionevole. Il client Microsoft non aspetta molto a lungo. Microsoft però sembra non sentire ragioni.

Problemi con la libreria winsock.dll

Se state usando una libreria non Microsoft, non avrete problemi se il programma installa la sua libreria proprietaria nella directory del programma.
Vedete quanto ha da dire la Microsoft in proposito. Anche la libreria Microsoft però non è esente da problemi.
La soluzione è assicurarsi che l'unica copia originale di winsock.dll sia nella directory %WINDIR% (ad esempio C:\WINDOWS) e che sia marcata a sola lettura.

Microsoft TCP/IP è lento

Il problema è che quando usate il protocollo di Windows 95, state usando in realtà due stack, lo stack TCP/IP della Microsoft e lo stack per l'accesso remoto sviluppato da Shiva Corporation, così avrete sicuramente una perdita di prestazioni.
Per migliorare le cose provate a disabilitare la compressione software nelle proprietà del TCP/IP.

Accesso Remoto a linea di comando

Potete lanciare una sessione di Accesso Remoto lanciando il comando:

rundll32.exe rnaui.dll,RnaDial nome_della_connessione

PPP via null modem

Dovete creare un file .inf per il null modem, siccome Microsoft non ha pensato a questo. Fortunatamente Kevin Wells ha postato un modello per questo file.

Disabilitare la compressione IP

Se aprendo il file di log del PPP riscontrate un errore su protocol 80fd la soluzione potrebbe essere questa.

Togliere l'icona Posta in arrivo

Togliere l'icona The Microsoft Network

In teoria basterebbe andare nel Pannello di controllo e scegliere Installazione applicazioni, selezionare Setup di Windows 95 e togliere la spunta da The Microsoft Network, ma non sempre funziona.
Una cosa che potete provare è reinstallare e poi provare di nuovo a disinstallarlo. Per maggiori informazioni, vedere il Resource Kit di Microsoft.

Togliere l'icona Risorse di rete

Usando il Policy Editor, potete impostare delle restrizioni per gli utenti, tra cui non far comparire questa icona.
Per maggiori informazioni, vedere il Resource Kit di Microsoft o Windows 95 Annoyances.
Potete usare anche l'utility TweakUI disponibile sempre presso Microsoft. Potete anche modificare direttamente il Registro:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion... ...\Policies\Explorer
Aggiungete la stringa:

NoNetHood 00000001

Password caching

Windows 95 salva tutte le password di rete e per il collegamento via modem in un file .PWL facilmente leggibile. Microsoft ha risolto il problema della decriptazione con una patch prelevabile via Internet.
Potete però anche decidere di disattivare questa opzione, usando il Policy Editor, o modificando direttamente la seguente chiave nel Registro:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\...
...Policies\Network\DisablePwdCaching
mettendo come valore 1.
Oppure eseguite il seguente script che andrà a modificare per suo conto il Registro.
Salvatelo come NOCACHE.REG e premendo col tasto destro del mouse scegliete Installa.

REGEDIT4
[HKEY_LOCAL_MACHINE\SOFTWARE\...
...Microsoft\Windows\CurrentVersion\Policies\Network]...
..."DisablePwdCaching"=dword:00000001

Errori di trasmissione con Sound Blaster

Creative Labs ha realizzato dei nuovi driver per risolvere i problemi di multitasking che causano perdite di dati con connessioni sia di rete sia via modem.

Due connessioni di Accesso Remoto

Secondo alcuni dovete inserire tutti i server DNS utilizzati per le connessioni di Accesso remoto nelle Proprietà del Driver di Accesso remoto nell'icona Rete del Pannello di controllo o quello che avete impostato nella connessione di Accesso remoto verrà ignorato.
Altri sostengono che si debba impostare il meno possibile nel Pannello di controllo, quindi nessun server DNS, gateway o altro.
In un sistema operativo efficiente, le proprietà di una connessione dovrebbero soppiantare quelle standard impostate nel Pannello di controllo.
Un metodo complesso ma efficacie è questo: inserite tutte le configurazioni per uno dei vostri provider e salvate poi quella parte del Registro che contiene la configurazione del TCP/IP in un file .reg; ripetete poi la procedura per le altre connessioni che volete attivare. Ora avete delle configurazioni complete che potete installare al momento opportuno con semplice doppio clic del mouse.
La parte del Registro di Windows 95 che contiene questi parametri sono le seguenti:

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP]
e
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\NetTrans\]

Far convivere LAN e Accesso Remoto

Prima di tutto dovete tenere in mente che il protocollo TCP/IP è configurato per la macchina nel suo complesso e per ogni tipo di connessione separatamente.
Queste due configurazioni sono interrelate ma distinte. Installate il protocollo TCP/IP per ogni tipo di connessione, sia locale sia via modem.
Nelle Proprietà dell'abbinamento TCP/IP > Driver di Accesso remoto, azzerate tutti i parametri come server DNS e indirizzo IP.
Controllate alla voce Bindings che le accoppiate siano esatte. Non mettete nessun dato che riguarda la connessione via modem nell'icona Rete del Pannello di controllo, ad esempio indirizzo IP, server DNS, gateway.
Configurate questi stessi parametri in ogni connessione di Accesso remoto.
Nell'icona Rete del Pannello di controllo configurate i dati della rete locale: l'indirizzo IP statico, la netmask, il gateway e il server DNS. Non impostate nient'altro tranne l'Host name, richiesto ma non utilizzato dal TCP/IP.
Se impostate l'opzione Usa gateway predefinito sulla rete remota nella connessione di Accesso remoto mentre siete in rete locale, tutto il vostro traffico locale verrà dirottato (funzione di routing) sul modem al server remoto.
Una scheda di rete richiede due cose che non servono con il driver di Accesso remoto: subnet mask e default gateway. Una scheda di rete può convivere con più connessioni PPP (dial-up), tranne che per il fatto che l'opzione Usa Gateway predefinito sulla rete remota può essere usata solo se la connessione LAN è inattiva quando è attiva l'altra.
Ovviamente nel caso vogliate cambiare anche rete locale, ad esempio se usate un portatile, dovrete riavviare per modificare le impostazioni del Pannello di controllo.
Sembra però che le informazioni inserite nella connessione di Accesso remoto vengano ignorate se nell'icona Rete del Pannello di controllo sono presenti impostazioni; la stessa cosa tentando di utilizzare due schede di rete: cambiare le impostazioni di una delle due cambia anche l'altra.
Forse la soluzione migliore è intervenire sulla tabella di routing, il comando route su Windows 95 è ben implementato.
Togliete ogni impostazione dei server DNS nel Pannello di controllo, aggiungete delle voci nella tabella per il routing, una voce per ogni macchina che appartiene alla LAN, aggiungete cioè una voce nel file LMHOSTS.SAM che si trova nella directory Windows e rinominatelo poi LMHOSTS, abilitate il server DNS solo nelle Proprietà del Driver di Accesso remoto. Otterrete così accessi simultanei a macchine locali e remote senza problemi di risoluzione dei nomi.
L'unico problema è che chiamando una macchina locale per nome, invece che per indirizzo IP, apparirà la finestra dell'Accesso remoto.
Premendo Annulla, verrà letto il file lmhosts e la connessione riuscirà.
Vedete un'esempio di quanto detto. Secondo alcuni il fatto che l'indirizzo IP venga assegnato dal provider al momento della connessione (cioè quando si utilizza il protocollo PPP) è condizione sufficiente per far convivere connessione LAN e connessione RAS, resta solo da verificare.

Stefano Barni, ci ha scritto quanto segue:

Il problema della convivenza tra lan e accesso remoto l'ho risolto in questo modo: invece di generare un file LMHOSTS ho semplicemente scritto un batch che chiama più volte il comando route per aggiungere routing statici verso le reti remote che, scollegato da internet, vedo attraverso il default gateway impostato nel panello di controllo per il TCP/IP sulla scheda di rete locale. Le macchine sulla rete locale (cioè con indirizzo di net identico a quello della mia macchina) le vedo comunque anche senza routing statici.

La situazione è questa:

La parte da (PPP) in giù è ovviamente semplificata, presumo che ci sia una rete vostra e in qualche modo Italia Online fa da router verso internet. Io ho una scheda token ring sulla rete locale (LL), sulla quale sono bound sia IPX/SPX per netware, sia TCP/IP. Tramite (NW) posso vedere (LR1) e (LR2) (il router (R) per me è trasparente); in altre parole nel TCP/IP bound sulla token ring l'indirizzo di (NW) è usato come gateway di default. Se io mi collego a (IOL), nei parametri di connessione devo specificare di usare il gateway predefinito sulla rete remota: ovvio, perchè altrimenti il protocollo manderebbe tutti i pacchetti verso (INET) al vecchio gateway di default, che non saprebbe che farsene. Il risultato è che io potrei connettermi a (IOL), telnettarlo, etc, ma non riuscirei ad arrivare ad (INET). Invece, con quell'opzione settata, il mio gateway di default diventa (IOL), e quindi funziona internet. Posso ancora vedere tutte le macchine sulla (LL), perché la scheda di rete locale vi si affaccia direttamente, ma perdo di vista (LR1) e (LR2), perché i pacchetti per 160.110 e 160.11, non essendo locali, vengono inviati al nuovo gateway di default, cioè (IOL), che non sa che farsene (o meglio li manderà al suo gateway di default, se ne ha uno, e andranno prima o poi a morire in giro per il mondo). Se però col comando route di Windows 95 stabilisco dei percorsi statici per le (LR1) e (LR2), tutto funziona, ad esempio:

route add 160.110.0.0 mask 255.255.0.0 160.117.19.11
route add 160.11.0.0 mask 255.255.0.0 160.117.19.11

dove 160.117.19.11 è l'indirizzo di (NW), il quale conosce (R) come proprio gateway di default. Il fatto, poi, di avere gli indirizzi di IOL, NW e R nel file HOSTS è facoltativo e può facilitare i comandi route.

Connettersi automaticamente

Si può fare in modo di non dover premere il bottone Connetti nella finestra dell'Accesso remoto. Qui di seguito ne diamo un esempio, utilizzando un pezzo di codice Visual Basic:

x = Shell("rundll32.exe rnaui.dll,RnaDial nome_della_connessione", 1)
DoEvents
SendKeys "{enter}", True
DoEvents

Server WINS

I server WINS permettono di gestire Internet come fosse una rete peer-to-peer, cioè permettono di contattare siti che utilizzano come server Windows NT, utilizzando il protocollo NetBIOS sopra il TCP/IP.
Windows usa i nomi NetBIOS per la condivisione di file e stampanti e altri servizi di rete (dovete quindi installare il Client per reti Microsoft).
Essi convertono l'indirizzo IP in un nome nello standard NetBIOS. Se la vostra azienda o provider non ha un server WINS provate ad inserire nel Pannello di controllo questi server pubblici:

WINS primary: 204.118.34.6
WINS secondary: 204.118.34.11

Dovrete poi aggiungere delle voci al file LMHOSTS, simili a quella seguente che corrisponde al sito FTP della Microsoft:

198.105.232.1 ftp #PRE #Microsofts FTP site
Col Gestione Risorse potete poi connettere il sito Internet come fosse una unità di rete, inserendo un percorso del tipo:

\\ftp\data
Il parametro data è il nome della directory condivisa, solo i siti che condividono le directory possono essere contattati. Come nome NetBios del computer remoto ovviamente non potete tirare a indovinare o inventare voi un nome, dovete conoscere la giusta corrispondenza.
Potete anche premere il bottone Avvio, scegliere Esegui e poi digitare il nome NetBIOS. Riceverete come risposta il nome della directory condivisa sul sistema remoto. Scegliete il nome della directory e digitate la password.
Ricordatevi che questa connessione non sta mappando la directory con una lettera di drive. Ecco tutto quello che vi serve: l'indirizzo IP, il nome NetBIOS e la password.
Ogni macchina registrata sul server WINS manda ad intervalli regolari il proprio nome NetBIOS associato ad un indirizzo IP.
In sostanza è molto simile ad un server DNS, ma i nomi NetBIOS, diversamente da i nomi standard DNS, non sono gerarchici, non permettono il routing e questo può causare dei conflitti in caso due macchine assumano lo stesso nome.
Questo può essere un serio problema di sicurezza. Così come avete un file HOSTS per la risoluzione DNS, avrete un file LMHOSTS (LAN Manager Hosts) per la risoluzione WINS. Se non funziona questo secondo file, provate ad usare il primo. Microsoft afferma che il file LMHOSTS non è letto se la risoluzione DNS è attivata. Si tratta di un bug, che sembra risolversi installando il protocollo IPX.

Una opzione non impostata di default in Windows 3.11 permette di usare il server DNS per la risoluzione WINS quando il WINS lookup è disabilitato o ha fallito. In Windows 95, questa opzione è ora di default ed esiste soltanto una voce non documentata nel Registro (EnableDNS) per disabilitarla. Siccome NetBIOS non è gerarchico, potete navigare soltanto all'interno del dominio.

Se due macchine hanno lo stesso nome NetBIOS non può che nascere confusione, vi collegherete all'ultima macchina che ha inviato i suoi dati al server WINS.

(ndr: Ho implementato personalmente quanto scritto e ho verificato che impostando i server si hanno dei problemi, mentre configurando soltanto il file LMHOSTS funziona tutto bene, ma molto lentamente. Per quello che ho visto non è conveniente implementare un server di questo tipo)

Negoziazione PPP

Microsoft riporta problemi con la negoziazione PPP quando il Client per reti Microsoft è installato. Inoltre l'implementazione Microsoft della compresione dell'IP header è incompatibile con il PPP di alcuni tipi di server.

Problemi di routing

Windows 95 si ricorda il routing. Se avete un portatile con scheda di rete che utilizzate per collegarvi in ufficio e poi usate l'Accesso remoto per collegarvi da casa, la connessione tenterà di usare il gateway predefinito. Usate il comando ROUTE PRINT per vedere se il routing è corretto e il comando ROUTE -F per annullare quanto impostato. Se usate il protocollo DHCP, Windows 95 cercherà di riusare le stesse informazioni. Eseguite WINIPCFG per aggiornarle.

Protocollo DHCP

DHCP sta per Dynamic Host Configuration Protocol. Lo scopo del DHCP è di permettere ai singoli computer su una rete TCP/IP di ottenere la propria configurazione da un server. In questo modo si dovrebbe ridurre il lavoro necessario per amministrare una rete di grandi dimensioni. Il protocollo DHCP è basato su BOOTP e mantiene una certa compatibilità con questo.
La differenza più importante è che il BOOTP era stato designato per richiedere l'inserimento manuale delle informazioni sull'host in un database sul server, mentre il protocollo DHCP permette l'allocazione dinamica degli indirizzi degli host. Il protocollo DHCP permette la riallocazione degli indirizzi con grande immediatezza. RARP è il protocollo usato da Sun e altri che permette al computer di trovare il proprio indirizzo IP, parametro che viene tipicamente passato al client dal DHCP o da BOOTP. RARP non supporta altri parametri e il server può configurare una sola rete locale. DHCP e BOOTP sono realizzati per permettere il routing.
Questo modo di assegnare gli indirizzi ha però degli svantaggi. Il protocollo DHCP può supportare indirizzi IP statici. Un client BOOTP può ricevere istruzioni da un server DHCP solo se il server DHCP è scritto specificamente per supportare query BOOTP.
A sua volta un client DHCP può ricevere istruzioni da un server BOOTP solo se il client DHCP è scritto specificamente per far uso delle risposte di un server BOOTP. Lo stack TCP/IP incluso in Windows 95 non ha questa capacità.
Un client DHCP non può aggiornare il proprio DNS attraverso il protocollo DHCP, anche se in sé ne avrebbe le potenzialità.
Il supporto SLIP e PPP di Windows 95 non supportano il protocollo DHCP. Per avere maggiori informazioni, il primo posto dove guardare sono le DHCP Resources di Alan S. Dobkin. Potete anche seguire una mailing list sull'argomento, ce n'è più di una:

Mailing List Scopo

dhcp-v4@bucknell.edu Discussione generica

dhcp-bake@bucknell.edu DHCP bakeoffs

dhcp-impl@bucknell.edu Implementazioni

dhcp-serve@bucknell.edu Server to server protocol

dhcp-dns@bucknell.edu Integrazione DNS-DHCP

dhcp-v6@bucknell.edu DHCP per IPv6

Le mailing list sono eseguite da listserv@bucknell.edu, con cui dovete sottoscrivervi. È disponibile un archivio della dhcp-v4. Il protocollo DHCP è definito dai seguenti documenti ufficiali (RFC): RFC 1541, RFC 1534, RFC 1533.

Parametri del modem

Piccole modifiche al protocollo TCP/IP o ai parametri del modem causano il reset delle proprietà della vostra connessione di Accesso remoto ai valori di default, senza nemmeno avvertirvi. In genere questo significa cancellare le impostazioni del server DNS.

Password e sicurezza

Il modo in cui Microsoft cripta le password di connessione alle risorse di rete non è affatto sicuro. È possibile decifrare il codice senza molte difficoltà, infatti ci è riuscito persino David Ross, uno studente di un college americano senza nessuna esperienza nel campo della cifratura. Il codice da lui scritto riesce a decodificare una password per una risorsa condivisa, utilizzando il codice contenuto nel Registro alla voce:

[HKEY_LOCAL_MACHINE\SOFTWARE\...
...Microsoft\Windows\CurrentVersion\Network\LanMan]
La voce Parm1enc contiene la password per l'accesso completo, Parm2enc quella per la sola lettura.

Per risolvere il problema dovete installare il Service Pack 1 per Windows 95 oppure la sola patch per il caching delle password. Per maggiori informazioni vedete la pagina Hack Microsoft.