Bug 737448
| Summary: | VM's DHCP transaction ID is not random - it is based on the VM's MAC | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Yaniv Kaul <ykaul> | ||||
| Component: | gpxe | Assignee: | Amos Kong <akong> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | Virtualization Bugs <virt-bugs> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 6.2 | CC: | acathrow, ailan, djuran, jkt, juzhang, michen, mkenneth, shuang, tburke, virt-maint | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2012-02-01 02:31:17 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Yaniv Kaul
2011-09-12 07:15:43 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.
gpxe/net/udp/dhcp.c:
/**
* 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;
}
net/udp/dhcp6.c:
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.
Hi Yaniv, could you help to reply this mail? http://marc.info/?l=kvm&m=131610214800469&w=2 What real problem do you touched? only not in accordance to the RFC? 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. 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
0.0.0.0.bootpc > 255.255.255.255.bootps: [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
0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 9a:5e:b5:68:17:d8 (oui Unknown), length 387, xid 0xb56817d8, Flags [none] (0x0000)
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 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. |