That is from daemon log

Nov 15 15:00:53 localhost dhclient: send_packet: Network is unreachable

No one ask you to post output for

lspci

Could you post it here please.

Because I start suspect wireless driver.

Johnnie.it
Having carefully scanned your wicd.log (and please bear in mind I have never used wicd) it appears that the wicd daemon is initializing everytime that you are using your computer to access the internet. I could be wrong but looking at Nov 15th. the wicd.log started at 14:48:37 having been successfully connected at 20:01:52 on Nov 13th. then I see : #
2009/11/15 14:54:51 :: wicd initializing... then despite seeing 3 networks and later 5 networks it is only after: #
2009/11/15 14:55:05 :: Stopping wpa_supplicant
#
2009/11/15 14:55:05 :: wpa_cli -i wlan0 terminate
that you finally achieve success: 2009/11/15 14:55:14 :: Sending connection attempt result Success

However this only last until 15:00:10 when SOMETHING is starting scanning. I don't know whether that is wpa_supplicant that is scanning for ap's (access points) or whether it is dhcp - which from my perspective you don't need because you are statically setting your wlan0 to 192.168.1.99 and you don't need your ISP to allocate you an IP address. As an example My ISP will deal with DHCP requests from my Win XP tablet while being perfectly happy to let me choose 10.0.0.7 statically everytime on this debian laptop.

I don't know what is going on at 15:00:35 but it appears that you killed dhcd at 15:01:37, then a wicd reinitialization resulted in: 2009/11/15 15:03:02 :: Sending connection attempt result Success

then the scanning started 4minutes later and you success is short-lived, GROAN

it isn't until Nov 16th that success appears again:
#
2009/11/16 16:40:00 :: Sending connection attempt result Success
#
2009/11/16 18:23:01 :: found window_width in configuration 530
#
2009/11/16 18:23:01 :: found window_height in configuration 470
#
2009/11/16 18:23:01 :: scanning start
#
2009/11/16 18:23:01 :: ifconfig wlan0 up

I presume that you rebooted to achieve this, even though you lost it again at 18:23:01

SO, with some fear and trepidation, I will presume to say that you problem lies with wpa_supplicant and not with your wifi card, nor with its driver, nor with your ISP but with that SOMETHING that is starting erratic scanning once you have successfully established a connection.

Since I haven't been able to win in my battles with wpa_supplicant in Karmic, especially since I have an unencrypted link and therefore don't need WEP or WPA, I opted for debian stable and my trusty and rusty Ndiswrapper and a 64bit driver for my Broadcom 4306 (rev3) wireless minipci card.

Anyway I hope that this helps
Cheers

Hi, thanks for join us.

Hi started to scan network, as he was asked to find out why he lost connection.
To check if his card really can see any AP. I hope.

Now I think it is driver problem or card it self, because as OP said the only way to connect again is to reboot.
I don't know if there is any possibility to reload PCI card driver? And may be stop some how PCI card, and then reload driver.

Correct me, if I am wrong.

Hi repo,
as I said before, even on downtimes I am able to connect to my router with my pocket pc (HTC touch diamond).
Moreover, the fact that I am actually unable to see *any* wireless network, together with the fact that a reboot solves the issue, that alone would be too much of a coincidence, don't you think?

I don't know what to say, for debugging mode is already enabled.
That is, unless the graphic frontend is not working and therefore showing as active an option that isn't actually so.

Done already:
Well I actually connect to the internet only on startup, so everything should be normal...no?

about what you said next...I'm not sure I still follow you...
I'm not using any password or encryption anymore to avoid using the wpa supplicant...are you implying that wicd STILL uses the wpa_supplicant even though I'm on an unsecured network?
If that is the case, how could I disable it altogether?
May it be that wicd stops the wpa supplicant because the network doesn't need it?

