On 22/12/2020 08:33, udai sharma wrote:

Also I was able to break into shell using "ESC+B" as "CNTRL+B" wasn't working.
Then I tried to setup the interface ip using ifstat, it didn't work but dhcp succeeded.

"ifstat" is a command to display the status of interfaces, not to configure them.

How can I verify Tx/Rx big packets as ping also disabled/not present the default ipxe.efi.

As documented at https://ipxe.org/cmd/ping you will need to enable the option PING_CMD in config/general.h when building iPXE in order to have the "ping" command available.

Hope that helps,

Michael

Hi Michael,
I hope you are doing well. Sorry for the delay in reply.

So: there is no problem with the link state, and the fact that you were
able to obtain a DHCPv4 address and download something from your HTTP
server indicates that the link is very definitely up and functional.


The error that you are experiencing is described on the error page shown
in your error message:

http://ipxe.org/0f0a6095

As you will see from that page, this error indicates a TCP RST being
sent from your web server.

Since this appears to coincide with your first attempt to download
anything larger than a single network packet, my first guess would be
that you have a problem receiving full-sized packets.

iPXE will use the MTU as reported by your driver via
PXE_OPCODE_GET_INIT_INFO. The values in FrameDataLen and MediaHeaderLen
will be added together to create the receive buffer length as used by
iPXE. This buffer length will be provided to your driver as BufferLen
for subsequent calls to PXE_OPCODE_RECEIVE.

iPXE will also use the MTU to calculate the TCP MSS sent as part of the
TCP SYN packet.

The DHCP server is allowed to override the MTU, up to the maximum
supported by the hardware (which, in this case, is the value provided
via PXE_OPCODE_GET_INIT_INFO).

My UNDI driver is setting the same parameters in "UNDI_GetInitInfo" in the below driver.
https://github.com/tianocore/edk2-platforms/blob/master/Drivers/OptionRomPkg/UndiRuntimeDxe/Decode.c
For Underlying PHY, MTU is set to 1500.

You may want to check these various values. You may also want to check
that the MTU is configured correctly on your HTTP server, if your
network is using any kind of jumbo frames.

