Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Ethernet aliases no longer work for orinoco_cs adapter|
|Product:||[Fedora] Fedora||Reporter:||Aaron Gaudio <madcap>|
|Component:||dhcp||Assignee:||Jason Vas Dias <jvdias>|
|Status:||CLOSED ERRATA||QA Contact:||Ben Levenson <benl>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2004-08-02 19:43:45 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:||129096|
Description Aaron Gaudio 2004-07-05 14:04:56 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 Galeon/1.3.15 Description of problem: I have a Sony r505e laptop, which has built-in wireless that uses the orinoco_cs driver. Whenever I try to bring up an interface on this driver that uses an ethernet alias device (e.g. "eth1:2"), I get the error "SIOCSIFFLAGS: Cannot assign requested address". This happens not only from the system-config-network stuff, but even trying 'ifconfig eth1:1' (with or without 'eth1' already up). I do not believe this is an issue with the orinoco_cs kernel driver, because this started happening to me after upgrading everything to Fedora Core 2 *except for* the kernel. In other words, I started getting this after upgrading net-tools, but using a kernel in which these aliases work. I have since upgraded to a custom kernel based off of Fedora Core 2's kernel (the specific version is 2.6.5-1.315custom). This did not appear to affect this problem for better or worse. Version-Release number of selected component (if applicable): net-tools-1.60-25.1 How reproducible: Always Steps to Reproduce: 1. Define a network interface using a device alias. 2. Attempt to bring up the interface using ifup <interface>, or system-config-network/system-control-network, or even ifconfig directly. Actual Results: Get errors from ifconfig saying "SIOCSIFFLAGS: Cannot assign requested address". The interface is not up. Expected Results: The interface using the device alias is up and visible in subsequent call to 'ifconfig'.
Comment 1 Aaron Gaudio 2004-07-27 16:16:36 EDT
After some investigation, I believe the problem is with dhclient. After grabbing an old SRPM of dhcpcd, rebuilding and installing it, I can now bring up ehternet aliases as expected. The ifup script will dry dhclient first, which will result in the aforementioned error "SIOCSIFFLAGS: Cannot assign requested address", but then will fall back to dhcpcd, which brings the device up and assigns the correct IP address to it, as expected. Apparently my problems with ifconfig was a red herring; I probably just wasn't using it correctly (and neither, perhaps, is dhclient).
Comment 2 Phil Knirsch 2004-08-02 09:03:22 EDT
Reassigning to component owner. Read ya, Phil
Comment 3 Jason Vas Dias 2004-08-02 19:43:45 EDT
You cannot use ethernet aliases for dhcp with dhclient. dhclient is based on obtaining a Linux Packet Filter (LPF) socket; such sockets cannot be bound to pseudo-interfaces, so you should see an error in /var/log/messages: Bind socket to interface: No such device this causes dhclient to exit, which causes ifconfig to get a bad address for the SIOCSIFFLAGS ioctl; hence the error. But why would you need to do dhcp on an ethernet alias? Presumably, you want the same interface to respond to ARP for two IP addresses, one set with dhcp and one static. This can easily be achieved by configuring the real interface to do dhcp, and configuring the 'alias' interface with a static address, as follows: in /etc/sysconfig/network-scripts/ifcfg-eth1 : DEVICE=eth1 ONBOOT=yes BOOTPROTO=dhcp in /etc/sysconfig/network-scripts/ifcfg-eth1:0 : DEVICE=eth1:0 ONBOOT=yes IPADDR=$static_ip_address NETMASK=$static_netmask Where $static_ip_address and $static_netmask are replaced by the static IP address and netmask you want to use. This setup works fine with no errors.
Comment 4 John Flanagan 2004-12-21 14:41:52 EST
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2004-566.html