Prosíme přihlašte se nebo zaregistrujte.

Přihlašte se svým uživatelským jménem a heslem.
Vaše pomoc je stále potřeba!

Autor Téma: Akademická síť - koleje Větrník Praha - iftop, příliš velký RX provoz  (Přečteno 2977 krát)

majakmp3

  • Aktivní člen
  • *
  • Příspěvků: 451
Xubuntu 11.10 - 64bit, 100MB Ethernet.
Síť používám pouze kvůli Internetu, přesto Xubuntu stále něco stahuje asi 200 KiB/s dat. Nevím odkud a nevím, co je to za data. Také netuším, kam se ukládají. Věcí, která by mohla z Netu něco tahat je pouze aplet počasí, ale ten nemůže mít takovouto režii.

1) iftop sice vrací údaje, ale některé se nezdají být příliš přesvědčivé
    údaje za posledních zhruba 10 minut:
    TX:       22,7 KB
    RX:      111 MB
    TOTAL: 111MB
    Tyto údaje vcelku sedí s tím, co tvrdí conky a gnome-system-monitor , další údaje jsou však "zvláštní".
  • seznam PC v síti - asi 50 položek
  • seznam IP, které vykazují nějakou aktivitu - asi 9
  • pouze 3 IP adresy s provozem větším než 1Kb/S (2.44Kb 5.48Kb 1.28Kb) - přesto je průměrný příchozí provoz 200 KB/s

Podobnou věc jsem už jednou řešil zde: http://forum.ubuntu.cz/index.php?topic=56252.msg402051#msg402051, ale bez úspěchu.

PS: umí iftop ukládat data do logu a jak na to?

PS2: Dá se síť nastavit tak, abych ji využíval pouze pro Internet, tedy abych vůbec nepoužíval procházení sítí, sdílení, ... v této části bude, dle mého soudu, zakopaný pes. (v síti jsou 3 Jablečné stroje - jako anonymní uživatel toho moc nevidím a hesla neznám, síť windows, která většinou vrací hlášku "ze serveru se nepodařilo získat seznam sdílení". Někdy však ukáže několik podsítí a několik (desítky) strojů - většina sdílí složku shared s ničím nebo pouze brakem, několik uživatelů aktivně nabízí něco ke stažení a pár exotů dokonce sdílí vše. Tohle mi však k ničemu není, a rád bych se toho zbavil, protože podvědomě tuším, že toto je příčinou neustálého proudu příchozích dat.

PS3: Pokusně jsem najel do Live OpenSUSE 12.1 KDE a Systém vykazuje stejný příval příchozích dat ( Online asi 10 min. TX:  2 MB (díval jsem se na web) RX: 156 MB PROČ???
« Poslední změna: 23 Března 2012, 00:24:21 od majakmp3 »

jmp

  • Host
asi je cas nekoukat na kvanta, ale na obsah
takze pouzijte treba tcpdump, wireshark nebo tak neco...

ntz_reloaded

  • Lokaj
  • Závislák
  • ***
  • Příspěvků: 3735
  • skill :: ur home erly
lsof a netstat ti reknou jake jsou navazana spojeni
tikejte mi, taky Vam tikam ...
song of the day - openSUSE, openindiana, DuckDuckGo
The noise ain't noise anymore, who's to blame, WHO'S TO BLAME ??

beer

  • Host
možná by nebylo na škodu si nastavit firewall.

majakmp3

  • Aktivní člen
  • *
  • Příspěvků: 451
možná by nebylo na škodu si nastavit firewall.
Nastavení firewallu nepomohlo, ale objasnilo příčinu. Firewall mam standartně zapnutý. Pro nastavení pužívám Gufw 11.10.2. I když jsem zakázal VŠECHEN příchozí i odchozí traffic, tak přísun 200 KB/s kupodivu neustal (nastavení uloženo, dokonce jsem restartoval komp.)
Zjistil jsem však, že: 
viníkem je avahi-daemon

Jelikož tuto službu nevyužívám (viz. výše) použil jsem kouzelnou formuli:
Kód: [Vybrat]
sudo apt-get remove avahi-daemon a je vše vyřešeno.
Režije tohoto řešení 200KB/s (700MB /hod) je pro mě nepřijatelná.
« Poslední změna: 21 Března 2012, 18:01:00 od majakmp3 »

ntz_reloaded

  • Lokaj
  • Závislák
  • ***
  • Příspěvků: 3735
  • skill :: ur home erly
podle me si pletes jednotky a 200Kb/s to nemohlo bejt ..

ad.x) zareportoval jsi tento *kriticky bug ?
tikejte mi, taky Vam tikam ...
song of the day - openSUSE, openindiana, DuckDuckGo
The noise ain't noise anymore, who's to blame, WHO'S TO BLAME ??

majakmp3

  • Aktivní člen
  • *
  • Příspěvků: 451
podle me si pletes jednotky a 200Kb/s to nemohlo bejt ..

ad.x) zareportoval jsi tento *kriticky bug ?

