Bug 393801

Does it still happens when you increase DHCLIENT_WAIT_AT_BOOT in
/etc/sysconfig/network/dhcp to 15 or 30? See also bug #390676.

What exactly is the problem? That the dhcp client needs long
or that wireless association. Does it work with static IP?

CJP:
can you apply the patch from bug #389668 to /sbin/dhclient-script and test
if it works better for you?

Re comment #2 setting up static IP is not possible, yast2 lan hangs at "write routing configuration" and needs to be killed, see yast2logs attached.

After starting yast2 lan again it shows the static IP for WLAN, on closing hangs again. Probably a new Bug ?

As it appears after entering "Default Gateway" which had been there to begin with but now is empty yast2 lan now finishes properly. 

Yet it still takes _very_ long at "write routing configuration" as well as "Setting Firewall configuration"

Static IP seems to work, but not on boot. Issuing ifdown / ifup produces:

#ifdown wlan0
wlan0

    wlan0     device: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
executing additional global stop script if-down.d/21-dhcpcd-hook-samba
executing additional global stop script if-down.d/50-ntp
executing additional global stop script if-down.d/55-samba-winbindd
wlan0 wlan0
No services to handle for 'wlan0 wlan0'
wlan0 wlan0
interface wlan0 is not up
wlan0 wlan0
Shutting down service dhcp client on wlan0
wlan0 wlan0
PRS: OLDDEFROUTEIFACE=
PRS: OLDDEFROUTEARGS=
wlan0 wlan0
prefer wpa_supplicant: no
No wpa_supplicant running on interface wlan0

# ifup wlan0
wlan0

    wlan0     device: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
wlan0 wlan0
prefer wpa_supplicant: no
configuration requires wpa_supplicant
    wlan0     warning: WPA configured but may be unsupported
    wlan0     warning: by this device
using WPA driver 'wext' for interface wlan0
    wlan0     starting wpa_supplicant
Handling Index <>:
     IPADDR             = 192.168.0.44
     PREFIXLEN          = 24
     CHECK_DUPLICATE_IP = no
wlan0 wlan0
calling: ip route replace to default via 192.168.0.1  ---> OK
calling: ip route replace to 169.254.0.0/16 dev wlan0  ---> OK
wlan0 wlan0
No services to handle for 'wlan0 wlan0'
executing additional global start script if-up.d/21-dhcpcd-hook-samba
executing additional global start script if-up.d/50-ntp
Checking for network time protocol daemon (NTPD):                    unused
executing additional global start script if-up.d/55-samba-winbindd
executing additional global start script if-up.d/SuSEfirewall2


The patch from Bug # 389668 doesn't seem to make any difference for this issue.

Created attachment 217990 [details]
yast2logs from yast2 lan hang

