[lang]

Present Perfect

Personal
Projects
Packages
Patches
Presents
Linux

Picture Gallery
Present Perfect

Home test, and tftp bits

Filed under: sysadmin — Thomas @ 1:13 pm

2009-6-19
1:13 pm

After some situations at work this week where I lost time where I really shouldn’t have had to, combined with the observation that I get more useful strategic work done at home in Belgium, and because practically speaking going to Barcelona next week would be silly given that I can only leave on Monday and Wednesday is a day off (which I loathe – San Joan, the most dangerous night in Barcelona), I decided to stay home next week and compensate by fixing my phone setup.

You see, the only really annoying thing is that any conference call I end up in is terrible because I have a really hard time hearing the other side through either my mobile or my fixed phone, as the audio cuts out several times a second.

So, I spent a few hours yesterday first setting up the VPN, which aside from some minor issues seems to be working fine now. This was apparently a prerequisite for setting up asterisk because asterisk needs a fixed IP address or something I’ve been told.

After that, I started setting up Asterisk so that I could use the same THOMSON phone we have at work from home and call people in the office over it.

All of that is not what this post is about though.

This post is about the TFTP tricks and things I always need to re-learn any time I meddle with tftp. I’m putting them here because Google usually doesn’t find the problems and solutions I come up with, so maybe they’re of use to you if you play with TFTP. They will definately be of use to me next time I mess with tftp.

  • TFTP runs over UDP on port 69
  • on Linux TFTP typically runs from xinetd. Do yourself a favour, edit /etc/xinetd.d/tftpboot and add -v -v -v to the server_args line. These lines should end up in your /var/log/messages
  • For some reason xinetd is fidgety with tftp. It doesn’t restart in.tftpd properly when you reload or restart xinetd, and so your verbose changes might not happen. Check with ps aux. You can kill it, but then xinetd doesn’t seem to start up in.tftpd properly for a while either. Strange stuff – please tell me if you know what’s going on here
  • Keep a tcpdump running on your tftp server to see requests actually make it in: tcpdump | grep tftp
  • Start by trying a tftp transfer on the server to localhost:tftp localhost -c get testIdeally, you should get Error code 1: File not found back immediately.
  • Now try an nmap from another machine: nmap -sU -p 69 server which should come back with 69/udp open|filtered tftp. If it doesn’t, you probably didn’t open 69/UDP on your server’s firewall. You can confirm by just turning off your firewall on the server for a quick test.
  • If it shows as open|filtered, try tftp server -c get test. This should error out immediately as well. If it doesn’t, it’s probably because your test machine does not allow tftp in. Confirm simply by turning off your firewall. The simplest way to fix this is to load the tftp connection tracking module: modprobe nf_conntrack_tftp. This makes sure that your machine knows to accept the reply tftp request coming in on a random port. On Fedora/RedHat systems you can make this permanent by adding it int /etc/sysconfig/iptables-config to the IPTABLES_MODULES variable. This is the number one thing I keep forgetting when debugging tftp troubles.
  • After that, try with actually existing files. Make sure you have the SEcontext correct; you can run restorecon -vR /tftpbooton the server for that. You can always confirm or deny whether SELinux is giving you trouble by temporarily turning it off. My auditd (the process that logs SELinux violations to /var/log/audit/audit.log) sometimes stops logging properly to the log file, and I need to restart it in that case. It’s easy to spot when auditd is misbehaving because by default it even logs replies to calls like setenforce 0.
  • Be careful with symlinks in /tftpboot if you use them. On your system they should actually be broken, because the tftp server will serve from /tftpboot and treat that as its root, as if it were chroot’d. So, if you have a file /tftpboot/phone/phone.inf, and you want a symlink to that file to exist and work in /tftpboot, you actually need to create a broken symlink like this: ln -sf /phone/phone.inf /tftpbootso that the symlink will work for tftpd.in This is one of those steps that I completely forget every time too.

Well, that should be it for the next time I have tftp troubles!

3 Comments »

  1. Nice writeup! To join in, here’s a hint I found useful:

    When trying to use TFTP for netbooting a system (with PXE), the TFTP file transfer might start but then freeze. This could be an MTU problem. For me, it helped to add “-B 1200” to the tftpd command line (in (x)inetd configuration file). This reduces the maximum packet size to 1200 bytes and makes TFTP work with networks interfaces which have a low MTU set.

    Comment by oliver — 2009-6-19 @ 3:44 pm

  2. ‘tcpdump | grep tftp’ should be ‘tcpdump -n port tftp’ or at least ‘tcpdump -n -l | grep –line-buffered tftp’

    oh and.. I think I commented about this a while ago, but your blog is still messed up. It looks like it is hacked. Run these commands:

    wget -Onormal.html http://thomas.apestaart.org/log/?p=904
    wget -Ogoogle.html http://thomas.apestaart.org/log/?p=904 –referer=http://www.google.com/reader/
    diff normal.html google.html

    and you’ll see a ton of crap instead of your normal content

    Comment by Justin — 2009-6-19 @ 10:02 pm

  3. Try relative symlinks as your default for “local” symlinks. It’s usually easiest to change in the directory where you want to symlink and then do the ln -s from there. I think relative symlinks are more robust in many cases.

    Comment by martin — 2009-6-20 @ 4:39 pm

RSS feed for comments on this post. TrackBack URL

Leave a comment

picture