Also I captured the packet on server. And I see MSS value set to 1460.
Frame 1: 78 bytes on wire (624 bits), 78 bytes captured (624 bits)
Encapsulation type: Ethernet (1)
Arrival Time: Dec 22, 2020 13:13:51.093371000 India Standard Time
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1608623031.093371000 seconds
[Time delta from previous captured frame: 0.000000000 seconds]
[Time delta from previous displayed frame: 0.000000000 seconds]
[Time since reference or first frame: 0.000000000 seconds]
Frame Number: 1
Frame Length: 78 bytes (624 bits)
Capture Length: 78 bytes (624 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:tcp]
[Coloring Rule Name: HTTP]
[Coloring Rule String: http || tcp.port == 80 || http2]
Ethernet II, Src: ChelsioC_29:46:40 (00:07:43:29:46:40), Dst: ChelsioC_40:7c:60 (00:07:43:40:7c:60)
Destination: ChelsioC_40:7c:60 (00:07:43:40:7c:60)
Source: ChelsioC_29:46:40 (00:07:43:29:46:40)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 102.90.90.96, Dst: 102.90.90.48
Transmission Control Protocol, Src Port: 26442, Dst Port: 80, Seq: 0, Len: 0
Source Port: 26442
Destination Port: 80
[Stream index: 0]
[TCP Segment Len: 0]
Sequence number: 0 (relative sequence number)
[Next sequence number: 0 (relative sequence number)]
Acknowledgment number: 0
1011 .... = Header Length: 44 bytes (11)
Flags: 0x002 (SYN)
Window size value: 65532
[Calculated window size: 65532]
Checksum: 0xf4f1 [unverified]
[Checksum Status: Unverified]
Urgent pointer: 0
Options: (24 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps, No-Operation (NOP), No-
Operation (NOP), SACK permitted, No-Operation (NOP), Window scale, Maximum segment size
TCP Option - No-Operation (NOP)
TCP Option - No-Operation (NOP)
TCP Option - Timestamps: TSval 191936, TSecr 0
TCP Option - No-Operation (NOP)
TCP Option - No-Operation (NOP)
TCP Option - SACK permitted
TCP Option - No-Operation (NOP)
TCP Option - Window scale: 9 (multiply by 512)
TCP Option - Maximum segment size: 1460 bytes

On 15/12/2020 06:48, udai sharma wrote:

net2: 00:07:43:29:46:40 using NII on NII-0000:02:00.0 (open)

This shows that you are using iPXE's "NII" driver, which uses the UEFI UNDI API. (Possible alternatives were the "SNP" driver which uses the UEFI SNP API, or a native PCI driver.)

[Link:down, TX:0 TXE:0 RX:0 RXE:0]
[Link status: Unknown (http://ipxe.org/1a086194)]

The link is reported as down in this initial banner because the UEFI UNDI API does not provide any way to retrieve the link state until after the interface has been opened. However...

Configuring (net2 00:07:43:29:46:40)............. ok

... the link is successfully up at this point, otherwise you would be seeing a "Waiting for link-up on net2" message from iPXE.

net0: fe80::ec4:7aff:fe6c:623e/64 (inaccessible)
net1: fe80::ec4:7aff:fe6c:623f/64 (inaccessible)
net2: 102.90.90.96/255.255.255.0 gw 102.90.90.1
net2: fe80::207:43ff:fe29:4640/64
net3: fe80::207:43ff:fe29:4658/64 (inaccessible)
Next server: 102.90.90.48
Filename: http://102.90.90.48/real_boot_script.php
http://102.90.90.48/real_boot_script.php.... [connecting].. ok
real_boot_script.php : 208 bytes [script]
http://102.90.90.48/iPXE/initrd.img...... 0%
Connection reset (http://ipxe.org/0f0a6095)
Could not boot image: Connection reset (http://ipxe.org/0f0a6095)
No more network devices
As you can see it is able to fetch 'real_boot_script.php' from http server, but Link remains Down.

So: there is no problem with the link state, and the fact that you were able to obtain a DHCPv4 address and download something from your HTTP server indicates that the link is very definitely up and functional.

The error that you are experiencing is described on the error page shown in your error message:

http://ipxe.org/0f0a6095

As you will see from that page, this error indicates a TCP RST being sent from your web server.

Since this appears to coincide with your first attempt to download anything larger than a single network packet, my first guess would be that you have a problem receiving full-sized packets.

iPXE will use the MTU as reported by your driver via PXE_OPCODE_GET_INIT_INFO. The values in FrameDataLen and MediaHeaderLen will be added together to create the receive buffer length as used by iPXE. This buffer length will be provided to your driver as BufferLen for subsequent calls to PXE_OPCODE_RECEIVE.

iPXE will also use the MTU to calculate the TCP MSS sent as part of the TCP SYN packet.

The DHCP server is allowed to override the MTU, up to the maximum supported by the hardware (which, in this case, is the value provided via PXE_OPCODE_GET_INIT_INFO).

You may want to check these various values. You may also want to check that the MTU is configured correctly on your HTTP server, if your network is using any kind of jumbo frames.

Thanks,

Michael

Hi Michael,
I am unable to break into iPXE shell (using Ctrl+B).

I could capture the below log from the serial console.

>Checking Media Presence......
>>Media Present......
>>Start PXE over IPv4.
Station IP address is 102.90.90.195

Server IP address is 102.90.90.48
NBP filename is ipxe.efi
NBP filesize is 987744 Bytes
>>Checking Media Presence......
>>Media Present......
Downloading NBP file...

Succeed to download NBP file.
iPXE initialising devices...ok



iPXE 1.20.1+ (gb6e2e) -- Open Source Network Boot Firmware -- http://ipxe.org
Features: DNS HTTP iSCSI TFTP SRP AoE EFI Menu

Press Ctrl-B for the iPXE command line...
net2: 00:07:43:29:46:40 using NII on NII-0000:02:00.0 (open)
[Link:down, TX:0 TXE:0 RX:0 RXE:0]
[Link status: Unknown (http://ipxe.org/1a086194)]
Configuring (net2 00:07:43:29:46:40)............. ok
net0: fe80::ec4:7aff:fe6c:623e/64 (inaccessible)
net1: fe80::ec4:7aff:fe6c:623f/64 (inaccessible)
net2: 102.90.90.96/255.255.255.0 gw 102.90.90.1
net2: fe80::207:43ff:fe29:4640/64
net3: fe80::207:43ff:fe29:4658/64 (inaccessible)
Next server: 102.90.90.48
Filename: http://102.90.90.48/real_boot_script.php
http://102.90.90.48/real_boot_script.php.... [connecting].. ok
real_boot_script.php : 208 bytes [script]
http://102.90.90.48/iPXE/initrd.img...... 0%
Connection reset (http://ipxe.org/0f0a6095)
Could not boot image: Connection reset (http://ipxe.org/0f0a6095)
No more network devices


As you can see it is able to fetch 'real_boot_script.php' from http server, but Link remains Down.

I cloned 'git clone git://git.ipxe.org/ipxe.git' recently and created image using 'make bin-x86_64-
efi/ipxe.efi'.

Thanks.



On Tue, 15 Dec 2020 06:31:45 +0530 Michael Brown wrote
>On 14/12/2020 19:00, Laszlo Ersek wrote:

> On 12/14/20 18:44, udai sharma wrote:

>> Hello Community,

>>

>> My OptionRom driver works with PXE but it fails to get/report link

>> status in iPXE.

>>

>> I had setup iPXE.efi in dhcp.conf to load it from DHCP-PXE server.

>> I see it gets loaded properly.

>>

>> But when iPXE ifconfig tries to look for link status, it always

>> fails to get the link status.

>>

>> I need to understand is there something with my oprom driver or the

>> driver in iPXE.efi has to be looked into.

>>

>> Thanks in advance.

>

> no clue, but I'm adding Michael.



Thanks for the heads-up!



Udai: which driver is iPXE using? You can find out via the "ifstat"

command in the iPXE shell.



Thanks,



Michael

On 14/12/2020 19:00, Laszlo Ersek wrote:

On 12/14/20 18:44, udai sharma wrote:

Hello Community,
My OptionRom driver works with PXE but it fails to get/report link
status in iPXE.
I had setup iPXE.efi in dhcp.conf to load it from DHCP-PXE server.
I see it gets loaded properly.
But when iPXE ifconfig tries to look for link status, it always
fails to get the link status.
I need to understand is there something with my oprom driver or the
driver in iPXE.efi has to be looked into.
Thanks in advance.

no clue, but I'm adding Michael.

Thanks for the heads-up!

Udai: which driver is iPXE using? You can find out via the "ifstat" command in the iPXE shell.

Thanks,

Michael

Hi,

On 12/14/20 18:44, udai sharma wrote:

Hello Community,

My OptionRom driver works with PXE but it fails to get/report link status in iPXE.



I had setup iPXE.efi in dhcp.conf to load it from DHCP-PXE server. I see it gets loaded properly.

But when iPXE ifconfig tries to look for link status, it always fails to get the link status.

I need to understand is there something with my oprom driver or the driver in iPXE.efi has to be looked

into.



Thanks in advance.

no clue, but I'm adding Michael.

Thanks
Laszlo