Pleteme se určitě všichni, ale já mluvil (alespoň doufám) o 200KB/s, když vše vynásobíme počtem sekund a minut a výsledek vydělíme příslušným počtem 1024, tak by to mělo vycházet.

Tohle jsou skutečné hodnoty:
700 - 780 MB / hod bylo spolehlivě staženo vždy, když jsem nebyl na Netu (aplet počasí do toho nepočítám)
Po 10 hodinách provozu vždy pres 7GB přijatých dat. (pokud jsem nic cíleně nestahoval, nedíval se, neposlouchal, ... )

Bug jsem nereportoval - nebudu zkoumat, zda je problém shodu náhod, zda to má co dělat s integrovanou síťovkou nVidia,... . Je pravdou, že jsem stejný problém řešil, a tehdy nevyřešil, s Ubuntu 11.04. Viz. výš do stejných potíží jsem se na témže stroji a v téže síti dostal i s Live OpenSUSE 12.1 KDE (64 bit).
Jdu cestou nejmenšího odporu - avahi-daemon jsem odinstaloval a je po problému.

ntz_reloaded

  • Lokaj
  • Závislák
  • ***
  • Příspěvků: 3735
  • skill :: ur home erly
pozoruhodné
tikejte mi, taky Vam tikam ...
song of the day - openSUSE, openindiana, DuckDuckGo
The noise ain't noise anymore, who's to blame, WHO'S TO BLAME ??

jmp

  • Host
podle me si pletes jednotky a 200Kb/s to nemohlo bejt ..

ad.x) zareportoval jsi tento *kriticky bug ?

Pleteme se určitě všichni, ale já mluvil (alespoň doufám) o 200KB/s, když vše vynásobíme počtem sekund a minut a výsledek vydělíme příslušným počtem 1024, tak by to mělo vycházet.

Tohle jsou skutečné hodnoty:
700 - 780 MB / hod bylo spolehlivě staženo vždy, když jsem nebyl na Netu (aplet počasí do toho nepočítám)
Po 10 hodinách provozu vždy pres 7GB přijatých dat. (pokud jsem nic cíleně nestahoval, nedíval se, neposlouchal, ... )

Bug jsem nereportoval - nebudu zkoumat, zda je problém shodu náhod, zda to má co dělat s integrovanou síťovkou nVidia,... . Je pravdou, že jsem stejný problém řešil, a tehdy nevyřešil, s Ubuntu 11.04. Viz. výš do stejných potíží jsem se na témže stroji a v téže síti dostal i s Live OpenSUSE 12.1 KDE (64 bit).
Jdu cestou nejmenšího odporu - avahi-daemon jsem odinstaloval a je po problému.

tak to tam v te síti imho řádí nejakej trojan (dnschanger) a pokud to neřešíte a jste součástí problému, tak vás admini nakonec odfiknou od sítě
můžete adminům říct o tomto podezření a třeba to vyřeší za vás...

majakmp3

  • Aktivní člen
  • *
  • Příspěvků: 451
podle me si pletes jednotky a 200Kb/s to nemohlo bejt ..

ad.x) zareportoval jsi tento *kriticky bug ?

Pleteme se určitě všichni, ale já mluvil (alespoň doufám) o 200KB/s, když vše vynásobíme počtem sekund a minut a výsledek vydělíme příslušným počtem 1024, tak by to mělo vycházet.

