TFTP Server

[columbo1979]

Hallo,

kann ich irgendwie ein TFTP Server auf der Fritzbox erstellen?

Danke

Gruß

 

[PeterPawn]

Ja.

@(potentielle Kritiker): So kurz antworte ich nie wieder - ist mehr eine Demo und ich will von der Schnapszahl der geschriebenen Beiträge runter.

 

[columbo1979]

Ok, Frage falsch gestellt ;-)

Wie geht es mit der 7490 und der aktuelle 6.5 Firmware.

 

[PeterPawn]

Immer noch die falsche Frage ... ohne Idee, wofür Du den verwenden willst (extern, intern), von wo die Dateien kommen sollen bzw. wo sie gespeichert werden sollen und wie tiefgreifend die Änderungen sein sollen/dürfen, ist das alles immer noch Murks.

Wenn es generell ums Modifizieren der Firmware für eigene Erweiterungen geht, kannst Du Freetz oder modfs verwenden.

Vermutlich war aber auch das nicht der Kern des lockigen Hundes ... wenn es um TFTP-Server-Software geht, bietet sich z.B. dnsmasq an, wobei ich (wenn man dnsmasq nicht aus anderen Gründen noch benötigt) eher zur Busybox mit den passenden Applets (tftpd i.V.m. inetd oder udpsvd) greifen würde.

Schon von der vorstehenden Wahl hängt es dann natürlich ab, wie das konkret umzusetzen wäre. Es geht ggf. auch komplett ohne Freetz oder modfs, indem man die notwendigen Kommandos so ausführen läßt, wie es bei modfs-starter erfolgt.

Die (schon an der einen oder anderen Stelle beschriebenen) Möglichkeiten sind vielfältig, alle gleichzeitig erneut zu beschreiben ist ziemlich sinnlos ... also muß man sich erst einmal für einen Weg entscheiden und dann kann man - wenn die eigenen Anläufe nicht auf Anhieb klappen wollen - gemeinsam nach Fehlern suchen.

 

[columbo1979]

ok..

ich möchte über den tftp server erreichen, dass ich über das netzwerk ein pc booten kann... und möchte ungern die firmware modifizieren....

so, nun eine lösung? ;-)

 

[koyaanisqatsi]

Moins

Wie geht denn sowas :?:
Ein PC wird doch mit ether-wake gestartet :noidea:

Damit sich ein Telefon seine Konfig/Firmware holt
...hätt ich eher verstanden.

 

[columbo1979]

http://www.com-magazin.de/praxis/nas/multi-boot-nas-server-232864.html

 

[PeterPawn]

siehe #4 ... ich habe da ja die denkbaren Ansätze schon aufgezählt.

Wenn das zu unverständlich war, dann als Beispiel eines tftp-Servers mittels Busybox (tftpd mit udpsvd):

my_busybox=/var/custom/bin/busybox
my_address=192.168.178.1
my_port=69
source_dir=/var/media/ftp
$my_busybox udpsvd -v -c 3 -E $my_address $my_port $my_busybox tftpd -r -l $source_dir

Braucht ggf. auch gar keine Modifikation der Firmware, man kann ja auch die Busybox unterhalb eines NAS-Verzeichnisses ablegen (warum das gar keine gute Idee ist in meinen Augen, wiederhole ich hier nicht ... keine Angst).

Es versteht sich von selbst, daß (je nachdem, was Du nun wirklich machen willst, weil auch "pc booten" noch lange nichts Konkretes ist) für PXE noch mehr als ein TFTP-Server gebraucht wird - aber mit der o.a. Folge erhältst Du auf der FRITZ!Box einen TFTP-Server, der jede Datei unterhalb von "source_dir" auf Anforderung übertragen kann (max. 3 gleichzeitige Verbindungen).

Wenn es darum geht, wie man so etwas automatisch starten kann (dann sicherlich auch mit weniger geschwätzigen Parametern), hast Du offenbar #4 doch nicht richtig verstanden, denn dort habe ich schon einige denkbare Alternativen aufgezählt und parallel dazu darauf verwiesen, daß jeder Weg anders aussieht und ich weder alle drei dort verlinkten Möglichkeiten gleichzeitig (erneut) beschreiben will noch dazu bereit bin, hier eine Wiederholung der in den verlinkten Beiträgen bereits enthaltenen Erklärungen abzuliefern. Wenn Du aus dem dort Geschriebenen eigene Versuche abgeleitet hast und dabei Probleme auftreten, beantworte ich gerne konkrete Fragen, wo Dein Fehler liegen könnte.

