Imac 27" ipxe boot

[george1421]

@Seb-B Is your fog server, dhcp server, and target computer on the same subnet?

[Seb B]

@george1421

Actually no, the dhcp and fog server are on a dedicated server vlan while the host is on another vlan.

However, we have half a hundred stations on this configuration and never encountered any trouble so far.

We did a test where we check on the dhcp server while running dhcp net0 and get no request on the dhcp.

We tried with several efi files and never got anything showing up on the dhcp.

[george1421]

@Seb-B Well my thought was to have them on the same subnet (for testing), then setup tcpdump to capture any dhcp being emitted from the mac when you issue the dhcp net0 or dhcp net1 command. You can install tcpdump on the fog server or in your case setup wireshark to capture ports 67, 68 if done from the FOG server 67,68,69,4011 all udp ports.

What I’m interested in is the target computer actually requesting anything on the network wire, or is there still an iPXE <-> Hardware issue. By doing the capture from the fog server and all being on the same subnet you can inspect the entire pxe booting process, from dhcp to tftp moving of the file to the target computer.

[Seb B]

@george1421

Ok so we tried that and ran tcpdump on both the dhcp server and the fog server and didn’t get any result pas the bootp part where we get to choose ipxe from the mac boot menu.

The tcpdump command we ran:
tcpdump 'host 172.16.xxx.xxx and (portrange 67-69 or 4011)'

The result :

17:13:53.000214 IP 172.16.xxx.xxx.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 38:c9:86:12:xx:xx (oui Unknown), length 295
17:13:53.000463 IP Server.DOMAINNAME.bootps > 172.16.xxx.xxx.bootpc: BOOTP/DHCP, Reply, length 303
17:13:53.000569 IP Server.DOMAINNAME.bootps > 172.16.xxx.xxx.bootpc: BOOTP/DHCP, Reply, length 321
17:13:53.000643 IP Server.DOMAINNAME.bootps > 172.16.xxx.xxx.bootpc: BOOTP/DHCP, Reply, length 321

And as soon as we click on the ipxe option, nothing is received

[george1421]

@Seb-B Ok then just to confirm, when you hit ‘s’ on the target computer and dropped to the iPXE kernel command prompt, and then waiting 30 seconds (for STP to timeout and start forwarding the port), when you issued a dhcp net0 or dhcp net1 nothing was detected by tcpdump? I’m trying to see if the iMac/iPXE is sending any data requests that might indicate it can talk out the network port.

Secondly since the target computer is on a different subnet from the fog server you will not see the broadcast messages it is sending out, you will only see the unicast messages to the computer you are running tcpdump on.

[george1421]

@george1421 Just for clarity (and my ignorance of Macs) we are talking about a desktop computer with a built in ethernet adapter, right? You are not using a usb ethernet dongle adapter.

[Seb B]

Hi,

let me sum up the tests so far, so that it’s clear for everyone (me included) :

• With the host and servers on a different vlan

  • while booting ipxe from the mac startup menu, nothing is detected by tcpdump on the fog and dhcp server
  • while on the ipxe kernel command prompt, after waiting 30 secs and launching dhcp, dhcp net0 , or dhcp net1 , nothing is detected by tcpdump either on the fog or the dhcp server

• With the host and servers on the same vlan

  • while booting ipxe from the mac startup menu, nothing is detected by tcpdump on the fog and dhcp server
  • while on the ipxe kernel command prompt, after waiting 30 secs and launching dhcp, dhcp net0 , or dhcp net1 , nothing is detected by tcpdump either on the fog or the dhcp server

We also tried with the default .efi file but didn’t get any more result in tcpdump…
It doesn’t seem it can use the NIC properly once in ipxe, we might try a tcp dump without filter except the source to see if anything is sent once the ipxe is loaded, which I doubt at this point

To address your other question, yes it is a built-in NIC in a desktop computer with no dongle whatsoever…

[Sebastian Roth]

@Seb-B said:

we might try a tcp dump without filter except the source to see if anything is sent once the ipxe is loaded, which I doubt at this point

Yes, please do so as DHCP messages usually don’t have IP addresses set in the IP header yet - sure because the client is asking to get an IP! DHCP and TFTP are both UDP while lots of other traffic is TCP. So using tcpdump with filter udp is a good start I reckon.

[george1421]

@Seb-B FWIW: This is the preferred tcpdump query:
tcpdump -w output.pcap port 67 or port 68 or port 69 or port 411
if executed on the fog server.

