Newsgroup: it.comp.os.os2
Titolo: Problema con il browser

Questa e' una domanda per esperti di tcpip: ho installato in svista 
sia Win2000 che eComstation. 
In entrambi i casi, senza entrare (almeno per ora :-) in dettagli 
relativi alla configurazione dei vari nodi della mia retina locale, 
succede che il ping funziona, tracerte funziona, nslookup funziona, 
con ftp riesco a loggarmi ai siti ma qualunque azione finisce con un 
bel "service not available, remote server has closed connection" e 
http sta appeso delle ore in attesa di ricevere la pagina richiesta, 
senza mai ricevere un bel niente.
Questo accende qualche lampadina nella mente di qualcuno? :-)
-- 
ciao, Gabriele
[ 
http://www.ecomstation.it/xwp
 ]
[ 
http://www.ecomstation.it/ecsoft2/
 ]

 Questo accende qualche lampadina nella mente di qualcuno? :-)
ne accende tante..
ip forwarding attivato sul gateway?
indirizzo del gateway nella macchina virtuale settato giusto?
hopcount ecc..
-- 
Massimo
- eCS Irc Network   
irc.ecomstation.it
    chans: #eCS #eCSita   
- 
http://www.ecomstation.com
 
http://www.teamos2.it

 hopcount ecc..
nslookup nelle macchine virtuali cosa dice? trova qualcosa?
-- 
Antonio Manara Rossini (aka: WarpToy)
WSiTE: 
www.vrglabs.com
 - FiDONET: 2:332/807.14 - iCQ: 14586599 
PGP 5.0i key available.

 
trova tutto. Anche il ping funziona. E' essenzialmente http che non ne
vuole sapere!


 
Grazie dell'interessamento! Allora entro in dettagli :-) 
setup.cmd sul gateway:
route -fh
arp -f
ifconfig lo 127.0.0.1
ifconfig lan0 192.168.1.100 netmask 255.255.255.0 metric 1 mtu 1500   
<----- questa e' la mia rete locale
dhcpstrt -i lan1    <----- questa e' la connessione ad internet
route add 192.168.2.0 192.168.1.10    <----- questo e' per vedere dal 
gateway la macchina virtuale sull'host
ipgate on
setup.cmd sullo host della macchina virtuale:
route -fh
arp -f
ifconfig lo 127.0.0.1
ifconfig lan0 192.168.1.10 netmask 255.255.255.0 metric 1 mtu 1500    
  <----- questa e' l'indirizzo reale della scheda di rete
ifconfig lan1 192.168.2.1 netmask 255.255.255.0 metric 1 mtu 1500    
<----- questo e' virtuale, e qui su stanno le macchine Svista
route add default 192.168.1.100
ipgate on
setup.cmd all'interno della virtual machine:
route -fh
arp -f
ifconfig lo 127.0.0.1
ifconfig lan0 192.168.2.3 netmask 255.255.255.0 metric 1 mtu 1500
route add default 192.168.2.1        <----- questa e' la macchina host
route add -net 192.168 192.168.2.1 -hopcount 1
ipgate off
Mmh, appare evidente dal confronto (che faccio per la prima volta, mea
culpa) che non c'e' un "route add" uguale a un altro... io ho seguito 
le indicazioni dello wizard incluso in svista, ma di questa roba non 
capisco niente, sono sempre andato avanti a dhcp!
Devo aggiungere "route add -net 192.168 192.168.1.100 -hopcount 1" 
alla macchina host?


 capisco niente, sono sempre andato avanti a dhcp!
