[Bug 1327412] Re: Delay during PXE Boot, IP-Config gives up

Tue Apr 26 17:38:39 UTC 2016

@Mathieu Trudel-Lapierre 
> please check whether this actually fixes the issue.
> this is no guesswork.
Yes it is; I'm saying here for almost 2 years what it has to be done to fix this problem and you recommend to see if a partial fix solves the problem or not. well...

>Bits can be missed.
Sure but do not make waste my time testing something I know that goes against the corresponding RFCs.

>I believe that you misunderstand how klibc on the whole works, 
You are guessing again... I just said "please do not flag this issue as solved by a patch that does not work".

>this is why we shouldn't change yiaddr directly in dhcp_send
you wrong again; by RFC2131 all the DHCP traffic generated by a DHCP client "must" have  yiaddr = 0, then you can VERY WELL define yiaddr = 0 at dhcp_send()

> I've re-read the spec, and it looks like klibc only ever does a discover and 
> request with the dhcp_send() method; so I'll rework the patch to make this 
> clear and correctly fix the issue.
You just want to re-invent the wheel here; just add the missing line and give all of us a break;

>This is the kind of package in which you really need to know what you're doing when making changes.
I do. do you?

>dhcp_send_discover() was doing the right thing for yiaddr: it sets dev->ip_addr = INADDR_ANY; 
>which value will get copied in yiaddr in dhcp_send(), "as it should", except that's only good for dhcp_discover. >dhcp_send_request() also needs to keep track of dev->ip_addr, and shouldn't overwrite it, 
>but still ought to send with yiaddr set to INADDR_ANY.
So??? Are you trying to tell me that you finally understood what's going on here ??? 
Did you finally see the problem? well it only takes one line of code to force yiaddr to 0 and 
finish with this long story. 

Best,
Patrick

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, 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:
  In Progress
Status in klibc source package in Trusty:
  In Progress
Status in klibc source package in Wily:
  In Progress
Status in klibc source package in Xenial:
  In Progress
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