Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1065673 - HostAPD removes IPv6 addresses from interface in manged mode
HostAPD removes IPv6 addresses from interface in manged mode
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: hostapd (Show other bugs)
19
arm Linux
unspecified Severity high
: ---
: ---
Assigned To: John W. Linville
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2014-02-15 11:58 EST by hansgeorg.schwibbe
Modified: 2014-02-17 11:21 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 729183
Environment:
Last Closed: 2014-02-17 11:21:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description hansgeorg.schwibbe 2014-02-15 11:58:33 EST
+++ This bug was initially created as a clone of Bug #729183 +++

Description of problem:
On World IPv6 day I noticed that hostapd removes any non-fe80 address from the interface it starts on. This is documented at http://hostap.epitest.fi/bugz/show_bug.cgi?id=298

There is a possible solution there, though it seems it may not handle multiple IPv6 addresses on the same interface.

Is it possible to get a fix like this into the official Fedora package.

Version-Release number of selected component (if applicable):
hostapd-0.7.3-2.fc15.x86_64

How reproducible:
Every time

Steps to Reproduce:
1. Setup an AP with hostapd, configure ifcfg-wlan0 or whatever to have an IPv6 address
2. Start hostapd
3. No IPv6 addresses

--- Additional comment from Pete Zaitcev on 2011-10-18 23:37:50 EDT ---

The solution offered in the upstream bug is to set addresses by hooking around
hostpad. This stinks of a band-aid. Root cause is not identified. What does
the upstream say about this on mailing lists?

--- Additional comment from Pete Zaitcev on 2011-10-18 23:52:55 EDT ---

I think what must be confusing John here is that hostapd by itself does
nothing. Try to remove all addresses before running hostapd. The hostapd
will configure the interface for wireless, but not add even IPv4 addresses.

--- Additional comment from Trever Adams on 2011-10-19 08:49:11 EDT ---

Yes, this is very strange. I couldn't find any code that sets or unsets ip addresses in HostAPD. However, I can set an IPv6 address and the moment hostapd starts, it kills the address. Maybe this is a kernel bug?

--- Additional comment from John W. Linville on 2011-10-19 10:15:55 EDT ---

I think the config is being lost when the device is brought down and its mode is changed to make it an AP.  What have you got in ifcfg-wlan0?

--- Additional comment from Pete Zaitcev on 2011-10-19 11:22:17 EDT ---

Just in case: my interface is renamed. It's not called "wlan0", but "wlanhome".
This is done by this:

[root@elanor tmp]# cat /etc/udev/rules.d/70-persistent-net.rules
........................
# USB device 0x0b95:0x7720 (usb)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:b6:07:42:03", ATTR{type}=="1", KERNEL=="eth*", NAME="ethmodem"

# PCI device 0x14e4:0x4311 (b43 from niphredil)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:19:7d:a7:fc:36", ATTR{type}=="1", NAME="wlanhome"

This may be relevant, if we find that Trever's interface is renamed too
(his original report says "wlan0 _or whatever_").

Here's the /etc/sysconfig/network-scripts/ifcfg-wlanhome:

# See also /etc/udev/rules.d/70-persistent-net.rules
# b43 from niphredil
HWADDR=00:19:7D:A7:FC:36
DEVICE=wlanhome
TYPE=Wireless
# This is a lie, hostapd brings this device up on boot.
# However, if we put "no" here, dhcp races hostapd and fails to listen.
ONBOOT=yes
#
BOOTPROTO=static
IPADDR=192.168.130.1
NETMASK=255.255.255.0
#
IPV6INIT=yes
IPV6_AUTOCONF=no
IPV6ADDR="fd2d:acfb:74cc:2::1/64"
# radvd bails without a link-local address
IPV6ADDR_SECONDARIES="fe80::2:0:0:c0a8:8201/64"
#
NM_CONTROLLED=no
USERCTL=no

