Bug 230949

Summary: Manual IPv6 configuration for network install is broken
Product: [Fedora] Fedora Reporter: Mark McClelland <mark>
Component: libdhcpAssignee: David Cantrell <dcantrell>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: aj.werkman, cra
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-04-21 23:11:02 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 195271, 235706    

Description Mark McClelland 2007-03-04 18:58:37 EST
Description of problem:
If I configure an Ethernet interface manually when setting up for an IPv6 HTTP
install, the settings I entered are not used according to ifconfig. Instead, it
looks like the interface is set up with stateless autoconfig. Also, the address
of the gateway is assigned to the interface. This network has an radvd server,
and no DHCP/DHCPv6 or available IPv4 addresses.

Version-Release number of selected component (if applicable):
Fedora 7 test 2 (i386 or x86_64)

How reproducible:
Every time

Steps to Reproduce:
1. Start anaconda from CD (boot.iso)
2. Choose HTTP install source
3. Choose network interface
4. At "Configure TCP/IP" dialog, uncheck "Enable IPv4 support"
5. Select "Enable IPv6 support" and choose "Manual configuration"
6. On "Manual TCP/IP Configuration" dialog, I entered this info:
  IPv6 address: 2001:470:1f01:2931::42 / 64
  Gateway:      2001:470:1f01:2931::0
  Name Server:  2001:470:1f01:2931::0
7. Enter HTTP server info and wait for X to start

Actual results:
ifconfig output:
eth1    Link encap:Ethernet  HWaddr 00:0F:B5:FB:3B:28
        inet6 addr: 2001:470:1f01:2931::/0 Scope:Global
        inet6 addr: fec0::1:20f:b5ff:fefb:3b28/64 Scope:Site
        inet6 addr: 2001:470:1f01:2931:20f:b5ff:fefb:3b28/64 Scope:Global
        inet6 addr: fe80::20f:b5ff:fefb:3b28/64 Scope:Link
        UP BROADCAST RUNNING MTU:1500 Metric:1
        [...]

Expected results:
eth1    Link encap:Ethernet  HWaddr 00:0F:B5:FB:3B:28
        inet6 addr: fec0::1:20f:b5ff:fefb:3b28/64 Scope:Site
        inet6 addr: 2001:470:1f01:2931::42/64 Scope:Global
        inet6 addr: fe80::20f:b5ff:fefb:3b28/64 Scope:Link

Additional info:
Here's the routing table (global unicast addresses only). The first entry looks
wrong (but consistent with the ifconfig output).

#route -n -A inet6
Kernel IPv6 routing table
Destination                Next Hop                 Flags Metric Ref Use Iface
2001:470:1f01:2931::/128   2001:470:1f01:2931::     UAC   0      6     0 eth1
2001:470:1f01:2931::/64    ::                       UA    256    35    0 eth1
::/0                       2001:470:1f01:2931::     UG    1024   0     0 eth1
2001:470:1f01:2931:20f:b5ff:fefb:3b28/128    ::     U     0      56270 1 lo
[...]
Comment 1 David Cantrell 2007-03-05 10:42:52 EST
Excellent debugging info, thanks (we don't usually get detailed reports like
this)!  DHCP (for IPv4 and IPv6) in anaconda's loader is handled by libdhcp, so
I've reassigned the component.
Comment 2 David Cantrell 2007-03-08 15:00:46 EST
OK, so it wasn't in libdhcp.  It was in anaconda's use of libdhcp.  Fixed in
rawhide.  Thanks.
Comment 3 Mark McClelland 2007-03-16 23:01:29 EDT
I'm still seeing this in the Mar. 14 rawhide. I tried using three unique
addresses for the IPv6 address, gateway, and nameserver, and I can confirm that
the gateway text field is where the bogus 2001:470:1f01:2931::/0 address is
coming from.
Comment 4 Matthew Miller 2007-04-06 16:23:08 EDT
This isn't obvious anywhere, but Fedora 7 test bugs should be filed against the
"devel" version.
Comment 5 David Cantrell 2007-05-22 16:31:27 EDT
I think I have this fixed up.  It was staring at me for a while and I kept
overlooking it.

I wasn't disabling the auto neighbor discovery for IPv6 when you select manual
IPv6 configuration in anaconda.  So anaconda would take the information for you,
set it, and then drive over it with the auto discovery garbage.

When you select manual IPv6 configuration, I disable both DHCPv6 *and* auto
neighbor discovery.  Code is checked in to anaconda CVS, will show up in rawhide
the next time we rebuild anaconda.  Going ahead and marking this as closed rawhide.

Thanks.
Comment 6 Mark McClelland 2007-05-26 01:36:03 EDT
Thanks for trying to get a fix in under the wire, but it appears that your fix
needs fixing. I get the error below after entering my IPv6 addresses and hitting
OK. I couldn't get it to happen with IPv4 (manual or otherwise) or IPv6
autoconf, so I suspect it's related to your fix. If not, I can open a new bug.