Having gone back to ifup / dhcpSetting DHCLIENT_WAIT_AT_BOOT to 30 ( as per comment #1 ) does not seem to have any influence.

ifstatus wlan0 after boot shows:

# ifstatus wlan0
wlan0

    wlan0     device: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
wlan0 wlan0
    wlan0     DHCP client NOT running
wlan0 is up
4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:13:02:18:12:ac brd ff:ff:ff:ff:ff:ff
    inet6 fe80::213:2ff:fe18:12ac/64 scope link 
       valid_lft forever preferred_lft forever
wlan0 wlan0
Configured routes for interface wlan0:
  default 192.168.0.1 - -  

0 of 1 configured routes for interface wlan0 up
wlan0 wlan0
prefer wpa_supplicant: no
wlan0     IEEE 802.11g  ESSID:">manus manum lavat<"  
          Mode:Managed  Frequency:2.422 GHz  Access Point: 00:04:0E:A4:4F:A7   
          Bit Rate=54 Mb/s   Tx-Power=27 dBm   
          Retry min limit:7   RTS thr:off   Fragment thr=2352 B   
          Encryption key:DFBA-01A2-C366-B996-F5BA-522A-3069-818A [2]
          Link Quality=88/100  Signal level=-44 dBm  Noise level=-80 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

wlan0 wlan0

issuing a dhclient wlan0 then does it:

dhclient wlan0
Internet Systems Consortium DHCP Client V3.0.6
Copyright 2004-2007 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

wmaster0: unknown hardware address type 801
wmaster0: unknown hardware address type 801
Listening on LPF/wlan0/00:13:02:18:12:ac
Sending on   LPF/wlan0/00:13:02:18:12:ac
Sending on   Socket/fallback
DHCPREQUEST on wlan0 to 255.255.255.255 port 67
DHCPACK from 192.168.0.1
bound to 192.168.0.32 -- renewal in 1467 seconds.

issuing ifdown wlan0 results in:

# ifdown wlan0
wlan0

    wlan0     device: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
executing additional global stop script if-down.d/21-dhcpcd-hook-samba
executing additional global stop script if-down.d/50-ntp
executing additional global stop script if-down.d/55-samba-winbindd
wlan0 wlan0
No services to handle for 'wlan0 wlan0'
wlan0 wlan0
interface wlan0 is not up
wlan0 wlan0
Shutting down service dhcp client on wlan0
wlan0 wlan0
Shutting down service dhcp client on wlan0
wlan0 wlan0
PRS: OLDDEFROUTEIFACE=
PRS: OLDDEFROUTEARGS=
wlan0 wlan0
prefer wpa_supplicant: no
No wpa_supplicant running on interface wlan0

issuing ifup wlan0 then gives:

# ifup wlan0
wlan0

    wlan0     device: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
wlan0 wlan0
prefer wpa_supplicant: no
configuration requires wpa_supplicant
    wlan0     warning: WPA configured but may be unsupported
    wlan0     warning: by this device
using WPA driver 'wext' for interface wlan0
    wlan0     starting wpa_supplicant
wlan0 wlan0
Starting service dhcp client on wlan0
Starting DHCP Client Daemon on wlan0... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . no IP address yet... backgrounding. 
wlan0 wlan0
calling: ip route replace to default via 192.168.0.1  ---> FAILED

issuing dhclient wlan0 the produces:

# dhclient wlan0
Internet Systems Consortium DHCP Client V3.0.6
Copyright 2004-2007 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

wmaster0: unknown hardware address type 801
wmaster0: unknown hardware address type 801
Listening on LPF/wlan0/00:13:02:18:12:ac
Sending on   LPF/wlan0/00:13:02:18:12:ac
Sending on   Socket/fallback
DHCPREQUEST on wlan0 to 255.255.255.255 port 67
DHCPACK from 192.168.0.1
bound to 192.168.0.32 -- renewal in 1373 seconds.

after updating from factory this morning the issue seems to be resolved, on boot internet access is established.

ifdown / ifup / ping now produce expected results

# ifdown wlan0
wlan0

    wlan0     device: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
executing additional global stop script if-down.d/21-dhcpcd-hook-samba
executing additional global stop script if-down.d/50-ntp
executing additional global stop script if-down.d/55-samba-winbindd
wlan0 wlan0
No services to handle for 'wlan0 wlan0'
wlan0 wlan0
wlan0 wlan0
Shutting down service dhcp client on wlan0
wlan0 wlan0
Shutting down service dhcp client on wlan0
wlan0 wlan0
PRS: OLDDEFROUTEIFACE=
PRS: OLDDEFROUTEARGS=
wlan0 wlan0
prefer wpa_supplicant: no

# ifup wlan0
wlan0

    wlan0     device: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
wlan0 wlan0
prefer wpa_supplicant: no
configuration requires wpa_supplicant
    wlan0     warning: WPA configured but may be unsupported
    wlan0     warning: by this device
using WPA driver 'wext' for interface wlan0
    wlan0     starting wpa_supplicant
wlan0 wlan0
Starting service dhcp client on wlan0
Starting DHCP Client Daemon on wlan0... . . . . . . . . IP/Netmask: '192.168.0.23' / '255.255.255.0' 
wlan0 wlan0
calling: ip route replace to 169.254.0.0/16 dev wlan0  ---> OK

# ping google.com
PING google.com (64.233.187.99) 56(84) bytes of data.
64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=1 ttl=242 time=146 ms
64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=2 ttl=242 time=148 ms
64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=3 ttl=242 time=147 ms

(In reply to comment #4 from Casual J. Programmer)
> Re comment #2 setting up static IP is not possible, yast2 lan hangs at "write
> routing configuration" and needs to be killed, see yast2logs attached.
> 
> After starting yast2 lan again it shows the static IP for WLAN, on closing
> hangs again. Probably a new Bug ?

It looks like. I've "cloned" the bug, so we can handle them separately...

First of all, don't use the ISC dhclient for multiple parallel running
interfaces - it is not supported by the network scripts (ifup-dhcp)
until now. You should get this message in /var/log/messages:

 dhclient is already running for some interface. Stop it first.
 If you want to run dhcp on several interfaces, please use dhcpcd.

[You can use it with STARTMODE="ifplugd" + different IFPLUGD_PRIORITY's
 for the interfaces (so only one is up).]

You can change it in /etc/sysconfig/network/dhcp by setting:
  DHCLIENT_BIN="dhcpcd" or DHCLIENT_BIN="

Further, when you configure to use static IP, please make sure that
there is:
 - one default route in /etc/sysconfig/network/routes (ifroute-*)

   default 192.168.0.1 0.0.0.0 wlan0

 - a nameserver and a search entry in /etc/resolv.conf
     search ac
     nameserver 192.168.0.1

When you're using dhcp, make sure at least, there is no static
default route in /etc/sysconfig/network/routes (ifroute-*).

You're already in Cc of Bug #386364 that is about driver specific
association problems. But you seem to not to have any?

You write in comment #5 "Static IP seems to work, but not on boot."
What exactly does this mean? Are there some error messages?
What is the output of "rcnetwork restart -o boot debug"?

(In reply to comment #8 from Casual J. Programmer)
> after updating from factory this morning the issue seems to be resolved,
> on boot internet access is established.

Hmm... And what happens now with your eth0 interface? Before, both
was with BOOTPROTO=dhcp (before you've changed one to static):

PRO/100 VE Network Connection
PRO/Wireless 3945ABG Network Connection

Are you using one of the interfaces with BOOTPROTO="static" now?
Can you provide the network script logs from /var/log/boot.msg?

BTW:

Last change was DHCLIENT_WAIT_AT_BOOT=15, another are not related:
* Fr Mai 23 2008 mt@suse.de
- new version 0.70.8
- Improved ifup-bridge script reliability and allow that the
  bridge exists, e.g. because created by xen (bnc#378595).
- Increased DHCLIENT_WAIT_AT_BOOT to 15 and added comment note,
  that RFC 2131 specifies, that the dhcp client should wait a
  random time between one and ten seconds to desynchronize the
  use of DHCP at startup (bnc#390676).
- Fixed rcnetwork reload to delete [vlan] interfaces when the
  ifcfg file got deleted and honor the -o skip option for the
  non-physical interfaces (bnc#346566).

The most easy first: 
"You're already in Cc of Bug #386364 that is about driver specific
association problems. But you seem to not to have any?" 

No I don't have any driver related issues and I doubt there are any, as you may judge by comment #0 and  comment #22 of that bug. If the driver had an issue, it would not be able to talk to the ap and associate. I rather think that bug needs to be set up afresh to make sure people talk about _identical_ issues and facts.

For the rest you gave me a lot of reading, and I will work it off one by one. so be patient.

One thing to think about though: Although I may be setting up networks in a nonstandard way with respect to using two interfaces in parallel, this used to work without problem in the past...

(In reply to comment #12 from Casual J. Programmer)
> The most easy first: 
> "You're already in Cc of Bug #386364 that is about driver specific
> association problems. But you seem to not to have any?" 
> 
> No I don't have any driver related issues and I doubt there are any, as you may
> judge by comment #0 and  comment #22 of that bug. If the driver had an issue,
> it would not be able to talk to the ap and associate. I rather think that bug
> needs to be set up afresh to make sure people talk about _identical_ issues and
> facts.

Yes, this is also my impression. But this is Helmut's issue :-)

> For the rest you gave me a lot of reading, and I will work it off one by one.
> so be patient.

OK, thank you very much for all your efforts of bug hunting!!

> One thing to think about though: Although I may be setting up networks in a
> nonstandard way with respect to using two interfaces in parallel, this used
> to work without problem in the past...

It still works using the dhcpcd client. Please give it a try too...

It never worked in the past with ISC dhclient (dhcp-client package)
or it was due to accident. The scripts never supported this.

Next step: static IP 

It still does not work on boot ( you need to kick dhcp to get name resolution ) and also yast2 lan again hangs when setting the routes.

So here is something amiss

Created attachment 218163 [details]
/var/log/boot.msg from booting with static IP on wlan0

Interesting observation:

configured wlan0 for static IP=192.168.0.23, Mask=255.255.255.0

NetworkMonitor applet shows IP=192.168.0.30

# ifstatus wlan0
wlan0

    wlan0     device: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
wlan0 is up
4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:13:02:18:12:ac brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.30/24 brd 192.168.0.255 scope global wlan0
    inet6 fe80::213:2ff:fe18:12ac/64 scope link 
       valid_lft forever preferred_lft forever
    wlan0     IP address: 192.168.0.30/24
wlan0 wlan0
Configured routes for interface wlan0:
  169.254.0.0 - 255.255.0.0 wlan0  
Active routes for interface wlan0:
  192.168.0.0/24  proto kernel  scope link  src 192.168.0.30
  169.254.0.0/16  scope link
  default via 192.168.0.1
1 of 1 configured routes for interface wlan0 up
wlan0 wlan0
prefer wpa_supplicant: no
wlan0     IEEE 802.11g  ESSID:">manus manum lavat<"  
          Mode:Managed  Frequency:2.422 GHz  Access Point: 00:04:0E:A4:4F:A7   
          Bit Rate=54 Mb/s   Tx-Power=27 dBm   
          Retry min limit:7   RTS thr:off   Fragment thr=2352 B   
          Encryption key:9F92-C896-BAB2-D240-A56C-5D1B-8C1B-CF03 [2]
          Link Quality=90/100  Signal level=-42 dBm  Noise level=-82 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

wlan0 wlan0

question is, why isn't 192.168.0.23 used, but 192.168.0.30 ???

I just had a chance to repeat all the steps for configuration, I will just list them here, then we can decide whether some of them are bugs in their own right.

Clean installing from factory sets network up for use with NetworkManager, to use the traditional method yast2 lan needs to be invoked and NICs reconfigured.

First of all "Network Settings/Global Options" check "Traditional Method" with ifup, as well as set up the credentials for wlan ( ESSID / Pasphrase ) and the Routing Gateway.

Yast2 spends a lot of time setting up routing, it then comes to a point where it wants to install smpppd and kinternet, which fails as during network setup repos are not available as network is down.

Checking this shows wlan0 comes preconfigured with "Enable Device Control for Non-root User Via Kinternet" unchecking this makes yast2 lan finish properly.

Nothing goes at all..

there are two instances of dhcpcd running, killing and restarting one with dhcpcd wlan0 achieves nothing.

As wpa_supplicant is required, checking whether it's up. ps -A | grep wpa shows 2 instances are running. ifdown wlan0 makes one go away. So there must be one left over from NetworkManager. Killing it and ifup wlan0 produces a state where the AP (192.168.0.1) can be pinged but no network access possible.

Going over every step again, reveals that yast2 lan is removing the entry for the routing gateway when started, it has to be set explicitly again before closing it.

After that both dhcpcd as well as dhclient can get IP address and Name Resolution.

One thing I added in the previous experiments was the concurrent use of dhcpd and dhclient, as I wasn't aware that they are really two different animals

(In reply to comment #17 from Casual J. Programmer)
> I just had a chance to repeat all the steps for configuration, I will just list
> them here, then we can decide whether some of them are bugs in their own right.

Yes, I think we definitely have to handle them separately.

> Clean installing from factory sets network up for use with NetworkManager, to
> use the traditional method yast2 lan needs to be invoked and NICs reconfigured.
> 
> First of all "Network Settings/Global Options" check "Traditional Method" with
> ifup, as well as set up the credentials for wlan ( ESSID / Pasphrase ) and the
> Routing Gateway.
> 
> Yast2 spends a lot of time setting up routing, it then comes to a point where
> it wants to install smpppd and kinternet, which fails as during network setup
> repos are not available as network is down.
> 
> Checking this shows wlan0 comes preconfigured with "Enable Device Control for
> Non-root User Via Kinternet" unchecking this makes yast2 lan finish properly.
> 
> Nothing goes at all..
> 
> there are two instances of dhcpcd running, killing and restarting one with
> dhcpcd wlan0 achieves nothing.
> 
> As wpa_supplicant is required, checking whether it's up. ps -A | grep wpa shows
> 2 instances are running. ifdown wlan0 makes one go away. So there must be one
> left over from NetworkManager. Killing it and ifup wlan0 produces a state where
> the AP (192.168.0.1) can be pinged but no network access possible.
> 
> Going over every step again, reveals that yast2 lan is removing the entry for
> the routing gateway when started, it has to be set explicitly again before
> closing it.
> 
> After that both dhcpcd as well as dhclient can get IP address and Name
> Resolution.

OK, cool.

> One thing I added in the previous experiments was the concurrent use of dhcpd
> and dhclient, as I wasn't aware that they are really two different animals

Yes, it are different animals.

Michal, as most of the steps was done in yast2, I reassign to you for an
review and then you'll "bounce back" when the reason is in sysconfig, OK?

After booting to the above ( comment #17 ) configuration today, no network connection again. I rechecked all the settings arrived at in comment #17, they were still unchanged. But:

# service network restart
Shutting down network interfaces:
    eth0      device: Intel Corporation PRO/100 VE Network Connectiondonev 02)
    wlan0     device: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)                                                             done
Shutting down service network  .  .  .  .  .  .  .  .  .  .  .  .  . done.
Hint: you may set mandatory devices in /etc/sysconfig/network/config
Setting up network interfaces:
    lo        
    lo        IP address: 127.0.0.1/8   
              IP address: 127.0.0.2/8                                done
    eth0      device: Intel Corporation PRO/100 VE Network Connection (rev 02)
    eth0      is controlled by ifplugd                               waiting
    wlan0     device: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
    wlan0     warning: WPA configured but may be unsupported
    wlan0     warning: by this device
    wlan0     starting wpa_supplicant
WEXT auth param 4 value 0x0 - ioctl[SIOCSIWAUTH]: Operation not supported
    wlan0     (DHCP) . . . . . no IP address yet... backgrounding.   waiting
Setting up service network  .  .  .  .  .  .  .  .  .  .  .  .  .  . done.
SuSEfirewall2: Setting up rules from /etc/sysconfig/SuSEfirewall2 ...
SuSEfirewall2: Warning: no default firewall zone defined, assuming 'ext'
SuSEfirewall2: using default zone 'ext' for interface wmaster0
SuSEfirewall2: batch committing...
SuSEfirewall2: Firewall rules successfully set

# ps -A | grep dhc

# ifdown wlan0
    wlan0     device: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
workstation6l:/home/antonyarendt/Desktop # ifup wlan0
    wlan0     device: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
    wlan0     warning: WPA configured but may be unsupported
    wlan0     warning: by this device
    wlan0     starting wpa_supplicant
WEXT auth param 4 value 0x0 - ioctl[SIOCSIWAUTH]: Operation not supported
Starting DHCP Client Daemon on wlan0... . . . . . no IP address yet... backgrounding. 

# ps -A | grep dhc
# ping 192.168.0.1
connect: Network is unreachable
# dhcpcd wlan0
# ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=7.31 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=1.60 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=2.73 ms
^C
--- 192.168.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2009ms
rtt min/avg/max/mdev = 1.606/3.884/7.310/2.466 ms
# ps -A | grep dhc
10512 ?        00:00:00 dhcpcd

So it appears that dhcpcd is started, but somehow ceases to run after "backgrounding", manually starting it resolves the issue.

Not sure what kind of log or other information could be useful, please advise.

please try the new package of dhcpc:

ftp.suse.com/pub/people/varkoly/dhcpcd/<arch>

rpm -Uvh dhcpcd-3.2.3-1.i586.rpm
error: failed to stat /var/lib/gdm/.gvfs: Permission denied
Preparing...                ########################################### [100%]
	package dhcpcd-3.2.3-3 (which is newer than dhcpcd-3.2.3-1) is already installed

Peter, can you look what exactly happens with dhcpcd here?
[I'm away for the next two weeks.]

CJP:
can you check if the DHCLIENT_ADDITIONAL_OPTIONS variable in
/etc/sysconfig/network/dhcp contains any options (bug 389759)?

When yes, please remove them and try if it works then.

yes it is set to " -B", removing "-B" solves the issue. 

It was set because I checked "Request Broadcast Response" under "DHCP Client Options" in yast2 lan's "Global Options". 

Not sure why this should cause trouble, I always had this set and it worked as expected.

Also I note, after having removed -B from DHCLIENT_ADDITIONAL_OPTIONS, setting up eth0 and selecting "Activate device: At Boot Time" still renders wlan0 nonfunctional. This is the case where AP can be pinged, yet no network connection.


# ping google.com
connect: Network is unreachable

# ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=1.90 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=1.76 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=1.70 ms
^C
--- 192.168.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2007ms
rtt min/avg/max/mdev = 1.703/1.789/1.902/0.096 ms

# ifstatus wlan0
    wlan0     device: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
    wlan0     DHCP client (dhcpcd) is running
              IPADDR='192.168.0.40'
              NETMASK='255.255.255.0'
              GATEWAYS='192.168.0.1'
              DNSSERVERS='192.168.0.1'
              REBINDTIME='756000'
              DHCPCHADDR='00:13:02:18:12:ac'
wlan0 is up
4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:13:02:18:12:ac brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.40/24 brd 192.168.0.255 scope global wlan0
    inet6 fe80::213:2ff:fe18:12ac/64 scope link 
       valid_lft forever preferred_lft forever
    wlan0     IP address: 192.168.0.40/24
Configured routes for interface wlan0:
  169.254.0.0 - 255.255.0.0 wlan0  
Active routes for interface wlan0:
  192.168.0.0/24  proto kernel  scope link  src 192.168.0.40
  169.254.0.0/16  scope link
1 of 1 configured routes for interface wlan0 up
bssid=00:04:0e:a4:4f:a7
ssid=>manus manum lavat<
id=0
pairwise_cipher=CCMP
group_cipher=CCMP
key_mgmt=WPA2-PSK
wpa_state=COMPLETED
ip_address=192.168.0.40

Where I am not sure what this

"Configured routes for interface wlan0:
  169.254.0.0 - 255.255.0.0 wlan0"

is supposed to be ???

Setting both NICs down, then wlan0 up works as expected then

# ifdown eth0
    eth0      device: Intel Corporation PRO/100 VE Network Connection (rev 02)

# ifdown wlan0
    wlan0     device: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)

# ifup wlan0
    wlan0     device: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
    wlan0     warning: WPA configured but may be unsupported
    wlan0     warning: by this device
    wlan0     starting wpa_supplicant
WEXT auth param 4 value 0x0 - ioctl[SIOCSIWAUTH]: Operation not supported
Starting DHCP Client Daemon on wlan0... . . . . . . . . . IP/Netmask: '192.168.0.40' / '255.255.255.0' 
workstation6l:/home/antonyarendt # ping google.com
PING google.com (64.233.187.99) 56(84) bytes of data.
64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=1 ttl=242 time=147 ms
64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=2 ttl=242 time=148 ms
64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=3 ttl=242 time=146 ms
^C
--- google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2006ms
rtt min/avg/max/mdev = 146.826/147.556/148.152/0.706 ms

*** Bug 394477 has been marked as a duplicate of this bug. ***

(In reply to comment #25 from Casual J. Programmer)
> yes it is set to " -B", removing "-B" solves the issue. 
> 
> It was set because I checked "Request Broadcast Response" under "DHCP Client
> Options" in yast2 lan's "Global Options". 
> 
> Not sure why this should cause trouble, I always had this set and it worked
> as expected.

There is a new dhcpcd 3.x (code fork), that does not support all the old
(dhcpcd 1.x) options.

See also "man dhcpcd" and /usr/share/doc/packages/dhcpcd/dhcpcd-1-vs-3.

The maintainer of dhcpcd has a fix (or is working on it) to remove all
unsupported options when the package gets installed.

(In reply to comment #26 from Casual J. Programmer)
> Also I note, after having removed -B from DHCLIENT_ADDITIONAL_OPTIONS, setting
> up eth0 and selecting "Activate device: At Boot Time" still renders wlan0
> nonfunctional. This is the case where AP can be pinged, yet no network
> connection.
> 
> 
> # ping google.com
> connect: Network is unreachable

There is no default route set. I think, I know why this happens.
Because the ifup-dhcp script detected, that there are two interfaces
using dhcp, it disabled setting of a default route on the second one
and this is wlan0. The dhcp on eth0 does not provide any, right?

Can you provide the output of "ps ax | grep dhcpcd" please to verify?

This needs explicit configuration of the dhcp clients in ifcfg files;
please set:

  - in ifcfg-eth0:
    DHCLIENT_SET_DEFAULT_ROUTE="no"

  - in ifcfg-wlan0:
    DHCLIENT_SET_DEFAULT_ROUTE="yes"

consider to set also:
    DHCLIENT_SET_HOSTNAME
    DHCLIENT_SET_DOMAINNAME
    DHCLIENT_KEEP_SEARCHLIST
    DHCLIENT_MODIFY_RESOLV_CONF
    DHCLIENT_MODIFY_NTP_CONF
    DHCLIENT_MODIFY_NIS_CONF 

> "Configured routes for interface wlan0:
>   169.254.0.0 - 255.255.0.0 wlan0"
> 
> is supposed to be ???

Zeroconf aka APIPA link local route (RFC 3927):

"a host may automatically configure an interface with an IPv4 address
 within the 169.254/16 prefix that is valid for communication with
 other devices connected to the same physical (or logical) link."

You can set the "-L" option in DHCLIENT_ADDITIONAL_OPTIONS globally
or for interface, where you don't want it. See also "man dhcpcd"
and also LINKLOCAL_INTERFACES in /etc/sysconfig/network/config.

And see also "man ifcfg" for STARTMODE=ifplugd. You can set
a lower prio using IFPLUGD_PRIORITY for eth and higher for
wlan0 when you don't need both links at same time.

In reply to comment # 28

>There is a new dhcpcd 3.x (code fork), that does not support all the old
>(dhcpcd 1.x) options.

This needs to be reflected in yast2 lan then also, i.e. checkbox removed.

>There is no default route set. I think, I know why this happens.
>Because the ifup-dhcp script detected, that there are two interfaces
>using dhcp, it disabled setting of a default route on the second one
>and this is wlan0. The dhcp on eth0 does not provide any, right?

This also has been working as expected before, in addition I would expect the script to detect that eth0 is configured but no cable attached.

As you can see by the following, a dhcpcd is started for each NIC as you said:

# ifdown wlan0
    wlan0     device: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)

# ifdown eth0
    eth0      device: Intel Corporation PRO/100 VE Network Connection (rev 02)

# ifup eth0
    eth0      device: Intel Corporation PRO/100 VE Network Connection (rev 02)
Starting DHCP Client Daemon on eth0... . . . . . . . . . . . . . . . no IP address yet... backgrounding.
 
# ifup wlan0
    wlan0     device: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
    wlan0     warning: WPA configured but may be unsupported
    wlan0     warning: by this device
    wlan0     starting wpa_supplicant
WEXT auth param 4 value 0x0 - ioctl[SIOCSIWAUTH]: Operation not supported
Starting DHCP Client Daemon on wlan0... . . . . . . . . . IP/Netmask: '192.168.0.40' / '255.255.255.0' 

And it also indicates the wlan0 gets an IP while eth0 gets none ( no wonder if no cable is present )

consequently:

 # ps ax | grep dhc
14118 pts/2    S      0:00 /sbin/dhcpcd -D -K -N -t 999999 -h workstation6l -c /etc/sysconfig/network/scripts/dhcpcd-hook eth0
14306 ?        Ss     0:00 /sbin/dhcpcd -R -G -N -Y -t 999999 -h workstation6l -c /etc/sysconfig/network/scripts/dhcpcd-hook wlan0
14619 pts/2    R+     0:00 grep dhc

>This needs explicit configuration of the dhcp clients in ifcfg files;

Thanks that you point that out, I still contend that this should be done by the setup program ( yast2 lan ) in the first place. I am probably not the only one falling into that trap, and my ( as well as others ) in depth knowledge of networking is limited. 

>Zeroconf aka APIPA link local route (RFC 3927):

Thanks again for pointing out. Not sure if this is relevant for proper function, if it doesn't hurt it may well sit there. Again I expect the setup program to take care of that.

In response to comment #29

Also very helpful information, thank you. 

Again if I set both NICs to be started at boot, I expect the setup scripts to detect that eth0 has no cable. For me it used to work as expected. When eth0 cable connected no need for wlan0, if cable not present wlan0 required

From my Windows XP Installation I am used to use multiple interfaces in parallel I can even add a modem connection and use it together with LAN and WLAN, the load gets split among all connected interfaces. Sounds reasonable for me. Somehow..

In any case, I am very grateful to you for taking the time to explain issues in depth. Thank you!