Unsolved proxyDHCP Issue
@cml I tested that this works in Win 7 and have updated the “Troubleshoot TFTP” article to reflect binary only.
Maybe the issue is tftp defaulting to ASCII? Can you try transfering it with WinSCP?
Or try using binary mode?
tftp -i x.x.x.x get issue.pcap
@Exig3nci Not ignoring you, just thinking about the issue and problems.
@Wayne-Workman unfortunately the issue is still the same.
Is there a way to cap the file when using TCPdump? I’ve tried -s 65535 but I still get the same result.
I keep getting this error when I open the file.
I’ve gotten that error the last time I tried to do a TCPDump at home with a dnsmasq issue… That was maybe two weeks ago.
Because you too have gotten this error, it leads me to think that either something about dnsmasq changed or something about Wireshark changed, or something about TCPDump changed - and I doubt that TCPDump changed - and I doubt that dnsmasq changed…
I see you’re using the latest version of Wireshark. Could you try an older version? Maybe 6 months older?
@Wayne-Workman Thanks again Wayne, wish I could focus on this project, but I’m also busy with HelpDesk tickets. Sorry for the late reply, but I managed to get the file to my windows 7 PC, but I keep getting this error when I open the file.
@Exig3nci Did you get the file transferred? When you have ProxyDHCP issues, you’re number one tool is TCPDump and Wireshark.
@Exig3nci Several options.
You can place it inside your fog server’s /tftpboot directory and use tftp commands in Win7 to get the file via command prompt as seen here: https://wiki.fogproject.org/wiki/index.php/Troubleshoot_TFTP#Try_to_get_a_file_with_Windows: Or you can place the file inside of your /images directory and then use FTP to get the file as seen here: https://wiki.fogproject.org/wiki/index.php/Troubleshoot_FTP#Try_to_get_a_file_with_Windows: Or, you can connect to a windows share on your Ubuntu machine and copy the file there as seen here: https://wiki.fogproject.org/wiki/index.php/Fedora_21_Server#mounting_a_smb_share.2FNAS_at_boot
The easiest and quickest way is to copy it to your /tftpboot directory and then use WIn7’s command prompt to just get the file. Using this method will (normally) download the file to %userprofile%
To find out where the %userprofile% is, at your win7 command prompt, issue:
@Wayne-Workman What’s a good way to share files between an ubuntu server vm and windows 7? I’ve tried auto fs, and installing VMWare tools, but I’m getting no luck. And I can’t get to the file.
I’m stuck with the PXE-E51 message when I try to boot into PXE on a machine
That means the machine didn’t get either DHCP offers or ProxyDHCP offers.
Check that your firewall is off on the FOG server, check that SELinux is off.
Beyond that, fire up TCPDump and see what’s actually happening. https://wiki.fogproject.org/wiki/index.php/Troubleshoot_TFTP#Troubleshooting
@Wayne-Workman That worked! I tried your method of copying the file worked I believe, now I’m stuck with the PXE-E51 message when I try to boot into PXE on a machine, any advice on troubleshooting?
I see you’re a regular here Mr. Workman. I tried looking at this:
I ran the ls command for the tftpboot folder. Below is what it spat out if that helps at all.
I found your problem
Line two needs a forward slash instead of back slash.
Line 6 you missed a “n”
dhcp-o-override should be dhcp-no-override
I ran this command on my box at home (which uses dnsmasq) and get this output:
[root@fog ~]# netstat -tulpn Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 684/smbd tcp 0 0 0.0.0.0:2049 0.0.0.0:* LISTEN - tcp 0 0 127.0.0.1:9000 0.0.0.0:* LISTEN 9497/php-fpm: maste tcp 0 0 0.0.0.0:41098 0.0.0.0:* LISTEN 672/rpc.statd tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 684/smbd tcp 0 0 0.0.0.0:55118 0.0.0.0:* LISTEN - tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 9407/rpcbind tcp 0 0 0.0.0.0:20048 0.0.0.0:* LISTEN 9452/rpc.mountd tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 7734/vsftpd tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 659/sshd tcp6 0 0 :::443 :::* LISTEN 9506/httpd tcp6 0 0 :::445 :::* LISTEN 684/smbd tcp6 0 0 :::42142 :::* LISTEN 672/rpc.statd tcp6 0 0 :::35007 :::* LISTEN - tcp6 0 0 :::2049 :::* LISTEN - tcp6 0 0 :::9090 :::* LISTEN 1/systemd tcp6 0 0 :::3306 :::* LISTEN 7437/mysqld tcp6 0 0 :::139 :::* LISTEN 684/smbd tcp6 0 0 :::111 :::* LISTEN 9407/rpcbind tcp6 0 0 :::80 :::* LISTEN 9506/httpd tcp6 0 0 :::20048 :::* LISTEN 9452/rpc.mountd tcp6 0 0 :::22 :::* LISTEN 659/sshd udp 0 0 0.0.0.0:4011 0.0.0.0:* 3385/dnsmasq udp 0 0 0.0.0.0:2049 0.0.0.0:* - udp 0 0 0.0.0.0:67 0.0.0.0:* 3385/dnsmasq udp 0 0 0.0.0.0:68 0.0.0.0:* 940/dhclient udp 0 0 0.0.0.0:69 0.0.0.0:* 7693/xinetd udp 0 0 0.0.0.0:111 0.0.0.0:* 9407/rpcbind udp 0 0 0.0.0.0:678 0.0.0.0:* 9407/rpcbind udp 0 0 127.0.0.1:849 0.0.0.0:* 672/rpc.statd udp 0 0 0.0.0.0:58511 0.0.0.0:* 672/rpc.statd udp 0 0 0.0.0.0:36026 0.0.0.0:* - udp 0 0 0.0.0.0:20048 0.0.0.0:* 9452/rpc.mountd udp 0 0 0.0.0.0:14057 0.0.0.0:* 940/dhclient udp6 0 0 :::36715 :::* - udp6 0 0 :::49021 :::* 940/dhclient udp6 0 0 :::2049 :::* - udp6 0 0 :::111 :::* 9407/rpcbind udp6 0 0 :::678 :::* 9407/rpcbind udp6 0 0 :::48245 :::* 672/rpc.statd udp6 0 0 :::20048 :::* 9452/rpc.mountd
Notice that dnsmasq is using ports 4011 and 67.
My home fog server’s IP address is 10.0.0.3 and I use undionly.kkpxe as my boot file. Instead of making a symbolic link (because that’s never worked for me), I just copy undionly.kkpxe to undionly.0 like this:
cp /tftpboot/undionly.kkpxe /tftpboot/undionly.0
However Tom and everyone else will recommend creating a symbolic link… and to that I say good luck lol.
Here is the contents of my /etc/dnsmasq.d/ltsp.conf
[root@fog ~]# cat /etc/dnsmasq.d/ltsp.conf port=0 log-dhcp tftp-root=/tftpboot dhcp-boot=undionly.0,10.0.0.3,10.0.0.3 dhcp-option=17,/images dhcp-option=vendor:PXEClient,6,2b dhcp-no-override pxe-prompt="Press F8 for boot menu", 3 pxe-service=X86PC, “Boot from network”, undionly pxe-service=X86PC, "Boot from local hard disk", 0 dhcp-range=10.0.0.3,proxy
However, if you look a the output you posted, it says that dnsmasq is already running… both with IPv6 and with IPv4.
Since it’s saying port 53 is already in use, and port 53 is being used by dnsmasq, then I’d say kill dnsmasq and anything else that appears to be using port 53 with the “kill” command and it’s process ID. (pid).
Here’s how you’d list all processes that dnsmasq has:
ps axjf | grep dnsmasq
one of the numbers given by that command will be the PIDs of dnsmasq. You’d then kill those tasks like this (we’re using the example number 3385 for this):
kill -KILL 3385
After you kill the instances of dnsmasq, check your port usage again… see if it’s free’d up.
Then cross your fingers and try to start dnsmasq, then check it’s status after it’s started.
Let us know how it goes.
@Tom-Elliott I still get the same issue unfortunately.
@Wayne-Workman so I still get the error even though it’s listed in netstat.
Also, to answer your original question, it’s because our DHCP here in my environment is handled through the switches instead of a DHCP server. And I don’t have any Cisco training to make changes lol.
Tom Elliott last edited by
Comment the port=0 line.
But for port 53, I still get the same issue after a restart.
@Wayne-Workman Thanks for the reply, I added the symbolic link.
But for port 53, I still get the same issue after a restart. What exavtly would I be looking for with the top command?
It’s just a bunch of text that I’m not too familiar with aha.
And for the port issue, I’d say figure out what’s running on port 53… dnsmasq is supposed to use 53…
Try to reboot? List your processes with the “top” command to see if there is anything weird going on?