This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 691663 - dhcp process screwed up
dhcp process screwed up
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
15
x86_64 Linux
high Severity high
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-03-29 04:19 EDT by Luya Tshimbalanga
Modified: 2011-05-31 21:15 EDT (History)
6 users (show)

See Also:
Fixed In Version: 0.8.993-3.git20110526
Doc Type: Bug Fix
Doc Text:
Taken from Dan quote: Mar 30 01:45:26 muamba dhclient[1306]: DHCPDISCOVER on em2 to 255.255.255.255 port 67 interval 5 Mar 30 01:45:27 muamba dhclient[1306]: DHCPOFFER from 192.168.1.254 Mar 30 01:45:27 muamba dhclient[1306]: DHCPREQUEST on em2 to 255.255.255.255 port 67 Mar 30 01:45:30 muamba dhclient[1306]: DHCPREQUEST on em2 to 255.255.255.255 port 67 Mar 30 01:45:34 muamba dhclient[1306]: DHCPREQUEST on em2 to 255.255.255.255 port 67 Mar 30 01:45:43 muamba dhclient[1306]: DHCPDISCOVER on em2 to 255.255.255.255 port 67 interval 8 Mar 30 01:45:43 muamba dhclient[1306]: DHCPOFFER from 192.168.1.254 but the DHCP server isn't responding to the request for the address that was offered. It should look like this: Mar 28 08:50:35 dcbw dhclient[1206]: DHCPOFFER from 192.168.1.1 Mar 28 08:50:35 dcbw dhclient[1206]: DHCPREQUEST on wlan12 to 255.255.255.255 port 67 Mar 28 08:50:35 dcbw dhclient[1206]: DHCPACK from 192.168.1.1 Issue affected both desktop and laptop after upgrade and installation from scratch
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-05-31 21:15:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
/var/log/message | grep NetworkManager (1.11 MB, text/plain)
2011-03-29 13:50 EDT, Luya Tshimbalanga
no flags Details
New /var/log/message | grep NetworkManager (129.69 KB, text/plain)
2011-03-29 15:12 EDT, Luya Tshimbalanga
no flags Details
/var/log/message | grep NetworkManager (92.45 KB, text/plain)
2011-03-30 05:15 EDT, Luya Tshimbalanga
no flags Details
full /var/log/messages (2.32 MB, text/plain)
2011-03-30 12:51 EDT, Luya Tshimbalanga
no flags Details
lspci -nn (2.12 KB, text/plain)
2011-03-31 04:02 EDT, Luya Tshimbalanga
no flags Details
latest messages (5.58 MB, text/plain)
2011-03-31 15:07 EDT, Luya Tshimbalanga
no flags Details
Latest /var/log/messages (2.02 MB, text/plain)
2011-04-04 23:08 EDT, Luya Tshimbalanga
no flags Details
modem-manager sealert (482 bytes, text/plain)
2011-04-05 02:13 EDT, Luya Tshimbalanga
no flags Details
NetworkManager sealert (11.31 KB, text/plain)
2011-04-05 02:14 EDT, Luya Tshimbalanga
no flags Details
pcscd sealert (2.96 KB, text/plain)
2011-04-05 02:14 EDT, Luya Tshimbalanga
no flags Details
Latest /var/log/messages (1.07 MB, text/plain)
2011-04-13 15:41 EDT, Luya Tshimbalanga
no flags Details
wpa_supplicant.log (9.58 KB, text/x-log)
2011-04-13 15:41 EDT, Luya Tshimbalanga
no flags Details
Messages with succesful access to public AP (1.11 MB, text/plain)
2011-04-13 18:04 EDT, Luya Tshimbalanga
no flags Details
Router status (77.75 KB, image/jpeg)
2011-04-30 06:04 EDT, Luya Tshimbalanga
no flags Details
latest messages (2.06 MB, text/plain)
2011-04-30 18:42 EDT, Luya Tshimbalanga
no flags Details
ifcfg-auto_ethernet (298 bytes, text/plain)
2011-05-03 14:23 EDT, Luya Tshimbalanga
no flags Details
gconf.xml for nm-applet (102 bytes, text/xml)
2011-05-04 14:53 EDT, Luya Tshimbalanga
no flags Details
Latest /var/log/messages (1.75 MB, text/plain)
2011-05-04 14:56 EDT, Luya Tshimbalanga
no flags Details
/var/log/messages from F15 Beta Live Media (119.49 KB, text/plain)
2011-05-05 14:30 EDT, Luya Tshimbalanga
no flags Details
Wireshark report from desktop (Acer E380) (566.69 KB, text/plain)
2011-05-07 19:47 EDT, Luya Tshimbalanga
no flags Details
Wireshark report from desktop (Acer E380) (141.72 KB, application/octet-stream)
2011-05-09 10:40 EDT, Luya Tshimbalanga
no flags Details
Wireshark wlan0 from laptop (18.11 KB, application/octet-stream)
2011-05-09 18:10 EDT, Luya Tshimbalanga
no flags Details
Wireshark report from desktop (Acer E380) running kernel F15 beta (22.84 KB, application/octet-stream)
2011-05-13 14:49 EDT, Luya Tshimbalanga
no flags Details
message from F15RC3 Design edition Live (79.21 KB, text/plain)
2011-05-15 21:36 EDT, Luya Tshimbalanga
no flags Details
Latest /var/log/messages from Toshiba C650 (113.75 KB, text/plain)
2011-05-15 22:14 EDT, Luya Tshimbalanga
no flags Details
Updated wlan0 from Toshiba C650 (22.20 KB, application/octet-stream)
2011-05-16 17:22 EDT, Luya Tshimbalanga
no flags Details
Updated wlan0 from Toshiba C650 (36.80 KB, application/octet-stream)
2011-05-26 15:09 EDT, Luya Tshimbalanga
no flags Details
Updated wlan0 from Toshiba C650 (1.07 MB, application/octet-stream)
2011-05-27 15:12 EDT, Luya Tshimbalanga
no flags Details

  None (edit)
