Bug 473507
|
Description
Zoltan Balogh
2008-11-28 23:23:02 UTC
Created attachment 325050 [details]
/var/log/messages
Connecting from HOME to the EXTERNAL VPN, which requires identical settings to the Internal one.
Created attachment 325053 [details]
/var/log/messages of an entire session which ended with Kernel Panic
This is from the university, taken today, ended in a sad Kernel Panic.
Created attachment 325054 [details] HOWTO of University on setting up NetworkManager. See also: http://docking.ncl.ac.uk/vpn/linux/ As a final note, it is worth noting that I only experience Kernel Panics, when using my notebook on the university VPN. What has not been tested yet: Whether the kernel panics, even if I just associate with the Wifi access point ONLY. Whether it works without errors in different buildings, using other access points. (Usually being in one building, one floor.) I'm planning to revert to prior versions of NetworkManager and NetworkManager-pptp in order to be able to work at the University. Thanks for your time and efforts. Zoltan kernel panics are kernel issues; the kernel should never panic. (In reply to comment #4) > kernel panics are kernel issues; the kernel should never panic. Fair enough. Please let me know if I can help you by any means to determine the kernel bug. Also, I think there are several issues mentioned in my bug-report that are of incorrect/unexpected nature. Do you agree that I should file them as separate bugs against NetworkManager? (Example the sequence numbers, exporting VPN conf files or re-adding the wlan0 interface.) I'm testing the External VPN from home right now. I route every traffic of mine through that at the moment. Had no panics so far, so I suspect, there might be an iwl3945 bug as the root of all problems. (There are about 10 wifi access points in range at the room I am usually working in and this might mess things up.) Created attachment 325244 [details]
iwlist wlan0 scan from library
I have made some further research towards determining the nature of this defect. I found out that I never get a kernel panic from connecting to the External VPN from home (I use Wifi at home.).
In addition to this, I went to the library (see access point information), to see if all Internal VPN connections make my kernel panic or whether just given ones.
I did a 5 hour session in the library, without a kernel panics. Therefore I determined that there is something unusual in the wireless access points of the building, where I usually work from, which somehow make my kernel panics.
I *guess*, it's down to an iwl3945 bug and/or a mis-configuration of routers locally.
I'll keep you updated. I'll also send a file with the iwlist wlan0 scan results of the exact location where I get panics at.
Created attachment 325246 [details]
iwlist wlan0 scan with Access Points that DO cause my Kernel Panics
Here are the wireless access points of the location, where my laptop's kernel panics.
I forgot to mention that the network I use throughout the campus has the ESSID "magpie".
As a next step, I'm contacting the relevant authorities of my university to see if they can help me tracing down the problem. I'll keep you updated.
Created attachment 325355 [details]
ifconfig wlan0 when connected to Access Point that causes Kernel Panic
Forgot to add this yesterday. My kernel panicked a few minutes after saving this file. I was NOT connected to the VPN, therefore the defect is down to the level of wireless communication between the access point and the laptop of mine.
Will raise a defect against iwl3945 as well to help problem resolution.
So far no reply had been received from my university's IT support services, however they assigned the issue to an engineer.
Can you capture the Oops using netconsole over a wired connection to another box? Or perhaps you can recreate the crash using a text console? It is difficult to debug without more information about where the crash is occuring. Created attachment 325670 [details]
Captured Kernel Oops Message via Netconsole
Hello John,
I hope this helps. I'll let the iwl3945 people know as well that I managed to capture the Oops.
Also according to dmesg, my iwl3945 version is the following:
iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 1.2.26kds
The driver is the default that is packaged with Fedora 10.
The first oops looks more like a mac80211 problem (ieee80211_invoke_rx_handlers) to me. The second WARN() looks like netconsole related, you can ignore it. Does the problem happen on upstream? As I'm not entirely sure what Mr. Zhu means by "upstream", could anyone specify this to me? I'm going on a holiday next Friday (12th of Dec.) and hence we should get all the trace beforehand, especially as the university might modify the network over the holidays as I reported my problems to them as well. "Upstream" means an official, unpatched kernel from Linus. (We push patches "upstream" to him, and they flow from him "downstream" to us.) Created attachment 326612 [details]
Upstream kernel solved the problem, the issue is Fedora-related.
Hello,
With the kind help of John, I managed to check out the new wireless testing kernel yesterday. Compilation was based on the default Fedora config (make oldconfig) and I left every new configuration setting as default (as John suggested).
Good news is: it works without any problems. :D (iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 1.2.26kds)
I've attached a text file containing the following information:
uname -a, extract from /var/log/messages, iwlist wlan0 scan, ifconfig, dmesg
Another good news is that with the help of our Information Systems Services team, we figured out why I get messages about PPTP packets arriving in a bad sequence.
Basically you can't set up the default MTU for VPN connections from the new NetworkManager. Therefore it uses 1500 instead, however the university would rather prefer 1416. This then messes things up as it constantly needs to recover. I'll find out later, how to manually set up the MTU. I found this bug on Ubuntu's Launchpad already, so not reporting it.
Thank you very much for all your co-operation and please try to fix this issue in Fedora 10's (or a next release's) default kernel.
Wishing you a Merry Christmas,
Zoltan
PS: Marking this defect as needinfo, so that you'd get back to me quicker. Then I could still extract some info out from the network setup before I go on a holiday tomorrow.
|