appunto, prova a dire al sistema GUEST di andare in DHCP. Se veramente 
SVISTA sta lavorndo in BRIDGE, il sistema Guest riuscira` ad ottenere un 
indirizzo IP dal tuo server DHCP e funzionara`.
Inoltre controlla le impostazioni di SVISTA. Su linux non riesce a 
creare reti virtuali o altro, ma lavora semplicemente in bridge.
(*) Bridge e` il nome che da VMWare alle reti "trasparenti", cioe` ogni 
guest e` come se fosse attaccato allo switch di casa (viene fatto un 
bridge sulla scheda di rete dei pacchetti). Le altre cfg che ha VMWare sono:
* NAT, in cui ogni guest viene nattato prima di andare sulla rete (come 
se le machcine virtuali fossero dietro un router collegato allo switch). 
  In questo caso il DHCP non funziona (richiede scambio pacchetti in 
modo  bidirezionale in UDP)
* Virtual, in cui il programma crea una rete virtuale tra guest e host. 
Il guest non puo` vedere il resto della rete (come se il mio PC avesse 2 
schede di rete una verso lo switch e l'altra verso il PC virtuale).
Diciamo che per la tua rete di casa la migliore e` usare la rete BRIDGE. 
La macchina virtuale risulta a tutti gli effetti attaccata al tuo switch 
e funziona come un pc stand-alone. Ora, non so se SVISTA la chiami 
BRIDGE, ma su linux e` cosi` che funziona (dopo mangiato guardo se 
supprta altri tipi di networking).
-- 
ciao, Mirco.
[ 
http://hellspawn.dnsalias.net/~mircomir/
 ] [ Icq#:51640305 ]
[ 
http://pido2.webhop.net/
 ]

 creare reti virtuali o altro, ma lavora semplicemente in bridge.
Svista/2 ha bisogno di stare in una sua sottorete.


 Svista/2 ha bisogno di stare in una sua sottorete.
a questo punto sorge spontanea una domanda: xche` per ogni SO (host) 
implementano SVISTA in modo diverso? Non mi sembra una cosa molto furba.


 
Premesso che le scatole mi stanno girando piuttosto rapidamente dato 
che ho speso tutta questa sera per cercare di fare andare questa roba 
che continua a non volerne sapere, e sicuramente rimpiango la 
facilita' d'uso del sistema di VPC, riporto comunque quanto nelle Faq 
di Svista/2, per tua curiosita':
NQ6: What are the advantages of Serenity Virtual Net Driver vs Filter?
NA6: There are many advantages:
      1. You can use any protocols with this driver. 
             // Filter requires modifications for every protocol.
             // Ethernet, Token-Ring, ISDN & WiFi will require own 
filters.
      2. The driver may be configured using MPTS and other standard 
         system tools.
             // Filter blocks scaling & extension of network;
      3. SVSNET doesn't have any restrictions in network construction;
             // Filter has some restrictions. 
      4. SVSNET doesn't conflict with drivers of network cards.
             // Filters may not work on WiFi network cards, etc.
      5. SVSNET may be used on computers without physical network 
card,
           by dial-up home users, instead of NULLNDIS.
             // Filter requires presence of physical network card 
             // (NULLNDIS doesn't suit);
      6. SVISTA project is friendly. You may install other virtual 
machine
         with network support. You may use SVSNET as physical card for
         its filters. 
 
     Disadvantages:
      1. SVSNET requires adjusting of routing information on all 
computers;
             // Filters require IP & MAC determination (routing 
rarely);


 di Svista/2, per tua curiosita':
[..]
Bah, non e` che mi dica molto su come e` implementato il tutto...


 
Apparentemente e' semplice: con MPTS installi, dopo la scheda di rete 
vera coi suoi protocolli, la scheda di rete virtuale di svista e ci 
colleghi i protocolli che preferisci. Fine.


 colleghi i protocolli che preferisci. Fine.
Vi ho seuiti un po'... praticvamente svista ti tiene eCS in una sottorete .2.x mentre
la tua rte e' tutta su 1.x? giusto? allora prova a lanciare routed nella
macchina che ospita svista oppure nel gateway di rete, che non ricordo
qual'e'. E' una prova, perche' in teoria, SE pinghi, non dovrebbe essere
necessario, non ricordo bene il protocollo rip come funzioni. 


 qual'e'. 
Prima di provare, a che servirebbe?
Comunque, ho fatto ulteriori esperimenti. Oltre all'http, non funziona
neanche l'upload via FTP. In compenso il download si'... mi sembra 
assurdo, ma a quel che vedo e' cosi': dalla virtual machine riesco a 
connettermi al server FTP sul gateway E a scaricare, ma non ad 
uplodare. L'upload inizia e poi resta appeso. Ci puo' essere un senso 
in questo?


 in questo?
Il routed e' il server rip di osso, serve, su macchine gateway per piu' reti, 
al routing degli ip tra le sottoreti. Ne avevamo parlato anche tempo fa, se 
ricordi. Ad ogni modo, non ti costa nulla lanciarlo, non devi configurarlo,
devi solo lanciarlo e vedere se cambia qualcosa. NON avendo
uno svista che funzioni, non capisco come faccia a metterti la macchina
virtuale su una sottorete differente dalla tua e pretendere che vada.
Il resto dei problemi "potrebbero" dipendere da questo, visto che
ftp e http lavorano su porte diverse tra upload e download...
Tutte supposizioni, se li avessi qui ti derei qualcosa con certezza....


 ipgate off
Non ti risolvera' il problema, comunque quel 
route add -net 192.168 192.168.2.1 -hopcount 1
mi sembra superfluo, perche' con 
route add default 192.168.2.1
dici di mandare _tutto_ al 192.168.2.1, che senso ha allora dire di
mandare roba per la rete 
192.168.0.0/16
 sempre allo stesso host? E'
implicito. Altre considerazioni in un altro messaggio.
-- 
Francesco

 Questo accende qualche lampadina nella mente di qualcuno? :-)
