atftpd - won't start, just gives help message

[Java Jive]

Can't seem to start atftpd on my NSA221 NAS. Every single one of the
many command lines that I've tried just display the help as though I'd
called it with -h.

An online search got a few hits, but nearly all the people with the
problem just used a server program running on Windows instead - I've
done this too, but I'd rather have it working on the NAS.

Grateful for any helpful suggestions ...
--
========================================================
Please always reply to ng as the email in this post's
header does not exist. Or use a contact address at:
http://www.macfh.co.uk/JavaJive/JavaJive.html
http://www.macfh.co.uk/Macfarlane/Macfarlane.html

[Chris]

Java Jive <ja...@evij.com.invalid> wrote:
> Can't seem to start atftpd on my NSA221 NAS. Every single one of the
> many command lines that I've tried just display the help as though I'd
> called it with -h.

I've no experience of atftpd but that behaviour usually means that the
program isn't able to interpret your command-line. The more helpful progs
will give an error message just before printing the help. Have you scrolled
up to the top the help to see if there is any such message? If there, it
might give a hint to the problem.

[Nick Leverton]

In article <g3nopcpnlh1bipou8...@4ax.com>,

Java Jive <ja...@evij.com.invalid> wrote:
>Can't seem to start atftpd on my NSA221 NAS. Every single one of the
>many command lines that I've tried just display the help as though I'd
>called it with -h.
>
>An online search got a few hits, but nearly all the people with the
>problem just used a server program running on Windows instead - I've
>done this too, but I'd rather have it working on the NAS.
>
>Grateful for any helpful suggestions ...

First helpful suggestion would be to say what you've tried ;)
However I had a look at the .deb and the default command line, when
it's being started from init rather than by inetd, is as follows:

/usr/sbin/atftpd --tftpd-timeout 300 --retry-timeout 5 --mcast-port 1758 --mcast-addr 239.239.239.0-255
--mcast-ttl 1 --maxthread 100 --verbose=5 /srv/tftp

Probably you can omit the multicast options. Make sure the tftp root
directory exists on startup.

If this doesn't work, make sure nothing is already bound to port 69/udp,
it might be that your inetd is configured to invoke some other tftpd:

# fuser -v 69/udp
USER PID ACCESS COMMAND
69/udp: root 1426 F.... inetd

Hope, as they say, this does help :)

Nick
--
"The Internet, a sort of ersatz counterfeit of real life"
-- Janet Street-Porter, BBC2, 19th March 1996

[Andy Burns]

Nick Leverton wrote:

> make sure nothing is already bound to port 69/udp

multiple programs can bind to a UDP port at the same time (if they use
SO_REUSEADDR), though a

netstat -panul | grep ":69"

would show up if something was already listening.

[Nick Leverton]

In article <f04t7q...@mid.individual.net>,

Hm well, I did try this in a VM and found that atftpd complains if inetd
has the port. (closed the window and reset it now so can't prove this ;))
The OP still wants to make sure nothing else is listening there, otherwise
it is pot luck which of the processes will receive any incoming TFTP packets.

[Java Jive]

On Tue, 22 Aug 2017 17:36:31 +0100, Java Jive <ja...@evij.com.invalid>
wrote:

> Can't seem to start atftpd on my NSA221 NAS. Every single one of the
> many command lines that I've tried just display the help as though I'd
> called it with -h.
>
> An online search got a few hits, but nearly all the people with the
> problem just used a server program running on Windows instead - I've
> done this too, but I'd rather have it working on the NAS.
>
> Grateful for any helpful suggestions ...

Thanks to both.

I finally got it going late last night, but ...

The program is so moronic that it can't seem to serve either a bound
directory or a linked one. As this is a NAS and all the hard disks
are accessed via the former, I'm stuck with serving from /tftpd in the
NAS' filesystem RAM, and that's has very limited space, AND the
contents are lost every time the NAS is rebooted!

I tried both ...
mount -o bind <HD Directory> /tftpd
... and ...
ln -s <HD Directory> /tftpd
... to get round this, but the connecting client gets "File not found"
in each case.

Fer chrissake, what is the point of having all this wonderful
flexibility in the filesystem, linking, cross-mounting, etc,
flexibility which even the kernel commonly uses as it boots ...
vmLinuz -> vmLinuz.<version>
... or somesuch, only to have some fool write a service that falls
down because it completely ignores all that?

I think I've just discovered why most of the users complaining that it
wouldn't work eventually went down the Windows route instead!

<shakes head in disbelief>

[Nick Leverton]

In article <d6gqpcloehl96ufsa...@4ax.com>,

Java Jive <ja...@evij.com.invalid> wrote:

>> Grateful for any helpful suggestions ...
>
>Thanks to both.

Welcome :)

