Topics created by ***Redbob

@Redbob ok I think I know where its falling down but we need evidence and not an opinion.

Can you get a computer on the target’s network running wireshark? If yes create a pcap of the pxe booting process with this capture filter port 67 or port 68 This will only capture the dhcp process. What we are interested in is the dhcp OFFERS from one or more dhcp servers. In one of those OFFER packets is the bad actor that is sending your pxe booting into a loop. If you can’t figure it out who the bad actor is post the pcap here and I’ll look at it. The answer will be in the pcap. Use my capture filter so we only see the dhcp process and not other random traffic on your network.

@Redbob Yeah the wiki is really dated. We really need people from the community help us sort through it and move it all to the new documentation platform: https://docs.fogproject.org/en/latest/

Would you be keen to help us?

@Redbob Any news on this?

@george1421, great stuff! How couldn’t I see this before?
lol!!!
Well, I reinstalled it, and already applied what Elliot said. Let’s see if it will take things easy. Thanks!!

@Redbob Great stuff we figured this out so quickly. Hope you can dig up what was actually causing the issue for this particular IP address.

Could you check PCAP of 172.24.12.65? It’s here: new PCAP, just to understand it

What exactly are we looking for this time? For this client IP I see the TFTP transfer (default.ipxe) and next is a HTTP POST request (/fog/service/ipxe/boot.php) and a HTTP GET request (/fog/service/ipxe/bg.png) which seems fine from my point of view. The only thing I wonder is one last FIN,PSH,ACK in the TCP session but that is quite common as many clients simply drop the connection without closing it nicely.

@Redbob Hmm, that’s interesting. Have your tried in non-debug mode again? Failure or does it run through as well? What changed in between? Non-debug and debug mode are not any different while the later one only waits for your confirmations and if variables are set will print more debug information.

@redbob said in Task taking too long time to begin after FOG Menu:

r8169

120 seconds sounds like a timeout (wait) for the initialization of the card.

@redbob said in UEFI PXE boot from Windows 2003 DHCP:

it worked!

However as George said already, this is not a real solution. The network needs fixed.

@sebastian-roth and @Wayne-Workman, solved! I just had to update storage management password for DefaultMember. After that, I got successfully uploaded captured image. Thanks!
0_1512643251788_Seleção_208.png

@NateCCC Do you have any custom scripts, post-init or post-deploy?

To me it seems you have a similar but still different issue. Better open a new thread and describe your setup in detail: FOG version, picture of any messages on screen at the end of deploy on the client, even better take a video of pre and post imaging screens…

@redbob I’ve updated the wiki to include details for creating a user in FOG in 1.4.0 and 1.5.0. Future readers can find that information here: https://wiki.fogproject.org/wiki/index.php?title=Password_Central#Web_Interface

@redbob With the access control plugin. Enable the plugin system inside FOG Configuration -> FOG Settings, then install the access control plugin. There’s some threads here in the forums on how to use it.

@Junkhacker, it worked! Thanks!