Let me list what I did, and some of my conf files, and see if it agrees with what you're doing

1) downloaded dongle.bin.mvpmc-20050417, renamed to dongle.bin.mvpmc, made /tftpboot directory and copied it in there.

2) copied my old dongle.bin.mvpmc.config file in there too:



3) edited /etc/default/tftpd-hpa and /etc/inetd.conf per your changes

4) created /etc/exports:



and started nfs-kernel-server and nfs-start

5) restarted /etc/init.d/inetd

6) edited /etc/dhcp3/dhcpd.conf



(I have real IP numbers in place of the "xx"s)

7. Restarted /etc/init.d/dhcp3-server

8. Started up the MediaMVP, got the messages I listed in /var/log/syslog

Any ideas? Most of the things I did I did as root. Hm. Thanks.

The only thing I found via Google that looked appropriate is this:

http://www.redhat.com/archives/redhat-l ... 03619.html

which suggests that it might be a problem with multiple copies of inetd running. How can I check that? Would I ps -ef | grep "inetd"? Or would I do it by checking top (and if so, how does one grep top?)

For easily checking processes that are running I use Webmin. If you do not already have webmin setup follow the WIKI instructions here:

http://knoppmythwiki.homelinux.org/inde ... ebminHowTo

Inside webmin go to system and then running processes. There you can see if you have multiple versions of INETD running. You can also shutdown instances of INETD and do all kinds of other cool stuff.

I have not been able to grab my settings from home yet. Hopefully this weekend I can compare mine to yours. Nothing that you posted stands out as being bad though.

- John

Ceenvee did you ever figure out the problem? The weird thing is that all of a sudden I am getting the exact same problem! Here is my Daemon logfile:



Look at the first line. Maybe it has something to do with the tftpd server and when it starts up. Somehow it is trying to access a socket that is already in use and so it is denied. Then when the MediaMVP box tries to connect to the TFTPD server it looks like it is being denied because the socket was never able to be allocated to the TFTPD server.

It seems like the majority of the difficulty in getting the MediMVP to work with Knoppmyth is in the TFTPD server. Most likely I don't understand how to make it work well or it is complicated to make it work well and that is the problem.

Did you solve this problem? Any ideas?

- John

Sorry I jinxed you!

I posted the question over at the SHSPVR forum and got an answer:

http://www.shspvr.com/forum/viewtopic.php?t=8027

Basically, the answer was to set up the tftp line in inetd.conf as "root" instead of "nobody" as well as changing some of the parameters in that line. That worked and remotely booted my MediaMVP no problem.

You'll notice the person who helped me raised security as an issue with setting tftp to root like that. I still have to read the man pages for tftpd to see what's going on, but I know that port isn't open to the outside world, so hopefully it's less of an issue. All I know is that I set the kernel and the directory to user:group nobody:nogroup and that didn't work.

Hope this helps!

That worked! Thank you for the link.

- John

I realize that it has been some time since this was last updated, but a fairly simple explanation of what the securityissue involved happens to be, may be in order.

The tftp protocol has no authentication built into it. While your log files may show the IP address of a host requestin, or submitting a file, it can not identify who on that system initiated the request. Unless you run the process in a chroot jail, it is not exceedingly difficult to access files that are known to exist outside of the directory that tftpd is configured to serve files from. Lastly when run as root there is effectively no restriction preventing tftp from overwriting any file on your system.

In order to prevent arbitrary files from being written, tftpd requires that the file that is being submitted exist, or has a stub that exists on your system to begin with. Most systems have a .bashrc file in the root directory. If a malicious user were to create such a file that simply logged the user off, then 'sent' it to the system with a tftp client sending the destination file as '../root/.bashrc' and the folder that tftpd is serving files from is /tftpboot, then the root user's .bashrc file gets overwritten, and every time that 'root' attempts to log in, he gets logged right back out again.

There are a number of ways around this. You could even set up a shorewall or firewall rule to redirect requests to the tftp prot to another port outside of the root controlled port range (1-1024 I seem to recall, may be some other top end.) and then have your 'nobody' user run the tftpd server against that port via inet.d or xinet.d. Another possibility is to run tftpd in a chroot jail. (I don't know how to set that up, however instructions are online) You can also portforward to a completely different system somewhere in your network.

You can also set up rules to restrict tftp requests to only be considered for devices from within your network. You will need to be sure of the integrity of your network if you choose to do that, but it is an option. You may even choose to only allow the mvp device to access the tftp server, though a dedicated individual could still get around that.

Hopefully you have some idea of some of the concerns involved. You have a margine o fsafety in that you are not forwarding tftp requests across your broadband router, from the internet, but this is not a guarantee of security by any means.

Still, I am setting up something like this myself. Radio Shack is selling these devices at $79 each at the moment. It will free up a computer I have other prospective uses for, such as an improved firewall/router.

-Rusty

_________________
Master:
- AMD 1800XP on a MSI KT4V motherboard, via KT400 bios
- 120 G Segate Baracuda /, /cache, /myth, swap
- 200 G Segate Baracuda /myth/tv
- 3 Haupauge! WinTV PVR250s
- 19" Daewoo Monitor (1280x1024 ni)

Rusty: thanks for the follow up. If you get it running and you set up security that you think is adequate, please post what you did.

One question, however... my inetd.conf line includes the option "-s /tftpboot" The tftpd man page says "If possible, it is recommended that the -s flag is used to set up a chroot() environment for the server to run in once a connection has been set up." Is that enough of a chroot "jail"?

I'll investigate firewall options on the server, as well as trying to get a different user to work. Thanks.

EDIT: If I'm reading the tftpd man page correctly, since I'm not specifying a user with the -u flag, the default is to log in as user "nobody." So I think that the "root" in the inetd.conf line is deceptive: although root has to be there to access the port, the login isn't happening as root, it's happening as nobody. Plus, the chroot jail is in place with the -s flag so I think that line is as it should be.