Bug 737448 - VM's DHCP transaction ID is not random - it is based on the VM's MAC
Summary: VM's DHCP transaction ID is not random - it is based on the VM's MAC
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: gpxe
Version: 6.2
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Amos Kong
QA Contact: Virtualization Bugs
Depends On:
TreeView+ depends on / blocked
Reported: 2011-09-12 07:15 UTC by Yaniv Kaul
Modified: 2015-05-25 00:06 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-02-01 02:31:17 UTC

Attachments (Terms of Use)
patch: [dhcp] Use random transaction ID to associate messages (3.67 KB, patch)
2011-09-18 01:35 UTC, Amos Kong
no flags Details | Diff

Description Yaniv Kaul 2011-09-12 07:15:43 UTC
Description of problem:
It appears that when a VM is DHCP'ing, its DHCP transaction ID is the last 4 bytes of its MAC.
This is not in accordance to the RFC (http://www.networksorcery.com/enp/rfc/rfc2131.txt):

xid           4  Transaction ID, a random number chosen by the
                    client, used by the client and server to associate
                    messages and responses between a client and a

Not sure what the consequences are, but it's wrong.

Version-Release number of selected component (if applicable):

How reproducible:
Look at the a DHCP of a VM booting (I've seen it with virtio-net)

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

Comment 2 Amos Kong 2011-09-14 13:01:41 UTC
If boot up guest from disk, then launch the network interface, we can capture the real random ID (it changes every time).

I found this problem only exist when booting up guest from pxe.

 * Calculate DHCP transaction ID for a network device
 * @v netdev            Network device
 * @ret xid             DHCP XID
 * Extract the least significant bits of the hardware address for use
 * as the transaction ID.
static uint32_t dhcp_xid ( struct net_device *netdev ) {
        uint32_t xid;

        memcpy ( &xid, ( netdev->ll_addr + netdev->ll_protocol->ll_addr_len
                         - sizeof ( xid ) ), sizeof ( xid ) );
        return xid;

static uint32_t dhcp6_xid ( struct net_device *netdev ) {

According to this, moving this bug to gpxe Component.
This bug also exist in gpxe upstream.

Comment 5 Amos Kong 2011-09-17 00:24:09 UTC
Hi Yaniv, could you help to reply this mail?

What real problem do you touched? only not in accordance to the RFC?

Comment 10 David Juran 2011-09-20 07:23:00 UTC
I've tried the rom on http://fileshare.englab.nay.redhat.com/pub/section2/kvm/akong/virtio-net.rom and I managed to boot the VM three consecutive times. Of course this doesn't prove anything since the issue wasn't 100% reproducible in the first place but I'll update this Bz if I again manage to reproduce this issue again with the updated rom.

Comment 11 Suqin Huang 2011-09-21 02:38:54 UTC
reproduce it on gpxe-roms-qemu-0.9.7-6.7.el6.noarch

boot guest with -boot n 

[root@dhcp-8-125 ~]# tcpdump broadcast -i switch -vv|grep DHCP
tcpdump: listening on switch, link-type EN10MB (Ethernet), capture size 65535 bytes > [udp sum ok] BOOTP/DHCP, Request from 9a:5e:b5:68:17:d8 (oui Unknown), length 387, xid 0xb56817d8, Flags [none] (0x0000)
	    DHCP-Message Option 53, length 1: Discover > [udp sum ok] BOOTP/DHCP, Request from 9a:5e:b5:68:17:d8 (oui Unknown), length 387, xid 0xb56817d8, Flags [none] (0x0000)

Comment 13 David Juran 2011-09-21 10:53:48 UTC
Tried again with the testing ROM from http://fileshare.englab.nay.redhat.com/pub/section2/kvm/akong/virtio-net.rom and today booting failed )-:
The boot went a bit further, (Sent a request and recieved an ACK but no TFTP started) Dump attached in  https://bugzilla.redhat.com/attachment.cgi?id=524184

Comment 20 Amos Kong 2012-02-01 02:31:17 UTC
No specific bug was mentioned in comment #1, and I didn't target any problem before applying this patch. So close this bug as NOTABUG.

Note You need to log in before you can comment on or make changes to this bug.