I just discovered what a pain jaunty is. Basically, the network blocks all ports after approx 3 hours from a fresh install. Initially i was thinking I was doing something wrong. Few poeple seemed to be saying NetworkManager does not like to be reconfigured by editing /etc/network/interfaces. I could get my head around why.

I use a wired ethernet network with static addressing as done previous Debian builds.

The symptoms would be not ping my gateway or load it's browser interface, let. alone anything outside the gateway.

In order to eliminate problems on my end I rebooted into the live CD which gave access to the network. Similarly in windows and Centos which are part of my triple boot system.


I also eliminated firewalls because iptables command showed all ports open.


What baffles me is that I seem to be the only one writing about this otherwise there would have been more posts regarding this exact problem.

Is it just jaunty that is behaving like this? Would there be a more stable Ubuntu I could try.


On a third system build I made sure not to touch the default dhcp network and again bang on three hours all ports got blocked.

Goodby jaunty...

... nah - it's just you

Seriously, jaunty has been around a while. If this were a general problem then, you are correct: other people would have been writing about it. It follows, therefore, that this is not a general problem.

It is true, however, that the network manager has received a lot of complaints over the years. It is great when it works but when it doesn't it can be a pita. Especially as there has been a paradigm shift away from allowing users to configure the system by fiddling with the text files.

... provide evidence and submit a bug report. You need to be able to show how you came to this conclusion.

... yes - Jaunty is not stable, and is not represented as stable.
The stable releases are anything labelled LTR. That would be 8.04.

If the problem is more network-manager related, then you may want to try Kubuntu instead - different toolset. However, as you indicate that you have said goodbye to Ubuntu, theres no point me trying to work out what you have done wrong.

Please bear in mind that generalizing from personal experience is fraught with difficulty.

You could also try using wicd instead of network manager

Hi Simon, I guess I was hasty saying goodby to jaunty". I usually try to solve problems as a learning process. In this case I simply could not afford to be off line for any length of time.

However, I stand by every thing else in my last post. You mention providing "evidence" for my assertions, while at the same time conceding there is in fact a problem with NetworkManager. Maybe I should have added the word "approximate" in relation to how long it takes before NetworkManager starts playing up. Just for your benefit I will use a stop watch next time...!!

I can tell you on each of the fresh installs, it only takes a few hours and never lasts beyond day one. This symptom has been consistent. Initially, I tried to setup static addresses using the scripts as I used to do with Debian. On the second and third installation I decided to leave default configuration untouched without making any difference.

The basic network trouble shooting has been fairly systematic eliminating failure on my end.

Live CD would connect to the network including the distros on my triple boot.


I am currently using OpenSUSE and am noticing similar symptoms but not to the same severity as Jaunty. Unlike Ubuntu which blocked access to my gateway, ( I could not ping anything ), for the first time ( after three trouble free days ) I have been noticing web pages not loading, while at the same time able to ping my gateway but nothing outside. Unlike Ubuntu the problem intermittent and find that pages load after a refresh or two. Lo and behold, I see that OpenSUSE is also using using NetworkManger.

For this reason Simon, I have to disagree when you imply the problem is on my end and NOT "general problem".

I did not realize Jaunty was unstable. I understood the difference is in the kernel numbers. I.e. even minor numbers are stable. So am I to suppose the installed OpenSUSE is also unstable. I don't even know what version it is. I downloaded the latest advertised on their website.


Apart from already mentioned Ubuntu, maybe someone would be kind enough to show me how to check stable relesases in Debian, OpenSUSE and other RH derivatives which have full features. OpenOffice 3, cheese for webcam, .I like to stick Debian and Redhat derivatives since that is what the LPI exams seem to be based on.

Kbuntu is not an option because I use one or two gnome utilities.

So I am also guessing Debian Lenny is also unstable.

I migrated from Lenny because it presented a riskier problem which presented dangers of data loss. While I make sure to mount my /home drive on an external drive, I still might have important stuff on temporary folders.

On two occasions when when booting Debian Lenny it would force fsck which seemed to go into a yes/no loop. This is just one paragraph of the error I saved.

**************************************************************************************************** ********************************************************

436.821659 end request.
IO ERROR: io error.
dev/hda sector 69354418412
436.821659
buffer i/o error
on device ha2
logical block 43057264
error reading block 43057264
Attempt to read block from filesystem resulted in short read while getting next node from scan. Ignore Y/N

This Y/N seemed to want to continue indefinitely.

**************************************************************************************************** ********************************************************

The only way I could see round this was a reinstall, but since at the time I was dealing with Pentium III it would take up most part of a day.

Here again, I eliminated hard drive problems because they are still working with OpenSUSE.


On a final note scheidel21, could you tell me how to uninstall NetworkManager in order to replace it with wicd?

at the command line in Ubuntu type

