Newsgroup: it.comp.os.linux.sys
Titolo: pxe boot oltre un router

buongiorno a tutti, ho questa situazione:
server1-----rete1-----serverdebian-----rete2
         192.168.0.0                 192.168.3.0
server1: 192.168.0.2
serverdebian:192.168.0.7-192.168.3.1
vorrei fare il boot dei client della rete2 via pxe, passando perň da
serverdebian, questo perché devo raggiungere il tftp su server1; ho
provato configurando il dhcpd su serverdebian cosě:
host prova {
    hardware ethernet 00:11:22:33:44:55;
    fixed-address 192.168.3.104;
    option routers 192.168.3.1;
    filename "pxelinux.0";
    next-server 192.168.0.2;
    }
il client testato riceve al boot l'ip assegnato, ma si impalla al momento
di contattare il tftp server, che si trova nella rete1:
CLIENT IP: 192.168.3.104 MASK: 255.255.255.0 DHCP IP: 192.168.3.1
TFTP...
PXE-E32: TFTP open timeout
qualcuno sa indicarmi i passi da seguire per riuscire nell'intento?
Gracias
bluto
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 qualcuno sa indicarmi i passi da seguire per riuscire nell'intento?
Controlla se il routing tra le subnet è regolarmente e correttamente 
configurato.
Altrimenti  guarda i logs del tfpt server.

 Altrimenti  guarda i logs del tfpt server.
il ruoting č ok, per prova ho anche messo ACCEPT sia il FORWARD di
serverdebian che INPUT di server1, ma niente...


 serverdebian che INPUT di server1, ma niente...
Nei log del tftp ci sono tentativi di connessione almeno ?

 Nei log del tftp ci sono tentativi di connessione almeno ?
daemon.log mi dice solo che xinetd ha riletto la configurazione di
xinetd/tftp, nessuna voce relativa a connessioni, in realtà non ho trovato
un file di log specifico per tftpd.


 trovato un file di log specifico per tftpd.
E allora hai problemi di filtraggio su "serverdebian" o problemi di 
routing su server1 (il cui default GW non hai indicato).
Sniffa e controlla cosa arriva su server1.
Se non arriva nulla, sniffa su serverdebian su entrambe le interfacce.

 Se non arriva nulla, sniffa su serverdebian su entrambe le interfacce.
ok, ora mi attivo e faccio sapere, thx


 writes:
b> daemon.log mi dice solo che xinetd ha riletto la configurazione di
b> xinetd/tftp, nessuna voce relativa a connessioni, in realtà non ho trovato
b> un file di log specifico per tftpd.
Se non è in "verbose", xinetd/tftp non sta lì a scrivere poemi nei log:
al massimo vedi roba tipo
Aug 20 09:15:08 xxxxx xinetd[18869]: START: tftp pid=756 from=xxx.yyy.zzz.ttt
.....
Aug 20 09:30:10 xxxxx xinetd[18869]: EXIT: tftp status=0 pid=756 duration=902(sec)
Se  non vedi  neanche questo,  ma solo  il reread  della configurazione,
allora tftpd  non è configurato correttamente  (controllo idiota: sicuro
che in /etc/xinetd.c/tftp  non ci sia ancora "disable=yes"  ? Non ho mai
ben capito  il perché di  questa logica negata,  ma è facile  cascarci e
leggere "enable=yes"...).
Ricordo anche che qualche vecchia versione di tftpd aveva problemi (tipo
che proprio non  partiva...) se IPv6 era abilitato;  intanto questa è la
configurazione che uso io:
service tftp
{
        socket_type             = dgram
        protocol                = udp
        wait                    = yes
        user                    = root
        server                  = /usr/sbin/in.tftpd
        # Per debug:
        # server_args             = -s /tftpboot -r blksize -vv
        server_args             = -s /tftpboot -r blksize
        disable                 = no
        per_source              = 11
        cps                     = 100 2
        flags                   = IPv4
}
Poi c'è sempre tcpdump...
Saluti,
Luca Polo.
-- 
|| Luca Polo : 
Luca...@gest.unipd.it
 || Dipartimento di Tecnica e
