FOG DHCP problems with possible printer interference?



  • Server
    • FOG Version: 1.3.0-RC-37
    • SVN Revision: 6049
    • OS: Ubuntu 14.04
    • DHCP is running on: Windows Server 2008 R2 Standard

    Hi Fog Community! Happy Holidays!

    I’ve scoured the forums in hope for an answer, but I’m coming up short.

    My FOG server has no problem with some computers on our domain, but I keep getting this error on most of them that are in a different part of the building:

    http://imgur.com/a/ZMuDD

    I looked up that error on the ipxe.org website, and it told me to run a couple commands in the iPXE shell:

    ifconf

    and

    ifconf -c dhcp net0

    After I ran these commands, I get these positive responses:

    http://imgur.com/a/IcdqV

    So when I type ‘exit’ in the iPXE shell, it exits out and immediately boots to the FOG boot menu! Amazing!!

    I may have saw 1 other post on the forums where someone had a similar problem with these DHCP issues, and found that one of their Xerox printers was the problem. We do have multiple Xerox printers in our building, including 1 that is close to the computer in the pictures I provided.

    Any idea what is going on here?



  • @george1421

    Sounds good. I’ll update when I have more information.


  • Moderator

    @afriedman Thinking about it a bit more, lets hold off on the tcpdump. I think you have a path forward there. Collecting a pcap would be nice to know but not need to know.

    IF you are still having issues after you get the spanning tree issues resolved then we can go down that path.



  • @george1421

    Sorry about the delayed response, I was out sick yesterday.

    Do you want me to PXE boot a computer that isn’t booting to FOG with the tcpdump program? Or PXE boot a computer that is working with FOG?



  • @george1421

    Sounds good. I’ll try to run that when I do some work from home tonight.

    Yeah I’m waiting on some responses from her. I believe I’ve narrowed it down to 1 specific cluster of computers (about 24-28 of them) in our building. All other 90% of computers see the FOG server with no problems.

    I’ll post an update when I can.


  • Moderator

    @afriedman Yes please that would help understand the data that joe’s script is spitting out.

    But you know you need to talk with your network group about the switch configuration too, we kind of have two threads running inside this one.



  • @george1421

    Amazing!! I just used a dumb switch in between that trouble computer, and it booted to FOG INSTANTLY, no hesitation.

    Still want me to install tcpdump and follow your instructions for it?


  • Moderator

    @afriedman We’ll just taking with Joe through chat. What he’s seeing and what I thought I say was too different things.

    It would be helpful if you can capture a pcap of the pxe booting process.

    Please do the following (assuming your fog server, dhcp server, and pxe booting clinet are on the same subnet).

    1. Install tcpdump on your fog server
    2. Launch the tcpdump program with this command tcpdump -w output.pcap port 67 or port 68 or port 69 or port 4011
    3. PXE boot the target computer until you get the error
    4. Press ctrl-c to exit out of the tcpdump program
    5. Upload the pcap file here for review.

  • Moderator

    @afriedman As I said, if you place the dumbest switch you can find (that’s still functional) between your cisco switch and the target computer. Then pxe boot the target computer, if you can get to the fog menu where you couldn’t without the dumb switch, then its most likely a spanning tree issue.

    I can say typically they would turn on one of the fast STP protocols by default (just for this reason). There have been documented cases of target computers not getting dhcp addresses because of this.



  • @Joe-Schmitt Oh alright. Well it’s a pretty neat program.

    @george1421 I’m going to try to talk to Cisco Technical Support either today or tomorrow about having them remote into our switch and turn on one of the fast STP protocols. I’ll let you know the results, unless you’d prefer I do something else before talking to Cisco.


  • Senior Developer

    @afriedman the tool was never really tested outside of with a consumer grade router. As for the output, this would be something for @george1421 to look at.



  • @Joe-Schmitt You weren’t expecting that outcome? Lol interesting.


  • Senior Developer

    @afriedman well I guess the tool works? Huh, wasn’t expecting that.



  • @Joe-Schmitt

    http://imgur.com/a/y57wR

    The bottom image is the first half, and the top image is the second half.


  • Senior Developer

    @george1421 with any luck that new build will handle multiple responses just fine. That tool was in the middle of research and development though, so it’s a toss up on how well it’ll work. I do remember I was I was in the middle of setting the vendor extension (to simulate different architectures, mac, windows, bios, and uefi boots as they do slightly different discovery packets).


  • Moderator

    @Joe-Schmitt Side note: it will need to capture at least two if not more offers from dhcp servers. If we are running dnsmasq you will get two offers right away one from the dhcp server and one from the dhcpProxy server.


  • Senior Developer

    @afriedman I just looked over what I built and it definitely won’t capture more than 1 server’s response. Use this instead: https://build.jbob.io/Tools/DHCPCheck2.exe (it seems I had some debug statements left in place).



  • @Joe-Schmitt Ahhhhhh okay. I’ll let you know the results very soon!


  • Senior Developer

    @afriedman Nope, the program will simulate a computer booting up requesting PXE information and capture who responds and with what.



  • @Joe-Schmitt Thank you very much for this program.

    When I run this program, I should then turn on a different machine in the same area and look at the results on the computer where im running your program?


Log in to reply
 

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.