EDIT: Nachdem nun in #7 ein Link steht ... da wäre dann wohl dnsmasq doch geeigneter, denn der DHCP-Server der FRITZ!Box liefert weder einen Bootimage-Namen noch einen TFTP-Server aus, wenn ich mich recht erinnere.

EDIT2: Ich habe mal den verlinkten Artikel etwas gelesen und kann nur dringend davon abraten (meine Meinung), den dort vorhandenen Abschnitt "Router konfigurieren" allzu ernst zu nehmen. Erstens sind bei der dort empfohlenen Vorgehensweise Probleme mit VPN-Verbindungen der FRITZ!Box quasi vorprogrammiert (das war am 03.02.2014 auch schon so), weil die FRITZ!Box die Adressen hinter ihrer DHCP-Range für statische IP-Adressen für VPN-Clients nutzt. Wenn man so etwas also machen sollte, dann immer im anderen DHCP-Server erst bei "Ende-Adresse der FRITZ!Box + n" beginnen, wobei "n" ausreichend groß gewählt werden sollte, damit da mind. die Anzahl der Usernamen in der FRITZ!Box abgedeckt wird. Wer natürlich seine VPN-Clients ohnehin von Hand verwaltet, braucht darüber auch nicht nachzudenken.

Auch verstehe ich nicht so richtig, wie der Autor dort sich das "Teilen" des Netzes für die DHCP-Server vorstellt. Wenn da zwei DHCP-Server aktiv sind, antworten m.E. auch beide auf DISCOVER-Requests von Clients. Die Existenz zweier Server im Netzwerk stört also nur dann nicht, wenn ein (intelligenter) PXE-Client sich von den beiden Servern jetzt genau den aussucht, der neben einer IP-Adresse auch noch die weiteren benötigten Optionen anbietet. Darauf würde ich mich aber nicht in jedem Falle verlassen ... kenne aber auch nicht alle PXE-Implementierungen im BIOS von PCs (bei mir gibt es nur ein c't-Desinfect per PXE und dann nicht von einer FRITZ!Box); bei Problemen würde ich zuerst schauen, ob wirklich die IP-Adresse (und damit das gesamte Bouquet an DHCP-Optionen) vom richtigen Server stammt.

 

[koyaanisqatsi]

Interessant, dann macht das natürlich Sinn.
...theoretisch, ob die Geschwindigkeit befriedigend ist wäre die zweite Frage.
Wenns nur das Bootmenü ist nicht, bei kompletten Imagedateien mein ich.

 

[splenditnet]

Hallo columbo1979,
dies sollte u.a. auch durch das gut ausgestattete Busybox-Binary von PeterPawn aus SIAB-Projekt problemlos umsetzbar sein

Download des Busybox-Binaries:

# wget http://yourfritz.de/inject_shellinabox_vr9_nand_sqfs4.tar
# ls -la
drwxr-xr-x    2 root     root          4096 Jan  1 16:08 .
drwxrwxrwx   32 root     root          4096 Jan  1 15:51 ..
-rw-r--r--    1 root     root        539648 Jan  1 15:50 inject_shellinabox_vr9_nand_sqfs4.tar
# tar xvpf inject_shellinabox_vr9_nand_sqfs4.tar
./var/
./var/install
./var/signature
./var/tmp/
./var/tmp/kernel.image
./var/tmp/filesystem.image
# mkdir temp_dir
# mount -t squashfs var/tmp/filesystem.image temp_dir
# find temp_dir
temp_dir
temp_dir/bin
temp_dir[COLOR="#0000FF"]/bin/busybox[/COLOR]
temp_dir/etc
temp_dir/etc/init.d
temp_dir/etc/init.d/rc.custom
temp_dir/lib
temp_dir/lib/libprivatekeypassword.so
temp_dir/usr
temp_dir/usr/bin
temp_dir/usr/bin/privatekeypassword
temp_dir/usr/bin/shellinaboxd

Kontrolle, ob tftpd-Server enthalten ist:

# temp_dir/bin/busybox
BusyBox v1.23.2 (2015-12-15 09:59:22 CET) multi-call binary.
BusyBox is copyrighted by many authors between 1998-2012.
Licensed under GPLv2. See source distribution for detailed
copyright notices.

Usage: busybox [function [arguments]...]
   or: busybox --list
   or: function [arguments]...

        BusyBox is a multi-call binary that combines many common Unix
        utilities into a single executable.  Most people will create a
        link to busybox for each function they wish to use and BusyBox
        will act like whatever it was invoked as.

Currently defined functions:
        [, [[, addgroup, adduser, arp, arping, ash, awk, base64, basename, bash, bbconfig, blkid, blockdev, brctl, bunzip2, bzcat, bzip2, cat, chat, chattr, chgrp, chmod, chown, chpst,
        chroot, cksum, clear, cmp, comm, conspy, cp, cpio, crond, crontab, cryptpw, cttyhack, cut, date, dc, dd, delgroup, deluser, depmod, devmem, df, dhcprelay, diff, dirname, dmesg,
        dnsd, dnsdomainname, dos2unix, dpkg, dpkg-deb, du, dumpleases, echo, egrep, env, envdir, envuidgid, ether-wake, expand, expr, false, fatattr, fdisk, fgconsole, fgrep, find,
        findfs, flash_eraseall, flash_lock, flash_unlock, flashcp, flock, fold, free, fsck, fsync, ftpd, ftpget, ftpput, fuser, getopt, grep, groups, gunzip, gzip, halt, hd, hdparm, head,
        hexdump, hostid, hostname, httpd, id, ifconfig, ifdown, ifenslave, ifup, inetd, init, inotifyd, insmod, install, iostat, ip, ipaddr, ipcalc, ipcs, iplink, iproute, iprule,
        iptunnel, kill, killall, killall5, klogd, last, less, ln, logger, login, logname, logread, losetup, ls, lsattr, lsmod, lsof, lspci, lsusb, lzcat, lzma, makedevs, makemime, md5sum,
        microcom, mkdir, mkfifo, mknod, mkpasswd, mkswap, mktemp, modinfo, modprobe, more, mount, mountpoint, mpstat, mv, nanddump, nandwrite, nbd-client, nc, netstat, nice, nmeter,
        nohup, nslookup, ntpd, od, openvt, passwd, patch, pgrep, pidof, ping, ping6, pipe_progress, pivot_root, pkill, pmap, poweroff, printenv, printf, ps, pscan, pstree, pwd, pwdx,
        rdate, rdev, readlink, realpath, reboot, reformime, renice, reset, rev, rfkill, rm, rmdir, rmmod, route, rpm, rpm2cpio, run-parts, runsv, runsvdir, rx, sed, sendmail, seq,
        setconsole, setlogcons, setserial, setsid, setuidgid, sh, sha1sum, sha256sum, sha3sum, sha512sum, shuf, slattach, sleep, smemcap, softlimit, sort, split, start-stop-daemon, stat,
        strings, stty, stun-ip, sv, svlogd, swapoff, swapon, switch_root, sync, sysctl, syslogd, tac, tail, tar, taskset, tcpsvd, tee, telnet, telnetd, test, tftp, [COLOR="#0000FF"]tftpd[/COLOR], time, timeout,
        top, touch, tr, traceroute, traceroute6, true, tty, tunctl, tune2fs, ubiattach, ubidetach, ubimkvol, ubirmvol, ubirsvol, ubiupdatevol, udhcpc, udhcpc6, udhcpd, udpsvd, umount,
        uname, unexpand, uniq, unix2dos, unlink, unlzma, unxz, unzip, uptime, users, usleep, uudecode, uuencode, vconfig, vi, watch, watchdog, wc, wget, which, who, whois, xargs, xz,
        xzcat, yes, zcat, zcip
#

Check tftpd Optionen:

# temp_dir/bin/busybox tftpd
BusyBox v1.23.2 (2015-12-15 09:59:22 CET) multi-call binary.

Usage: tftpd [-cr] [-u USER] [DIR]

Transfer a file on tftp client's request

tftpd should be used as an inetd service.
tftpd's line for inetd.conf:
        [COLOR="#0000FF"]69 dgram udp nowait root tftpd tftpd -l /files/to/serve[/COLOR]
It also can be ran from udpsvd:
        udpsvd -vE 0.0.0.0 69 tftpd /files/to/serve

        -r      Prohibit upload
        -c      Allow file creation via upload
        -u      Access files as USER
        -l      Log to syslog (inetd mode requires this)
#

Das Aktivieren kann u.a. per modifizierter inetd.conf erfolgen (blau markierte Zeile einbauen, Pfad "/files/to/serve" sowie ggf. absoluter Pfad zu tftpd-binary anpassen)
anschließend inetd-Prozess reloaden, d.h. "SIGHUP"-Signal an inetd-PID senden

# ls -la /etc/inetd.conf
lrwxrwxrwx    1 root     root            21 Dec 10 19:23 /etc/inetd.conf -> ../var/tmp/inetd.conf
# cat /etc/inetd.conf
21 stream tcp6 nowait.30 root /bin/sh sh /bin/inetdftp
139 stream tcp6 nowait root /bin/sh sh /bin/inetdsamba
445 stream tcp6 nowait root /bin/sh sh /bin/inetdsamba
#
# mkdir /var/media/ftp/bin
# cp -p bin/busybox /var/media/ftp/bin/busybox_pp
# mkdir /var/media/ftp/tmp
#
# vi /etc/inetd.conf
21 stream tcp6 nowait.30 root /bin/sh sh /bin/inetdftp
139 stream tcp6 nowait root /bin/sh sh /bin/inetdsamba
445 stream tcp6 nowait root /bin/sh sh /bin/inetdsamba
[COLOR="#0000FF"]69 dgram udp nowait root /var/media/ftp/bin/busybox_pp tftpd -l /var/media/ftp/tmp[/COLOR]

# ps | grep inetd
 [COLOR="#0000FF"]3111[/COLOR] root      1376 S    /usr/sbin/inetd
 6134 root      1372 S    grep inetd
# kill -SIGHUP [COLOR="#0000FF"]3111[/COLOR]
#

Gruß
Splenditnet

EDIT: Abschnitt bzgl. Modifikation /etc/inetd.conf angepasst und reload inetd eingepflegt

 

[columbo1979]

danke @splenditnet

aber da bin ich nun überfordert ;-)
wie bekomme ich dieses nun umgesetzt?

 

[PeterPawn]

Mir fällt hier irgendwie eine Zeile aus dem Kinderfernsehen ein:

"1, 2 oder 3… Du musst Dich entscheiden, 3 Felder sind frei…"

Voraussetzung mag ja sein, daß man die angegebenen Quellen erst einmal liest ... ich werde irgendwie nicht so richtig schlau daraus, ob das nun schon passiert ist oder nicht.

 

[splenditnet]

wie bekomme ich dieses nun umgesetzt?

Hallo columbo1979,
die Umsetzung insbesondere das "persistente" Verankern des TFTPD-Binaries in Fritzbox-Bootprozess ist hier beschrieben:
http://www.ip-phone-forum.de/showthread.php?t=283039&page=2&p=2136386#post2136386

Gruß
Splenditnet

 

[andiling]

EDIT2: ...

Ich sehe da (wenn es ordentlich konfiguriert ist) keine Probleme. Letztlich sind es zwei verschiedene Dienste bootpc und dhcpc, die zwar den gleichen Port nutzen aber sich in ihren Antworten unterscheiden.

Beim Boot wird der Client falls er zuerst die Fritzbox kontaktiert mangels PXE Daten zum nächsten übergehen und im laufenden Betrieb des Clients wird der PXE Server als Proxy für das DHCP der Fritzbox dienen.

 

[PeterPawn]

Ich sehe da (wenn es ordentlich konfiguriert ist) keine Probleme.

Vielleicht habe ich es mißverständlich formuliert ... der Autor erwartet nach meinem Verständnis, daß der Client sich die eigene IP-Adresse vom DHCP-Server auf dem NAS besorgt.

Die PXE-Beschreibung von Intel sagt dazu etwas anderes - nach meiner Lesart, die muß ja nicht stimmen.

Der Prozess zur Ermittlung eines Boot-Servers (Punkt 2.4.4) ist getrennt von der Zuweisung einer IP-Adresse, im Absatz unmittelbar vor diesem Punkt wird auch beschrieben, daß ein PXE-Client durchaus die IP-Adresse auch von einem anderen Server beziehen kann:

In this state, the client must also be prepared to receive one or more standard DHCPOFFER messages from servers. Each of these messages will contain configuration information as specified in RFC 2131. Each extended DHCPOFFER message can also contain configuration information as specified in RFC 2132. Which, of these configurations, if any, is used by the client is not defined by this specification.

Den Part mit dem DHCP-Proxy verstehe ich nicht ... was sollte den PXE-Server auf dem NAS (sind ja mehrere Dienste) denn jetzt bewegen, seinerseits den DHCP-Proxy für die FRITZ!Box zu geben? Wenn das so wäre, müßte er sicherlich von Beginn an als DHCP-Proxy für die FRITZ!Box konfiguriert werden ... wobei er dann m.E. in der Prioritätenliste beim DHCPREQUEST (Punkt 2.4.1) eben wieder hinter die FRITZ!Box zurückfallen müßte, wenn der Client die Wahl hat.

Das würde vielleicht alles tatsächlich weiterhin funktionieren ... aber der PXE-Client muß eben nicht zwangsläufig seine IP-Adresse vom DHCP-Server auf dem NAS beziehen. Vielleicht habe ich das im verlinkten Beitrag ja auch falsch verstanden bei der Intention des Autors ... aber warum er dann nicht gleich einen in der FRITZ!Box vorhandenen DHCP-Server komplett abstellen will, wenn es das NAS doch "gleich richtig" machen könnte (also DHCPOFFER inkl. PXE-Options - 93,94,97 - und auch in aller Regel noch flexibler zu konfigurieren, was andere Optionen angeht), verstehe ich eben nicht.

Die VPN-Warnung meinerseits bleibt auch bestehen ... wenn der DHCP-Server im NAS nicht vor einer Zuweisung per ARP nach der zuzuweisenden Adresse fragt (und nicht per ICMP, das muß nicht funktionieren, solange die betreffende VPN-Verbindung nicht aufgebaut ist), dann würde schon die erste in der FRITZ!Box eingerichtete VPN-Verbindung (für Benutzer natürlich nur) dazu führen, daß die FRITZ!Box die .201-Adresse per Proxy-ARP für sich reklamiert, damit der Traffic zum VPN-Client bei ihr ankommt. Wenn dann der DHCP-Server im NAS diese IP-Adresse einem LAN-Client zuweist, ist dieser Client von anderen Stationen im LAN mal erreichbar und mal nicht, je nachdem, welche ARP-Antwort bei der anderen Station als erste eingeht, die des Clients oder die der FRITZ!Box.

Ob der beschriebene DHCP-Server im Synology-NAS tatsächlich per ARP sucht oder nicht, weiß ich nicht ... mir geht es hier mehr um die prinzipielle Gefahr, weil natürlich jemand beim "Nachbauen" mit einem anderen NAS ebenfalls in diese Falle tappen könnte.

EDIT:
Das wirklich Witzige habe ich erst jetzt gesehen, als ich mir mal das Bild von der DHCP-Serverkonfiguration aus dem verlinkten Artikel angesehen habe. Dort wird der DHCP-Server gar nicht auf die Vergabe der 192.168.178.201-210 konfiguriert, sondern auf 192.168.172.201-210 mit einer /16-Maske - während Gateway und DNS-Server bei der FRITZ!Box unter 192.168.178.1 bleiben ... mir fehlt gerade die Phantasie, wie sich das auf das PXE-Booten auswirkt, aber das VPN-Problem wäre damit tatsächlich umschifft, weil es ein anderes Segment ist.

Stimmt aber nicht mit dem Text überein:

Die „Start-IP-Adresse“ ist die erste IP-Adresse, die vom DHCP-Server auf dem NAS vergeben werden darf. Im Abschnitt „Router konfigurieren“ hatten wir hierfür 192.168.178.201 vorgesehen. Als „End-IP-Adresse“ bietet sich 192.168.178.210 an. Sie haben dann zehn IP-Adressen zur Verfügung, die vom DHCP-Server auf dem NAS vergeben werden dürfen.

und die Bilder habe ich nur deshalb jetzt nachträglich angesehen, weil ich nach einer Option für diese "ARP discovery" vor dem DHCPOFFER gesucht habe.

 

[columbo1979]

es steht in dem verlinkten artikel, dass ich ein dhcp auf der fritz laufen lassen kann und einem auf dem nas... woher weiß nun der pc, ob er den dhcp von der fritz oder vom nas nehmen soll?

 

[columbo1979]

http://blog.romal.de/2014/07/fritzbox-und-pxe.html

 

[unrealzocker]

Damit Netzwerkboot funktioniert brauchst du ja sowieso noch einen weiteren Server wo die Dateien liegen. Dort kannst du ja auch den TFTP-Server laufen lassen.

 

[columbo1979]

noch mal zusammengefasst:

habe eine NAS: QNAP TVS-463
eine Fritzbox: 7490

Die NAS kann TFTP und auch einen DHCP Server erstellen - allerdings macht die Nas Probleme bei der Zuweisung des DNS und und dem Gateway.
Daher kam die Idee, die Box dafür zu nutzen...

 

[columbo1979]

so, 2 DHCP Server wie im Artikel funktionieren... bei mir läuft es so...