proxyDHCP Issue
-
Comment the port=0 line.
-
@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 I still get the same issue unfortunately.
-
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 3385
or 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.
-
Oh.
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 -
@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:
https://forums.fogproject.org/topic/4867/issues-booting-to-fog-using-dnsmasq
I ran the ls command for the tftpboot folder. Below is what it spat out if that helps at all.
-
@Exig3nci said:
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 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.
-
@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:
echo %userprofile%
-
@Exig3nci Did you get the file transferred? When you have ProxyDHCP issues, you’re number one tool is TCPDump and Wireshark.
-
@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 said:
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 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. -
@Exig3nci Not ignoring you, just thinking about the issue and problems.
-
https://ask.wireshark.org/questions/8931/capture-file-appears-to-be-damaged-or-corrupt
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
From: https://technet.microsoft.com/en-us/library/Ff698993.aspx?f=255&MSPPError=-2147217396
-
@cml I tested that this works in Win 7 and have updated the “Troubleshoot TFTP” article to reflect binary only.
-
@Wayne-Workman thanks for the updated
@cml I’ve followed that step, but I still get the same issue. -
@Exig3nci Try setting the maximum packet size via TCPDump to exactly what the error says…
262144
Then after you do a capture with that setting and put the file in the /tftpboot directory, make sure you use binary mode to transfer via TFTP.
You might also try some older versions of WireShark https://www.wireshark.org/download/win32/all-versions/
-
@Wayne-Workman So I have an older version of WireShark (1.10.4) I’ve set tftp in binary mode:
tftp
tftp> binary
Ran this command:
sudo tcpdump -w issue.pcap -i eth0 -c 65535
But I still get the same issue, The packet limit error on WireShark is capped at 65535, but the command in Ubuntu still runs.
Am I doing this correct? I have to break the command with Ctrl+C to get it to stop and it still goes over by many bytes. -
@Wayne-Workman I’m also just trying to run WireShark on my VM nic cards from my Windows 7 machine, think that will work?