About the IP address: before, I used the router to assign always the same ip to this mac address (my laptop's).
A few days ago, I also configured the static IP in wicd.
And please note that my ip address has nothing to do with my isp; it's a private address, 192.168.1.99, my public ip is 80.som.eth.ing
>_<

Well, now I may not be a linux expert but a crazy dhcp or wpa supplicant services screwing up the wifi card/driver seems a very plausible scenario to me...only thing that's strange, is that we're not able to find any clue in any log.
How could that be possible?

That would be great.
If only there was a way to stop and restart the wireless service/daemon/kernel/whatever should be pretty safe to actually pinpoint the problem...

I have an idea, but need help of others, because I don't know what in ubuntu 9.10 network scripts do.

I suggest to disable every network services: dhsp, avahi, wpa..., disable boot start wireless up.
And use "ifconfig wlan0 up" with static configuration IP, GW, default route.
I know how to do it in OpenSuse, but have no idea about Ubuntu.



Good news for Johnnie.it

In my OpenSuse I can simply type:
modprobe -r 8139too (8139too - this is my ethernet driver, wireless should be the same)
and unload driver, so ethernert stops, then as well simply, I type
modprobe 8139too, and load driver again, then I need to up interface up: ifup eth0.
That is all.
So, if you do "lspci -vv -s 0b:00.0" (0b:00.0 - should be your card address, correct if wrong), at the and of the output will be something like:
Kernel driver in use: 8139too
Kernel modules: 8139too, 8139cp
So use it for actual driver name.

Try. I just have, for me it works perfect, even if card in use. I check my self.
If it will work for you, you can check if it really driver problem.

johnnie.it: I don't think reloading your driver is the way to go, because on reboot it loads perfectly, or so it appears. I don't recall of you have tried the following two commands as root:

ifdown wlan0
ifup wlan0

If the result, when you have lost the connection, is a string of dhcp or dhclient failures, then I suggest you disable dhcpd (it might be dhcp3) and then edit, as root, your /etc/network/interfaces to include:

auto lo
iface lo inet loopback

allow-hotplug wlan0
iface wlan0 inet static
address 192.168.1.99
netmask 255.255.255.0
broadcast 192.168.1.255
gateway 192.168.1.1
wireless-essid John_WiFi
dns-nameservers 192.168.1.1

then save the file. Then retry the 'ifdown wlan0' and 'ifup wlan0' commands and then report back - the desired result is to re-enable your connection without rebooting. You may want to check your wicd.log to see what effect this plan has.

Good luck

Fine, minrich, but before doing that I wanted to ask a couple questions:
I already disabled dhcp wicd-side...is there any running client-daemon-service I should be aware of?

The second question is: I already provided all those info to wicd!
Have I been wasting time till now???

Let's see...

edit: So far so good (almost...)
As I said, so far so good.
Now I only have to try that next time the net goes down.
Not having to reboot would at least be a first step...
The goal should be to not lose network at all


@minrich:
What the...?

Nice,

You don't need to do ~$ sudo ifup wlan0 - you can use WICD. And anyway wireless interface eth0 or eth1.

To ALL.

Isn't that strange, look

Interrupt: pin A routed to IRQ 30

I don't think it is good mine card on <Interrupt: pin A routed to IRQ 10>

Sorry, didn't understand that.
Could you please explain?


Addendum:
Since I was more and more sure that the problem relates to the wifi card, I did a quick search (don't swing your fingers at me, I already did that of course, only I didn't specify the wifi card itself, I searched for the laptop).
Although lots of people WERE experiencing the (almost) same issue with this intel 4695 it has been confirmed to be present in Karmic Koala too.
Now, for jaunty jackalope and hardy heron a fix was in the proposed backports; for karmic this fix has supposedly been integrated in the distro itself or perhaps its regular repositories but, as I said, other people are still experiencing it.
Plus, discussion for kernel-related bugs are not public anymore for ubuntu, if I understood well.
Lastly, there are at least 2 other bug reports that are all too similar to this one, but still refer to other problem, and as far as I can tell it's VERY hard to understand what's related to what...at least for me.


Conclusion: lots of people solved this problem by either uninstalling update-motd package (which handles the update manager in ubuntu, and obviously I wouldn't want to do that), by fiddling with something they refer to as "ucode" (what's that???), using compat wireless (drivers, I suppose), or just updating the "official" intel wireless drivers.

Of course it's too much info for me to handle right now, I'll need a little while to sort everything out, but it could be worth a shot to try and update the drivers.
After all, I upgraded from ubuntu 9.04 up to 9.10, and all those who are experiencing this problem under 9.10 also did upgrade from 9.04; I couldn't find any fresh 9.10 install involved.

As I said, this will take me a while to sort out but, should any of you be so kind as to wanting to help me (^__^), here are a couple links I found to be pretty interesting:
https://bugs.launchpad.net/ubuntu/+s...ux/+bug/277634
https://bugs.launchpad.net/ubuntu/+s...22/+bug/144621 <-- look at comment #42
http://wireless.kernel.org/en/users/Download
Thanks in advance.

On a side note, I stumbled upon my kern.log file....it's huge!!! 321'815 lines head to tail!!!
And most of them are almost identical, such as:
How can I cut out those almost-duplicate lines to have a readable file? There are hundreds of them in a row...

Look, this from you previous post:

johnnie@johnnie-xps:~$ sudo modprobe -r iwlagn
johnnie@johnnie-xps:~$ sudo modprobe iwlagn
johnnie@johnnie-xps:~$ sudo ifup wlan0
Ignoring unknown interface wlan0=wlan0.

You got message: Ignoring unknown interface wlan0=wlan0, so if you do "ifconfig" you will see all interfaces you have.

About interrupts. Please do from root console: "cat /proc/interrupts"
You should get all interrupts in your system.

Now I am really annoyed - I just typed in something along the lines of the following post - an my wireless connection dropped out before I could post it - when I got my connection back my post had disappeared - GROAN so this time I am typing in an editor and will copy it across to the 'post quick reply' box, upon completion.

Johnnie.it

I wouldn't worry about your IRQ, here is my listing:

dl503@deb503:~$ lspci -vv -s 00:09.0
00:09.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03)
Subsystem: Wistron NeWeb Corp. TravelMate 290E WLAN Mini-PCI Card
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64
Interrupt: pin A routed to IRQ 19
Region 0: Memory at d0014000 (32-bit, non-prefetchable) [size=8K]
Kernel driver in use: ndiswrapper
Kernel modules: ssb

