TFTP: Transfer timed out

[bepeppered]

Guten Morgen,

ich habe Probleme beim Einrichten vom TFTP-Server auf meiner RedHat-Maschine (RHEL 6 - Kernel 2.6.32-71 - 64 Bit).

1. Zuerst habe ich meine Firewall deaktiviert.

iptables -F

2. Eingerichtet habe ich es normal: TFTP-Server (tftp-server-0.49-5.1.el6.x86_64.rpm) und NFS-Server (nfs-utils-lib-1.1.4-8.1.el6.x86_64.rpm) installiert.

3. freigegebenes TFTP-Verzeichnis erstellt

mkdir /tftpboot

4. Datei hinzugefügt (/tftpboot/test mit "Hello" als Inhalt)

5. die /etc/xinetd.d/tftp geändert:

{
disable = no
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -s /tftpboot
}

6. XInetd und NFS-Server neugestartet

# /etc/init.d/xinetd restart
# /etc/init.d/nfs restart

Der Neustart läuft problemlos. Lediglich der NFS-Server wurde nicht automatisch beim Systemstart gestartet. Deswegen kann er mit restart nicht beendet werden, wird aber gestartet.
Der Restart von XInetd und NFS-Server gibt mir in der /var/log/messages folgendes

xinetd[1621]: Exiting...
xinetd[3002]: xinetd Version 2.3.14 started with libwrap loadavg labeled-networking options compiled in.
xinetd[3002]: Started working: 1 available service
kernel: Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
kernel: NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
kernel: NFSD: starting 90-second grace period

7. Nun wird TFTP gestartet:

# tftp localhost
tftp> status
Connected to localhost.localdomain.
Mode: netascii Verbose: off Tracing: off Literal: off
Rexmt-interval: 5 seconds, Max-timeout: 25 seconds
tftp> get test
Transfer timed out

Leider läuft dabei was schief.

8. Die /var/log/messages liefert folgendes:

xinetd[3002]: START: tftp pid=3375 from=127.0.0.1
in.tftpd[3375]: /tftpboot: Permission denied
kernel: type=1400 audit(1315465999.026:27758): avc:  denied  { search } for  pid=3375 comm="in.tftpd" name="tftpboot" dev=dm-0 ino=1438981 scontext=unconfined_u:system_r:tftpd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:default_t:s0 tclass=dir
xinetd[3002]: EXIT: tftp status=66 pid=3375 duration=1(sec)
xinetd[3002]: START: tftp pid=3378 from=127.0.0.1
kernel: type=1400 audit(1315466003.992:27759): avc:  denied  { search } for  pid=3378 comm="in.tftpd" name="tftpboot" dev=dm-0 ino=1438981 scontext=unconfined_u:system_r:tftpd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:default_t:s0 tclass=dir
in.tftpd[3378]: /tftpboot: Permission denied
xinetd[3002]: EXIT: tftp status=66 pid=3378 duration=0(sec)
xinetd[3002]: START: tftp pid=3389 from=127.0.0.1
in.tftpd[3389]: /tftpboot: Permission denied
kernel: type=1400 audit(1315466008.991:27760): avc:  denied  { search } for  pid=3389 comm="in.tftpd" name="tftpboot" dev=dm-0 ino=1438981 scontext=unconfined_u:system_r:tftpd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:default_t:s0 tclass=dir
xinetd[3002]: EXIT: tftp status=66 pid=3389 duration=0(sec)
xinetd[3002]: START: tftp pid=3390 from=127.0.0.1
in.tftpd[3390]: /tftpboot: Permission denied
xinetd[3002]: EXIT: tftp status=66 pid=3390 duration=0(sec)
kernel: type=1400 audit(1315466013.992:27761): avc:  denied  { search } for  pid=3390 comm="in.tftpd" name="tftpboot" dev=dm-0 ino=1438981 scontext=unconfined_u:system_r:tftpd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:default_t:s0 tclass=dir
xinetd[3002]: START: tftp pid=3391 from=127.0.0.1
kernel: type=1400 audit(1315466018.992:27762): avc:  denied  { search } for  pid=3391 comm="in.tftpd" name="tftpboot" dev=dm-0 ino=1438981 scontext=unconfined_u:system_r:tftpd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:default_t:s0 tclass=dir
in.tftpd[3391]: /tftpboot: Permission denied
xinetd[3002]: EXIT: tftp status=66 pid=3391 duration=0(sec)