|| System & network administrator      || Gestione dei Sistemi Industriali
|| 
http://www.gest.unipd.it/~jake
      || Universita` degli Studi di Padova

 il default gw di server1 è un'altra macchina della rete 192.168.0.0
e le routing table di server1 ??
Lui (o il suo degault GW) lo sa come raggiungere la 192.168.3.0 ??
route -n

 un file di log specifico per tftpd.
xinetd può essere avviato in modalità debug: -d
Ma, comunque, sulla stessa rete lo hai testato?
Cioè, sicuro che il problema si verifica solo quando hai il router di mezzo?
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
   printf $i }'; echo

 route -n
ecco l'output: 
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use
Iface
172.16.150.0    0.0.0.0         255.255.255.0   U     0      0        0
vmnet1
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0
eth0
172.16.218.0    0.0.0.0         255.255.255.0   U     0      0        0
vmnet8
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0
eth0
192.168.0.1 è la macchina che fa uscire la rete su internet 


 Cioè, sicuro che il problema si verifica solo quando hai il router di mezzo?
allora, nella stessa rete 192.168.0.0 funziona tutto, con il dhcpd e il
tftpd ospitati su server1; il dhcpd ha le stesse direttive che ho
riportato nel primo post per serverdebian. I pc fanno il boot, prendono
l'ip e scaricano il file pxeboot.0. Il problema è solo nella rete
192.168.3.0, dalla quale non riesco a contattare il tftpd
Grazie 


 Luca Polo.
in realtà, come ho scritto a Max_Adamo, il sistema funziona all'interno
della sua sottorete, il demone è regolarmente in ascolto; proverò a dargli
un pizzico di verbose, non mi costa nulla, intanto grazie.


> Lui (o il suo degault GW) lo sa come raggiungere la 192.168.3.0 ??
[CUT]
Ok, capisco che di routing non sei proprio una cima
Ti ripropongo la domanda sopra, visto che hai risposto solo per metà.
il 192.168.0.1 sa come raggiungere la 
192.168.3.0/24
 ??
Secondo me no.
Se ho ragione hai due opportunità:
1) aggiungere una rotta statica sul 0.1 per raggiungere la 3.0 (e lo 
faresti per tutta la subnet)
2) istruire server1 per raggiungere la 3.0 impostando solo su di lui una 
rotta statica.

 dargli un pizzico di verbose, non mi costa nulla, intanto grazie.
Come ti ho scritto all'inizio, hai problemi di routing.
Leggiti l'altro post.

 rotta statica.
ho aggiunto una rotta cosě:
route add -net 192.168.3.0 netmask 255.255.255.0 gw 192.168.0.7
e ora da 192.168.0.2 pingo gli host in 192.168.3.0, solo che il problema
perdura. 
Ora devo scappare, torno alla carica lunedě, grazie a todos
bluto


 perdura. 
Se prima i computer dentro a 
192.168.3.0/24
 navigavano su internet,
allora dovevi far funzionare il masquerading su 192.168.0.7.
Adesso lo disattivi e quasi certamente funziona tutto.
Se la rete 
192.168.3.0/24
 non va piů su internet, modifica in maniera
appropriata il tuo gateway.
Perché TFTP non funziona dietro NAT ? Boh, so solo questo
http://www.tftp-server.com/tftp_server_faq.html
Domanda 1

 Altrimenti  guarda i logs del tfpt server.
Non che ci abbia lavorato molto, e certo mi sbagliero', ma tftp non mi
ha mai funziato fuori dalla lan (ovvero, uno stesso dominio di
broadcast).
bye G.L.
-- 
Da it.discussioni.consumatori.tutela:
 > P.S. Quando ci sarà lo switch-off, avrò problemi anche col
 > monitor del PC? Ho visto che è collegato in modalità analogica.

 bye G.L.
bč, giusto per chiudere il discorso, pare proprio che il tftp dietro nat
si comporti come hai sottolineato, qui c'č un vecchio progetto di un
server nat-friendly:
http://troja.ath.cx/~zond/jtftp/
ma al momento devo archiviare la cosa.
saluti a tutti


 Ora devo scappare, torno alla carica lunedě, grazie a todos
ho mischiato quel che č stato scritto qui, con quel che č stato scritto 
da G.L., ho incrociato i dati e ne č venuto fuori che un bel
'modprobe nf_nat_tftp' potrebbe tirarti fuori da tutti i pasticci.
that's it in my opinion.
