Accounting for /proc/net/dev reported traffic
Clash Royale CLAN TAG#URR8PPP
up vote
6
down vote
favorite
I noticed that according to /proc/net/dev I am constantly receiving around 6Kb/s on my wireless usb interface. But I can't account for anything even close to that with the individual connections that I get with iptraf, iftop, and nethogs. Investigations with netstat, lsof, and tcpdump didn't help either.
So, what else could contribute to /proc/net/dev values? I can speculate that, while only IP based traffic is reported by the applications I mentioned, /proc/net/dev probably accounts for other link-layer/internet-layer stuff too (arp? icmp? wireless management stuff?). Or maybe other transport/application protocols. Can anyone confirm this?
How else would you proceed to find out: through what sockets are the 6Kb/s coming through? What processes are receiving the traffic?
[EDIT]
The 2 consistent results across all the tools:
- the totals of Rx are around a few Kb/s
- confirmed with /proc/net/dev, dstat, bmw-ng, cbm, iptraf, ifstat, gnome-system-monitor
- no connection/packet stream justifies that
- confirmed with netstat, tcpdump, iftop, nethogs, iptraf
All of this with a Netgear WDNA 4100 wireless usb adapter using a custom driver from some git (the only way I got it to work). I asked the devs about it here.
This might be malware, but I suspect the driver is simply reporting wrong totals. Nevertheless, I cannot explain what's going on for sure.
networking monitoring proc netstat traffic
asked Feb 12 '14 at 0:12
ricab
3411313
add a comment |Â
up vote
6
down vote
favorite
I noticed that according to /proc/net/dev I am constantly receiving around 6Kb/s on my wireless usb interface. But I can't account for anything even close to that with the individual connections that I get with iptraf, iftop, and nethogs. Investigations with netstat, lsof, and tcpdump didn't help either.
So, what else could contribute to /proc/net/dev values? I can speculate that, while only IP based traffic is reported by the applications I mentioned, /proc/net/dev probably accounts for other link-layer/internet-layer stuff too (arp? icmp? wireless management stuff?). Or maybe other transport/application protocols. Can anyone confirm this?
How else would you proceed to find out: through what sockets are the 6Kb/s coming through? What processes are receiving the traffic?
[EDIT]
The 2 consistent results across all the tools:
- the totals of Rx are around a few Kb/s
- confirmed with /proc/net/dev, dstat, bmw-ng, cbm, iptraf, ifstat, gnome-system-monitor
- no connection/packet stream justifies that
- confirmed with netstat, tcpdump, iftop, nethogs, iptraf
All of this with a Netgear WDNA 4100 wireless usb adapter using a custom driver from some git (the only way I got it to work). I asked the devs about it here.
This might be malware, but I suspect the driver is simply reporting wrong totals. Nevertheless, I cannot explain what's going on for sure.
networking monitoring proc netstat traffic
asked Feb 12 '14 at 0:12
ricab
3411313
Can you show exactly what you're talking about? How did you determine this number?
– slm♦
Feb 12 '14 at 0:33
@slm: I didn't calculate directly from /proc/net/dev, I relied on tools that get their data there and do the calculation. The exact number is not important, but if Iwatch -n 0.2 'cat /proc/net/dev', I see the byte total constantly increasing. This is consistent with results from gnome-system-monitor, iptraf's "general interface statistics", bwm-ng, etc.
– ricab
Feb 12 '14 at 9:53
tcpdump -n -i wlan0(or whatever the device is called) shows no traffic?
– derobert
Jun 20 '14 at 20:37
@derobert: it does, but not nearly enough to cover the 6Kb/s total I get from several sources
– ricab
Jun 23 '14 at 9:49
add a comment |Â
up vote
6
down vote
favorite
up vote
6
down vote
favorite
I noticed that according to /proc/net/dev I am constantly receiving around 6Kb/s on my wireless usb interface. But I can't account for anything even close to that with the individual connections that I get with iptraf, iftop, and nethogs. Investigations with netstat, lsof, and tcpdump didn't help either.
So, what else could contribute to /proc/net/dev values? I can speculate that, while only IP based traffic is reported by the applications I mentioned, /proc/net/dev probably accounts for other link-layer/internet-layer stuff too (arp? icmp? wireless management stuff?). Or maybe other transport/application protocols. Can anyone confirm this?
How else would you proceed to find out: through what sockets are the 6Kb/s coming through? What processes are receiving the traffic?
[EDIT]
The 2 consistent results across all the tools:
- the totals of Rx are around a few Kb/s
- confirmed with /proc/net/dev, dstat, bmw-ng, cbm, iptraf, ifstat, gnome-system-monitor
- no connection/packet stream justifies that
- confirmed with netstat, tcpdump, iftop, nethogs, iptraf
All of this with a Netgear WDNA 4100 wireless usb adapter using a custom driver from some git (the only way I got it to work). I asked the devs about it here.
This might be malware, but I suspect the driver is simply reporting wrong totals. Nevertheless, I cannot explain what's going on for sure.
networking monitoring proc netstat traffic
asked Feb 12 '14 at 0:12
ricab
3411313
I noticed that according to /proc/net/dev I am constantly receiving around 6Kb/s on my wireless usb interface. But I can't account for anything even close to that with the individual connections that I get with iptraf, iftop, and nethogs. Investigations with netstat, lsof, and tcpdump didn't help either.
So, what else could contribute to /proc/net/dev values? I can speculate that, while only IP based traffic is reported by the applications I mentioned, /proc/net/dev probably accounts for other link-layer/internet-layer stuff too (arp? icmp? wireless management stuff?). Or maybe other transport/application protocols. Can anyone confirm this?
How else would you proceed to find out: through what sockets are the 6Kb/s coming through? What processes are receiving the traffic?
[EDIT]
The 2 consistent results across all the tools:
- the totals of Rx are around a few Kb/s
- confirmed with /proc/net/dev, dstat, bmw-ng, cbm, iptraf, ifstat, gnome-system-monitor
- no connection/packet stream justifies that
- confirmed with netstat, tcpdump, iftop, nethogs, iptraf
All of this with a Netgear WDNA 4100 wireless usb adapter using a custom driver from some git (the only way I got it to work). I asked the devs about it here.
This might be malware, but I suspect the driver is simply reporting wrong totals. Nevertheless, I cannot explain what's going on for sure.
networking monitoring proc netstat traffic
networking monitoring proc netstat traffic
asked Feb 12 '14 at 0:12
ricab
3411313
asked Feb 12 '14 at 0:12
ricab
3411313
edited Feb 18 '14 at 21:49
asked Feb 12 '14 at 0:12
ricab
3411313
asked Feb 12 '14 at 0:12
ricab
3411313
asked Feb 12 '14 at 0:12
ricab
3411313
3411313
Can you show exactly what you're talking about? How did you determine this number?
– slm♦
Feb 12 '14 at 0:33
@slm: I didn't calculate directly from /proc/net/dev, I relied on tools that get their data there and do the calculation. The exact number is not important, but if Iwatch -n 0.2 'cat /proc/net/dev', I see the byte total constantly increasing. This is consistent with results from gnome-system-monitor, iptraf's "general interface statistics", bwm-ng, etc.
– ricab
Feb 12 '14 at 9:53
tcpdump -n -i wlan0(or whatever the device is called) shows no traffic?
– derobert
Jun 20 '14 at 20:37
@derobert: it does, but not nearly enough to cover the 6Kb/s total I get from several sources
– ricab
Jun 23 '14 at 9:49
add a comment |Â
Can you show exactly what you're talking about? How did you determine this number?
– slm♦
Feb 12 '14 at 0:33
@slm: I didn't calculate directly from /proc/net/dev, I relied on tools that get their data there and do the calculation. The exact number is not important, but if Iwatch -n 0.2 'cat /proc/net/dev', I see the byte total constantly increasing. This is consistent with results from gnome-system-monitor, iptraf's "general interface statistics", bwm-ng, etc.
– ricab
Feb 12 '14 at 9:53
tcpdump -n -i wlan0(or whatever the device is called) shows no traffic?
– derobert
Jun 20 '14 at 20:37
@derobert: it does, but not nearly enough to cover the 6Kb/s total I get from several sources
– ricab
Jun 23 '14 at 9:49
Can you show exactly what you're talking about? How did you determine this number?
– slm♦
Feb 12 '14 at 0:33
Can you show exactly what you're talking about? How did you determine this number?
– slm♦
Feb 12 '14 at 0:33
@slm: I didn't calculate directly from /proc/net/dev, I relied on tools that get their data there and do the calculation. The exact number is not important, but if I
watch -n 0.2 'cat /proc/net/dev', I see the byte total constantly increasing. This is consistent with results from gnome-system-monitor, iptraf's "general interface statistics", bwm-ng, etc.– ricab
Feb 12 '14 at 9:53
@slm: I didn't calculate directly from /proc/net/dev, I relied on tools that get their data there and do the calculation. The exact number is not important, but if I
watch -n 0.2 'cat /proc/net/dev', I see the byte total constantly increasing. This is consistent with results from gnome-system-monitor, iptraf's "general interface statistics", bwm-ng, etc.– ricab
Feb 12 '14 at 9:53
tcpdump -n -i wlan0 (or whatever the device is called) shows no traffic?– derobert
Jun 20 '14 at 20:37
tcpdump -n -i wlan0 (or whatever the device is called) shows no traffic?– derobert
Jun 20 '14 at 20:37
@derobert: it does, but not nearly enough to cover the 6Kb/s total I get from several sources
– ricab
Jun 23 '14 at 9:49
@derobert: it does, but not nearly enough to cover the 6Kb/s total I get from several sources
– ricab
Jun 23 '14 at 9:49
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
0
down vote
When dealing with applications that are using up network bandwidth the best tool I've come across for tying back utilization to specific apps has got to be nethogs.
You can use ip link show or netstat -i to find out your network interface names.
$ netstat -i
Kernel Interface table
Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
em1 1500 0 0 0 0 0 0 0 0 BMU
lo 65536 81375 0 0 0 81375 0 0 0 LRU
virbr0 1500 0 0 0 0 0 0 0 0 BMU
wlp3s0 1500 2264942 0 0 0 2376236 0 0 0 BMRU
My wireless on my Fedora 19 laptop is wlp3s0, so we tell nethogs to watch that:
$ sudo nethogs wlp3s0
    
