I've tested the same setup (HTTP server in a different network than the DHCP server)
using QEMU and OVMF and it worked correctly for me.

Compared the DHCP Discover, Offer, Request and ACK packets from your tcpdump capture
and a capture of this configuration that worked, I only one difference in the DHCP
fields (besides IP address, mask, boot file name, etc that are expected).

This is the Client Network Interface Identifier Option (Code 94). With OVMF this is
set to 3.1 and with the firmware where this issue happens is set to 3.0.

According to RFC 4578 [0], this field encode the UNDI revision. So the firmware has

           3.00    32/64-bit UNDI specification.    (Alpha)
                   EFI boot services driver only.
                   No EFI runtime support.

While OVMF has:

           3.10    32/64-bit UNDI specification.     (Beta)
                   First generation EFI runtime driver support.

I wonder if a UNDI revision of 3.00 doesn't set the default gateway? Since GRUB does
not set the routing table and it just gets this information from the EFI firmware. It
calls EFI_IP4_CONFIG_PROTOCOL.GetData() to get this information.

I'll attach a GRUB test build that add some debug prints to the net_ls_routes command.
Could you please test it and let me know what's the output?

[0]: https://tools.ietf.org/html/rfc4578#section-2.2

Created attachment 1714837 [details]
grubx64.efi

Thank you for your investigations Javier. 

I've tried the grub which you attached and the output of the net_ls_routes command is below. 


grub>
grub>net_ls_routes 
route table entry  0 
card efinet1 interface efinet1 subnet 10.126.18.0 mask 255.255.255.0 gateway 0.0.0.0 
efinet1:local 10.126.18.0/24 efinet1 
grub>

Thanks for testing. I think this is an EFI firmware issue and not something that could
be fixed in GRUB.

As explained in the UEFI Spec [0], the EFI_IP4_CONFIG2_PROTOCOL.GetData() function is used
to query the IPv4 network configuration. Part of this data is an EFI_IP4_ROUTE_TABLE array
that contains the route table of the IPv4 network stack that runs on the network interface.

The EF firmware you are testing only returns a single entry for interface efinet1, that has
the subnet 10.126.18.0 with netmask /24 and gateway set to 0.0.0.0.

But the firmware should have another routing table entry that has 0.0.0.0/0 and a gateway
set, to use it as the default route. This entry is missing in the routing table returned by
the EFI firmware in your tests.

For reference this is what the same GRUB test build prints when running on an Qemu+ovmf VM:

grub> net_ls_routes
route table entry 0
card efinet0 interface efinet0 subnet 192.168.122.0 mask 255.255.255.0 gateway 0.0.0.0
route table entry 1
card efinet0 interface efinet0 subnet 0.0.0.0 mask 0.0.0.0 gateway 192.168.122.1
efinet0:local 192.168.122.0/24 efinet0
efinet0:default 0.0.0.0/0 gw 192.168.122.1

Since GRUB relies on the EFI firmware correctly setting up the network configuration using
DHCP and just does HTTP requests using the EFI_HTTP_PROTOCOL, I don't think there's much
that we can do to make this work.

[0]: https://uefi.org/sites/default/files/resources/UEFI%20Spec%202.8B%20May%202020.pdf

Thanks for the details. 

I understand that this might be a firmware bug and we will get in contact with the manufacturer. 

I did a reset of the config and also took out the vlan tag which you might recall that it was used. I can see now the same behavior which I mentioned also in the beginning of our email discussion: the default route is set, but on the wrong interface. 

grub>net_ls_routes
route table entry 0 
card efinet1 interface efinet1 subnet 10.126.18.0 mask 255.255.255.0 gateway 0.0.0.0
efinet1:local 10.126.18.0/24 efinet1 
route table entry 0 
card efinet0 interface (null) subnet 10.126.18.0 mask 255.255.255.0 gateway 0.0.0.0
route table entry 1 
card efinet0 interface (null) subnet 0.0.0.0 mask 0.0.0.0 gateway 10.126.18.10
efinet0:default 0.0.0.0/0 gw 10.126.18.10 
grub>net_ls_cards
efinet1 00:a0:10:01:d5:a1
efinet0 00:a0:10:01:cf:85 
grub>net_ls_addr
efinet1 00:a1:10:01:d5:a1 10.126.18.28 
grub>

One of the errors that we see on the debug grub you provided is "net/efi/net.c:1236: interface lookup failed, using default efinet1". This will explain the "null" value for the interface on the net_ls_routes.

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.