Re: iPXE isnt able to get link status from my oprom driver, but PXE works.


UdayS
 

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

Join discuss@edk2.groups.io to automatically receive all group messages.