>I finally got it going late last night, but ...
>
>The program is so moronic that it can't seem to serve either a bound
>directory or a linked one. As this is a NAS and all the hard disks
>are accessed via the former, I'm stuck with serving from /tftpd in the
>NAS' filesystem RAM, and that's has very limited space, AND the
>contents are lost every time the NAS is rebooted!
>
>I tried both ...
> mount -o bind <HD Directory> /tftpd
>... and ...
> ln -s <HD Directory> /tftpd
>... to get round this, but the connecting client gets "File not found"
>in each case.

I would hazard a guess that the daemon is being started up on /tftpd
before you bind the other directory on top of it, and thus retains the
original view.

Why not just make the final, directory, parameter of your atftpd command
line point to the non-root directory in the first place ?

[Richard Stearn]

Java Jive wrote:
> The program is so moronic that it can't seem to serve either a bound
> directory or a linked one. As this is a NAS and all the hard disks
> are accessed via the former, I'm stuck with serving from /tftpd in the
> NAS' filesystem RAM, and that's has very limited space, AND the
> contents are lost every time the NAS is rebooted!

> Fer chrissake, what is the point of having all this wonderful
> flexibility in the filesystem, linking, cross-mounting, etc,
> flexibility which even the kernel commonly uses as it boots ...
> vmLinuz -> vmLinuz.<version>
> ... or somesuch, only to have some fool write a service that falls
> down because it completely ignores all that?

In a TFTP server it is very deliberate that the server can not access
outside the specified directory structure and device. TFTP has no
concept of security or access permissions hence the restriction.

From the man page for atftp about the <path>:
"All requested files from a TFTP client must reside in this directory."

[Andy Burns]

Java Jive wrote:

> what is the point of having all this wonderful
> flexibility in the filesystem, linking, cross-mounting, etc,

I don't suppose /usr/bin/atftpd (or whatever) has been replaced with a
script that calls /private/atftpd in a chroot folder? And disregarding
your arguments for good measure?

I suspect the answer to your actual question is supportability fro
Zyxel, if you want unadulterated linux build your own rather than buy
an "appliance" that's been nailed down to one job.

[Java Jive]

On Wed, 23 Aug 2017 09:21:47 +0000 (UTC), Nick Leverton
<ni...@leverton.org> wrote:
>
> In article <d6gqpcloehl96ufsa...@4ax.com>,
> Java Jive <ja...@evij.com.invalid> wrote:
> >
> >I tried both ...
> > mount -o bind <HD Directory> /tftpd
> >... and ...
> > ln -s <HD Directory> /tftpd
> >... to get round this, but the connecting client gets "File not found"
> >in each case.
>
> I would hazard a guess that the daemon is being started up on /tftpd
> before you bind the other directory on top of it, and thus retains the
> original view.

No, I stopped it, made the mount -o bind, and then restarted it. Same
thing happens, "File not found".

> Why not just make the final, directory, parameter of your atftpd command
> line point to the non-root directory in the first place ?

That was the first thing I tried, same result. The HD directories are
all 'virtualised' by Zyxel's firmware &/or the xfs filesystem, I'm not
sure which. In a shell, I see each disk as /i-data/<8 hex digits>
which itself is a bloody nuisance, because it takes a long time to
learn the new digits every time I upgrade the HDs. However, I've
partially solved that by having /etc/profile find and store them in
more conveniently named environment variables.

[Java Jive]

On Wed, 23 Aug 2017 10:32:45 +0100, Richard Stearn
<inv...@invalid.invalid> wrote:
>
> In a TFTP server it is very deliberate that the server can not access
> outside the specified directory structure and device. TFTP has no
> concept of security or access permissions hence the restriction.
>
> From the man page for atftp about the <path>:
> "All requested files from a TFTP client must reside in this directory."