Welches Problem übersehe ich? =(

Grüßle David

 

[MainframeX]

Was für Rechte sind auf /tftpboot gesetzt? (sollte 755 ein)

The use of TFTP services does not require an account or password on the server system. Due to the lack of authentication information, tftpd will allow only publicly readable files (o+r) to be accessed, unless the -p option is specified. Files may be written only if they already exist and are publicly writable, unless the -c option is specified. Note that this extends the concept of ''public'' to include all users on all hosts that can be reached through the network; this may not be appropriate on all systems, and its implications should be considered before enabling TFTP service.

Warum tftp und nicht sftp?

 

[Krik]

TFTP wird üblicherweise im Zusammenhang mit PXE verwendet.


in.tftpd[3391]: /tftpboot: Permission denied
Das ist das Problem, die Rechte des Verzeichnisses sind falsch gesetzt. Fehlt ein read-Flag?

 

[bepeppered]

Hm, hab die Rechte gesetzt:

chmod 755 /tftpboot
chmod 755 /tftpboot/test

Danach noch kurz:

setenforce 0

Jetzt kommt kein Timeout mehr. Ebenso ist das Permission denied weg. Leider werden noch keine Daten übertragen. Das Log jetzt:

xinetd[3002]: START: tftp pid=4511 from=127.0.0.1
kernel: type=1400 audit(1315469853.196:27769): avc:  denied  { search } for  pid=4511 comm="in.tftpd" name="tftpboot" dev=dm-0 ino=1438981 scontext=unconfined_u:system_r:tftpd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:default_t:s0 tclass=dir
kernel: type=1400 audit(1315469853.200:27770): avc:  denied  { read } for  pid=4512 comm="in.tftpd" name="test" dev=dm-0 ino=1438980 scontext=unconfined_u:system_r:tftpd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:default_t:s0 tclass=file
kernel: type=1400 audit(1315469853.200:27771): avc:  denied  { open } for  pid=4512 comm="in.tftpd" name="test" dev=dm-0 ino=1438980 scontext=unconfined_u:system_r:tftpd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:default_t:s0 tclass=file
kernel: type=1400 audit(1315469853.200:27772): avc:  denied  { getattr } for  pid=4512 comm="in.tftpd" path="/test" dev=dm-0 ino=1438980 scontext=unconfined_u:system_r:tftpd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:default_t:s0 tclass=file

TFTP muss ich leider benutzen, da das vorhandene Board, auf das ich mit U-Boot Daten übertragen muss nur TFTP unterstützt. =/

 

[MainframeX]

SE-Linux ist ein Krampf

genaue ursache wüsste ich jetzt auch nicht, 2 Möglichkeiten, die man versuchen kann
guck hier unter "Fully Disabling SELinux"
http://www.crypt.gen.nz/selinux/disable_selinux.html

oder versuch selinux beizubringen, das tftp 'nett' ist
http://www.8-p.org/wiki/doku.php?id=linux:selinux

ich gehe davon aus, das du als root unterwegs bist und nicht im Verzeichnis /tftpboot stehst wenn du den 'get' versuchst?

Wenn ich nach dem Thema suche finde ich deine Frage in 3 Foren, scheint wichtig zu sein

 

[bepeppered]

Wenn ich nach dem Thema suche finde ich deine Frage in 3 Foren, scheint wichtig zu sein

Dann scheint der Google Crawler echt fix zu sein Ja, es ist wichtig. Sitze schon seid 2 * 10h dran und muss Leistung abliefern

Ich werde mich jetzt durch SELinux kämpfen (Scheiss redhat) ...

 

[Krik]

Viel Spaß!
Ich hatte bisher nur einen Kontakt mit SELinux und der lief mit einem ähnlichen WTF?!-Moment ab wie bei dir.

Afaik musst du dem User, unter dem TFTP läuft, die Leserechte erteilen. Da gibt's auch ein Programm, mit dem man das bei SELinux einstellen kann. Frag mich aber nicht nach dem Namen. Oder halt, ich glaub das Problem bei mir lag eher daran, dass die Dateiart nicht festgelegt wurde. Argh, das ist hier aber auch komplizierter Kram. ^^

 

[MainframeX]

Da SE-linux ja jetzt im permissive Mode laufen sollte, kann es durchaus sein, das die Logmeldungen nichts damit zu tun haben, das die Datei nicht ankommt, wo sie hin soll.
SE-Linux schreibt ja 'nur' was es verbieten würde, ohne es dann zu tun.
Muss gestehen, dass ich tftp nie wirklich benutz habe, eventuell gibt es debug Schalter, wie bei ssh, die man einschalten kann um zu sehen was er genau tut?

 

[bepeppered]

So, nachdem ich jetzt erfolgreich SELinux deaktiviert habe, kommen auch keine Log-Meldungen mehr im /var/log/messages. Lediglich die Info, dass der TFTP-Client gestartet wurde.

Leider funktioniert die Datenübertragung nicht. TFTP-Server (tftpd) scheint zumindest zu laufen:

# ps -aux | grep tftp
root 2757 0.0 0.0 107576 1176 pts/0 S+ 11:17 0:00 tftp localhost
root 2758 0.0 0.0  10588  724 ?     Ss 11:17 0:00 in.tftpd -s /tftpboot
500  2858 0.0 0.0 105216  844 pts/2 S+ 11:19 0:00 grep tftp

Was bedeutet das ?, wo eigentlich pts/1 hinsollte. Ebenso wie das Ss?

Muss gestehen, dass ich tftp nie wirklich benutz habe, eventuell gibt es debug Schalter, wie bei ssh, die man einschalten kann um zu sehen was er genau tut?

Genau den suche ich auch. Muss doch irgendwo ne Log-Möglichkeit geben.

 

[Krik]

TFTP hat einen Verbose-Modus. Probiere den mal.
Ansonsten schau mal in die /var/log/messages, ob dort etwas über den Dienst berichtet wird.

 

[MainframeX]

Ich habs mal grade auf meinem Ubuntu getestet und da funzt es.
ruf mal nur mit tftp die tftp console auf und mach dann
verbose
connect 127.0.0.1
get test
quit

 

[bepeppered]

Perfekt, funktioniert. Komischerweise war der verbose-Modus nicht aktiviert, trotzdem ich in der config -v eingestellt habe. Danke, scheint echt an dem SELinux gelegen zu haben

Gelöst via Änderung der /etc/selinux/config:

[...]
SELINUX=disabled
[...]

Danach ein Restart

 

[mensch183]

# ps -aux | grep tftp
root 2757 0.0 0.0 107576 1176 pts/0 S+ 11:17 0:00 tftp localhost
root 2758 0.0 0.0  10588  724 ?     Ss 11:17 0:00 in.tftpd -s /tftpboot
500  2858 0.0 0.0 105216  844 pts/2 S+ 11:19 0:00 grep tftp

Was bedeutet das ?, wo eigentlich pts/1 hinsollte. Ebenso wie das Ss?

? ==> kein kontrollierendes Terminal (ein daemon halt)
Ss ==> S=sleeping s=session leader

... du wolltest bestimmt "ps aux" machen, nicht "ps -aux"

 

[bepeppered]

? ==> kein kontrollierendes Terminal (ein daemon halt)
Ss ==> S=sleeping s=session leader

Danke für die Info, wieder was gelernt

... du wolltest bestimmt "ps aux" machen, nicht "ps -aux"

Jeps, vertippt