Bug 47 - Tcpdump does not work properly
: Tcpdump does not work properly
Status: RESOLVED FIXED
Product: Desktop Bugs
Classification: ROSA Desktop
Component: Main Packages
: Marathon
: i586 Linux
: Normal enhancement
: ---
Assigned To: ROSA Linux Bugs
: ROSA Linux Bugs
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-14 02:34 MSD by Postnikov Dmitry
Modified: 2012-04-18 01:21 MSD (History)
2 users (show)

See Also:
RPM Package: tcpdump-4.1.1-5-mdv2011.0.i586
ISO-related:
Bad POT generating:
Upstream:


Attachments
Tcpdump does not work properly (73.67 KB, image/png)
2012-04-14 02:34 MSD, Postnikov Dmitry
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Postnikov Dmitry 2012-04-14 02:34:34 MSD
Created attachment 21 [details]
Tcpdump does not work properly

EN:
Description of problem:
Ttspdump not work correctly. After you Ctrl+C displays statistics about the packets, but the number of packets received almost equal to the number of packets dropped by the kernel. In 2011 ROSA it work all fine. (See the attached file)

RU:
Description of problem:
Некорректно работает tcpdump. После нажатия Ctrl+C выводится статистика о пакетах, но количество принятых пакетов почти равно количеству отвергнутых пакетов ядром. В РОСА 2011 ЕЕ работало все отлично. (См.аттач)

Version-Release number of selected component (if applicable):
tcpdump-4.1.1-5-mdv2011.0.i586

How reproducible:


Steps to Reproduce:
1.
2.
3.
Comment 1 Aleksandr Kazantcev 2012-04-14 10:42:22 MSD
It's not confirmed for me.

Try enable and disable firewall.
Comment 2 Postnikov Dmitry 2012-04-15 01:30:47 MSD
I disabled the firewall. But it does not help.
Ping produces no output on the screen and tcpdump too.
--------------
[root@mindlife dima]# service iptables stop
Stopping iptables (via systemctl):                                                                [  OK  ]
[root@mindlife dima]# chkconfig iptables off
[root@mindlife dima]# 
[root@mindlife dima]# ping mail.ru
PING mail.ru (94.100.191.203) 56(84) bytes of data.
^C64 bytes from 94.100.191.203: icmp_req=1 ttl=58 time=15.2 ms

--- mail.ru ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 15.236/15.236/15.236/0.000 ms
[root@mindlife dima]# tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
^C01:18:48.957484 IP 192.168.1.1 > all-systems.mcast.net: igmp query v3

1 packets captured
124 packets received by filter
93 packets dropped by kernel
[root@mindlife dima]#
-----------------
Comment 3 Denis Silakov 2012-04-16 10:26:37 MSD
Try to run 'tcpdump -n'.

It's likely that this will decrease number of dropped packats significantly. If so, then your problem is a side effect of bug #46 (DNS Lookup problems).

I'm pretty sure that tcpdump works correctly, but drops packets to do DNS lookup problems.
Comment 4 Postnikov Dmitry 2012-04-16 10:35:48 MSD
In the 225th (test) iso image and it works! Apparently something changed. Everything works and ping and tcpdump.
Comment 5 Postnikov Dmitry 2012-04-17 22:21:22 MSD
In the 240th (test) iso image and it NOT works! Everything NOT works and ping and tcpdump and traceroute.
Firewall is worked for default. Incidentally, the MCC shows that the firewall is disabled.

I'm disabled the firewall:

service iptables stop
chkconfig iptables off

And did not help. Still not working.
Comment 6 Aleksandr Kazantcev 2012-04-17 22:32:28 MSD
240 iso. run

ping www.ya.ru - work
tcpdump - work
tracepatch - work

in network part NOTHING been changed within 225 and 240 iso - only kernel.

a you test in live mode or installed system?

Is there somebody who hase similar problem?
Comment 7 Postnikov Dmitry 2012-04-17 22:42:16 MSD
I tested in installed system.

I do not know anyone with this problem because they do not talk. It should ask other testers.

EN:
Packets arriving on the network first processed by the kernel. Next is a firewall, and then the other programs. Therefore, most likely the problem I have a nucleus. Or in the network card driver incompatibility and the nucleus. But I tested it on two computers with different network cards + wifi.

RU:
Пакеты приходящие по сети первым обрабатываются ядром. Далее уже файрволом и потом уже остальными программами. Поэтому, скорее всего проблема я ядре. Или в несовместимости драйвера сетевой карты и ядра. Но я тестировал на ДВУХ компьютерах с разными сетевыми картами + wifi.
Comment 8 Aleksandr Kazantcev 2012-04-17 22:50:27 MSD
All problem start with DNS. For me it's problem for provider or router.

