The patch added to nominally fix this issue is incorrect; it is setting
the wrong bit in the BOOTP flags field for broadcast:
+ bootp.flags = htons(0x800);
The correct value should be 0x8000. This is causing issues with
switches that reject the packet as having bits set in a "must be zero"
flag area.
RFC 1542 defines the flags field as 16 bits, and the broadcast bit is
the most significant bit:
2.2 Definition of the 'flags' Field
The standard BOOTP message format defined in [1] includes a two-octet
field located between the 'secs' field and the 'ciaddr' field. This
field is merely designated as "unused" and its contents left
unspecified, although Section 7.1 of [1] does offer the following
suggestion:
"Before setting up the packet for the first time, it is a good
idea to clear the entire packet buffer to all zeros; this will
place all fields in their default state."
This memo hereby designates this two-octet field as the 'flags'
field.
This memo hereby defines the most significant bit of the 'flags'
field as the BROADCAST (B) flag. The semantics of this flag are
discussed in Sections 3.1.1 and 4.1.2 of this memo.
The remaining bits of the 'flags' field are reserved for future
use. They MUST be set to zero by clients and ignored by servers
[...]
and relay agents.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to klibc in Ubuntu.
https://bugs.launchpad.net/bugs/1327412
Title:
Delay during PXE Boot, IP-Config gives up
Status in klibc package in Ubuntu:
Fix Released
Status in klibc source package in Trusty:
Fix Released
Status in klibc source package in Wily:
Won't Fix
Status in klibc source package in Xenial:
Fix Released
Status in klibc package in Debian:
New
Bug description:
[Impact]
PXE booting users with live images or other minimal setups using klibc-utils.
[Test case]
Attempt to PXE boot using Ubuntu live images; see below for details.
[Regression potential]
This forces the yiaddr (client requested/current IP) to be set to 0 when
sending DHCP messages; currently the messages are DHCPREQUEST and DHCPDISCOVER,
which should typically only happen when there is no IP set on the device and it
is otherwise unable to receive unicast (on account of not being configured).
Should there be a need to send other messages which would require setting the
yiaddr value to the current configured IP address, a naive change would break.
The yiaddr variable would need to be adjusted to pull value from a new
location, or initialized directly by the callers to dhcp_send() where the
business logic would reside.
---
Attempting to PXE boot both the 12.04.3 and 14.04 Live images. PXE
boot works normally (PXE Menu, select desired image, image begins
loading), then the boot process hangs while IP-Config attempts to get
an IP address:
IP-Config: eth0 hardware address e0:db:55:0c:34:7e mtu 1500 DHCP
IP-Config: eth1 hardware address e0:db:55:0c:34:80 mtu 1500 DHCP
IP-Config: no response after 2 secs - giving up
IP-Config: eth0 hardware address e0:db:55:0c:34:7e mtu 1500 DHCP
IP-Config: eth1 hardware address e0:db:55:0c:34:80 mtu 1500 DHCP
IP-Config: no response after 3 secs - giving up
These lines appear very quickly (5 seconds has NOT elapsed), after
about a minute, we get this:
IP-Config: eth0 hardware address e0:db:55:0c:34:7e mtu 1500 DHCP
IP-Config: eth1 hardware address e0:db:55:0c:34:80 mtu 1500 DHCP
IP-Config: no response after 4 secs - giving up
Some time later, this:
IP-Config: eth0 hardware address e0:db:55:0c:34:7e mtu 1500 DHCP
IP-Config: eth1 hardware address e0:db:55:0c:34:80 mtu 1500 DHCP
IP-Config: no response after 6 secs - giving up
Until finally, this:
IP-Config: eth0 hardware address e0:db:55:0c:34:7e mtu 1500 DHCP
IP-Config: eth1 hardware address e0:db:55:0c:34:80 mtu 1500 DHCP
IP-Config: no response after 9 secs - giving up
IP-Config: eth0 hardware address e0:db:55:0c:34:7e mtu 1500 DHCP
IP-Config: eth1 hardware address e0:db:55:0c:34:80 mtu 1500 DHCP
IP-Config: eth0 guessed broadcast address 172.25.11.31
IP-Config: eth0 complete (dhcp from 172.25.10.20):
(snip)
While watching the DHCP server logs, Ubuntu is either not sending a
DHCP Discover at times, or is not replying back with a DHCPRequest
during these sessions, presumably ignoring an response from the DHCP
server. From the initial booting of the system via PXE, to when
Ubuntu finally shows the desktop, almost 12 minutes will have elapsed.
I am seeing this same behavior on both 12.04.3 and 14.04. After
finding a number of similar erros via Google and no real resolution, I
have opened this bug.
The system experiencing this issue has multiple ethernet interfaces
(actual HW, not a VM), some Google found solutions suggest hard coding
DEVICE=eth0 in /etc/initramfs-tools/initramfs.conf, however this isn't
acceptable as a system attempting to PXE boot may be using an
alternate port for the network.
I have found what looks to be a very similar bug filed for Debian,
#584583, which also contains a patch for this issue (under Debian).
I have no problems in PXE booting to various Windows, RedHat, Centos,
or Fedora OSs. Ubuntu is the only Live OS that I'm attempting to boot
at present.
ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: ubuntu-release-upgrader-core 1:0.220.2
ProcVersionSignature: Ubuntu 3.13.0-24.46-generic 3.13.9
Uname: Linux 3.13.0-24-generic x86_64
ApportVersion: 2.14.1-0ubuntu3
Architecture: amd64
CasperVersion: 1.340
CrashDB: ubuntu
CurrentDesktop: Unity
Date: Fri Jun 6 20:22:09 2014
LiveMediaBuild: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
PackageArchitecture: all
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: ubuntu-release-upgrader
Symptom: release-upgrade
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1327412/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