Description Luya Tshimbalanga 2011-03-29 04:19:54 EDT
Description of problem:
Updating to the latest version of NetworkManager caused inability to connect to either wired or wireless network.

Version-Release number of selected component (if applicable):
0.8.997-6.git20110328.fc15

How reproducible:
Always

Steps to Reproduce:
1. Use latest version release 
2.
3.
  
Actual results:
NetworkManager vainly attempt to connect.

Expected results:
Network should be connected

Additional info:
Comment 1 Adam Williamson 2011-03-29 12:41:31 EDT
Can we get the NM-related messages from /var/log/messages ? Are you in GNOME, KDE, or what? Thanks!
Comment 2 Luya Tshimbalanga 2011-03-29 13:50:16 EDT
Created attachment 488512 [details]
/var/log/message | grep NetworkManager

Gnome 3 in Fallback mode running Gallium3D 0.4 on llwnpipe for AMD Fusion E-350 based laptop. Unfortunately, hardware-acceleration is broken for Gnome-Shell. Anyway, here is the requested /var/log/messages
Comment 3 Luya Tshimbalanga 2011-03-29 13:54:23 EDT
It appears the cause of problem is:

Mar 29 10:05:24 muamba NetworkManager[987]: <error> [1301418324.25581] [nm-session-monitor.c:326] nm_session_monitor_init(): Error loading /var/run/ConsoleKit/database: Error statting file /var/run/ConsoleKit/database: No such file or directory
Comment 4 Adam Williamson 2011-03-29 14:02:40 EDT
what does 'systemctl status console-kit-daemon.service' show?
Comment 5 Luya Tshimbalanga 2011-03-29 14:20:53 EDT
#systemctl status console-kit-daemon.service
console-kit-daemon.service - Console Manager
   Loaded: loaded (lib/systemd/system/console-kit-daemon.service)
   Active: active (running) since Tue, 29 Mar 2011 11:12:52 -0700; 4min 4s ago
   Main POD: 1165 (console-kit-dae)
    CGroup: name=systemd:/system/console-kit-daemom.service
               1165 /user/sbin/console-kit-daemon --no-daemon
Comment 6 Adam Williamson 2011-03-29 14:34:25 EDT
it's only been running for four minutes? does /var/run/ConsoleKit/database exist _now_?

