Hi,

On 01/17/13 16:00, Gerd Hoffmann wrote:>   Hi,
>
> I'm running ovmf with networking enabled and ipxe efi roms.  Network
> driver seems to work properly.  In efi shell I can ifconfig the
> interface with a static ip address and ping the default gateway.
>
> dhcp autoconfigutation doesn't work though.  looks like ovmf doesn't
> like the replies it gets for some reason.
>
> Hints anyone?

Yes, at least in case you also ran qemu from libvirt:

request:

> -------------- [ tcpdump of dhcp req + reply ] ----------------
>
> 15:14:38.068671 IP (tos 0x0, ttl 64, id 1730, offset 0, flags [none],
> proto UDP (17), length 375)
>     0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from
> 52:54:00:0a:3a:49 (oui Unknown), length 347, xid 0x287606bf, secs 12,
> Flags [Broadcast]

response:

> 15:14:38.068836 IP (tos 0x0, ttl 64, id 45266, offset 0, flags [none],
> proto UDP (17), length 362)
>     192.168.144.1.1024 > 255.255.255.255.bootpc: BOOTP/DHCP, Reply,
> length 334, xid 0x287606bf, secs 12, Flags [Broadcast]

The first DHCP response (the DHCP offer) does not originate from UDP
port 67, according to the above trace. This is exactly what I'm seeing
as well.

After tracking the edk2 network stack from the bottom up for half a day
:-/, the packet is dropped on the floor here:

Udp4DgramRcvd() [MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Impl.c]
  Udp4Demultiplex()
    Udp4EnqueueDgram()
      Udp4MatchDgram() <--- returns FALSE
      InsertTailList(...)
    Udp4DeliverDgram()

>From Udp4MatchDgram():

  if ((!ConfigData->AcceptAnyPort && (Udp4Session->DestinationPort != 
ConfigData->StationPort)) ||
      ((ConfigData->RemotePort != 0) && (Udp4Session->SourcePort != 
ConfigData->RemotePort))
      ) {
    //
    // The local port or the remote port doesn't match.
    //
    return FALSE;
  }

The DEBUGs I added to this function log stuff such as:

  Udp4MatchDgram: listener: UseDefault=0 local IP=0.0.0.0 mask=0.0.0.0 port=68 
remote IP=0.0.0.0 port=67
                                                                                
                 ^^^^^^^
                                                                                
         ConfigData->RemotePort
  Udp4MatchDgram: packet: source IP=192.168.122.1 port=1024 dest 
IP=255.255.255.255 port=68
                                                  ^^^^^^^^^
                                           Udp4Session->SourcePort

The DHCP listener (ConfigData->RemotePort) is configured in
DhcpConfigUdpIo()
[MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Driver.c].


The problem is introduced by the following iptables rule, added by
libvirt (for the default network config), in the NAT table:

Chain POSTROUTING (policy ACCEPT 73 packets, 5689 bytes)
    pkts      bytes target     prot opt in     out     source               
destination
       0        0 MASQUERADE  tcp  --  *      *       192.168.122.0/24    
!192.168.122.0/24    masq ports: 1024-65535
       1      362 MASQUERADE  udp  --  *      *       192.168.122.0/24    
!192.168.122.0/24    masq ports: 1024-65535  <--- this one
       0        0 MASQUERADE  all  --  *      *       192.168.122.0/24    
!192.168.122.0/24

The DHCP DISCOVER message from OVMF is not matched by any of these rules
(the source IP is 0.0.0.0). The response (DHCP OFFER) from dnsmasq
*does* match the middle rule; iptables thinks the dhcp offer is an
initiator packet for an udp "connection" (the source matches, and the
destination 255.255.255.255 != 192.168.122.0/24 matches too), and
masquerades the DHCP OFFER as coming from source port 1024.

I inserted the following rule at the second position manually:

Chain POSTROUTING (policy ACCEPT 79 packets, 6075 bytes)
    pkts      bytes target     prot opt in     out     source               
destination
       0        0 MASQUERADE  tcp  --  *      *       192.168.122.0/24    
!192.168.122.0/24    masq ports: 1024-65535
       1      362 ACCEPT     udp  --  *      *       192.168.122.0/24     
255.255.255.255  <---- here
       1      362 MASQUERADE  udp  --  *      *       192.168.122.0/24    
!192.168.122.0/24    masq ports: 1024-65535
       0        0 MASQUERADE  all  --  *      *       192.168.122.0/24    
!192.168.122.0/24

And then dhcp started to work from the shell2 command line.

OTOH, now routing is broken for me too, just as for Duane (I can't ping
anything, public IP or default GW on virbr0), but I'll post about that
in a separate email (in the "OVMF networking for real this time"
thread).

Laszlo

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Reply via email to