[Seb B]

@george1421

George,

I ran this command on the Fog server while running a dhcp net0 on the client and got no result

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
0 packets captured
0 packets received by filter
0 packets dropped by kernel

With a 24ko wireshark file with no visible data.
I also tried with another efi file with no difference in the tcpdump results.

I can’t try on the dhcp sever right now as it is in use for something else. I’ll give it a shot tomorrow morning.

Thanks again to both of you.

[george1421]

@Seb-B Now I don’t know OSX so this instructions may be a bit off.

From a command prompt is there a lspci command? If so what is the output (from within OSX) of lspci -nn|grep ernet What is the output. I’m looking for hex numbers inside square brackets i.e. [8086:12df] (totally made up number). I think we are almost at a point where we need to contact the iPXE group to see if their kernel supports this hardware. I can find no references to iPXE not working with Late 2015 Macs (but its also possible I’m not searching for the right thing too).

[Seb B]

@george1421

Hi George,

the venID:devID of the ethernet card is 14e4:1686 (there’s no lspci command on osx but I had if already written down somewhere).

I’m still waiting for the dhcp server to be available for the tcpdump but I reckon you could be right about the ipxe kernell not supporting this device yet …

[Seb B]

So I was able to launch tcpdump on the dhcp server while running a dhcp net0 command on the ipxe kernell command prompt.

There is no result which can be linked with our host (some dhcp requests but from another subnet with diferent MAC addresses).

[Sebastian Roth]

@Seb-B We seem to do rounds and rounds without getting a step forward. From what I remember net0 should be the wireless interface, right?!?

14e4:1686 is supposed to be a Broadcom netXtreme BCM57766 ethernet card. I was able to PXE boot Macminis having the exact same ethernet card, see here: https://wiki.fogproject.org/wiki/index.php?title=FOG_on_a_MAC#Working_devices

[Sebastian Roth]

As we seem to have another iMac user with PXE issue I want to ask you to give us more information on the exact model of your iMac you have Please have a look on this website and tell us the exact model you have: http://www.everymac.com/systems/apple/imac/index-imac.html

To identify your iMac you can look up important system information via Apple Menu -> About This Mac -> System Report. And while you have this window open may I ask you to also take a screenshot of the Hardware -> Ethernet Cards view (https://www.tonymacx86.com/attachments/fake-screenshot-png.124954/) and post it here.

[Seb B]

@Sebastian-Roth

sure thing. It’s this one.

As for the screenshot, here it is (it’s in french, I can switch the system in english if you need)
![alt text](

Thanks again

[Sebastian Roth]

@Seb-B Sorry for not getting back to you in a while. Have been sick and then working a lot.

Thanks for the information and great that you posted in the iPXE forums as well!!

Have you ever used tcpdump or wireshark? Would you be able to hook up your iMac using a old network hub and get a packet dump of the whole bootup process? I’d love to see if snp.efi actually sends any DHCP request or not.

Other than that I am having a look at the source code as well. Maybe I’ll find something.

[Seb B]

@Sebastian-Roth

Hi.

We did try a tcpdump both on the fog server and the dhcp
tcpdump -w output.pcap port 67 or port 68 or port 69 or port 411
and got this answer on both :

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
0 packets captured
0 packets received by filter
0 packets dropped by kernel 

It is not going to be easy to have a readable unfiltered answer as the fog server is in use with several dozens of fog clients and the dhcp server is not only a dhcp a dhcp server but has some other roles as well.

I’m sot sure I understand where you are going with the network hub thingy, could you give me more details as to what you want me to do please?

[george1421]

@Seb-B The output of the tcpdump program is a bit unexpected.

Is the fog server and pxe booting computer(s) in the same broadcast domain (subnet, vlan)? If so the FOG server should see these dhcp requests as long as the firewall has been shut off on the FOG server.

DHCP communications are done via broadcasting, even initially if a dhcp relay service is used. The FOG server should see this communication.

[Seb B]

@george1421

I know it’s not what you’d expect, though it’s the same result as the last time I tried.
The test iMac and both the fog server and dhcp server are in the same server (normally a server dedicated vlan).
It acts as though, once the the ipxe file is downloaded and “launched”, the network interface is unable to send anything out.

As I said, I think it would be tricky to launch an unfiltered tcpdump request on the server vlan and get comprehensible results.

I’m willing to give it a try but I won’t be able to understand the results…

Thanks again for your help.