As you let nethogs run it will start to show you the applications that are consuming your network bandwidth.
answered Feb 12 '14 at 14:03
slm♦
239k65494664
Thanks, but I've been through that and it doesn't add up here. In fact, the total I get in nethogs and other tools is mostly at 0.000, while /proc/net/dev based calculations show a few thousand bytes coming in every second through my wireless usb adapter. BTW, this is not the case is another machine with a very similar installation but which is plugged through Ethernet. That's why I speculated some low level protocol msgs (for some wireless link management or sth) could be contributing to /proc/net/dev totals, although not participating in open socket totals. Does that make sense?
– ricab
Feb 12 '14 at 17:56
@ricab - if there isn't an app pulling the data directly then I'd check with tcpdump. You should be able to determine the nature of the packets flowing in/out. I'd be a little suspicious at this point, possible malware. I was looking at my wireless and there doesn't appear to be 6Kb/s levels of traffic for wireless network "plumbing" type of traffic. It could be something hammering your IP that might be the cause too.
– slm♦
Feb 12 '14 at 18:23
Tcpdump doesn't help either. The 2 consistent results across all the tools: 1) the totals of Rx are around a few Kb; 2) no connection/packet stream justifies that. All of this with a Netgear WDNA 4100 wireless usb adapter using a custom driver from some git (the only way I got it to work). This might be malware, but I suspect the driver is simply reporting wrong totals. Nevertheless, I cannot explain what's going on for sure. Anyway, thanks again.
– ricab
Feb 16 '14 at 18:29
@ricab - sounds suspicious to me. Check to see if any malware installed modified versions oftcpdump, modified versions could mask any actual traffic.
– slm♦
Feb 16 '14 at 22:37
1
Nope, I verified my tcpdump withdebsumsand, manually, against the web listed md5 and it's the original. Besides, this malware would have to have installed modified versions ofnetstat,iftop,nethogs, andiptrafas well to mask the traffic there. Unless the change was in a shared lib, but I just verified all libs I got withldd /usr/sbin/tcpdump(from deb packageslibssl1.0.0libpcap0.8libc6zlib1g). So I can't see it as being due to malware, except if it was in the wifi driver itself, which I doubt (it's public code). But thanks any case
– ricab
Feb 18 '14 at 21:49
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
When dealing with applications that are using up network bandwidth the best tool I've come across for tying back utilization to specific apps has got to be nethogs.
You can use ip link show or netstat -i to find out your network interface names.
$ netstat -i
Kernel Interface table
Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
em1 1500 0 0 0 0 0 0 0 0 BMU
lo 65536 81375 0 0 0 81375 0 0 0 LRU
virbr0 1500 0 0 0 0 0 0 0 0 BMU
wlp3s0 1500 2264942 0 0 0 2376236 0 0 0 BMRU
My wireless on my Fedora 19 laptop is wlp3s0, so we tell nethogs to watch that:
$ sudo nethogs wlp3s0
   Â
As you let nethogs run it will start to show you the applications that are consuming your network bandwidth.
answered Feb 12 '14 at 14:03
slm♦
239k65494664
Thanks, but I've been through that and it doesn't add up here. In fact, the total I get in nethogs and other tools is mostly at 0.000, while /proc/net/dev based calculations show a few thousand bytes coming in every second through my wireless usb adapter. BTW, this is not the case is another machine with a very similar installation but which is plugged through Ethernet. That's why I speculated some low level protocol msgs (for some wireless link management or sth) could be contributing to /proc/net/dev totals, although not participating in open socket totals. Does that make sense?
– ricab
Feb 12 '14 at 17:56
@ricab - if there isn't an app pulling the data directly then I'd check with tcpdump. You should be able to determine the nature of the packets flowing in/out. I'd be a little suspicious at this point, possible malware. I was looking at my wireless and there doesn't appear to be 6Kb/s levels of traffic for wireless network "plumbing" type of traffic. It could be something hammering your IP that might be the cause too.
– slm♦
Feb 12 '14 at 18:23
Tcpdump doesn't help either. The 2 consistent results across all the tools: 1) the totals of Rx are around a few Kb; 2) no connection/packet stream justifies that. All of this with a Netgear WDNA 4100 wireless usb adapter using a custom driver from some git (the only way I got it to work). This might be malware, but I suspect the driver is simply reporting wrong totals. Nevertheless, I cannot explain what's going on for sure. Anyway, thanks again.
– ricab
Feb 16 '14 at 18:29
@ricab - sounds suspicious to me. Check to see if any malware installed modified versions oftcpdump, modified versions could mask any actual traffic.
– slm♦
Feb 16 '14 at 22:37
1
Nope, I verified my tcpdump withdebsumsand, manually, against the web listed md5 and it's the original. Besides, this malware would have to have installed modified versions ofnetstat,iftop,nethogs, andiptrafas well to mask the traffic there. Unless the change was in a shared lib, but I just verified all libs I got withldd /usr/sbin/tcpdump(from deb packageslibssl1.0.0libpcap0.8libc6zlib1g). So I can't see it as being due to malware, except if it was in the wifi driver itself, which I doubt (it's public code). But thanks any case
– ricab
Feb 18 '14 at 21:49
add a comment |Â
up vote
0
down vote
When dealing with applications that are using up network bandwidth the best tool I've come across for tying back utilization to specific apps has got to be nethogs.
You can use ip link show or netstat -i to find out your network interface names.
$ netstat -i
Kernel Interface table
Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
em1 1500 0 0 0 0 0 0 0 0 BMU
lo 65536 81375 0 0 0 81375 0 0 0 LRU
virbr0 1500 0 0 0 0 0 0 0 0 BMU
wlp3s0 1500 2264942 0 0 0 2376236 0 0 0 BMRU
My wireless on my Fedora 19 laptop is wlp3s0, so we tell nethogs to watch that:
$ sudo nethogs wlp3s0
   Â
As you let nethogs run it will start to show you the applications that are consuming your network bandwidth.
answered Feb 12 '14 at 14:03
slm♦
239k65494664
Thanks, but I've been through that and it doesn't add up here. In fact, the total I get in nethogs and other tools is mostly at 0.000, while /proc/net/dev based calculations show a few thousand bytes coming in every second through my wireless usb adapter. BTW, this is not the case is another machine with a very similar installation but which is plugged through Ethernet. That's why I speculated some low level protocol msgs (for some wireless link management or sth) could be contributing to /proc/net/dev totals, although not participating in open socket totals. Does that make sense?
– ricab
Feb 12 '14 at 17:56
@ricab - if there isn't an app pulling the data directly then I'd check with tcpdump. You should be able to determine the nature of the packets flowing in/out. I'd be a little suspicious at this point, possible malware. I was looking at my wireless and there doesn't appear to be 6Kb/s levels of traffic for wireless network "plumbing" type of traffic. It could be something hammering your IP that might be the cause too.
– slm♦
Feb 12 '14 at 18:23
Tcpdump doesn't help either. The 2 consistent results across all the tools: 1) the totals of Rx are around a few Kb; 2) no connection/packet stream justifies that. All of this with a Netgear WDNA 4100 wireless usb adapter using a custom driver from some git (the only way I got it to work). This might be malware, but I suspect the driver is simply reporting wrong totals. Nevertheless, I cannot explain what's going on for sure. Anyway, thanks again.
– ricab
Feb 16 '14 at 18:29
@ricab - sounds suspicious to me. Check to see if any malware installed modified versions oftcpdump, modified versions could mask any actual traffic.
– slm♦
Feb 16 '14 at 22:37
1
Nope, I verified my tcpdump withdebsumsand, manually, against the web listed md5 and it's the original. Besides, this malware would have to have installed modified versions ofnetstat,iftop,nethogs, andiptrafas well to mask the traffic there. Unless the change was in a shared lib, but I just verified all libs I got withldd /usr/sbin/tcpdump(from deb packageslibssl1.0.0libpcap0.8libc6zlib1g). So I can't see it as being due to malware, except if it was in the wifi driver itself, which I doubt (it's public code). But thanks any case
– ricab
Feb 18 '14 at 21:49
add a comment |Â
up vote
0
down vote
up vote
0
down vote
When dealing with applications that are using up network bandwidth the best tool I've come across for tying back utilization to specific apps has got to be nethogs.
You can use ip link show or netstat -i to find out your network interface names.
$ netstat -i
Kernel Interface table
Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
em1 1500 0 0 0 0 0 0 0 0 BMU
lo 65536 81375 0 0 0 81375 0 0 0 LRU
virbr0 1500 0 0 0 0 0 0 0 0 BMU
wlp3s0 1500 2264942 0 0 0 2376236 0 0 0 BMRU
My wireless on my Fedora 19 laptop is wlp3s0, so we tell nethogs to watch that:
$ sudo nethogs wlp3s0
   Â
As you let nethogs run it will start to show you the applications that are consuming your network bandwidth.
answered Feb 12 '14 at 14:03
slm♦
239k65494664
When dealing with applications that are using up network bandwidth the best tool I've come across for tying back utilization to specific apps has got to be nethogs.
You can use ip link show or netstat -i to find out your network interface names.
$ netstat -i
Kernel Interface table
Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
em1 1500 0 0 0 0 0 0 0 0 BMU
lo 65536 81375 0 0 0 81375 0 0 0 LRU
virbr0 1500 0 0 0 0 0 0 0 0 BMU
wlp3s0 1500 2264942 0 0 0 2376236 0 0 0 BMRU
My wireless on my Fedora 19 laptop is wlp3s0, so we tell nethogs to watch that:
$ sudo nethogs wlp3s0
   Â
As you let nethogs run it will start to show you the applications that are consuming your network bandwidth.
answered Feb 12 '14 at 14:03
slm♦
239k65494664
answered Feb 12 '14 at 14:03
slm♦
239k65494664
answered Feb 12 '14 at 14:03
slm♦
239k65494664
answered Feb 12 '14 at 14:03
slm♦
239k65494664
239k65494664
Thanks, but I've been through that and it doesn't add up here. In fact, the total I get in nethogs and other tools is mostly at 0.000, while /proc/net/dev based calculations show a few thousand bytes coming in every second through my wireless usb adapter. BTW, this is not the case is another machine with a very similar installation but which is plugged through Ethernet. That's why I speculated some low level protocol msgs (for some wireless link management or sth) could be contributing to /proc/net/dev totals, although not participating in open socket totals. Does that make sense?
– ricab
Feb 12 '14 at 17:56
@ricab - if there isn't an app pulling the data directly then I'd check with tcpdump. You should be able to determine the nature of the packets flowing in/out. I'd be a little suspicious at this point, possible malware. I was looking at my wireless and there doesn't appear to be 6Kb/s levels of traffic for wireless network "plumbing" type of traffic. It could be something hammering your IP that might be the cause too.
– slm♦
Feb 12 '14 at 18:23
Tcpdump doesn't help either. The 2 consistent results across all the tools: 1) the totals of Rx are around a few Kb; 2) no connection/packet stream justifies that. All of this with a Netgear WDNA 4100 wireless usb adapter using a custom driver from some git (the only way I got it to work). This might be malware, but I suspect the driver is simply reporting wrong totals. Nevertheless, I cannot explain what's going on for sure. Anyway, thanks again.
– ricab
Feb 16 '14 at 18:29
@ricab - sounds suspicious to me. Check to see if any malware installed modified versions oftcpdump, modified versions could mask any actual traffic.
– slm♦
Feb 16 '14 at 22:37
1
Nope, I verified my tcpdump withdebsumsand, manually, against the web listed md5 and it's the original. Besides, this malware would have to have installed modified versions ofnetstat,iftop,nethogs, andiptrafas well to mask the traffic there. Unless the change was in a shared lib, but I just verified all libs I got withldd /usr/sbin/tcpdump(from deb packageslibssl1.0.0libpcap0.8libc6zlib1g). So I can't see it as being due to malware, except if it was in the wifi driver itself, which I doubt (it's public code). But thanks any case
– ricab
Feb 18 '14 at 21:49
add a comment |Â
Thanks, but I've been through that and it doesn't add up here. In fact, the total I get in nethogs and other tools is mostly at 0.000, while /proc/net/dev based calculations show a few thousand bytes coming in every second through my wireless usb adapter. BTW, this is not the case is another machine with a very similar installation but which is plugged through Ethernet. That's why I speculated some low level protocol msgs (for some wireless link management or sth) could be contributing to /proc/net/dev totals, although not participating in open socket totals. Does that make sense?
– ricab
Feb 12 '14 at 17:56
@ricab - if there isn't an app pulling the data directly then I'd check with tcpdump. You should be able to determine the nature of the packets flowing in/out. I'd be a little suspicious at this point, possible malware. I was looking at my wireless and there doesn't appear to be 6Kb/s levels of traffic for wireless network "plumbing" type of traffic. It could be something hammering your IP that might be the cause too.
– slm♦
Feb 12 '14 at 18:23
Tcpdump doesn't help either. The 2 consistent results across all the tools: 1) the totals of Rx are around a few Kb; 2) no connection/packet stream justifies that. All of this with a Netgear WDNA 4100 wireless usb adapter using a custom driver from some git (the only way I got it to work). This might be malware, but I suspect the driver is simply reporting wrong totals. Nevertheless, I cannot explain what's going on for sure. Anyway, thanks again.
– ricab
Feb 16 '14 at 18:29
@ricab - sounds suspicious to me. Check to see if any malware installed modified versions oftcpdump, modified versions could mask any actual traffic.
– slm♦
Feb 16 '14 at 22:37
1
Nope, I verified my tcpdump withdebsumsand, manually, against the web listed md5 and it's the original. Besides, this malware would have to have installed modified versions ofnetstat,iftop,nethogs, andiptrafas well to mask the traffic there. Unless the change was in a shared lib, but I just verified all libs I got withldd /usr/sbin/tcpdump(from deb packageslibssl1.0.0libpcap0.8libc6zlib1g). So I can't see it as being due to malware, except if it was in the wifi driver itself, which I doubt (it's public code). But thanks any case
– ricab
Feb 18 '14 at 21:49
Thanks, but I've been through that and it doesn't add up here. In fact, the total I get in nethogs and other tools is mostly at 0.000, while /proc/net/dev based calculations show a few thousand bytes coming in every second through my wireless usb adapter. BTW, this is not the case is another machine with a very similar installation but which is plugged through Ethernet. That's why I speculated some low level protocol msgs (for some wireless link management or sth) could be contributing to /proc/net/dev totals, although not participating in open socket totals. Does that make sense?
– ricab
Feb 12 '14 at 17:56
Thanks, but I've been through that and it doesn't add up here. In fact, the total I get in nethogs and other tools is mostly at 0.000, while /proc/net/dev based calculations show a few thousand bytes coming in every second through my wireless usb adapter. BTW, this is not the case is another machine with a very similar installation but which is plugged through Ethernet. That's why I speculated some low level protocol msgs (for some wireless link management or sth) could be contributing to /proc/net/dev totals, although not participating in open socket totals. Does that make sense?
– ricab
Feb 12 '14 at 17:56
@ricab - if there isn't an app pulling the data directly then I'd check with tcpdump. You should be able to determine the nature of the packets flowing in/out. I'd be a little suspicious at this point, possible malware. I was looking at my wireless and there doesn't appear to be 6Kb/s levels of traffic for wireless network "plumbing" type of traffic. It could be something hammering your IP that might be the cause too.
– slm♦
Feb 12 '14 at 18:23
@ricab - if there isn't an app pulling the data directly then I'd check with tcpdump. You should be able to determine the nature of the packets flowing in/out. I'd be a little suspicious at this point, possible malware. I was looking at my wireless and there doesn't appear to be 6Kb/s levels of traffic for wireless network "plumbing" type of traffic. It could be something hammering your IP that might be the cause too.
– slm♦
Feb 12 '14 at 18:23
Tcpdump doesn't help either. The 2 consistent results across all the tools: 1) the totals of Rx are around a few Kb; 2) no connection/packet stream justifies that. All of this with a Netgear WDNA 4100 wireless usb adapter using a custom driver from some git (the only way I got it to work). This might be malware, but I suspect the driver is simply reporting wrong totals. Nevertheless, I cannot explain what's going on for sure. Anyway, thanks again.
– ricab
Feb 16 '14 at 18:29
Tcpdump doesn't help either. The 2 consistent results across all the tools: 1) the totals of Rx are around a few Kb; 2) no connection/packet stream justifies that. All of this with a Netgear WDNA 4100 wireless usb adapter using a custom driver from some git (the only way I got it to work). This might be malware, but I suspect the driver is simply reporting wrong totals. Nevertheless, I cannot explain what's going on for sure. Anyway, thanks again.
– ricab
Feb 16 '14 at 18:29
@ricab - sounds suspicious to me. Check to see if any malware installed modified versions of
tcpdump, modified versions could mask any actual traffic.– slm♦
Feb 16 '14 at 22:37
@ricab - sounds suspicious to me. Check to see if any malware installed modified versions of
tcpdump, modified versions could mask any actual traffic.– slm♦
Feb 16 '14 at 22:37
1
1
Nope, I verified my tcpdump with
debsums and, manually, against the web listed md5 and it's the original. Besides, this malware would have to have installed modified versions of netstat, iftop, nethogs, and iptraf as well to mask the traffic there. Unless the change was in a shared lib, but I just verified all libs I got with ldd /usr/sbin/tcpdump (from deb packages libssl1.0.0 libpcap0.8 libc6 zlib1g). So I can't see it as being due to malware, except if it was in the wifi driver itself, which I doubt (it's public code). But thanks any case– ricab
Feb 18 '14 at 21:49
Nope, I verified my tcpdump with
debsums and, manually, against the web listed md5 and it's the original. Besides, this malware would have to have installed modified versions of netstat, iftop, nethogs, and iptraf as well to mask the traffic there. Unless the change was in a shared lib, but I just verified all libs I got with ldd /usr/sbin/tcpdump (from deb packages libssl1.0.0 libpcap0.8 libc6 zlib1g). So I can't see it as being due to malware, except if it was in the wifi driver itself, which I doubt (it's public code). But thanks any case– ricab
Feb 18 '14 at 21:49
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f114803%2faccounting-for-proc-net-dev-reported-traffic%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Can you show exactly what you're talking about? How did you determine this number?
– slm♦
Feb 12 '14 at 0:33
@slm: I didn't calculate directly from /proc/net/dev, I relied on tools that get their data there and do the calculation. The exact number is not important, but if I
watch -n 0.2 'cat /proc/net/dev', I see the byte total constantly increasing. This is consistent with results from gnome-system-monitor, iptraf's "general interface statistics", bwm-ng, etc.– ricab
Feb 12 '14 at 9:53
tcpdump -n -i wlan0(or whatever the device is called) shows no traffic?– derobert
Jun 20 '14 at 20:37
@derobert: it does, but not nearly enough to cover the 6Kb/s total I get from several sources
– ricab
Jun 23 '14 at 9:49