proxyDHCP Issue

[Wayne Workman]

@Exig3nci said:

But for port 53, I still get the same issue after a restart.

Check this out: http://www.cyberciti.biz/faq/find-out-which-service-listening-specific-port/

[Tom Elliott]

Comment the port=0 line.

[Exig3nci]

@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.

[Exig3nci]

@Tom-Elliott I still get the same issue unfortunately.

[Wayne Workman]

@Exig3nci

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.

[Wayne Workman]

@Exig3nci

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

[Exig3nci]

@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.

[Wayne Workman]

@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

[Exig3nci]

@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.

[Wayne Workman]

@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%

[Wayne Workman]

@Exig3nci Did you get the file transferred? When you have ProxyDHCP issues, you’re number one tool is TCPDump and Wireshark.

[Exig3nci]

@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.

[Wayne Workman]

@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?

[Exig3nci]

@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.

[Wayne Workman]

@Exig3nci Not ignoring you, just thinking about the issue and problems.

[cml]

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

[Wayne Workman]

@cml I tested that this works in Win 7 and have updated the “Troubleshoot TFTP” article to reflect binary only.

[Exig3nci]

@Wayne-Workman thanks for the updated
@cml I’ve followed that step, but I still get the same issue.

[Wayne Workman]

@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/

[Exig3nci]

@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.