hey, i happily use iftop for months
i now recognize some strange behaviour
using iftop on an wireguard vpn tunnel (layer3) if i can easily see all the endpoints for IPv4 . they are shown as they should in that case 192.168.99.something
if i use v6 inside this wireguard tunnel .. so the IPs are more like fdf1::16:3e75:72af (/64) than there is only one ip shown all the time - or one dns entry (from /etc/hosts)
but strangely iftop get the streams right ... so i have plenty of connections from fdf1::16:3e75:72af to fdf1::16:3e75:72af
they all show the correct amount of traffic, but the naming/display "error" makes it difficult to use or understand whats going on.
if i restart iftop, it may be so that another of the involved ipv6(or dns) is showed for all involved endpoints
any idea if i do something wrong,or where the error origin is?
thx a lot fuzzle/freiburg
Example (where rauberhaus-v6 is just one of the ipv6 involved, if restartet it could be any other too)
rauberhaus-v6 => rauberhaus-v6 167Kb 114Kb 93.5Kb
<= 162Kb 110Kb 89.0Kb rauberhaus-v6 => rauberhaus-v6 8.16Kb 7.07Kb 7.06Kb
<= 160Kb 107Kb 87.5Kb
On 02/03/2017 02:03 PM, jens wrote:
if i use v6 inside this wireguard tunnel .. so the IPs are more like fdf1::16:3e75:72af (/64) than there is only one ip shown all the time - or one dns entry (from /etc/hosts)
but strangely iftop get the streams right ... so i have plenty of connections from fdf1::16:3e75:72af to fdf1::16:3e75:72af
they all show the correct amount of traffic, but the naming/display "error" makes it difficult to use or understand whats going on.
This is a long standing bug. Here is when I reported it for RedHat:
https://bugzilla.redhat.com/show_bug.cgi?id=1120254
The workaround is to turn off DNS lookup ('n'). DNS is unreliable anyway, right?
On 04.02.2017 03:53, Stuart Gathman wrote:
On 02/03/2017 02:03 PM, jens wrote:
if i use v6 inside this wireguard tunnel .. so the IPs are more like fdf1::16:3e75:72af (/64) than there is only one ip shown all the time - or one dns entry (from /etc/hosts)
but strangely iftop get the streams right ... so i have plenty of connections from fdf1::16:3e75:72af to fdf1::16:3e75:72af
they all show the correct amount of traffic, but the naming/display "error" makes it difficult to use or understand whats going on.
This is a long standing bug. Here is when I reported it for RedHat:
https://bugzilla.redhat.com/show_bug.cgi?id=1120254
The workaround is to turn off DNS lookup ('n'). DNS is unreliable anyway, right?
think a little bit deeper in it, it seems that iftop is doing strange things, other than described in the issue , there are NO succesfull lookups of ipv6 addresses other than etc/hosts .. and there it picks randomly (i guess the first occuring of) a hosts-entry for a ipv6 and from this moment on use it buggy-wise use this for all ipv6 which are there ..
dont know if that helps in finding the problem, just wanted to clear this
On 03/02/17 19:03, jens wrote:
hey, i happily use iftop for months
i now recognize some strange behaviour
using iftop on an wireguard vpn tunnel (layer3) if i can easily see all the endpoints for IPv4 . they are shown as they should in that case 192.168.99.something
if i use v6 inside this wireguard tunnel .. so the IPs are more like fdf1::16:3e75:72af (/64) than there is only one ip shown all the time - or one dns entry (from /etc/hosts)
I've not been able to reproduce this. Can you confirm what version of iftop you're using?
I'd be grateful if you could try the latest version from git:
https://code.blinkace.com/pdw/iftop
If you're still seeing problems, please could you send me the contents of config.h after building?
thanks,
Paul
On Mon, 6 Feb 2017, Paul Warren wrote:
On 03/02/17 19:03, jens wrote:
hey, i happily use iftop for months
i now recognize some strange behaviour
using iftop on an wireguard vpn tunnel (layer3) if i can easily see all the endpoints for IPv4 . they are shown as they should in that case 192.168.99.something
if i use v6 inside this wireguard tunnel .. so the IPs are more like fdf1::16:3e75:72af (/64) than there is only one ip shown all the time - or one dns entry (from /etc/hosts)
I've not been able to reproduce this. Can you confirm what version of iftop you're using?
It works if all IPv6 rDNS lookups succeed. Even if most IPv6 rDNS lookups succeed, you might not notice the problem (and that is when it is the most dangerous). The best way to reproduce is to run on a local IPv6 subnet where *none* of the IPv6 lookups succeed, or else point /etc/resolv.conf to a local dnsmasq with ip6.arpa set to always return NXDOMAIN. Then all IPv6 will display as the same raw IP, and you will surely notice.
On 02/06/2017 12:12 PM, Stuart D. Gathman wrote:
On Mon, 6 Feb 2017, Paul Warren wrote:
I've not been able to reproduce this. Can you confirm what version of iftop you're using?
It works if all IPv6 rDNS lookups succeed. Even if most IPv6 rDNS lookups succeed, you might not notice the problem (and that is when it is the most dangerous). The best way to reproduce is to run on a local IPv6 subnet where *none* of the IPv6 lookups succeed, or else point /etc/resolv.conf to a local dnsmasq with ip6.arpa set to always return NXDOMAIN. Then all IPv6 will display as the same raw IP, and you will surely notice.
Not of the git commits since 1.0pre4, but I compiled up the latest and greatest from the git repo you requested to confirm that the same bug is still there after all these years. I've attached config.h from the build.
i get trouble to see any v6 traffic at all with you git/build
even with -l or with -G flag...
only v4 traffic is shown on wg0 if
./iftop -i wg0 -G fdf1::16:3e75:72af/64 ./iftop -i wg0 -l -G fdf1::16:3e75:72af/64 ./iftop -i wg0 -l ./iftop -i wg0 -G ::0/0 ./iftop -i wg0
the last one is normaly used command by default iftop.
(which works fine except for v6 dns)
latest git clone is iftop, version 1.0pre4 normaly used is strangely also iftop, version 1.0pre4 (is the string simply not updated?)
(checked by date and sha difference in iftop in build directory and also in usr/sbin)
# which iftop /usr/sbin/iftop # ls -la /usr/sbin/iftop -rwxr-xr-x 1 root root 64152 Jan 3 22:15 /usr/sbin/iftop
# ls -la iftop/iftop -rwxr-xr-x 1 root root 238752 Feb 6 10:27 iftop/iftop
config.h is added as file
On 06.02.2017 19:48, Stuart Gathman wrote:
On 02/06/2017 12:12 PM, Stuart D. Gathman wrote:
On Mon, 6 Feb 2017, Paul Warren wrote:
I've not been able to reproduce this. Can you confirm what version of iftop you're using?
On Mon, 6 Feb 2017, jens wrote:
i get trouble to see any v6 traffic at all with you git/build
even with -l or with -G flag...
only v4 traffic is shown on wg0 if
./iftop -i wg0 -G fdf1::16:3e75:72af/64 ./iftop -i wg0 -l -G fdf1::16:3e75:72af/64 ./iftop -i wg0 -l ./iftop -i wg0 -G ::0/0 ./iftop -i wg0
-G specifies the *local* subnet. With ::/0, everything is local and there is no remote, so nothing displays. You probably wanted
iftop -i wg0 -G fdf1::/64 # if there are other subnets like fdf1:1::/64 iftop -i wg0 -G fdf1::16:3e75:72af/128 # if only your box is local
Again, the purpose of -G is to bisect the address space into "inside" and "outside".
latest git clone is iftop, version 1.0pre4 normaly used is strangely also iftop, version 1.0pre4 (is the string simply not updated?)
You might not have the latest, where the "pre" warning is removed.
The last commit I have is:
commit 53e1150f66a478d3c52180d395a123ae9fcb8618 Author: Paul Warren pdw@ex-parrot.com Date: Thu Jan 5 21:23:57 2017 +0000
Support for unlimited number of lines of output in text mode - Roman Hoog Antink rha@open.ch
On 06.02.2017 22:43, Stuart D. Gathman wrote:
ftop -i wg0 -G fdf1::/64
sorry to disagree again, i try'd this .. didnt work, i only showed all i tested for transparency .. no v6 Adress is shown ... if i use this - ./iftop -i wg0 -G fdf1::16:3e75:72af/128 at least v6 adresses are shown (with wrong dns - all the same)
i build on this commit # git log|head -n1 commit 53e1150f66a478d3c52180d395a123ae9fcb8618
which is the latest - i just checked out your git after your email. The pre warning is still there
On Mon, 6 Feb 2017, jens wrote:
On 06.02.2017 22:43, Stuart D. Gathman wrote:
ftop -i wg0 -G fdf1::/64
sorry to disagree again, i try'd this .. didnt work, i only showed all i tested for transparency .. no v6 Adress is shown ...
That was just an example - I have no idea what your network actually looks like. The subnet you chose will be "local", and only connections to somewhere else will be shown.
if i use this - ./iftop -i wg0 -G fdf1::16:3e75:72af/128 at least v6 adresses are shown (with wrong dns - all the same)
Yep, that is the bug.
i build on this commit # git log|head -n1 commit 53e1150f66a478d3c52180d395a123ae9fcb8618
which is the latest - i just checked out your git after your email. The pre warning is still there
Not the latest. The latest is this:
commit 35af3cf65f17961d173b31fd3b00166ec095c226 Author: Paul Warren pdw@mythic-beasts.com Date: Mon Feb 6 21:35:37 2017 +0000
Fix bug with DNS resolution. https://bugzilla.redhat.com/show_bug.cgi?id=1120254
On 06.02.2017 23:50, Stuart D. Gathman wrote:
Not the latest. The latest is this:
commit 35af3cf65f17961d173b31fd3b00166ec095c226 Author: Paul Warren pdw@mythic-beasts.com Date: Mon Feb 6 21:35:37 2017 +0000
yay, this solves the issue, the iftop -h still show the pre version. You may want to fix this.
thx a lot
On 06/02/17 18:48, Stuart Gathman wrote:
It works if all IPv6 rDNS lookups succeed. Even if most IPv6 rDNS lookups succeed, you might not notice the problem (and that is when it is the most dangerous). The best way to reproduce is to run on a local IPv6 subnet where *none* of the IPv6 lookups succeed, or else point /etc/resolv.conf to a local dnsmasq with ip6.arpa set to always return NXDOMAIN. Then all IPv6 will display as the same raw IP, and you will surely notice.
Please could you try the latest in git?
https://code.blinkace.com/pdw/iftop/commit/35af3cf65f17961d173b31fd3b00166ec...
It looks like the key used for caching DNS lookups was assumed to be in6_addr, but in fact was a larger struct that wrapped the IP address. This means that the comparison looking for NS lookups was effectively ignoring 64 of the 128 bits in the v6 address, leading to very unpredictable results.
Paul
On Mon, 6 Feb 2017, Paul Warren wrote:
Please could you try the latest in git?
https://code.blinkace.com/pdw/iftop/commit/35af3cf65f17961d173b31fd3b00166ec...
It looks like the key used for caching DNS lookups was assumed to be in6_addr, but in fact was a larger struct that wrapped the IP address. This means that the comparison looking for NS lookups was effectively ignoring 64 of the 128 bits in the v6 address, leading to very unpredictable results.
That seems to fix it.
Could you tag 1.0 or 1.0.1?
-
jens -
Paul Warren -
Stuart D. Gathman -
Stuart Gathman