(I'm guessing the problem here is ConsoleKit not running at log in or some other issue with it.)
Comment 7 Luya Tshimbalanga 2011-03-29 14:45:30 EDT
Yes, it does now. I am still unable to connect with the laptop. =(
Comment 8 Adam Williamson 2011-03-29 14:58:08 EDT
can you try to connect again and look at what new messages show up in /var/log/messages during the attempt, and add them to the report? thanks.

(i should probably just come over and take a look for myself, huh :>)
Comment 9 Luya Tshimbalanga 2011-03-29 15:12:09 EDT
Created attachment 488535 [details]
New /var/log/message | grep NetworkManager

Here is. 
That would be nice =)
Comment 10 Adam Williamson 2011-03-29 15:18:23 EDT
seems to fail to get an IP address. have you rebooted since installing the NM update, btw?
Comment 11 Luya Tshimbalanga 2011-03-29 15:58:41 EDT
I did. Same result.
Comment 12 Luya Tshimbalanga 2011-03-30 05:15:57 EDT
Created attachment 488698 [details]
/var/log/message | grep NetworkManager

New installation from Fedora 15 Beta RC1 that now runs Gnome-Shell. NetworkManager still has issue.
Comment 13 Adam Williamson 2011-03-30 11:39:51 EDT
So...it's clearly DHCP failing, but I couldn't tell you why. Up to Dan, I guess.

(I could note that on my machine, the DHCP stage after a resume from suspend takes far, far longer than you'd expect it to on a wired interface, I guess; usually 20-30 seconds. It even does time out occasionally, but a second attempt makes it connect almost immediately. Not sure if that's at all related to this.)
Comment 14 Adam Williamson 2011-03-30 11:40:36 EDT
oh, btw, I guess it may help to have full /var/log/messages (not grepped - in case there's any relevant output from the kernel) and lspci -nn (so we know what the network hardware is). thanks.
Comment 15 Luya Tshimbalanga 2011-03-30 12:51:27 EDT
Created attachment 488830 [details]
full /var/log/messages

Here is a full /var/log/messages report
Comment 16 Luya Tshimbalanga 2011-03-31 04:02:50 EDT
Created attachment 488998 [details]
lspci -nn

Here is missing information. I updated to latest NetworkManager with no sucess.
Comment 17 Dan Williams 2011-03-31 12:52:14 EDT
So it looks like we're getting offers from the DHCP server on the wired network:

Mar 30 01:45:26 muamba dhclient[1306]: DHCPDISCOVER on em2 to 255.255.255.255 port 67 interval 5
Mar 30 01:45:27 muamba dhclient[1306]: DHCPOFFER from 192.168.1.254
Mar 30 01:45:27 muamba dhclient[1306]: DHCPREQUEST on em2 to 255.255.255.255 port 67
Mar 30 01:45:30 muamba dhclient[1306]: DHCPREQUEST on em2 to 255.255.255.255 port 67
Mar 30 01:45:34 muamba dhclient[1306]: DHCPREQUEST on em2 to 255.255.255.255 port 67
Mar 30 01:45:43 muamba dhclient[1306]: DHCPDISCOVER on em2 to 255.255.255.255 port 67 interval 8
Mar 30 01:45:43 muamba dhclient[1306]: DHCPOFFER from 192.168.1.254

but the DHCP server isn't responding to the request for the address that was offered.  It should look like this:

Mar 28 08:50:35 dcbw dhclient[1206]: DHCPOFFER from 192.168.1.1
Mar 28 08:50:35 dcbw dhclient[1206]: DHCPREQUEST on wlan12 to 255.255.255.255 port 67
Mar 28 08:50:35 dcbw dhclient[1206]: DHCPACK from 192.168.1.1

Same thing on wifi.  Is there a chance that the firewall rules are  blocking DHCP?  Try running the following in a terminal and then try reconnecting to your AP by picking it from the menu.

sudo service iptables stop

and lets see what we get.
Comment 18 Dan Williams 2011-03-31 12:52:53 EDT
You might also try rebooting the wifi AP (assuming that's also the DHCP server) because sometimes consumer-level wifi APs actually do get screwed up.
Comment 19 Adam Williamson 2011-03-31 13:02:25 EDT
can you also try:

systemctl disable NetworkManager.service
ifup em2 (or ifup wlan12)

and see if that works? just to see if it's actually NM-specific or not.
Comment 20 Luya Tshimbalanga 2011-03-31 15:07:31 EDT
Created attachment 489200 [details]
latest messages

No luck with service iptables stop
Comment 21 Luya Tshimbalanga 2011-03-31 15:11:08 EDT
(In reply to comment #19)
> can you also try:
> 
> systemctl disable NetworkManager.service
> ifup em2 (or ifup wlan12)
> 
> and see if that works? just to see if it's actually NM-specific or not.

At first that command would not work until I rebooted the system.
I now use em2 but I cannot use wlan0 for some odd reason.
Comment 22 Adam Williamson 2011-04-01 11:19:33 EDT
actually it would make sense that it can't bring up the wireless connection without further configuration (the old if* scripts can't read NM's configuration data, AIUI). But you can bring up the wired interface if you do it that way? So somehow, NM is screwing up the DHCP process...
Comment 23 Luya Tshimbalanga 2011-04-01 13:49:16 EDT
That problem occurred after updating to NM 0.9. 0.8 version worked fine on F15 Alpha. I wonder if the Network Controller module is broken with this newer NM.
Comment 24 Luya Tshimbalanga 2011-04-04 20:17:24 EDT
Issue turned out to be a conflict with selinux-policy because I received sealert when attempting to use NetworkManager.
Comment 25 Luya Tshimbalanga 2011-04-04 22:02:13 EDT
Here is a report from sealert from bug #693581
Comment 26 Luya Tshimbalanga 2011-04-04 23:08:14 EDT
Created attachment 489902 [details]
Latest /var/log/messages

After updating selinux-policy from koji repository, the problem still occurred.
Comment 27 Adam Williamson 2011-04-05 00:19:29 EDT
Can you try 'setenforce Permissive' at a console or boot with 'enforcing=0' parameter and see if that changes the behavior?
Comment 28 Luya Tshimbalanga 2011-04-05 00:35:29 EDT
Sadly neither suggestion has effect on the behaviour.
Comment 29 Adam Williamson 2011-04-05 00:49:24 EDT
The selinux denial may be unrelated, in that case. you can try with 'selinux=0' to turn selinux off harder, but it will require a relabel next time you boot with it enabled (takes some time).
Comment 30 Luya Tshimbalanga 2011-04-05 01:08:20 EDT
No effect with selinux=0 either. After relabelling, sealert popped out when attempting to connect to either wired or wireless network. modem-manager, NetworkManager, phcscd and pulseaudio source process are reported on sealert and require huge list of label.
Comment 31 Adam Williamson 2011-04-05 01:15:43 EDT
What selinux and systemd do you have? Hope you're not getting bitten by the various bugs surrounding actually being able to disable selinux atm. sigh.
Comment 32 Luya Tshimbalanga 2011-04-05 01:21:52 EDT
selinux-policy 3.9.16-12 
systemd 22-1
Comment 33 Adam Williamson 2011-04-05 01:38:37 EDT
oh, yeah, that's the possibly broken stuff, so we could be in a pickle.

well, in the meantime, can we see the contents of the selinux alerts, at least the ones that look relevant?
Comment 34 Luya Tshimbalanga 2011-04-05 02:13:40 EDT
Created attachment 489918 [details]
modem-manager sealert
Comment 35 Luya Tshimbalanga 2011-04-05 02:14:24 EDT
Created attachment 489919 [details]
NetworkManager sealert
Comment 36 Luya Tshimbalanga 2011-04-05 02:14:58 EDT
Created attachment 489920 [details]
pcscd sealert
Comment 37 Adam Williamson 2011-04-05 12:40:54 EDT
Can you try with the updates from https://admin.fedoraproject.org/updates/selinux-policy-3.9.16-12.fc15,udev-167-2.fc15,systemd-23-1.fc15 , which should fix the selinux stuff? Thanks.
Comment 38 Luya Tshimbalanga 2011-04-05 13:41:20 EDT
Updated selinux-policy and systemd seems to fix policy issue. Still no effect on NM behaviour that kept timed out.
Comment 39 Adam Williamson 2011-04-05 13:56:19 EDT
so, seems the selinux stuff is just a red herring, but we still don't know what's causing this :(
Comment 40 Luya Tshimbalanga 2011-04-05 22:21:06 EDT
This kind of bug appears to be a blocker for beta release =(. Trying to downgrade to old version of NM (0.8) will cause broken dependency.
Comment 41 Adam Williamson 2011-04-05 22:38:24 EDT
well, if it was happening to more people, but as long as it's just you, it's a bit trickier - I haven't seen anyone else report a bug quite like this, yet.
Comment 42 Luya Tshimbalanga 2011-04-06 02:56:24 EDT
Connecting on a AP Guest worked though I do not have password. Any WPA access will timed out.
Comment 43 Luya Tshimbalanga 2011-04-06 03:25:11 EDT
On i686 Gnome 3 Live based on Fedora 15 beta, NetworkManager is working smoothly. Not sure if the issue is related to x86_64.
Comment 44 Luya Tshimbalanga 2011-04-07 15:31:54 EDT
Turned out the entire network issue is related to this bug #693247. I can confirm it is SELinux bug. Should this report be closed as duplicate?
Comment 45 Adam Williamson 2011-04-07 15:43:36 EDT
well, I thought you said it doesn't work if you boot with selinux disabled?
Comment 46 Luya Tshimbalanga 2011-04-07 16:23:16 EDT
Still does not work with selinux disabled. What is odd is NetworkManager runs fine on i686 Fedora 15 based Gnome 3 Live. I am completely baffled about the issue. Hopefully udev update will resolve the problem.
Comment 47 Luya Tshimbalanga 2011-04-08 13:21:30 EDT
No effect with latest udev update.
Comment 48 Luya Tshimbalanga 2011-04-09 06:30:16 EDT
I installed Fedora 15 Beta RC2. The problem still exists with NetworkManager, using ifup em2 after disabling NM service no longer gives online access. It seems problem occurs on x86-64 architecture because i686 Gnome 3 Live media based on Fedora 15 is not affected.
Comment 49 Luya Tshimbalanga 2011-04-09 14:15:57 EDT
(In reply to comment #18)
> You might also try rebooting the wifi AP (assuming that's also the DHCP server)
> because sometimes consumer-level wifi APs actually do get screwed up.

Problem affects all AP I attempt to access except some of them with Guest name. I even rebooted my own wifi AP, NM still managed to screw up. I noticed that problem is not happening with i686 Gnome 3 Live Fedora 15 based. My laptop did not have that problem prior to Network 0.8 then used on Fedora 15 Alpha.
Comment 50 Luya Tshimbalanga 2011-04-13 15:35:22 EDT
Comment on attachment 489918 [details]
modem-manager sealert

latest selinux-policy fixes does not effect NM behaviour related to DHCP
Comment 51 Luya Tshimbalanga 2011-04-13 15:41:00 EDT
Created attachment 491884 [details]
Latest /var/log/messages

How to debug dhcp? I looked at my router that can see  ip from my laptop. I am also including wpa_supplicant.log if that helps.
Comment 52 Luya Tshimbalanga 2011-04-13 15:41:46 EDT
Created attachment 491885 [details]
wpa_supplicant.log
Comment 53 Luya Tshimbalanga 2011-04-13 18:04:50 EDT
Created attachment 491915 [details]
Messages with succesful access to public AP

Update. I was able to connect to a public AP (unsecured). I include the message. It appears the bug may be from WPA AP those have trouble to successfully set the AP. hope that will help investigating the problem.
Comment 54 Luya Tshimbalanga 2011-04-27 03:21:11 EDT
Looking at Realtek website http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PNid=48&PFid=48&Level=5&Conn=4&DownTypeID=3&GetDown=false&Downloads=true#RTL8192SE,
 it appears to be a kernel bug.
Comment 55 Adam Williamson 2011-04-27 10:35:31 EDT
what are you looking at on that page exactly?

You could certainly try with an older / newer kernel, you should still be able to pull various builds from Koji.
Comment 56 Luya Tshimbalanga 2011-04-27 16:27:47 EDT
rt8188ce driver updated on April 6, 2011. I did not see the newer update of that driver inside changelog from latest kernel. The odd issue is the problem only occurs in post installation, not in live media. =(
Comment 57 Luya Tshimbalanga 2011-04-30 06:03:43 EDT
Upgrading my wired network desktop (Acer Aspire E380) from F14 to F15 brought the same encountered issue with Toshiba Satelitte C650D. NM kept trying to connect. All updates were applied including kernel, wpa_supplicant, ModemManager.
The router provided by my ISP lists the addresses. Screenshot included.
Comment 58 Luya Tshimbalanga 2011-04-30 06:04:49 EDT
Created attachment 495927 [details]
Router status
Comment 59 Luya Tshimbalanga 2011-04-30 18:42:23 EDT
Created attachment 496006 [details]
latest messages

Updated /var/log/messages with both report of NM (unable to get dhpack stage) and ifconf from desktop.
Comment 60 Luya Tshimbalanga 2011-05-02 15:51:42 EDT
Further investigation. The issue is maybe dhclient after post installation of Fedora 15. NM can list available AP and wired. Perhaps the bug should be against dhclient.
Comment 61 Luya Tshimbalanga 2011-05-03 13:29:21 EDT
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Taken from Dan quote:
Mar 30 01:45:26 muamba dhclient[1306]: DHCPDISCOVER on em2 to 255.255.255.255
port 67 interval 5
Mar 30 01:45:27 muamba dhclient[1306]: DHCPOFFER from 192.168.1.254
Mar 30 01:45:27 muamba dhclient[1306]: DHCPREQUEST on em2 to 255.255.255.255
port 67
Mar 30 01:45:30 muamba dhclient[1306]: DHCPREQUEST on em2 to 255.255.255.255
port 67
Mar 30 01:45:34 muamba dhclient[1306]: DHCPREQUEST on em2 to 255.255.255.255
port 67
Mar 30 01:45:43 muamba dhclient[1306]: DHCPDISCOVER on em2 to 255.255.255.255
port 67 interval 8
Mar 30 01:45:43 muamba dhclient[1306]: DHCPOFFER from 192.168.1.254

but the DHCP server isn't responding to the request for the address that was
offered.  It should look like this:

Mar 28 08:50:35 dcbw dhclient[1206]: DHCPOFFER from 192.168.1.1
Mar 28 08:50:35 dcbw dhclient[1206]: DHCPREQUEST on wlan12 to 255.255.255.255
port 67
Mar 28 08:50:35 dcbw dhclient[1206]: DHCPACK from 192.168.1.1


Issue affected both desktop and laptop after upgrade and installation from scratch
Comment 62 Luya Tshimbalanga 2011-05-03 13:29:56 EDT
Renamed the bug because of dhcp issue.
Comment 63 Luya Tshimbalanga 2011-05-03 14:23:45 EDT
Created attachment 496606 [details]
ifcfg-auto_ethernet
Comment 64 Jef Spaleta 2011-05-03 14:41:40 EDT
Just to be clear is this only happening with WPA secured access points?  I have a WPA2 secured access point at home and I'm not having this problem with either of the 2 F15 laptop installs I currently have. I'll pulled updates on both of those laptops yesterday over the secured home network in fact.

I'm willing to try to reproduce this with test network configuration if there was a specific configuration that needed to be confirmed.

-jef
Comment 65 Luya Tshimbalanga 2011-05-03 15:12:28 EDT
Yes. In addition, my desktop which is wired connected got impacted as well. Note that running Live Media on both desktop and laptop does not display the issue. As talked with Adam on #fedora-qa, maybe the old nm config per user is the cause but I don't know the name of config file.
Comment 66 d. johnson 2011-05-03 15:16:30 EDT
Mine works with #c19, but fails with NM.  If I stop NM first, then manually run
'ifup eth0' or use 'network' instead of NM, it works as expected.  Mine is
wired only.

Desktops: gnome-failback, lxde, xfce all behave the same.
Comment 67 Jef Spaleta 2011-05-03 18:16:53 EDT
Wired connections not working? Well I can definitely say that's not the case for me. Have you tried with a completely fresh user to confirm if its a stale config file?  

My systems are fresh 64bit Beta installs+updates running gnome shell as the interface, very little if any system or user config customization at all.

Are all the affected systems upgrades from something pre-F15-Beta?

-jef
Comment 68 Luya Tshimbalanga 2011-05-03 23:40:17 EDT
(In reply to comment #67)
> Wired connections not working?

Not with NM. Wired connection only work with manual setup: ifcfg and network.



> Are all the affected systems upgrades from something pre-F15-Beta?

Yes for the desktop (upgrade straight from F14) which worked fine until latest NM update. I did a fresh network installation from my laptop using both Live Media and DVD for testing purpose. On both case, NM was able to access to Internet. 

I will do a fresh installation with F15 Final TC1 on my laptop.
Comment 69 Adam Williamson 2011-05-04 12:44:16 EDT
luya: it'd be nice to track this one down before you blow away the affected installs. Looks like NM's config per-user is in gconf, System / Networking / Connections; can you take a look there and see if you can spot a difference between affected and non-affected configurations? Thanks!
Comment 70 Luya Tshimbalanga 2011-05-04 14:53:43 EDT
Created attachment 496884 [details]
gconf.xml for nm-applet

Only possible nm config per user is located at .gconf/apps/nm-applet. 
I recently connected on another WPA2 AP at other place far from home. Odd because my home router has similar configuration yet dhcp will not respond.
Comment 71 Luya Tshimbalanga 2011-05-04 14:56:05 EDT
Created attachment 496885 [details]
Latest /var/log/messages
Comment 72 Jirka Klimes 2011-05-05 05:44:23 EDT
There's definitely a problem with your DHCP server/configuration. From your log in comment #71, connection to 'TELUS1603' always fails with DHCP timeout, while connection to 'private_wlan' and 'A11CD5' are successful; getting DHCPACK.

So, I suggest you ensured there's no firewall in the way, fired up wireshark and see the DHCP datagram exchange.

Moreover there are assertions in the log:
May  3 11:14:45 muamba NetworkManager[3709]: nm_connection_get_setting: assertion `NM_IS_CONNECTION (connection)' failed

causing NM to crash. But those are not related to this problem and are now fixed upstream (30c63ddcb721dc6c8a8273da4808d898e379eb44 : settings: fix assertion checks).


(In reply to comment #69)
> luya: it'd be nice to track this one down before you blow away the affected
> installs. Looks like NM's config per-user is in gconf, System / Networking /
> Connections; can you take a look there and see if you can spot a difference
> between affected and non-affected configurations? Thanks!

NM 0.9 doesn't use gconf to store connections any more. The whole concept was simplified and now we have just one settings service (instead of two system x user). As a consequence connections are stored by NM itself and are either in /etc/sysconfig/network-scripts/ifcfg-* (ifcfg-rh plugin) of /etc/NetworkManager/system-connections (keyfile plugin). Connection can be marked to be visible only for some users.
Comment 73 Luya Tshimbalanga 2011-05-05 13:43:00 EDT
(In reply to comment #72)
> There's definitely a problem with your DHCP server/configuration. From your log
> in comment #71, connection to 'TELUS1603' always fails with DHCP timeout, while
> connection to 'private_wlan' and 'A11CD5' are successful; getting DHCPACK.
> 
> So, I suggest you ensured there's no firewall in the way, fired up wireshark
> and see the DHCP datagram exchange.
> 
> Moreover there are assertions in the log:
> May  3 11:14:45 muamba NetworkManager[3709]: nm_connection_get_setting:
> assertion `NM_IS_CONNECTION (connection)' failed


Firewall is set to NAT on modem/router used for PVR as well. Should I set it lower to see in that case? Note that problem does not happen on Live Media, I will send /var/log/messages shortly.
Comment 74 Adam Williamson 2011-05-05 13:59:56 EDT
jirka: please note the wrinkle that this is only happening with an upgraded f14, it works correctly (against the same router) in a clean f15. so it looks to be certainly caused by some kind of configuration issue in a 14->15 upgrade.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 75 Adam Williamson 2011-05-05 14:00:18 EDT
i'm wondering if the network device renaming might have anything to do with this?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 76 Luya Tshimbalanga 2011-05-05 14:30:44 EDT
Created attachment 497183 [details]
/var/log/messages from F15 Beta Live Media

Default configuration from F15 Beta live media. dhcp server has no problem in that case
Comment 77 d. johnson 2011-05-06 17:49:37 EDT
Formatted over old install, and clean installed tc1, NM now works as expected again.

Post update to NetworkManager-gnome-0.8.999-1.fc15.x86_64 solves this issue for me.  (Even on wired network)
Comment 78 Luya Tshimbalanga 2011-05-07 19:47:22 EDT
Created attachment 497600 [details]
Wireshark report from desktop (Acer E380)

Included wireshark report. I have updated NM to latest version, the problem still occurs. Same result on my laptop.
Comment 79 Jiri Popelka 2011-05-09 06:32:21 EDT
When I try to open the wireshark-desktop.txt in Wireshark i get:
"The file wireshark-desktop.txt isn't a capture file in a format Wireshark understands."

Can you save the packet dump in Wireshark in libpcap format (it is the default one)? Thanks
Comment 80 Luya Tshimbalanga 2011-05-09 10:40:02 EDT
Created attachment 497818 [details]
Wireshark report from desktop (Acer E380)

wireshark format
Comment 81 Jiri Popelka 2011-05-09 12:15:25 EDT
Jirko, I don't see anything wrong in the DHCP messages so
at the moment I can't tell why there's no DHCPACK.
Comment 82 Luya Tshimbalanga 2011-05-09 18:10:21 EDT
Created attachment 497931 [details]
Wireshark wlan0 from laptop
Comment 83 Jirka Klimes 2011-05-10 09:24:10 EDT
DHCPACK is lost/dropped somewhere or it's not even sent.

- Try to monitor DHCP communication on the router side (if there is such option)
- Try an USB WiFi stick to use another hardware and driver
- Try downgrading to kernel used in the F15 Beta live
- Try installing latest driver

I am out of ideas, actually.
Comment 84 Luya Tshimbalanga 2011-05-10 21:18:27 EDT
(In reply to comment #83)
> DHCPACK is lost/dropped somewhere or it's not even sent.
> 
> - Try to monitor DHCP communication on the router side (if there is such
> option)

No option availabe =(

> - Try an USB WiFi stick to use another hardware and driver

I do not have one at the moment.

> - Try downgrading to kernel used in the F15 Beta live
Tried with no effect.

> - Try installing latest driver

Issue is both laptop and desktop are affected. Laptop uses realtek and desktop Marvell.
Comment 85 Luya Tshimbalanga 2011-05-13 14:49:55 EDT
Created attachment 498842 [details]
Wireshark report from desktop (Acer E380) running kernel F15 beta
Comment 86 Luya Tshimbalanga 2011-05-13 16:36:36 EDT
For details:
Modem is Actiontec V1000h. Running on other OS like OSX Snow Leopard, Windows (7 and Vista), Fedora Live Media show no error. Mystery continues.
Comment 87 Luya Tshimbalanga 2011-05-15 21:36:17 EDT
Created attachment 499072 [details]
message from F15RC3 Design edition Live

Attachment from latest live media.
Comment 88 Luya Tshimbalanga 2011-05-15 22:14:32 EDT
Created attachment 499073 [details]
Latest /var/log/messages from Toshiba C650

Installed F15RC3 from Live Media. Wireless is still a problem but ethernet is working fine this time.
Comment 89 Luya Tshimbalanga 2011-05-16 17:22:02 EDT
Created attachment 499231 [details]
Updated wlan0 from Toshiba C650

Wireshark wlan0 report
Comment 90 Luya Tshimbalanga 2011-05-26 15:09:56 EDT
Created attachment 501172 [details]
Updated wlan0 from Toshiba C650

Installed from F15 Design Spin which somehow solved wired network issue on both desktop and laptop. Wireless network is still a problem on post installation.
Comment 91 Luya Tshimbalanga 2011-05-27 15:12:18 EDT
Created attachment 501371 [details]
Updated wlan0 from Toshiba C650

Latest update of wlan0 from Wireshark showing fully connected wireless network with 0.8.993-3.git20110526.fc15 update. I included this attachment for comparison. I am still puzzled why wireless did not work for two months.
Interesting that Design spin restored wired connection unlike DVD and Live Desktop. I will wait one week before closing this bug report. 
Thanks for trying to resolve this odd bug.

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