Bug 279462

Created attachment 143186 [details]
yast2-000.png

Created attachment 143187 [details]
hwinfo-netcard.txt

Created attachment 143188 [details]
y2logs.tgz

I will look at that
There was a big code changes in network ...

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

This bug is still in Alpha6

fixed in yast2-network-2.15.50

When will this fix be available to users of SLED10?

Will, can you reproduce this problem on SLEDSP1?

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

yes, this problem happened to me last week under SLED 10 SP1.  I woke my T60p up from suspend, and it decided I had no network.  I realized it was the duplicate interface problem, and after a while, and a couple reboots, I managed to remember which one to delete by hand, and to get the hardware to discover the interface in a way that it would actually configure.

I see that the version of yast2-network incorporated into  SP1 as I currently have it installed is yast2-network-2.13.98-0.7, so I figured it was a known bug that would eventually resolved when 2.15.50 made it out to the world.  With this as the background, I re-ask my question:

When will yast2-network-2.15.50 be available to users of SLED10?

Because YES INDEED this is happening and it **IS** a problem.

No, it's not YaST known bug, it's kernel driver bug
This happends from time to time when your kernel driver from some reason doesn't provide MAC address
Then you can't match configuration file (where name consist from mac address) and device without mac address
Can you check this?
For 10.3 is this fixed together with sysconfig scripts when configuration names are based on device names (eth0, ...) - too complicated just for patch (maybe sp2?)
Please check and answer my question. In case there is another problem than missing MAC addresses, write new bugreport

Now we both understand better what the other was asking.  Sorry that my response was frustrating to you.

I'll make the test you ask for, but alas, you're going to have to baby me a bit in helping me understand how to make that test.  I'm not up to speed on the process by which hardware is discovered and configured under SuSE.

Q1. What's the name of the relevant configuration file under SuSE?
Q2. Where would I look to see that the kernel driver is not providing the MAC address?

To be honest, I do not fully understand why sometimes, even after going through the GUI offered by YaST to re-re-reconfigure networking, why, even across reboot, sometimes there's no wireless working on this T60p laptop.

Q1 - /etc/sysconfig/network/ifcfg-*
Q2 - see output from "hwinfo --netcard" (hwinfo is general tool for scanning hardware in suse/yast). MAC address is "HW Address" option

On T60 there is "Kill switch" for turn wlan/bluetooth/irda up or down
When this switch is turned off during boot, no device file will be created (you can see some warning in dmesg: "ipw3945: Radio Frequency Kill Switch is On:
Kill switch must be turned off for wireless networking to work.")

If it's not that case, collect all logs and send them to me (/var/log/YaST2/y2log, /var/log/messages, output from "hwinfo --netcard", dmesg)

I'm getting progressively more confused by the behavior of the wireless on this system.

First off, I'll re-confirm that the kill switch is NOT engaged.

Let me see if I can document my woes today.
I went online and looked at your message to determine what information I needed to gather.  I looked in /etc/sysconfig/network and there was ONLY 
ifcfg-eth-id-00:15:58:7e:f3:93 which is extremely odd, since that's the MAC address of the hardwired card, and I was LIVE with the wireless card.

I started up control panel, but it was taking forever to bring anything up.
Finally the panel came up and it said that the wireless interface I'd heretofore been using was present but not configured.  I aborted the network card tool, and sure enough, I could not pass bits.  The wireless card showed 4 bars, but nothing was reachable.

I re-ran the network card configuration tool, told it to configure the wireless device.  Told it to configure it at boot up, not when the wire was plugged in.  (Why it should default to plug-in for a WIRELESS card, I cannot guess.)
And clicked through next, next, next, etc. ... finish.

The networking icon in the panel did its "searching" thing, and came up "X", no network.  I tried a couple times more.  (Mind you, I'm sitting in a conference room with two other colleagues who have IBM T60p hardware.  They're running windows, and they're having NO connectivity problem with the wireless hub in the room.)

Eventually it gives sup.  "X" no network.

I re-run the configuraiton tool.  Same problem.

I left-click on the networking icon and choose, "Connect to other wireless network". I type "MIT", the network I've already specified as the SSID in the configuration. The icon disappears out of the panel.

I re-run the configuration tool.  No joy.
I re-re-run the configuration tool.  The icon shows back up, and I again say, "Connect to other wireless network".  It spins for a while and gives up.

I close the top, and move the computer to another location near a different wireless hub.  Now the computer sees two networks, "MIT", and "MIT-Outdoor".
I re-re-re select MIT, and now I have connectivity again.

I look in /etc/sysconfig/network,  and there is ifcfg-wlan-id-00:19:d2:28:50:52
as we all would expect.

At the moment, I only have the one interface showing up, but my confidence in the wireless configuration of SuSE SLED 10 SP 1 is completely gone.

I will attach the log files you requested.  Perhaps you can make sense of what is going on.

Created attachment 156302 [details]
/var/log/messages

Created attachment 156303 [details]
Output of hwinfo --netcard

Created attachment 156304 [details]
/var/log/YaST2/y2log output.

Had to compress the file because the ticketing system would not let me attach the file owing to it being too large.

While I was attaching the messages file, the net again flaked out.
This time merely re-selecting wireless network MIT seems to have solved the problem.   It is possible that our wireless infrastructure here in this building is flaky, but it is unclear to me why this would affect my use, but not the use by my colleagues with essentially the same hardware.

Perhaps a review of the attachments I have submitted by a trained eye will provide clues.

William, it seems that you don't have problem with YaST but driver/kernel.
While you're using NetworkManager, files below /etc/sysconfig/network are not important here
hwinfo looks ok, but messages not (multiple "ipw3945: REPLY_ADD_STA failed", "ipw3945: Microcode SW error detected.  Restarting" and finally "ipw3945: XXXL we have skipped command")

Please create new bugreport (because of sorting and bug owner) for this and assign it to jg@novell.com.
Write there also kernel and ipw3945 package version