I don't know why all work for me and other people and not work for you. I have three working machine at home, has a latest package base ROSA 2012 Marathon. All wi-fi and network card work ok and no problem with DNS, ping and other. 

Try add to /etc/resolv.conf

nameserver 8.8.8.8
nameserver 8.8.4.4

give us output for

ifconfig
lspci
Comment 9 Denis Silakov 2012-04-17 22:54:30 MSD
I have met a similar problem when running LSB tests on LTS Beta. More particular, I had problems with significant delays in 'gethostbyaddr' function. At that time I though that this was caused by recent changes in our network infrastructure (just at that time we had a series of interesting things happening with our internal DNS).

However, this behavior can be affected by kernel changes, since gethostbyaddr (and tcpdump which uses it) heavily relies on kernel-level components. I'll try to carry out more experiments and see if I can reproduce this on recent images.

One more thing I would ask is about hostname configuration - is hostname set to 'localhost' or to 'localhost.localdomain' in both test cases? It seems that setting hostname to something with a dot can cause significant delays in gethostaddr, as well.
Comment 10 Postnikov Dmitry 2012-04-17 23:20:34 MSD
EN:
I myself have been working with the provider, or rather in the company ISP. Each day confronted with different problems with network users and solve them. :)
But in this case, the problem (I think) is in the kernel, since the images changed the kernel. And yet, with the same settings and the router's DNS LiveCD Fedora works Windows works and ROSA 2012 (190th, 225th) iso images of the work, but the 218th and 240th does not work properly.
So for me it is important to efficient work of the network components.

RU:
Я сам работаю у провайдера, точнее в фирме ИСП. Каждый день сталкиваюсь с разными проблемами сети у пользователей и решаю их. :)
Но в данном случае, проблема (мне кажется) именно в ядре, так как с образами меялось только ядро. И еще, с теми же настройками роутера и ДНС ливСВ Федора работает, Виндойс роаботает, и РОСА 2012 (190й, 225й) образы работают, а 218й и 240й образы НЕ работают.
Для меня важно чтобы сетевые компоненты работали отлично.

----------
[root@mindlife etc]# cat hosts
# generated by drakconnect
127.0.0.1 mindlife
127.0.0.1 localhost
127.0.0.1 localhost.localdomain
::1 localhost6.localdomain6 localhost6
[root@mindlife etc]#
----------
[root@mindlife dima]# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:19:66:E5:26:C4  
          inet addr:192.168.1.2  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::219:66ff:fee5:26c4/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1561 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1911 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:912066 (890.6 KiB)  TX bytes:624573 (609.9 KiB)
          Interrupt:41 Base address:0xe000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

[root@mindlife dima]#
------------
[root@mindlife dima]# lspci
00:00.0 RAM memory: nVidia Corporation MCP78S [GeForce 8200] Memory Controller (rev a2)
00:01.0 ISA bridge: nVidia Corporation MCP78S [GeForce 8200] LPC Bridge (rev a2)
00:01.1 SMBus: nVidia Corporation MCP78S [GeForce 8200] SMBus (rev a1)
00:01.2 RAM memory: nVidia Corporation MCP78S [GeForce 8200] Memory Controller (rev a1)
00:01.3 Co-processor: nVidia Corporation MCP78S [GeForce 8200] Co-Processor (rev a2)
00:01.4 RAM memory: nVidia Corporation MCP78S [GeForce 8200] Memory Controller (rev a1)
00:02.0 USB controller: nVidia Corporation MCP78S [GeForce 8200] OHCI USB 1.1 Controller (rev a1)
00:02.1 USB controller: nVidia Corporation MCP78S [GeForce 8200] EHCI USB 2.0 Controller (rev a1)
00:04.0 USB controller: nVidia Corporation MCP78S [GeForce 8200] OHCI USB 1.1 Controller (rev a1)
00:04.1 USB controller: nVidia Corporation MCP78S [GeForce 8200] EHCI USB 2.0 Controller (rev a1)
00:06.0 IDE interface: nVidia Corporation MCP78S [GeForce 8200] IDE (rev a1)
00:07.0 Audio device: nVidia Corporation MCP72XE/MCP72P/MCP78U/MCP78S High Definition Audio (rev a1)
00:08.0 PCI bridge: nVidia Corporation MCP78S [GeForce 8200] PCI Bridge (rev a1)
00:09.0 IDE interface: nVidia Corporation MCP78S [GeForce 8200] SATA Controller (non-AHCI mode) (rev a2)
00:0a.0 Ethernet controller: nVidia Corporation MCP77 Ethernet (rev a2)
00:0b.0 PCI bridge: nVidia Corporation MCP78S [GeForce 8200] PCI Express Bridge (rev a1)
00:10.0 PCI bridge: nVidia Corporation MCP78S [GeForce 8200] PCI Express Bridge (rev a1)
00:12.0 PCI bridge: nVidia Corporation MCP78S [GeForce 8200] PCI Express Bridge (rev a1)
00:13.0 PCI bridge: nVidia Corporation MCP78S [GeForce 8200] PCI Bridge (rev a1)
00:14.0 PCI bridge: nVidia Corporation MCP78S [GeForce 8200] PCI Bridge (rev a1)
00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor HyperTransport Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Miscellaneous Control
00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Link Control
02:00.0 VGA compatible controller: nVidia Corporation C77 [GeForce 8200] (rev a2)
[root@mindlife dima]#
-----------------
Comment 11 Aleksandr Kazantcev 2012-04-17 23:28:02 MSD
Why you use drakconnect?