Tohle jsou skutečné hodnoty:
700 - 780 MB / hod bylo spolehlivě staženo vždy, když jsem nebyl na Netu (aplet počasí do toho nepočítám)
Po 10 hodinách provozu vždy pres 7GB přijatých dat. (pokud jsem nic cíleně nestahoval, nedíval se, neposlouchal, ... )

Bug jsem nereportoval - nebudu zkoumat, zda je problém shodu náhod, zda to má co dělat s integrovanou síťovkou nVidia,... . Je pravdou, že jsem stejný problém řešil, a tehdy nevyřešil, s Ubuntu 11.04. Viz. výš do stejných potíží jsem se na témže stroji a v téže síti dostal i s Live OpenSUSE 12.1 KDE (64 bit).
Jdu cestou nejmenšího odporu - avahi-daemon jsem odinstaloval a je po problému.

tak to tam v te síti imho řádí nejakej trojan (dnschanger) a pokud to neřešíte a jste součástí problému, tak vás admini nakonec odfiknou od sítě
můžete adminům říct o tomto podezření a třeba to vyřeší za vás...

Nemyslím, že by to byl trojan. Musel by si totiž brousit drápky pouze a výhradně na Linux, čemuž se mi nechce věřit. Na sejném stroji mam v dual bootu i 32 bitové Visty home premium (legální) a tam problém s nadbytečným samovolným stahováním není a nikdy nebyl.

Petr Merlin Vaněček

  • Moderátor
  • Závislák
  • ***
  • Příspěvků: 5057
    • Lomítkáři
Neběží na té síti nějaký multicast nebo broadcast? Jak již zde bylo řečeno, bylo by možná lépe podívat se na obsah resp. na povahu spojení (na toto myslím postačí iptraf). Oba jmenované protokoly mají pěknou vlastnost a to, že "obtěžují" na RX i stroje, které si toto vlastně ani nepřejí (ale pro jistotu poslouchají) :)

PS: A windows tato data nekalkulují ...
Stiskni CTRL + W ...
80% mozku tvoří kapalina ... u některých brzdová

majakmp3

  • Aktivní člen
  • *
  • Příspěvků: 451
Neběží na té síti nějaký multicast nebo broadcast? Jak již zde bylo řečeno, bylo by možná lépe podívat se na obsah resp. na povahu spojení (na toto myslím postačí iptraf). Oba jmenované protokoly mají pěknou vlastnost a to, že "obtěžují" na RX i stroje, které si toto vlastně ani nepřejí (ale pro jistotu poslouchají) :)

