Hello, I am seeing strange behavior recently in iftop on Ubuntu (x64, 12.04 and 13.10). With Port Display disabled, iftop simply uses more CPU than normal (say, 20% instead of a negligible amount). Then, when Port Display is enabled, CPU use goes straight to 100% and iftop becomes unresponsive.
This behavior started sometime in the last few months, and occurs on 2 of the 4 Ubuntu machines that I've tested it on. I compiled iftop 0.17 and 1.0-pre2 from source and observed the same behavior as the precompiled version (1.0-pre2 from the Ubuntu repo) on these computers.
I cannot figure out what is unique (other than physical hardware) about the 2 machines that still work, except that they use 3.2 and 3.6 kernels (vs. 3.5 and 3.11 on the machines that don't work). So maybe there's a network driver issue? I checked the version numbers of libc6, libncurses, libpcap, and libtinfo (all the dependencies I know of) and they are the same on 1 of the working machines vs. 1 of the non-working ones. And iftop worked properly on all of these machines until some relatively recent update.
So, iftop is completely unusable on at least 2 of my computers. Can anyone recommend further troubleshooting steps that I could take to isolate this problem, preferably without rebooting? Are there any other library versions I should check?
Thanks, Alex
Hi Alex,
Apologies for the delay in replying to this.
How much traffic is being seen on the machines involved?
Paul
On 02/11/2013 12:05, Alex Page wrote:
Hello, I am seeing strange behavior recently in iftop on Ubuntu (x64, 12.04 and 13.10). With Port Display disabled, iftop simply uses more CPU than normal (say, 20% instead of a negligible amount). Then, when Port Display is enabled, CPU use goes straight to 100% and iftop becomes unresponsive.
This behavior started sometime in the last few months, and occurs on 2 of the 4 Ubuntu machines that I've tested it on. I compiled iftop 0.17 and 1.0-pre2 from source and observed the same behavior as the precompiled version (1.0-pre2 from the Ubuntu repo) on these computers.
I cannot figure out what is unique (other than physical hardware) about the 2 machines that still work, except that they use 3.2 and 3.6 kernels (vs. 3.5 and 3.11 on the machines that don't work). So maybe there's a network driver issue? I checked the version numbers of libc6, libncurses, libpcap, and libtinfo (all the dependencies I know of) and they are the same on 1 of the working machines vs. 1 of the non-working ones. And iftop worked properly on all of these machines until some relatively recent update.
So, iftop is completely unusable on at least 2 of my computers. Can anyone recommend further troubleshooting steps that I could take to isolate this problem, preferably without rebooting? Are there any other library versions I should check?
Thanks, Alex
iftop-users mailing list iftop-users@lists.beasts.org http://lists.beasts.org/mailman/listinfo/iftop-users
Hi Paul,
Not a ton of traffic, tens or hundreds of kbps... it doesn't seem to depend on this. The highest typical amount would be 10-50Mbps, or occasionally up near 1Gbps on 1 of the faulty machines. It definitely seems NIC/driver-dependent, though, as I tried a wifi dongle on one of the bad machines and the problem didn't present itself on that interface. And as I mentioned, it has worked in the past on the same hardware.
Alex
On 11/12/2013 05:24 AM, Paul Warren wrote:
Hi Alex,
Apologies for the delay in replying to this.
How much traffic is being seen on the machines involved?
Paul
On 02/11/2013 12:05, Alex Page wrote:
Hello, I am seeing strange behavior recently in iftop on Ubuntu (x64, 12.04 and 13.10). With Port Display disabled, iftop simply uses more CPU than normal (say, 20% instead of a negligible amount). Then, when Port Display is enabled, CPU use goes straight to 100% and iftop becomes unresponsive.
This behavior started sometime in the last few months, and occurs on 2 of the 4 Ubuntu machines that I've tested it on. I compiled iftop 0.17 and 1.0-pre2 from source and observed the same behavior as the precompiled version (1.0-pre2 from the Ubuntu repo) on these computers.
I cannot figure out what is unique (other than physical hardware) about the 2 machines that still work, except that they use 3.2 and 3.6 kernels (vs. 3.5 and 3.11 on the machines that don't work). So maybe there's a network driver issue? I checked the version numbers of libc6, libncurses, libpcap, and libtinfo (all the dependencies I know of) and they are the same on 1 of the working machines vs. 1 of the non-working ones. And iftop worked properly on all of these machines until some relatively recent update.
So, iftop is completely unusable on at least 2 of my computers. Can anyone recommend further troubleshooting steps that I could take to isolate this problem, preferably without rebooting? Are there any other library versions I should check?
Thanks, Alex
iftop-users mailing list iftop-users@lists.beasts.org http://lists.beasts.org/mailman/listinfo/iftop-users
iftop-users mailing list iftop-users@lists.beasts.org http://lists.beasts.org/mailman/listinfo/iftop-users
Hi Alex,
I'm a bit short of ideas, but the fact that port display affects it makes me think that it's not directly hardware related, as port display makes no difference to how the packets are captured, it just makes a difference to how much work iftop does with them once received.
Does the traffic involve a large number of different hosts? Do you have any screen filters turned on? Does turning host resolution off make any difference?
Paul
On 12/11/2013 18:05, Alex Page wrote:
Hi Paul,
Not a ton of traffic, tens or hundreds of kbps... it doesn't seem to depend on this. The highest typical amount would be 10-50Mbps, or occasionally up near 1Gbps on 1 of the faulty machines. It definitely seems NIC/driver-dependent, though, as I tried a wifi dongle on one of the bad machines and the problem didn't present itself on that interface. And as I mentioned, it has worked in the past on the same hardware.
Alex
On 11/12/2013 05:24 AM, Paul Warren wrote:
Hi Alex,
Apologies for the delay in replying to this.
How much traffic is being seen on the machines involved?
Paul
On 02/11/2013 12:05, Alex Page wrote:
Hello, I am seeing strange behavior recently in iftop on Ubuntu (x64, 12.04 and 13.10). With Port Display disabled, iftop simply uses more CPU than normal (say, 20% instead of a negligible amount). Then, when Port Display is enabled, CPU use goes straight to 100% and iftop becomes unresponsive.
This behavior started sometime in the last few months, and occurs on 2 of the 4 Ubuntu machines that I've tested it on. I compiled iftop 0.17 and 1.0-pre2 from source and observed the same behavior as the precompiled version (1.0-pre2 from the Ubuntu repo) on these computers.
I cannot figure out what is unique (other than physical hardware) about the 2 machines that still work, except that they use 3.2 and 3.6 kernels (vs. 3.5 and 3.11 on the machines that don't work). So maybe there's a network driver issue? I checked the version numbers of libc6, libncurses, libpcap, and libtinfo (all the dependencies I know of) and they are the same on 1 of the working machines vs. 1 of the non-working ones. And iftop worked properly on all of these machines until some relatively recent update.
So, iftop is completely unusable on at least 2 of my computers. Can anyone recommend further troubleshooting steps that I could take to isolate this problem, preferably without rebooting? Are there any other library versions I should check?
Thanks, Alex
iftop-users mailing list iftop-users@lists.beasts.org http://lists.beasts.org/mailman/listinfo/iftop-users
iftop-users mailing list iftop-users@lists.beasts.org http://lists.beasts.org/mailman/listinfo/iftop-users
iftop-users mailing list iftop-users@lists.beasts.org http://lists.beasts.org/mailman/listinfo/iftop-users
Paul,
Thanks, host resolution appears to be the issue! I didn't test toggling it in iftop, because actually I switched routers and the problem disappeared. I have to assume that the issue was related to DNS resolution, since that's the only way I can see the router being involved with what iftop was doing. It's still strange that this problem suddenly appeared a few months ago, and seemed to depend on network interface, but I suppose there could have been something weird going on with the old router the whole time.
However, I would still consider this a bug... maybe iftop is handling something with DNS lookups badly? DNS queries made by any other application worked fine on those machines when iftop was choking. And in any case, DNS lookup issues in iftop probably shouldn't lock up a CPU.
Let me know if there's anything else I can do to test. Unfortunately (and fortunately), I got rid of the old router, so I have a feeling that I won't be able to reproduce the issue.
Alex
On 11/13/2013 04:34 AM, Paul Warren wrote:
Hi Alex,
I'm a bit short of ideas, but the fact that port display affects it makes me think that it's not directly hardware related, as port display makes no difference to how the packets are captured, it just makes a difference to how much work iftop does with them once received.
Does the traffic involve a large number of different hosts? Do you have any screen filters turned on? Does turning host resolution off make any difference?
Paul
On 12/11/2013 18:05, Alex Page wrote:
Hi Paul,
Not a ton of traffic, tens or hundreds of kbps... it doesn't seem to depend on this. The highest typical amount would be 10-50Mbps, or occasionally up near 1Gbps on 1 of the faulty machines. It definitely seems NIC/driver-dependent, though, as I tried a wifi dongle on one of the bad machines and the problem didn't present itself on that interface. And as I mentioned, it has worked in the past on the same hardware.
Alex
On 11/12/2013 05:24 AM, Paul Warren wrote:
Hi Alex,
Apologies for the delay in replying to this.
How much traffic is being seen on the machines involved?
Paul
On 02/11/2013 12:05, Alex Page wrote:
Hello, I am seeing strange behavior recently in iftop on Ubuntu (x64, 12.04 and 13.10). With Port Display disabled, iftop simply uses more CPU than normal (say, 20% instead of a negligible amount). Then, when Port Display is enabled, CPU use goes straight to 100% and iftop becomes unresponsive.
This behavior started sometime in the last few months, and occurs on 2 of the 4 Ubuntu machines that I've tested it on. I compiled iftop 0.17 and 1.0-pre2 from source and observed the same behavior as the precompiled version (1.0-pre2 from the Ubuntu repo) on these computers.
I cannot figure out what is unique (other than physical hardware) about the 2 machines that still work, except that they use 3.2 and 3.6 kernels (vs. 3.5 and 3.11 on the machines that don't work). So maybe there's a network driver issue? I checked the version numbers of libc6, libncurses, libpcap, and libtinfo (all the dependencies I know of) and they are the same on 1 of the working machines vs. 1 of the non-working ones. And iftop worked properly on all of these machines until some relatively recent update.
So, iftop is completely unusable on at least 2 of my computers. Can anyone recommend further troubleshooting steps that I could take to isolate this problem, preferably without rebooting? Are there any other library versions I should check?
Thanks, Alex
iftop-users mailing list iftop-users@lists.beasts.org http://lists.beasts.org/mailman/listinfo/iftop-users
iftop-users mailing list iftop-users@lists.beasts.org http://lists.beasts.org/mailman/listinfo/iftop-users
iftop-users mailing list iftop-users@lists.beasts.org http://lists.beasts.org/mailman/listinfo/iftop-users
iftop-users mailing list iftop-users@lists.beasts.org http://lists.beasts.org/mailman/listinfo/iftop-users
Hi Alex,
I actually think that a problem with DNS resolution is unlikely to be affected by a change in the router. More likely is that the new router is somehow filtering out some packets.
The fact that the problem gets worse when you turn port display on strongly hints at an issue in the display code, rather than the packet capture or DNS resolution code, and in particular, something that's burning through port numbers.
Let me know if you do see it again and we can investigate further.
Paul
On 20/11/2013 02:56, Alex Page wrote:
Paul,
Thanks, host resolution appears to be the issue! I didn't test toggling it in iftop, because actually I switched routers and the problem disappeared. I have to assume that the issue was related to DNS resolution, since that's the only way I can see the router being involved with what iftop was doing. It's still strange that this problem suddenly appeared a few months ago, and seemed to depend on network interface, but I suppose there could have been something weird going on with the old router the whole time.
However, I would still consider this a bug... maybe iftop is handling something with DNS lookups badly? DNS queries made by any other application worked fine on those machines when iftop was choking. And in any case, DNS lookup issues in iftop probably shouldn't lock up a CPU.
Let me know if there's anything else I can do to test. Unfortunately (and fortunately), I got rid of the old router, so I have a feeling that I won't be able to reproduce the issue.
Alex
On 11/13/2013 04:34 AM, Paul Warren wrote:
Hi Alex,
I'm a bit short of ideas, but the fact that port display affects it makes me think that it's not directly hardware related, as port display makes no difference to how the packets are captured, it just makes a difference to how much work iftop does with them once received.
Does the traffic involve a large number of different hosts? Do you have any screen filters turned on? Does turning host resolution off make any difference?
Paul
On 12/11/2013 18:05, Alex Page wrote:
Hi Paul,
Not a ton of traffic, tens or hundreds of kbps... it doesn't seem to depend on this. The highest typical amount would be 10-50Mbps, or occasionally up near 1Gbps on 1 of the faulty machines. It definitely seems NIC/driver-dependent, though, as I tried a wifi dongle on one of the bad machines and the problem didn't present itself on that interface. And as I mentioned, it has worked in the past on the same hardware.
Alex
On 11/12/2013 05:24 AM, Paul Warren wrote:
Hi Alex,
Apologies for the delay in replying to this.
How much traffic is being seen on the machines involved?
Paul
On 02/11/2013 12:05, Alex Page wrote:
Hello, I am seeing strange behavior recently in iftop on Ubuntu (x64, 12.04 and 13.10). With Port Display disabled, iftop simply uses more CPU than normal (say, 20% instead of a negligible amount). Then, when Port Display is enabled, CPU use goes straight to 100% and iftop becomes unresponsive.
This behavior started sometime in the last few months, and occurs on 2 of the 4 Ubuntu machines that I've tested it on. I compiled iftop 0.17 and 1.0-pre2 from source and observed the same behavior as the precompiled version (1.0-pre2 from the Ubuntu repo) on these computers.
I cannot figure out what is unique (other than physical hardware) about the 2 machines that still work, except that they use 3.2 and 3.6 kernels (vs. 3.5 and 3.11 on the machines that don't work). So maybe there's a network driver issue? I checked the version numbers of libc6, libncurses, libpcap, and libtinfo (all the dependencies I know of) and they are the same on 1 of the working machines vs. 1 of the non-working ones. And iftop worked properly on all of these machines until some relatively recent update.
So, iftop is completely unusable on at least 2 of my computers. Can anyone recommend further troubleshooting steps that I could take to isolate this problem, preferably without rebooting? Are there any other library versions I should check?
Thanks, Alex
iftop-users mailing list iftop-users@lists.beasts.org http://lists.beasts.org/mailman/listinfo/iftop-users
iftop-users mailing list iftop-users@lists.beasts.org http://lists.beasts.org/mailman/listinfo/iftop-users
iftop-users mailing list iftop-users@lists.beasts.org http://lists.beasts.org/mailman/listinfo/iftop-users
iftop-users mailing list iftop-users@lists.beasts.org http://lists.beasts.org/mailman/listinfo/iftop-users
iftop-users mailing list iftop-users@lists.beasts.org http://lists.beasts.org/mailman/listinfo/iftop-users
-
Alex Page -
Paul Warren