Delete ALL from hosts and give us output from /etc/hostname.

Then try change hostname for similar, as 'computer6' and try.

And what is in you /etc/resolv.conf?
Comment 12 Postnikov Dmitry 2012-04-17 23:29:40 MSD
Pardon! In 190th and 218th iso image is work. But in 225th and 240th do NOT work.
Comment 13 Postnikov Dmitry 2012-04-17 23:45:10 MSD
RU:
Я пользуюсь NetworkManager'ом.
Удалил все из hosts и поставил "computer6", сделал перезагрузку. Не помогает.

EN:
I use NetworkManager.
Removed all of the hosts and put "computer6", did a reboot. It does not help.

192.168.1.1 - this router. The router receives DNS:
217.71.224.66 and 217.71.225.66

--------
[root@mindlife dima]# cat /etc/hosts
# generated by drakconnect
127.0.0.1 computer6
[root@mindlife dima]# 
[root@mindlife dima]# cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 192.168.1.1
[root@mindlife dima]#

--------

[root@mindlife dima]# nslookup
> server 217.71.224.66
Default server: 217.71.224.66
Address: 217.71.224.66#53
> mail.ru
Server:         217.71.224.66
Address:        217.71.224.66#53

Non-authoritative answer:
Name:   mail.ru
Address: 94.100.191.202
Name:   mail.ru
Address: 94.100.191.203
Name:   mail.ru
Address: 94.100.191.204
Name:   mail.ru
Address: 94.100.191.201
> exit

[root@mindlife dima]#
---------------------
Comment 14 Postnikov Dmitry 2012-04-17 23:47:53 MSD
to Alex Kazancev:

>Try add to /etc/resolv.conf
>
>nameserver 8.8.8.8
>nameserver 8.8.4.4
>

When i change the data in this file, reboot NetworkManader automatically change them back.
Comment 15 Postnikov Dmitry 2012-04-17 23:59:00 MSD
RU:
Удалил все из hosts и поставил "localhost", сделал перезагрузку. Не помогает.

EN:
Removed all of the hosts and put "localhost", did a reboot. It does not help.
Comment 16 Aleksandr Kazantcev 2012-04-18 00:00:06 MSD
You need change name for computer by hand (from root) in 

/etc/hostname 

file.

What's output for this file?
Comment 17 Postnikov Dmitry 2012-04-18 00:05:35 MSD
I change by hand (from root) and reboot. Doesn't work. 
-------
[root@mindlife dima]# cat /etc/hostname
localhost
[root@mindlife dima]# cat /etc/hosts
# generated by drakconnect
127.0.0.1 localhost
[root@mindlife dima]#
-------
Comment 18 Aleksandr Kazantcev 2012-04-18 00:17:37 MSD
ping 192.168.1.1 work?

and

tracepath 192.168.1.1

?
Comment 19 Postnikov Dmitry 2012-04-18 00:27:18 MSD
What is Avahi service? mDNS? It not work.

In /var/log/
---------------
root@mindlife log]# cat kernel/info.log | grep avahi
Apr 17 01:52:42 localhost systemd[1]: avahi-daemon.service: main process exited, code=exited, status=255
Apr 17 01:52:42 localhost systemd[1]: Unit avahi-daemon.service entered failed state.
Apr 17 01:57:41 localhost systemd[1]: avahi-daemon.service: main process exited, code=exited, status=255
Apr 17 01:57:41 localhost systemd[1]: Unit avahi-daemon.service entered failed state.
Apr 17 01:58:34 localhost systemd[1]: avahi-daemon.service: main process exited, code=exited, status=255
Apr 17 01:58:34 localhost systemd[1]: Unit avahi-daemon.service entered failed state.
Apr 17 02:07:34 localhost systemd[1]: avahi-daemon.service: main process exited, code=exited, status=255
Apr 17 02:07:34 localhost systemd[1]: Unit avahi-daemon.service entered failed state.
........
-------------