Prima cosa credo che il routing sia a posto, altrimenti, per dire, non
funzionerebbe nslookup; inoltre guardando le istruzioni di impostazione 
routing mi sembra sia tutto ok, a parte la ridondanza che ti ho detto in
un altro messaggio.
A differenza di ftp e http, che usano tcp, nslookup usa udp,
ping e traceroute icmp, quindi probabilmente c'e' qualche problema con tcp.
La situazione e' abbastanza strana, se dici che ftp download funziona (e 
immagino pure "ls" e comandi vari) e upload no (se non ho capito male questo
problema con ftp si verifica in rete locale tra gli host 102.168.2.3 e 
192.168.1.100 che e' pure gateway).
Quello che ti posso dire e' che per ogni comando e per ogni upload e 
download, si apre un altro canale tcp (oltre a quello dove passano i
comandi) dove passera' il file o per esempio l'elenco dei file di
una dir richiesto con ls. Il canale aggiuntivo e' di norma aperto dal
server, a meno che non usi il modo passivo di ftp. 
Fa una prova, non so che client usi, ma dovrebbe avere un comando "passive",
o "pasv" o qualcosa di simile, in questo modo sei tu a iniziare entrambe 
le connessioni (comandi + dati) tra il client e il server.
Comunque quello che ti posso dire in piu' e' che nel caso di download e'
il server a chiudere la connessione dati, in upload e' il client. 
La chiusura indica che il trasferimento e' finito.
Ma mi concentrerei sull'http, che mi dici non funziona pure lui, e lui
usa connessioni "normali", nel senso che il client apre la connessione
tcp, scarica e chiude (e ne puo' aprire un certo tot, dipende da quanta
roba c'e' nella pagina chiesta). 
Detto questo, al momento pero' non mi viene in mente cosa potrebbe causare
i problemi che hai
-- 
Francesco
eCSoft/2 -> 
http://www.ecomstation.it/ecsoft2

 in questo?
Ma che significa "inizia e poi resta appeso" ? Trasferisce dei dati o
dice solo "inizio l'upload"?
-- 
Francesco

 
Ma hai provato anche le ultime beta di svista?? L'ultima e' 
dell'altroieri o giu' di li'!



wrote:

Il file da uplodare viene creato ma resta a 0 bit (facendo la stessa 
cosa dalla macchina host anziche' dalla virtual machine uploda senza 
problemi).


 wrote:

E' vero, ma la crea cosi' di default l'installazione ossica. 


 
All'inizio pensavo fosse il routing, ma ping e nslookup funzionano. 
Poi ho pensato al firewall, ma non riesco a vedere neanche l'apache 
sul gateway. Non so che pesci pigliare (e purtroppo sono nella stesa 
situazione sul forum di Svista, ho impressione).


 dell'altroieri o giu' di li'!
No... da provare.


 neanche l'upload via FTP. In compenso il download si'... mi sembra 
non che ci chiappi tanto, ma se ti connetti con telnet alla porta 80 del 
server http ti risponde? (se telnet funziona, ovviamente)
Questo almeno ti direbbe se c'e' un problema con la porta. Poi ci 
dev'essere il modo di inviare richieste HTTP in telnet e "ascoltare" 
cosa si dicono le due porte con un altro programma, ma ora non mi 
ricordo come si fa.
ciao
Piersante

 Se fai un trace dei pacchetti cosa scopri?
ehh, come si fa? :-)


 
Mi invia il contenuto della homepage, quindi direi che si', mi 
risponde!


 ricordo come si fa.
da os2
telnet -p 80 -l pippo.log 
www.quelchevuoi.net
dove -l= -elle. Serve per fare un file di log perche' per motivi ignoti 
il telnet mi si chiude quando arriva la risposta
al prompt gli dai:
GET  /  HTTP/1.0
(mi raccomando maiuscole e spazi)
seguito da enter (in genere due volte)
se tutto va bene sul video compare il file index.htm del sito
se la finestra si chiude prima che tu riesca a leggerlo, guarda il file 
pippo.log e ce la dovresti trovare.
se invece va male, puoi guardare qui per cercare di capire il problema:
http://www.linuxhomenetworking.com/linux-hn/network-trouble.htm#_Toc80377775
magari serve
ciao,
piersante

 
Dopo il primo enter mi dice:
Bad request
Your browser sent a request that this server could not undestand
In ogni caso, lo vede :-)


 In ogni caso, lo vede :-)
se funziona tramite telnet deve andare anche il browser.
Hai eliminato USE_HOST_FIRST (o come cavolo si chiamava) dalla 
configurazione del TCP/IP della macchina eCS Guest?


 
Adesso nella macchina guest sto usando w2k. Ho provato a installare 
mozilla, ma niente.
Per inciso, il mex di internet explorer, a qualunque sito cerchi di 
connetermi, e' sempre: "Rilevato sito web. In attesa di risposta". La 
barra di avanzamento procede con lentezza micidiale, poi dopo un paio 
di minuti rinuncia.


 
beh, qual'e' il vero Gabriele Gamba?
  :-)
Piersante

 > 
questo e' connettendosi e cliccando a caso un paio di volte. Forse in 
realta' era lo stesso mex di errore di cui sopra. In ogni caso, via 
telnet si vedono :-)
