Hot answers tagged

13

You would make TFTP access over the internet secure the same way you'd make access to anything over the internet secure. By going through a VPN. Cisco's IP phones can be set up to use a VPN, and someone even put together a handy doc around common issues with this setup that you might want to take a look at.


11

From the dnsmasq example config # An example of dhcp-boot with an external TFTP server: the name and IP # address of the server are given after the filename. # Can fail with old PXE ROMS. Overridden by --pxe-service. #dhcp-boot=/var/ftpd/pxelinux.0,boothost,192.168.0.3 # If there are multiple external tftp servers having a same name # (using /etc/hosts) ...


10

Then you can't do it. You've rejected another protocol that permits authenticating the requestor (hcsteve's answer) and you've rejected a VPN which would have allowed TFTP to be tunneled through an authenticated service (Hopeless N00b.*'s answer), so you're stuck with stock TFTP. RFC 1350 makes it fairly clear, in section 1, that authentication is not an ...


8

I don't see how it could have ever worked if the client doesn't respond to ARP. You can't send packets to the IP address without knowing the MAC address, and that's where ARP comes in. If the client doesn't respond to ARP then it's broken.


5

The issue is that you have configured dnsmasq to provide TFTP service (via the enable-tftp option in dnsmasq.conf). The service port for TFTP is UDP/69, so dnsmasq wants to bind to it, but xinetd has already done so, and it is impossible for two different processes to bind to the same service port. If you want dnsmasq to provide TFTP service, you will need ...


5

dhcp protocol can send hostname. It can be set with request host-name option in gnu/linux. https://tools.ietf.org/html/rfc1533#section-3.14


3

It's a tftp server, so you'll need to use a tftp client.


3

Yes, it is absolutely possible. The Ubuntu Way The "Ubuntu Way" (which is also the Debian way) would be to set up a local apt repository, and configure your client systems to get their updates from there. The Ask Ubuntu question above (which Deer Hunter graciously provided for me to steal the link to) has a pretty good description of what's involved, and ...


3

Why not specify a tftp server that's a hop away? As long as your clients are receiving the appropriate default gateway this might be the easiest way to go. That said, if you must support multiple interfaces - It's possible to run multiple instances of dhcpd. Each would have its own configuration that would include entries to specifically bind said ...


3

Cisco Small Business (SPA3xx, SPA5xx) phones support provisioning over HTTPS with mutual SSL authentication - the client can authenticate the provisioning server and the server can also authenticate the client based on the client's built-in certificate. That's the way to do it securely over the internet - forget about TFTP. See the full provisioning guide ...


3

Since you're using the state module in your iptables configuration to only allow NEW connections on the tftp port and you only posted an excerpt from your firewall config: 1 ACCEPT udp -- anywhere anywherestate NEWudp dpt:tftp is that rule in the INPUT chain and is there also a generic -A INPUT -m state --state RELATED,ESTABLISHED -j ...


3

Turns out that when testing TFTP, you have to punch a hole through both the server AND the client's firewall. That doesn't make a lot of sense since most of the articles online will talk about selinux as well as disabling the firewall on the tftp server. The server was working fine and even though I tried it from multiple different operating system types, ...


2

I had the same problem and wanted to share my experience. Promiscuous mode allows client RRQ packets with protocol problems to reach the destination (TFTP server). In my case there was a problem in ARP and the Ethernet header of the RRQ was using all zero's for the destination MAC. With promiscuous mode on, the packets were being received by the TFTP server, ...


2

Change: preseed/url=${base-url}/ubuntu/kickstart.cfg into: ks=${base-url}/ubuntu/kickstart.cfg The boot option preseed/url expects to find a Preseed configuration file, but what you have here is a KickStart configuration file. These are two different systems, which is why you're getting the error. Using ks= tells the system it's loading a ks file, not a ...


2

In isc-dhcp-server I create the option globally and then use it at the host level. You should be able to use vendor-option-space at the subnet level as well. option space SunRay; option SunRay.FWSrvr code 31 = ip-address; option SunRay.FWSrvr 10.99.90.160; option SunRay.AuthSrvr code 21 = ip-address; option SunRay.AuthSrvr 10.99.90.160; option SunRay....


2

In a production environment you would want to specifically allow TFTP through the firewall. This can be done by running system-config-firewall-tui, customising the firewall, and selecting the "TFTP" service.


2

The tftp bit has worked: the kernel is loaded and attempting to mount the root filesystem. It looks like the NFS server you're trying to mount isn't responding. Check from another client that you can actually mount /nfsroot from your server (assuming you followed the naming convention in the HOWTO).


2

Settings those permissions is absolutely not needed. Furthermore, you could set the permissions to allow only the user running the TFTP server to read the files. No execution permissions are needed in any of the files under the PXE root directory. As a matter of fact, I'm using TFTP/PXE on Debian under /srv/tftp, being /srv a separate LV mounted noexec


2

Found the problem It was the VMware NIC type. I was using the VNXNET3, once I changed to E1000 everythings works as expected. Apparently, the problem still exists in vSphere 5. http://communities.vmware.com/thread/215456


2

Nothing bad will happen, assuming that it is actually registering the same DLL. The exact same - path and version. If there's nothing wrong with it and your system, it will succeed, even if it has already been registered.


2

As answer 1, you might just disable dhcp on your router and move that role to a configurable box, like your CentOS Server A simple sample config might be (dhcpd.conf): subnet 192.168.2.0 netmask 255.255.255.0 { option domain-name-servers 192.168.2.1, 8.8.8.8; option routers 192.168.2.1; range 192.168.2.20 192.168.2.100; authoritative; } ...


2

Yes, this is possible although it may or may not work with your (unspecified) equipment. You need to tell the router(with dhcpd) to provide the address of the tftp server and the file name to request. How you do this is very much dependant on router(with dhcpd). For example pfsense Other router(with dhcpd) will be different.


2

It turned out to be a rather embarrasing mistake. Inside /etc/default/tftp.conf, I used the wrong syntax to point to the /etc/tft_remap.conf file. The correct file contents are these: TFTP_USERNAME="tftp" TFTP_DIRECTORY="/var/lib/tftpboot" TFTP_ADDRESS="0.0.0.0:69" TFTP_OPTIONS="--secure -l -v -m /etc/tftp-remap.conf"


2

The error was on my TFTP server. I changed the following line on my /etc/xinetd.d/tftp file: server_args = -s /var/tftpboot/ to this: server_args = -c -s /var/tftpboot/ And the problem is solved. The missing -c option allows new files to be created on the TFTP server.


2

You can add a static entry to your ARP table: Example: :: Add a static entry. arp -s 157.55.85.212 00-aa-00-62-c6-09 :: Displays the arp table. arp -a


2

TFTP server on it's own does not have any reason to exist. And because of that, there's no such option in DHCP (it's like specifying HTTP server in DHCP. Unless you know what is it for, it's useless). From what I've read, polycom can download their configuration from HTTP and FTP, not only TFTP. They use DHCP options 160 and 66 for configuration URL, option ...


2

TFTP over internet is never a good approach. you will run into several problems with firewalls,NAT, and timeout related aborted transfers. Considering your constraints probably you should think of securely distributing (i.e. a password protected download) the phone configuration file with a small footprint portable TFTP server; then when the update is ...


2

Seems you're starting tftpd-hpa from xinetd and as a standalone service at the same time. Please choose one and disable the other. E.g. set disable = yes in /etc/xinetd.d/tftp and restart xinetd. Then restart the standalone service service tftpd-hpa restart and try the connection again.


2

The daemon's dying unexpectedly on launch (status=1). It looks like the arguments to tftpd that you have are inappropriate for your current tftp version. Running the daemon from the shell has brought this into view, you have made the server_args parameter make sense for the current daemon, and all is now well.


2

tftpd does not write to log files on it's own. Rather, it logs via syslog (it opens /dev/log and writes messsages there, which are collected by some sort of logging daemon and then dispatched to files based on its configuration). Inside a typical container there is no logging daemon, so nothing is listening on /dev/log and your log messages simply disappear....


Only top voted, non community-wiki answers of a minimum length are eligible