Well at least that's what I need to do for Lenny with the backports site added, wicd is from backports. if that doesn't work you can remove network-manager and network-manager-gnome as nm-applet is just a dummy package for those.

Oh and note you may want to install wicd before removing network manager in case removing network manager messes with your network connection.

In SUSE or other distros try the package manager do a search for those packages I listed above and add/remove them as need be.


On another note, not to fan any flames, but I've never seen an issue like you described with Lenny were you using it before it went to stable? Because that is the current stable release of Debian, and it is generally known as one of the most stable of stable distros because they take so long to vet the entire distro and the packages that go into it.

As far as not using kubuntu can't you just install the gnome libraries that are required for those utilities you need along with those utilities, my gnome stuff works fine in my KDE desktop.

Oh yes, dont' forget to sudo those apt commands if need be or run them as root.

As for the Lenny HD issues looking into it further you sure you didn't have bad sectors on the HD that were later locked out by the install of a different Filesystem?

Hi, I have only used ext3 on this specific hard drive. In recent times this has only happened with Lenny so far.

Well I wonder if a later format of the HD even of ext3 again locked out bad sectors, but that neither her nor there. Hope wicd solves your issue.

Thanks folks that was very helpful. As an aside, I never had any network problems with Lenny. I mean, you got understand I am a relative newbie. As far as /etc goes I did see a NetworkManager directory in Lenny. You seem to be referring to it as a utility. I remember trying to run NetworkManager from console but the command was not recognized. As you say, that is neither here or there. Well, Lenny is no longer on my system. And as for the hard drive that was storing it, I have plunked it into my external enclosure and just repartitioned it and seems fine.

I am going to try and remove NetworkManager on the OpenSUSE, and see how it goes.

I take on-board what you say about Debian stability. That's exactly what surprises me. It is quite possible I am the one making the mistakes. But it beats the hell out of as to what. I might yet return to Lenny.

Once again, thank you to all.

While there are many reports of issues involving Network Manager, without further information it is impossible to tell which, if any, may apply here. However, I was mostly interested in finding out how you knew that "network blocks all ports".

How do you know that any ports were blocked?
How do you know that "network" was responsible for this?

I just wanted you to support your statements. CLI output, demonstrating your investigation, is the usual method. There are other useful methods where the CLI output is an onerous read. To understand where I am coming from, please read the advice link in my sig.

The time you reported is neither here nor there.

I suspected that when you said "all ports" you were not speaking precisely - perhaps you meant "all internet access stopped"? Peraps you were referring to gateway access? But I didn't want to guess.

I realise that I am asking some questions below which have replies in other posts. The perpose of these is rhetorical. If you suspect I have missed something though, just post a quote of the bit I missed. Thanks.

But you did not say what system you used or what you did. Don't make the reader guess.

Since you are new, it is not beyond reason that there may be something you are not aware of which you are doing or not doing to get a reliable network connection. Zero details means that people with more experience will have trouble working out what this may be.

Did the live CD have the "port closing" problem? If not, then the canonical setup worked and yours did not. What is different?

You reported that network access vanished after a time and attributed this to something identified as "network" closing down or blocking "all ports". <reads further>

So it wasn't due to a port being blocked? It was access to the internet gateway being blocked?

Of course - this also makes the port unavailable, so does unplugging the cable, but I hope you can see the difference?

Guessing: cannot ping anything = cannot ping gateway? Inferred from the following: yes.

This rather suggests that whatever is stopping web pages loading may be beyond or at the gateway doesn't it?

When you experience this problem, have you tried pinging external IPs?

OpenSUSE also uses a great deal of other programs in common - dhcpd for eg.

The nature of your internet connection would be useful to diagnosing this problem.

It is possible that you are the first person ever to notice this issue in the months since Ubuntu 9.04 and OpenSUSU 11 were released. Which is why I also suggested filing a bug report. However, wouldn't we expect to see other people start reporting the same symptoms?

Maybe more reports will surface over time.
Maybe what you have reported is not how others have reported it - perhaps there is something going on and you just have a different way of describing it. Further investigation is needed to figure this out.

Importantly, though, we need to know which distro you want to troubleshoot with - Debian, Ubuntu, or OpenSUSE ... or another?

Ubuntu, in general, is more stable that Debian's "unstable" and less stable than Debian's "stable".

Different people mean different things by "stable".
http://ubuntuforums.org/showthread.php?t=59098
... could just mean that it does not force a BSOD style reboot - or that you never see "this program or application has performed an illegal operation, close all windows and reboot" - which we count as a crash, but some people do not.

Any FOSS OS is made of a large collection of different bits, all in a different

You have made a common mistake - the kernel is only a small part of a distribution. Parts of Ubuntu are very stable, other parts are a work in progress. A few parts are stable in the sence that they do not work in predictable situations - consistently.