That's perfectly understandable when it comes to linking, because a
remote user could upload a link to outside the shared folder, but I
see no reason why it disallows a cross 'mount -o bind' made
intentionally from within the server by its own administrator. You've
already seen the result, it renders the program near useless.

[Java Jive]

On Wed, 23 Aug 2017 11:04:06 +0100, Andy Burns <use...@andyburns.uk>
wrote:

>
> Java Jive wrote:
> >
> > what is the point of having all this wonderful
> > flexibility in the filesystem, linking, cross-mounting, etc,
>
> I don't suppose /usr/bin/atftpd (or whatever) has been replaced with a
> script that calls /private/atftpd in a chroot folder? And disregarding
> your arguments for good measure?

See my answer to Nick. I did many tests in a shell starting the
service from the command-line, and the only combination which worked
was to use the folder /tftpd.

> I suspect the answer to your actual question is supportability fro
> Zyxel, if you want unadulterated linux build your own rather than buy
> an "appliance" that's been nailed down to one job.

Well, yes, and actually that's why I need a TFTP service right now on
one of these NASs, because I'm experimenting with my own builds on the
other. I need to be able to access a good kernel and initrd via TFTPD
for if & when I screw up, which has already happened! In fact, so far
I've probably spent more of my time writing USB de-bricking code than
actually tweaking the original Zyxel builds, but, having got that down
to a fine art, I'm now free-er to experiment with the builds
themselves, so I'm hoping to make more actual progress over the coming
days than so far has been possible.

[Nick Leverton]

In article <ua5rpcphhu77jcre2...@4ax.com>,

Java Jive <ja...@evij.com.invalid> wrote:
>On Wed, 23 Aug 2017 09:21:47 +0000 (UTC), Nick Leverton
><ni...@leverton.org> wrote:
>>
>> I would hazard a guess that the daemon is being started up on /tftpd
>> before you bind the other directory on top of it, and thus retains the
>> original view.
>
>No, I stopped it, made the mount -o bind, and then restarted it. Same
>thing happens, "File not found".
>
>> Why not just make the final, directory, parameter of your atftpd command
>> line point to the non-root directory in the first place ?
>
>That was the first thing I tried, same result. The HD directories are
>all 'virtualised' by Zyxel's firmware &/or the xfs filesystem, I'm not
>sure which. In a shell, I see each disk as /i-data/<8 hex digits>
>which itself is a bloody nuisance, because it takes a long time to
>learn the new digits every time I upgrade the HDs. However, I've
>partially solved that by having /etc/profile find and store them in
>more conveniently named environment variables.

I'm glad you have a workaround, but I don't think the base problem
is to do with bind mounting or symlinking the tftp startup directory.
The program would have to jump through hoops to detect the former case and
disable it, and I don't see any references to mount or mtab in the code.
Nor does it seem to look at the mode bits in any stat call.

If you have strace on the device, and want to go deeper, then tracing the
atftpd startup (strace -f atftpd <options>) might give some clues to how
it accesses the startup directory and why it doesn't notice your changes.
Permissions, possibly, though I'm sure you'll have covered that too.

Incidentally may I give my congratulations that you've succeeded in
beating it into shape this far, considering the messy state of the
device's original code when you first started posting about this
project :)

[df7...@gmail.com]

On Tuesday, August 22, 2017 at 9:36:33 AM UTC-7, Java Jive wrote:
> Can't seem to start atftpd on my NSA221 NAS. Every single one of the
> many command lines that I've tried just display the help as though I'd
> called it with -h.
>
> An online search got a few hits, but nearly all the people with the
> problem just used a server program running on Windows instead - I've
> done this too, but I'd rather have it working on the NAS.
>
> Grateful for any helpful suggestions ...
> --

I was having same problem with older Ubuntu version. Searching Internet just had the same old information:

Edit /etc/default/atftpd
Change: USE_INETD=true to USE_INETD=false

Change: OPTIONS directory to be the one you want (e.g. /tftpboot).

Ensure directory is setup:
mkdir /tftpboot && chmod -R 777 /tftpboot && chown -R nobody:nogroup /tftpboot

But still not working. Well there was one additional change that made it work for me:

Add: --daemon to the OPTIONS in /etc/default/atftpd

Hope that helps someone else as I spent a good 5 to 6 hours on this.