I would like to underscore that this configuration worked for a long
time, perhaps since Fedora 10. I started serving IPv6 on wireless about
2 years ago. It's some kind of recent regression, came with Fedora 15
or maybe even an update inside Fedora 15.

In Fedora 14 there was a regression where secondary IPv6 address stopped
being applied, but that was fixed. I think maybe the component should
be initscripts, not hostapd.

--- Additional comment from John W. Linville on 2011-10-19 13:45:08 EDT ---

Bill, any thoughts on comment 5?

--- Additional comment from Bill Nottingham on 2011-10-19 15:32:29 EDT ---

Given the upstream bug reporter is on Debian, I can't imagine it's anything specific to our initscripts.

--- Additional comment from Trever Adams on 2011-10-19 15:49:00 EDT ---

ONBOOT=yes
TYPE=Wireless
DEVICE=wlan0
BOOTPROTO=none
IPV6INIT=yes
NETMASK=255.255.255.128
IPADDR=5.1.1.129 
ESSID=MyNetwork
CHANNEL=4
RATE=Auto
MODE=Master
IPV6ADDR=fd....
IPV6ADDR_SECONDARIES=2001....

IPv6 link-local always gets assigned on my system. However, the IPv6 addresses assigned in the ifcfg-wlan0 NEVER get assigned. If I assign them with this or any other method, then bring up hostapd, they disappear. I can add them AFTER it gets started and they work find.

--- Additional comment from Trever Adams on 2012-06-19 00:47:32 EDT ---

This is still a problem.

--- Additional comment from Pierre Ossman on 2013-03-05 16:04:34 EST ---

Ping?

--- Additional comment from Trever Adams on 2013-03-05 16:37:30 EST ---

Yes, this is still a problem.

--- Additional comment from John W. Linville on 2013-03-05 16:53:32 EST ---

The device has to go down to switch modes when starting the AP.  Taking the device down causes the kernel to drop its network address configuration.  What is it that you expect to be responsible for replacing that configuration?

--- Additional comment from Pierre Ossman on 2013-03-06 01:09:37 EST ---

Well something. I expect the components of the distribution to work together. :)

So either retrigger the normal configuration routines (which I guess would mean integration with NM or initscripts), or hostapd should store and restore any configuration it nukes as part of fiddling with the device.

And why are only some things affected? The IPv4 address isn't dropped.

--- Additional comment from John W. Linville on 2013-11-22 14:41:21 EST ---

I really don't have an answer for you.  I suggest that you raise this issue with the upstream project.

--- Additional comment from  on 2014-02-15 11:52:57 EST ---

Hello,

I have the same problem with my Raspberry Pi configured as wireless access point.

I used the following tutorial to setup my raspberry pi as wireless access point:
http://itsacleanmachine.blogspot.de/2013/02/wifi-access-point-with-raspberry-pi.html

The wlan interface is configured with a static IP address:
 iface wlan0 inet static
 address 192.168.3.1
 netmask 255.255.255.0
 broadcast 192.168.3.255

My hostapd config is as follows:
    interface=wlan0
    driver=nl80211
    ssid=MY_STATION
    hw_mode=g
    channel=11
    wpa=2
    wpa_passphrase=SECRETPASSWORD
    wpa_key_mgmt=WPA-PSK
    wpa_pairwise=CCMP
    wpa_ptk_rekey=600
    macaddr_acl=0

The configuration seems to work fine, but somtimes when the router comes up, wlan0 has no IP address. 

So I tried to find the cause for this issue, and I figured the following out.

When I restart networking the IP address is allways available
sudo /etc/init.d/networking stop
sudo /etc/init.d/networking start
ifconfig

But everytime I start/restart hostapd the static IP address goes away. It looks like hostapd is doing something nasty with the wireless network interface.
Comment 1 John W. Linville 2014-02-17 11:21:22 EST
You've got to be kidding -- not only is Raspberry Pi not a supported platform for normal Fedora, but you are talking about a problem on a Debian-based distribution!

Feel free to raise your issue with the upstream project(s)...

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