| Summary: | Tcpdump does not work properly | ||
|---|---|---|---|
| Product: | [ROSA-based products] ROSA Fresh | Reporter: | Postnikov Dmitry <dmitry.postnikov> |
| Component: | Packages from Main | Assignee: | ROSA Linux Bugs <bugs> |
| Status: | RESOLVED FIXED | QA Contact: | ROSA Linux Bugs <bugs> |
| Severity: | enhancement | ||
| Priority: | Normal | CC: | alexander.kazantsev, denis.silakov |
| Version: | Marathon | ||
| Target Milestone: | --- | ||
| Hardware: | i586 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Platform: | --- | ROSA Vulnerability identifier: | |
| RPM Package: | tcpdump-4.1.1-5-mdv2011.0.i586 | ISO-related: | |
| Bad POT generating: | Upstream: | ||
| Attachments: | Tcpdump does not work properly | ||
It's not confirmed for me. Try enable and disable firewall. 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]# ----------------- 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. In the 225th (test) iso image and it works! Apparently something changed. Everything works and ping and tcpdump. 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. 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? 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. 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 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. 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]#
-----------------
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? Pardon! In 190th and 218th iso image is work. But in 225th and 240th do NOT work. 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]# --------------------- 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. RU: Удалил все из hosts и поставил "localhost", сделал перезагрузку. Не помогает. EN: Removed all of the hosts and put "localhost", did a reboot. It does not help. You need change name for computer by hand (from root) in /etc/hostname file. What's output for this file? 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]# ------- ping 192.168.1.1 work? and tracepath 192.168.1.1 ? 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]# ---------------- urpmi --replacepkg avahi then reboot 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. WOW!! It fine!!! All service is WORK! And ping and tcproute and tcpdump!! TANKS!! :) I will continue to test 240th iso ... Reinstalled avahi: urpmi --replacepkg avahi And reboot. All WORKS!! :) But first line in ping many time. And time computer boots (KDE) in speed!! 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. OK And it is necessary to close the bug 46. http://bugs.rosalinux.ru/show_bug.cgi?id=46 |
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.