PS: A windows tato data nekalkulují ...
Vypadá to, že tam nějaký multicast opravdu běží. Viz. malý kousek (1. sekunda) logu z iptrafu níže. Nějaký nápad, jak by se to dalo úplně zakázat? Přes firewall to nejde. I když dám zakázat veškerý traffic, tak příchozí pakety pořád naskakují. (Je to o moc lepší než s nainstalovaným avahi-daemonem předtím 600-680MB/hod. nyní 20-40MB/hod. což je pořád ještě hodně.) Navíc ty UDP přenosy jsou otevřené pokaždé na jiném portu.
Kód: [Vybrat]
Thu Mar 22 22:56:47 2012; UDP; eth0; 78 bytes; source MAC address 101f74e7db9b; from 78.128.179.81:netbios-ns to 78.128.179.255:netbios-ns
Thu Mar 22 22:56:47 2012; UDP; eth0; 72 bytes; source MAC address 00e04d92bc9c; from vetr-0470.koleje.cuni.cz:46932 to ajifs01.jinonice.cuni.cz:domain
Thu Mar 22 22:56:47 2012; UDP; eth0; 110 bytes; source MAC address 0011bb3ef2c8; from ajifs01.jinonice.cuni.cz:domain to vetr-0470.koleje.cuni.cz:46932
Thu Mar 22 22:56:47 2012; UDP; eth0; 78 bytes; source MAC address 002655bc926b; from 78.128.179.234:netbios-ns to 78.128.179.255:netbios-ns
Thu Mar 22 22:56:47 2012; UDP; eth0; 73 bytes; source MAC address 00e04d92bc9c; from vetr-0470.koleje.cuni.cz:55105 to ajifs01.jinonice.cuni.cz:domain
Thu Mar 22 22:56:47 2012; UDP; eth0; 111 bytes; source MAC address 0011bb3ef2c8; from ajifs01.jinonice.cuni.cz:domain to vetr-0470.koleje.cuni.cz:55105
Thu Mar 22 22:56:47 2012; UDP; eth0; 78 bytes; source MAC address 001e688546ae; from vetr-0333.koleje.cuni.cz:netbios-ns to 78.128.179.255:netbios-ns
Thu Mar 22 22:56:47 2012; UDP; eth0; 78 bytes; source MAC address 00235468a2d8; from 78.128.179.120:netbios-ns to 78.128.179.255:netbios-ns
Thu Mar 22 22:56:47 2012; UDP; eth0; 78 bytes; source MAC address 00235468a2d8; from 78.128.179.120:netbios-ns to 78.128.179.255:netbios-ns
Thu Mar 22 22:56:47 2012; UDP; eth0; 73 bytes; source MAC address 00e04d92bc9c; from vetr-0470.koleje.cuni.cz:50800 to ajifs01.jinonice.cuni.cz:domain
Thu Mar 22 22:56:47 2012; UDP; eth0; 111 bytes; source MAC address 0011bb3ef2c8; from ajifs01.jinonice.cuni.cz:domain to vetr-0470.koleje.cuni.cz:50800
Thu Mar 22 22:56:47 2012; IGMP; eth0; 46 bytes; source MAC address 0011bb3ef29b; from vetr-gw.koleje.cuni.cz to 239.255.0.4
Thu Mar 22 22:56:47 2012; UDP; eth0; 70 bytes; source MAC address 00e04d92bc9c; from vetr-0470.koleje.cuni.cz:56334 to ajifs01.jinonice.cuni.cz:domain
Thu Mar 22 22:56:47 2012; UDP; eth0; 78 bytes; source MAC address 001e8c523488; from 78.128.179.227:netbios-ns to 78.128.179.255:netbios-ns
Thu Mar 22 22:56:47 2012; UDP; eth0; 127 bytes; source MAC address 0011bb3ef2c8; from ajifs01.jinonice.cuni.cz:domain to vetr-0470.koleje.cuni.cz:56334
Thu Mar 22 22:56:47 2012; UDP; eth0; 73 bytes; source MAC address 00e04d92bc9c; from vetr-0470.koleje.cuni.cz:59291 to ajifs01.jinonice.cuni.cz:domain
Thu Mar 22 22:56:47 2012; UDP; eth0; 111 bytes; source MAC address 0011bb3ef2c8; from ajifs01.jinonice.cuni.cz:domain to vetr-0470.koleje.cuni.cz:59291
Thu Mar 22 22:56:47 2012; UDP; eth0; 78 bytes; source MAC address 001560b53f6b; from 78.128.179.226:netbios-ns to 78.128.179.255:netbios-ns
Thu Mar 22 22:56:47 2012; UDP; eth0; 73 bytes; source MAC address 00e04d92bc9c; from vetr-0470.koleje.cuni.cz:57955 to ajifs01.jinonice.cuni.cz:domain
Thu Mar 22 22:56:47 2012; UDP; eth0; 111 bytes; source MAC address 0011bb3ef2c8; from ajifs01.jinonice.cuni.cz:domain to vetr-0470.koleje.cuni.cz:57955
Thu Mar 22 22:56:47 2012; UDP; eth0; 229 bytes; source MAC address 0026183b611c; from vetr-0743.koleje.cuni.cz:netbios-dg to 78.128.179.255:netbios-dg
Thu Mar 22 22:56:47 2012; UDP; eth0; 229 bytes; source MAC address 0022646854e6; from 78.128.178.181:netbios-dg to 78.128.179.255:netbios-dg
Thu Mar 22 22:56:47 2012; UDP; eth0; 73 bytes; source MAC address 00e04d92bc9c; from vetr-0470.koleje.cuni.cz:51611 to ajifs01.jinonice.cuni.cz:domain
Thu Mar 22 22:56:47 2012; UDP; eth0; 111 bytes; source MAC address 0011bb3ef2c8; from ajifs01.jinonice.cuni.cz:domain to vetr-0470.koleje.cuni.cz:51611
Thu Mar 22 22:56:47 2012; UDP; eth0; 78 bytes; source MAC address 0016cba5f75c; from 78.128.176.207:60929 to 78.128.179.255:netbios-ns
Thu Mar 22 22:56:47 2012; UDP; eth0; 73 bytes; source MAC address 00e04d92bc9c; from vetr-0470.koleje.cuni.cz:52779 to ajifs01.jinonice.cuni.cz:domain
Thu Mar 22 22:56:47 2012; UDP; eth0; 111 bytes; source MAC address 0011bb3ef2c8; from ajifs01.jinonice.cuni.cz:domain to vetr-0470.koleje.cuni.cz:52779
Thu Mar 22 22:56:47 2012; UDP; eth0; 78 bytes; source MAC address 485b3962e809; from 78.128.176.236:netbios-ns to 78.128.179.255:netbios-ns
Thu Mar 22 22:56:47 2012; UDP; eth0; 73 bytes; source MAC address 00e04d92bc9c; from vetr-0470.koleje.cuni.cz:50771 to ajifs01.jinonice.cuni.cz:domain
Thu Mar 22 22:56:47 2012; UDP; eth0; 111 bytes; source MAC address 0011bb3ef2c8; from ajifs01.jinonice.cuni.cz:domain to vetr-0470.koleje.cuni.cz:50771
Thu Mar 22 22:56:47 2012; UDP; eth0; 147 bytes; source MAC address bcaec514e75b; from 78.128.176.71:mdns to 224.0.0.251:mdns
Thu Mar 22 22:56:47 2012; UDP; eth0; 72 bytes; source MAC address 00e04d92bc9c; from vetr-0470.koleje.cuni.cz:42498 to ajifs01.jinonice.cuni.cz:domain
Thu Mar 22 22:56:47 2012; UDP; eth0; 70 bytes; source MAC address 00e04d92bc9c; from vetr-0470.koleje.cuni.cz:55522 to ajifs01.jinonice.cuni.cz:domain
Thu Mar 22 22:56:47 2012; UDP; eth0; 110 bytes; source MAC address 0011bb3ef2c8; from ajifs01.jinonice.cuni.cz:domain to vetr-0470.koleje.cuni.cz:42498
Thu Mar 22 22:56:47 2012; UDP; eth0; 78 bytes; source MAC address 001d925297ee; from vetr-0152.koleje.cuni.cz:netbios-ns to 78.128.179.255:netbios-ns
Thu Mar 22 22:56:47 2012; UDP; eth0; 78 bytes; source MAC address 0018f3e63a8b; from 78.128.178.175:netbios-ns to 78.128.179.255:netbios-ns
Thu Mar 22 22:56:47 2012; UDP; eth0; 73 bytes; source MAC address 00e04d92bc9c; from vetr-0470.koleje.cuni.cz:39652 to ajifs01.jinonice.cuni.cz:domain
Thu Mar 22 22:56:47 2012; UDP; eth0; 111 bytes; source MAC address 0011bb3ef2c8; from ajifs01.jinonice.cuni.cz:domain to vetr-0470.koleje.cuni.cz:39652
Thu Mar 22 22:56:47 2012; UDP; eth0; 127 bytes; source MAC address 0011bb3ef2c8; from ajifs01.jinonice.cuni.cz:domain to vetr-0470.koleje.cuni.cz:55522
Thu Mar 22 22:56:47 2012; UDP; eth0; 239 bytes; source MAC address f04da286ce96; from 78.128.178.152:netbios-dg to 78.128.179.255:netbios-dg
Thu Mar 22 22:56:47 2012; UDP; eth0; 73 bytes; source MAC address 00e04d92bc9c; from vetr-0470.koleje.cuni.cz:36903 to ajifs01.jinonice.cuni.cz:domain
Thu Mar 22 22:56:47 2012; UDP; eth0; 111 bytes; source MAC address 0011bb3ef2c8; from ajifs01.jinonice.cuni.cz:domain to vetr-0470.koleje.cuni.cz:36903
Thu Mar 22 22:56:47 2012; UDP; eth0; 1356 bytes; source MAC address 000bcd4eda6d; from 78.128.179.3:56426 to 239.255.0.3:1982
Thu Mar 22 22:56:47 2012; UDP; eth0; 1356 bytes; source MAC address 000bcd4eda6d; from 78.128.179.3:56426 to 239.255.0.3:1982
Thu Mar 22 22:56:47 2012; UDP; eth0; 71 bytes; source MAC address 00e04d92bc9c; from vetr-0470.koleje.cuni.cz:53352 to ajifs01.jinonice.cuni.cz:domain
Thu Mar 22 22:56:47 2012; UDP; eth0; 70 bytes; source MAC address 00e04d92bc9c; from vetr-0470.koleje.cuni.cz:54843 to ajifs01.jinonice.cuni.cz:domain
Thu Mar 22 22:56:47 2012; UDP; eth0; 106 bytes; source MAC address 0011bb3ef2c8; from ajifs01.jinonice.cuni.cz:domain to vetr-0470.koleje.cuni.cz:53352
Thu Mar 22 22:56:47 2012; UDP; eth0; 1356 bytes; source MAC address 000bcd4eda6d; from eliska.koleje.cuni.cz:56426 to 239.255.0.3:1982
Thu Mar 22 22:56:47 2012; UDP; eth0; 78 bytes; source MAC address 101f74e7db9b; from vetr-0840.koleje.cuni.cz:netbios-ns to 78.128.179.255:netbios-ns
Thu Mar 22 22:56:47 2012; UDP; eth0; 1356 bytes; source MAC address 000bcd4eda6d; from eliska.koleje.cuni.cz:56426 to 239.255.0.3:1982
Thu Mar 22 22:56:47 2012; UDP; eth0; 1356 bytes; source MAC address 000bcd4eda6d; from eliska.koleje.cuni.cz:56426 to 239.255.0.3:1982
Thu Mar 22 22:56:47 2012; UDP; eth0; 1356 bytes; source MAC address 000bcd4eda6d; from eliska.koleje.cuni.cz:56426 to 239.255.0.3:1982
Thu Mar 22 22:56:47 2012; UDP; eth0; 1356 bytes; source MAC address 000bcd4eda6d; from eliska.koleje.cuni.cz:56426 to 239.255.0.3:1982
Thu Mar 22 22:56:47 2012; UDP; eth0; 1356 bytes; source MAC address 000bcd4eda6d; from eliska.koleje.cuni.cz:56426 to 239.255.0.3:1982
Thu Mar 22 22:56:47 2012; UDP; eth0; 1356 bytes; source MAC address 000bcd4eda6d; from eliska.koleje.cuni.cz:56426 to 239.255.0.3:1982
Thu Mar 22 22:56:47 2012; UDP; eth0; 127 bytes; source MAC address 0011bb3ef2c8; from ajifs01.jinonice.cuni.cz:domain to vetr-0470.koleje.cuni.cz:54843
Thu Mar 22 22:56:47 2012; UDP; eth0; 78 bytes; source MAC address 002655bc926b; from vetr-0993.koleje.cuni.cz:netbios-ns to 78.128.179.255:netbios-ns
Thu Mar 22 22:56:47 2012; UDP; eth0; 78 bytes; source MAC address 001e688546ae; from vetr-0333.koleje.cuni.cz:netbios-ns to 78.128.179.255:netbios-ns
Thu Mar 22 22:56:47 2012; UDP; eth0; 223 bytes; source MAC address 001d721da687; from 78.128.178.146:netbios-dg to 78.128.179.255:netbios-dg
Thu Mar 22 22:56:47 2012; UDP; eth0; 73 bytes; source MAC address 00e04d92bc9c; from vetr-0470.koleje.cuni.cz:34465 to ajifs01.jinonice.cuni.cz:domain
Thu Mar 22 22:56:47 2012; UDP; eth0; 111 bytes; source MAC address 0011bb3ef2c8; from ajifs01.jinonice.cuni.cz:domain to vetr-0470.koleje.cuni.cz:34465
Thu Mar 22 22:56:47 2012; UDP; eth0; 78 bytes; source MAC address 00235468a2d8; from vetr-0879.koleje.cuni.cz:netbios-ns to 78.128.179.255:netbios-ns
Thu Mar 22 22:56:47 2012; UDP; eth0; 78 bytes; source MAC address 00235468a2d8; from vetr-0879.koleje.cuni.cz:netbios-ns to 78.128.179.255:netbios-ns
« Poslední změna: 23 Března 2012, 00:30:38 od majakmp3 »

 

Provoz zaštiťuje spolek OpenAlt.