nimnull2

I am confused by your comment that eth0 and/or eth1 are wireless interfaces. These are, in all the distros that I have been using for the past 8 years referred to wired interfaces. And wlan0 and ath0 are logical names for wireless interfaces.

johnnie.it

It appears that when you ran ifup wlan0 you received a message 'Ignoring Unknown Interface wlan0=wlan0' which indicates that your ifstate file does not contain wlan0=wlan0 (probably only lo=lo, if the file exists) which will mean that when you lose your connection # iwlist wlan0 scan will not return anything. You then have to bring your interface down with # ifdown wlan0 and then up with # ifup wlan0. This might result in a string od dhcp or dhclient searches if your dhcpd (maybe it is dhcpd3) daemon is running. That is why I suggested that you edit your /etc/network/interfaces file as per my post #52 because this is the file that ifup and ifdown read (read manual pages for ifup or ifdown if you don't believe me). This way you bypass running the scripts that run if you run # /etc/init.d/networking restart or you effectively restart using network-manager or wicd. You can find the scripts that run in the /etc/network/ Folder look in each of the sub-Folders: if-down.d, if-post-down.d, if-pre-up.d and if-up.d to see what a network manager does.

What I am essentially suggesting is that you try a manually set network connection the next time you lose your connection, becaquse we know from your pocket pc that your ISP access point is still live. What will this prove? It will prove that it is not your driver or the network card, but that it is in the scripts that are running when you use a network manager which uses wpa_supplicant whether or not you are using a wep/wpa encrypted connection. Tehn we can try and find out which of the scripts is causing the scanning I referred to in an earlier post.

johnnie.it

Having just read your upated post, I had tremendous problems with my wifi connection whhen I tried karmic alpha, and I tried the 64bit beta with no better results, and I was unable to overcome a scanning function in wpa_supplicant which had a nasty effect because my ISP has two access points with the same ESSID name only different channels (4 and 11) and different ap addresses. Even though I can manually connect to either using the same static IP address my end I have to login each time that access point changed and anything in firefox or evolution that I was working on was lost.

On your question concerning repeat entries in your kern.log - I am not sure what "l2cap_recv_acldata" refers to --- well a quick http://www.google.co.uk/linux search returns an october 2008 bug report and then a Linux-kernel Archive Re: Bluetooth memory corruption. I am not volunteering to read these for you, but I would suggest that you disable your bluetooth until you need it, and it might cut down the length of your kern.log

Now that's strange...
I wrote the following post, but on hitting "submit reply" I discovered my network was down again -_-

Good news is, I managed to restore it without rebooting.
Bad news is, I don't know how I did that

After giving those modprobe commands wicd was able to successfully scan for networks again - and found them all, so to reconnect from there on was not an issue.

Anyway, ifup and ifdown give this error:
postconf: fatal: open /etc/postfix/main.cf: No such file or directory
With ifdown the network goes actually down, despite the error messages, but ifup doesn't bring it up again.
I had to go again through modprobe -r wlagn and modprobe wlagn, and then reconnect using wicd.

Now if you'll please excuse me...It's 22:31 here and I still have to cook something.
I'm about to faint...

Do it, it is the best way for now.

Try to enable encryption later.