UEFI-PXE-Boot (Asus t100 Tablet)
-
@K.Hays said in UEFI-PXE-Boot (Asus t100 Tablet):
all other computers work just fine to image.
-
@Wayne-Workman I am currently updating the firmware. If it is a network issue as you’re thinking, could it be caused by the fact that we’re running a Sever 2008 DHCP?
-
@Wayne-Workman Firmware update was ineffective.
-
@K.Hays well, i know that you can get BIOS and UEFI to coexist and work with Windows 2012 server or a linux DHCP, but you should be able to get BIOS or UEFI (but not both at the same time) to work on Windows 2008 server as DHCP. I’d like to see the exact configuration you have the server set to, is it anything but options 66/67?
-
@Junkhacker What exactly do you mean by that?
-
@K.Hays He’s talking about your dhcp server’s scope options. Option 066 should already be correct as you said fog works for other computers. Option 067 needs set to
ipxe.efifor this device only, or tosnponly.efi@Scott-Adams hit on this point earlier.It might be worthwhile to run wireshark on the DHCP server to see if it’s even getting a request for DHCP from the device. Also, what are you connecting to as far as the network goes? We know you’re using the adapter, but can you put a dumb-switch (aka a mini-switch) between the adapter and the rest of the network and see what that does?
-
@K-Hays said:
>>Start PXE over IPv4This is way before any kernel options and even before iPXE binaries are being loaded. To me it seems like it does not get an IP via DHCP. Wonder if it does send a DHCP discovery request at all?!
The only thing that can help is wireshark/tcpdump I suppose. Are you aware on how to use those tools? Please take a packet dump and upload here to the forum.
Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)
Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG
-
@Sebastian-Roth I agree here. The image below with starting ipxv4 indicates that the firmware IS seeing that the network interface is pxe bootable (otherwise no boot option). And it is attempting to init it. I would go the tcpdump route if the FOG server and target computer is on the same subnet/broadcast domain.
with this command
tcpdump -w output.pcap port 67 or port 68that would be executed on your FOG server and then attempt to boot the target computer. Stop the tcpdump program after your target computer errors out. Then upload the pcap file here. -
@george1421 said in UEFI-PXE-Boot (Asus t100 Tablet):
tcpdump -w output.pcap port 67 or port 68
When i run this command i get “tcpdump: no suitable device found”
Tcpdump is installed, and i can run it with just the tcpdump command, but this specific line is not working. -
@K.Hays try
sudo tcpdump -w issue.pcap -i eth0(make sure the interface is specified correctly there)
-
@Quazz just for clarity you also need the filter part in addition to the interface selection.
-
@Quazz Thanks, i rebooted and was able to run the previous command.
-
@george1421 You can, but you could also filter afterwards so it doesn’t matter much imo.
-
@Quazz said in UEFI-PXE-Boot (Asus t100 Tablet):
@george1421 You can, but you could also filter afterwards so it doesn’t matter much imo.
The issue is without the filter part you will collect all broadcast traffic as well as unicast traffic to the device where you run tcpdump. This maybe too much to filter through (i.e. looking for a needle in the haystack). Also by only capturing the specific traffic there is little concern about other traffic leaking private info out if the pcap file is posted here.
Just for clarity the command should be this
sudo tcpdump -w issue.pcap -i eth0 port 67 or port 68Depending on the flavor of linux you are running you may need the sudo command (which now that I think about it could have been the root cause of the interface not being found).
-
@K.Hays Please try to re-upload… wireshark is saying it’s damaged/corrupt.
-
@K.Hays Just so I’m looking at the correct dhcp request (I think I see it already) what is the mac address of this device?
If its the one I think I see it is a uefi device with a IE32 arch.
Also can you confirm that your dhcp server has an 10.40.0.x IP address?
-
@george1421 Would you need the mac address of the adapter or the tablet itself?
The mac adress of the adapter would be 9c:eb:e8:2b:7c:b1
Also the dhcp server does not have a 10.40.0.x address. it would be 10.100.0.x -
@K.Hays OK that is the mac address of what I’m seeing.
What I see in your pcap file is the tablet asking for dhcp stuff but your dhcp server never responds. I do see other clients sending informs (dhcp client saying hello i’m here but nothing from your dhcp server.)
OK then that explains why the pcap is missing the dhcp server responses. You have the dhcp server on a different subnet, so then your router must have a dhcp-relay service running. If this is the case the responses from the dhcp server will be unicast on the client side.
-
This post is deleted! -
@K.Hays ok I see the same results in this pcap file.
You have an unfortunate situation here.
Because of the way a switched network works the fog server (packet capture device) will never see unicast communication that its not directly involved with. So what you must do is insert the packet capture device in the data path between the two unicast devices.
Its not as complicated as it sounds, if you switch has a port mirroring capabilities then you can mirror the traffic going to your router interface on the client subnet to the network interface where your packet capture device is running. The port mirroring will echo all traffic going into and out of the link that goes to your router to the packet capture device. I feel this is more complicated of a setup than you are ready for. But if you can do this, then use wireshark to capture this traffic into a pcap file.
Another solution is to move this device to the same subnet as your dhcp server (for debugging purposes only), as well as setup wireshark on a laptop (or what ever) and capture the dhcp broadcast traffic from there. You won’t get the tftp stuff, but I think the error so far is on the dhcp side.