[root@mindlife log]# cat daemons/info.log | grep avahi
Apr 17 22:54:27 localhost dbus-daemon[1846]: Unknown username "avahi" in message bus configuration file
Apr 17 22:54:27 localhost dbus-daemon[1846]: Unknown group "avahi" in message bus configuration file
Apr 17 23:44:57 localhost dbus-daemon[1802]: Unknown username "avahi" in message bus configuration file
Apr 17 23:44:57 localhost dbus-daemon[1802]: Unknown group "avahi" in message bus configuration file
[root@mindlife log]#
-------------

[root@mindlife log]# cat daemons/errors.log | grep avahi
Apr 17 01:52:42 localhost avahi-daemon[2460]: Failed to find user 'avahi'.
Apr 17 01:57:41 localhost avahi-daemon[2427]: Failed to find user 'avahi'.
Apr 17 01:58:34 localhost avahi-daemon[3143]: Failed to find user 'avahi'.
Apr 17 02:07:34 localhost avahi-daemon[2514]: Failed to find user 'avahi'.
Apr 17 14:03:54 localhost avahi-daemon[2509]: Failed to find user 'avahi'.
Apr 17 19:04:50 localhost avahi-daemon[2351]: Failed to find user 'avahi'.
Apr 17 19:05:15 localhost avahi-daemon[3388]: Failed to find user 'avahi'.
Apr 17 20:37:56 localhost avahi-daemon[25082]: Failed to find user 'avahi'.
Apr 17 20:37:56 localhost avahi-daemon[25086]: Failed to find user 'avahi'.
-------------

[root@mindlife log]# cat daemons/info.log | grep avahi
Apr 17 22:54:27 localhost dbus-daemon[1846]: Unknown username "avahi" in message bus configuration file
Apr 17 22:54:27 localhost dbus-daemon[1846]: Unknown group "avahi" in message bus configuration file
Apr 17 23:44:57 localhost dbus-daemon[1802]: Unknown username "avahi" in message bus configuration file
Apr 17 23:44:57 localhost dbus-daemon[1802]: Unknown group "avahi" in message bus configuration file
[root@mindlife log]#
---------------

[root@mindlife kernel]# cat warnings.log | grep avahi
Apr 17 20:37:56 localhost systemd[1]: avahi-daemon.service start request repeated too quickly, refusing to start.
Apr 17 22:48:33 localhost systemd[1]: avahi-daemon.service start request repeated too quickly, refusing to start.
Apr 17 22:59:13 localhost systemd[1]: avahi-daemon.service start request repeated too quickly, refusing to start.
Apr 17 23:31:45 localhost systemd[1]: avahi-daemon.service start request repeated too quickly, refusing to start.
Apr 17 23:47:47 localhost systemd[1]: avahi-daemon.service start request repeated too quickly, refusing to start.
[root@mindlife kernel]#
----------------
Comment 20 Aleksandr Kazantcev 2012-04-18 00:30:36 MSD
urpmi --replacepkg avahi

then reboot
Comment 21 Postnikov Dmitry 2012-04-18 00:38:58 MSD
1. ping 192.168.1.1 work
2. tracepath 192.168.1.1 work

My DNS
3. ping 217.71.224.66 work
4. tracepath 217.71.224.66 not work
5. traceroute 217.71.224.66 not work

6. ping ya.ru work
7. traceroute ya.ru not work

8. ping mail.ru not work
9. traceroute mail.ru not work

In LiveCD Fedora 16:
1, 2, 3, 4, 5, 6, 7, 9 - all work. Why is work, in rosa doesn't work?

And... But tcpdump does not depend on the provider.
Comment 22 Postnikov Dmitry 2012-04-18 00:46:17 MSD
WOW!! It fine!!!

All service is WORK! And ping and tcproute and tcpdump!!

TANKS!! :)
I will continue to test 240th iso ...
Comment 23 Postnikov Dmitry 2012-04-18 00:51:23 MSD
Reinstalled avahi:
urpmi --replacepkg avahi
And reboot. 
All WORKS!! :) But first line in ping many time. And time computer boots (KDE) in speed!!
Comment 24 Aleksandr Kazantcev 2012-04-18 00:55:45 MSD
Problem with start avahi daemon is known and will be fixed in future ISO. If all work, bug will be close as resolved. You may open it later if problem will appear again.
Comment 25 Postnikov Dmitry 2012-04-18 01:21:52 MSD
OK
And it is necessary to close the bug 46.
http://bugs.rosalinux.ru/show_bug.cgi?id=46