Most Ubuntu releases are focussed on developing functionality - sometimes trying new ideas out. Jaunty was focussed on increasing boot speed (amongst others) for example. Some things which worked well in earlier releases have become temperamental in this one (some aspects of X configuration for instance.).

Periodically the focus is on feature stability. At this time you get an LTS release. This are usually considered "suitable for enterprise" and can be thought of as like the Enterprise distros.

I pointed this out because you specifically requested a more stable release than Jaunty.

That would be OpenSUSE 11.something SLED would be expected to be more stable. SLED is to OpenSUSE what RHEL is to fedora ... though my impression is that OpenSUSE is more stable than fedora.

All FOSS software is a work in progress, with stability and features varying over time. OK - same applies to all software period - it's just that FOSS has a much faster development cycle than many alternate paradigms.

Apart from already mentioned Ubuntu, maybe someone would be kind enough to show me how to check stable relesases in Debian, OpenSUSE and other RH derivatives which have full features.You have to read the release notes that go with the available versions.

Debian Stable is highly regarded for stability and reliability - your experience not withstanding. It has not been established that your issue with Lenny is due to instability.

A distro you may want to consider for it's proximity to the Enterprise-style is CentOS. This is a point-for-point duplicate of RHEL used by IBM and installed to many high-reliability roles (like Stock Exchanges) around the World.

Using KDE does not preclude the use of gtk utilities. Just install them.

I have been using gnome programs in kde and the other way for years.

No, that would be Sid, Lenny is stable and Squeeze is "testing".

You don't - unless you put them there. Linux is not organised that way. All user info goes in /home/$USER

However, this is no substitute for a backup.

Yeah, you reported that problem in another thread - respondents were nat very forthcoming, but then you probably didn't realise that they needed extra information - like what you hoped to achieve.

from that thread:
This is far from obvious to the people reading your posts. There is a utility telling you that it may not be. If you have reason to believe the utility is mistaken - let us in on it please.

Debian distros, and many others, force a fsck roughly every 30 boots. This is to test for wear-and-tear on the fs and the underlying drive.

If you start failing these, it is time to consider replacing the drive (or the cable, or the controller).

You can also tell fsck to attempt a repair.

man fsck for a list of options.

You installed a new OS - as part of that process, the installer avoided damaged parts of the drive. So this means nothing.

It is entirely possible that another reinstallation of Lenny would have had the same effect. Maybe not. We cannot tell from this information.

It would be part of best practice, however, to run fsck on the new installation fs - where the disk has failed a previous check - to make sure there are no additional faults. This helps assure that we are not looking at progressive drive failure - amongst other things.

It will be interesting to see if changing from network manager will help the connectivity issue.

Bear in mind, it may not be you or Lenny... there are other possibilities. Without more information, nobody can work out what it may be.

Your trouble with lenny may have been normal random corruption of the drive - it happens even to brand new drives.