loader received SIGSEGV! Backtrace:
[0x80402a4]
[0x5da420]
[0x80b2529]
[0x806105a]
[0x8063ccb]
[0x8049246]
[0x804a9e8]
[0x8172728]
[0x8048131]
install exited abnormally [1/1]
Comment 7 David Cantrell 2007-05-29 11:11:42 EDT
Damn.  Yeah, totally related.  I'll get on this, but the window for getting
fixes in for Fedora 7 is closed.  I can get this fixed up and provide you with a
custom initrd.img for F-7 that has the fix.  I hate to leave you hanging where
you can't get it installed in your environment.

First things first, let me reproduce this and get it fixed, then we test, then I
can make you custom initrds (or show you how).
Comment 8 Mark McClelland 2007-05-29 23:12:29 EDT
Don't worry, I'm only trying to install this way for better testing coverage. I
normally use IPv6 autoconfig instead, and I suspect that most IPv6 users do the
same (or use DHCPv6). I'd be glad to test a custom initrd though, since I'm sure
someone else will want it eventually.
Comment 9 David Cantrell 2008-02-08 22:04:23 EST
Is this happening for you with the current development releases?
Comment 10 Mark McClelland 2008-02-09 01:50:30 EST
Just tested with F9 alpha i386 DVD askmethod and got this:

loader received SIGSEGV! Backtrace:
/sbin/loader(loaderSegvHandler+a0)[0x80505f0]
[0x12f420]
/lib/libdhcp-1.99.so.1(pumpSetupInterface+0x1f2)[0x25df92]
/sbin/loader(configureNetwork+0x1a)[0x806350a]
/sbin/loader(readNetConfig+0x5c6)[0x8066316]
/sbin/loader(main+0xdba)[0x8051d0a]
/lib/libc.so.6(__libc_start_main+0xe0)[0x4274a0]
/sbin/loader[0x804e771]
install exited abnormally [1/1]
Comment 11 David Cantrell 2008-02-09 03:41:27 EST
Right, so that was a problem that creeped in to the alpha release of F-9.  If
you could try from the nightly rawhide builds, that would be good.  I have fixed
the problem you see above.

http://download.fedora.redhat.com/pub/fedora/linux/development/i386/os/images/boot.iso
Comment 12 Mark McClelland 2008-02-09 04:57:06 EST
With the boot.iso dated 08-Feb-2008 15:20:

loader received SIGSEGV! Backtrace:
/sbin/loader(loaderSegvHandler+0xa0)[0x8050320]
[0x131420]
/lib/libdhcp-1.99.so.1(pumpSetupInterface+0x1f2)[0x25ff92]
/sbin/loader(configureNetwork+0x1a)[0x806330a]
/sbin/loader(readNetConfig+0x5de)[0x806704e]
/sbin/loader(main+0xf05)[0x8051855]
/lib/libc.so.6(__libc_start_main+0xe6)[0x4304a6]
/sbin/loader[0x804e541]
install exited abnormally [1/1]

I don't know if the fix was supposed to be in that boot.iso already. I'll try
again tomorrow.
Comment 13 Mark McClelland 2008-02-17 20:18:28 EST
I get basically the same backtrace with boot.iso dated 17-Feb-2008 12:43:

loader received SIGSEGV! Backtrace:
/sbin/loader(loaderSegvHandler+0xa0)[0x804fb90]
[0x131400]
/lib/libdhcp-1.99.so.1(pumpSetupInterface+0x1d0)[0x261000]
/sbin/loader(configureNetwork+0x1a)[0x8062a5a]
/sbin/loader(readNetConfig+0x5de)[0x806679e]
/sbin/loader(main+0xf05)[0x80510b5]
/lib/libc.so.6(__libc_start_main+0xe6)[0x432516]
/sbin/loader[0x804ddb1]
install exited abnormally [1/1]
Comment 14 A.J. Werkman 2008-03-26 17:00:13 EDT
AJ.Werkman@digifarma.nl
Comment 15 Mark McClelland 2008-04-02 01:42:17 EDT
This bug is still present in F9 beta. The backtrace is virtually the same.
Comment 16 Charles R. Anderson 2008-04-03 23:32:03 EDT
Same crash from Comment #13 in F9 rawhide as of 2008-04-03.
Comment 17 Jon Stanley 2008-04-16 13:16:59 EDT
*** Bug 433290 has been marked as a duplicate of this bug. ***
Comment 18 David Cantrell 2008-04-21 23:11:02 EDT
Fought this bug today and won.  It is actually a libdhcp bug, so changing the components there.  Basically, 
in pumpSetupInterface(), it was not allowing a set of configuration data that only contained a single 
networking stack.  It assumed that every caller would be doing both IPv4 and IPv6.  I released a new 
version of libdhcp with the fix, libdhcp-1.99.8, so you can now do just IPv6 and completely disable IPv4.

There are also some cleanup patches I did for anaconda that are related to this bug, so there should be a 
rebuild there too.