The network issues may be related to the nic (I've seen those symptoms where a nic just spontaneously decides to go to sleep for eg), cables, the gateway itself timing you out if it does not get a particular signal in 3 hours or even a general systems failure in progress (though those are usually wierder). I've seen all these and stranger.

You may have tested for these as part of your basic, systematic, network troubleshooting. How am I supposed to know?

Hello Simon, your reply is quite comprehensive and deserve careful study. This just a quick note before I hit the sack. I do appreciate where your coming from in relation to providing more detail. It is a toss up between providing too much and too little. If you look at my previous (Debian queries) posts you will see complaints about providing too much detail. Everyone is entitled to it when expressed in moderation.

You may be interested to know that since getting Lenny problem this got progressively worse. Now the BIOS does not recognize any hard drive. I am concluding IDE motherboard controller rather than the drive.

I.e. a process of elimination. The Lenny was running on an ancient PIII. The triple boot was split into 3 dedicated hard drives. When I isolated the hard drives ( connected each one as stand alone ) I noticed none of them were recognized in the BIOS.

I went got myself a ribbon cable was getting same results. However the same hard drives are fine ( as in being recognized and NOT a detailed fsck result ) on a second system. So I am concluding the problem has to be the IDE controller on the motherboard. I am going try to get hold of an IDE/PCI expansion card to see if this confirms my conclusion.

Similarly with the network issue, if I can get through to the internet with my other triple boot distros or the live cd I am assuming the problem is related to some sort software issue on the Jaunty, call it ports, network utility, firewall or whatever.

So I may not be using the same technical jargon as the difference between blocked ports or access to the internet but i think i am generally on the right track, don't you agree?

It is not a NIC issue because the aforementioned third jaunty install occurred on my second system with the exact same symptoms. Few hours after a fresh install I could not ping my gateway. Ethernet cables are definitely ok because not only did i perform a loop back test on my gateway ( connecting both ends of the cable to the router ) but again, the symptom is exclusive to jaunty. With the exception of the intermitant issue on the OpenSuse and windows, my Centos was connecting fine ( until that is, the hard drive controller failure ).

As to your query regarding my network, it is a 6 meg ADSL. My router is a wired Netgear. I do not use wireless at all. I have no proxies. I generally setup static addressing but since the NeworkManger issue I am leaving dhcp as is by default.

I had already done an iptables -l and was getting

sudo iptables -L

So it cannot be firewall issue.

Anyway, I will keep you updated. Thanks for giving me your perspective.

Can you be specific about how the problem is manifest? Does your connection stop passing packets? Does your interface lose its DHCP lease?
What commands have you run to determine what the problem is and what were their results?
Is this a wired or wireless connection? Encrypted? WEP/WPA/WPA-AES?

Details please?

Hello nowonmai, if you care to read the preceding post it outlines the symptoms and my trouble shooting steps. However here is short synopsis;

The first jaunty installation was followed by some hours of relatively productive work. Then I noticed loosing access to the net. No web pages displaying, no access to my mail servers.

I tried to login to my gateway without any success. I could not ping the gateway or outside the gateway.

Then I booted into Centos on the same machine but different hard drive. I discovered I can access web pages and my mail servers. I also booted in the jaunty live DVD with same successful access to the Internet. I have Windows on another hard drive again I was able to access to the Internet.

I booted back into jaunty checked for firewalls with iptales -l command. The results are in previous post.

Based on these I have formed the opinion that the problem has to do with some software issue within jaunty and NOT my equipment or configuration. Due to the fact that on the first install I had edited /etc/resolve and etc/network/interfaces and someone suggested it could interefere with NetworkManager, I decided to start again.

I wiped jaunty and reinstalled. This resulted in exactly same behavior. After a few hours of work I lost access to the Internet. I could not ping anything.

Even though it was evident my hardware worked with the other distros, I did go ahead to perform a loop back test for my Ethernet cables,inserting both ends into my router, which checked out ok.

Then I decided to install jaunty on a second machine. It resulted in exactly the same as the above. I lost access to the net after a few hours from installation. This time I did not touch any of network scripts /etc/resolv.conf or /etc/network/interfaces. Even with default dhcp I could not ping my gateway or beyond.


If like Simon your looking for a more low level trouble shooting steps, I would like to ask you to walk me through it with step by step instructions. However, I need you to wait a week for me to rebuild jaunty on my original machine. I am busy this week with other things.

I am currently using OpenSUSE but very eager to get to the bottom of this as a community project.

I do NOT use wireless at all. This an Ethernet via ADSL.

I do not use proxies.

I hope you can wait for a few days.

Many thanks in advance.

OK - we can establish progressive HW failure for the HDD issues in lenny. i.e. this does not speak to lenny stability. That annoying fsck error was actually telling you something useful.

All that testing you spoke of is what I needed to know.
Did you read the advise part in my sig? It is a very useful article which includes stuff which can help to work out how much information to send, and how to avoid annoying the geeks you want to help you.

You left out important info in the following:
Did you wait three hours to see if the connection vanished?

Your reported problem is not that you cannot establish a network connection but that it is not persistent after 3-or-so hours.

Things often work with windows - this is because vendors will take windows' little foibles into account in their design. Sometimes they use them. However, if something works in windows but not in linux, that can tell us where to look.

For ubuntu:
Keep DHCP. Make sure the network cable is plugged in when you install jaunty. Test that you can ping the gateway, and outside, in live mode before the install. Since the install won't take three hours, there should be no problem. After install, get the updates.

Let the network manager handle things on the new install - a wired connection on a supported nic via dhcp should be automatic - no config needed - especially if you installed while connected.

Check jaunty's power management - set it to not suspend etc.

If the pIII machine is what you are expecting to run jaunty, then I don't have much confidence of finding anything.
Humour an old man and show me the lspci output about your nic.

Verify the initial connection - we need to see ifconfig,

However - once you see the problem, enter

dmesg | tail

and let us see what is there.

also, ifconfig output again. But I expect the syslog to tell us something.
If there is nothing about the nic in tail, then you'll just have to search by eyeball or grep through it for things like eth0.


You start having an internet connection - but it goes away.
Working backwards from the gateway - there is still the possibility of some weirdness with the nic. Yeah - even unto a second machine.

While a fair few people have trouble with wired connections, they are usually like this:
http://answers.yahoo.com/question/in...7124639AAKWDeK
... where the machine never connects.

When something vanishes after a set time, always the same time, it suggests a timer is involved somewhere. We are usually suspicious of the power management system, though it is possible that you have dhcp leases set to expire in 3 hours on the router. If it is only approximately the same time, then we suspect something failing in the HW. It can take a while for small failures to accumulate to make something stop working.