abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
včera 22:44 | Komunita

Joinup informuje, že Mnichov používá open source groupware Kolab. V srpnu byl dokončen dvouletý přechod na toto řešení. V provozu je asi 60 000 poštovních schránek. Nejenom Kolabu se věnoval Georg Greve ve své přednášce Open Source: the future for the European institutions (SlideShare) na konferenci DIGITEC 2016, jež proběhla v úterý 29. listopadu v Bruselu. Videozáznam přednášek z hlavního sálu je ke zhlédnutí na Livestreamu.

Ladislav Hagara | Komentářů: 1
včera 15:30 | Zajímavý projekt

Společnost Jolla oznámila v příspěvku Case study: Sailfish Watch na svém blogu, že naportovala Sailfish OS na chytré hodinky. Využila a inspirovala se otevřeným operačním systémem pro chytré hodinky AsteroidOS. Použita je knihovna libhybris. Ukázka ovládání hodinek na YouTube.

Ladislav Hagara | Komentářů: 5
včera 14:15 | Nová verze

Byla vydána verze 7.1.0 skriptovacího jazyka PHP používaného zejména k vývoji dynamických webových stránek. Jedná se o první stabilní verzi nejnovější větvě 7.1. Přehled novinek v dokumentaci. Podrobnosti v ChangeLogu. K dispozici je také příručka pro přechod z PHP 7.0.x na PHP 7.1.x.

Ladislav Hagara | Komentářů: 0
včera 12:55 | Nová verze

Google Chrome 55 byl prohlášen za stabilní. Nejnovější stabilní verze 55.0.2883.75 tohoto webového prohlížeče přináší řadu oprav a vylepšení (YouTube). Opraveno bylo také 36 bezpečnostních chyb. Mariusz Mlynski si například vydělal 22 500 dolarů za 3 nahlášené chyby (Universal XSS in Blink).

Ladislav Hagara | Komentářů: 4
včera 11:55 | Pozvánky

Máte rádi svobodný software a hardware nebo se o nich chcete něco dozvědět? Přijďte na 135. sraz spolku OpenAlt, který se bude konat ve čtvrtek 8. prosince od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Sraz bude tentokrát tématický. Bude retro! K vidění budou přístroje jako Psion 5mx nebo Palm Z22. Ze svobodného hardwaru pak Openmoko nebo čtečka WikiReader. Přijďte se i vy pochlubit svými legendami, nebo alespoň na pivo. Moderní hardware má vstup samozřejmě také povolen.

xkucf03 | Komentářů: 0
včera 00:10 | Nová verze

Byla vydána verze 3.2 svobodného systému pro detekci a prevenci průniků a monitorování bezpečnosti počítačových sítí Suricata. Z novinek lze zmínit například podporu protokolů DNP3 a CIP/ENIP, vylepšenou podporu TLS a samozřejmě také aktualizovanou dokumentaci.

Ladislav Hagara | Komentářů: 0
1.12. 21:00 | Nová verze

Byla vydána beta verze Linux Mintu 18.1 s kódovým jménem Serena. Na blogu Linux Mintu jsou hned dvě oznámení. První o vydání Linux Mintu s prostředím MATE a druhé o vydání Linux Mintu s prostředím Cinnamon. Stejným způsobem jsou rozděleny také poznámky k vydání (MATE, Cinnamon) a přehled novinek s náhledy (MATE, Cinnamon). Linux Mint 18.1 bude podporován až do roku 2021.

Ladislav Hagara | Komentářů: 0
1.12. 16:42 | Nová verze

Byl vydán Devuan Jessie 1.0 Beta 2. Jedná se o druhou beta verzi forku Debianu bez systemd představeného v listopadu 2014 (zprávička). První beta verze byla vydána v dubnu letošního roku (zprávička). Jedna z posledních přednášek věnovaných Devuanu proběhla v listopadu na konferenci FSCONS 2016 (YouTube, pdf).

Ladislav Hagara | Komentářů: 0
1.12. 15:16 | Komunita

Na GOG.com začal zimní výprodej. Řada zlevněných her běží oficiálně také na Linuxu. Hru Neverwinter Nights Diamond lze dva dny získat zdarma. Hra dle stránek GOG.com na Linuxu neběží. Pomocí návodu ji lze ale rozběhnout také na Linuxu [Gaming On Linux].

Ladislav Hagara | Komentářů: 1
1.12. 13:14 | Bezpečnostní upozornění

Byla vydána verze 2.7.1 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Řešeno je několik bezpečnostních problémů. Aktualizován byl především Tor Browser na verzi 6.0.7. Tor Browser je postaven na Firefoxu ESR (Extended Support Release) a právě ve Firefoxu byla nalezena a opravena vážná bezpečnostní chyba MFSA 2016-92 (CVE-2016-9079, Firefox SVG Animation

… více »
Ladislav Hagara | Komentářů: 0
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (24%)
 (29%)
 (7%)
 (5%)
 (3%)
Celkem 759 hlasů
 Komentářů: 50, poslední 29.11. 15:50
Rozcestník
Reklama

Dotaz: Výpadky připojení

13.6.2015 19:33 Martin
Výpadky připojení
Přečteno: 521×

Ahoj,

mám problém s připojením k internetu, resp. vypadává mi spojení.

Tento stroj slouží jako router (cca rok), cca před 14 dny jsem měl jeden problém, že mi to na jednom rozhraní způsobovalo chyby, protože jsem měl v záloze ještě jednu volnou síťovou kartu, tak jsem to předělal na tu druhou, ale po 14 dnech se to ozvala opět ta samá chyba. Ping z venkovní sítě na router, chvíli jede, chvíli zase ne:

64 bytes from 188-xxxxx.cz (188.xxx.xxx.xxx): icmp_seq=314 ttl=54 time=16.0 ms
64 bytes from 188-xxxxx.cz (188.xxx.xxx.xxx): icmp_seq=315 ttl=54 time=16.0 ms
From 188-xxxxx.cz (188.xxx.xxx.xxx) icmp_seq=323 Destination Host Unreachable
From 188-xxxxx.cz (188.xxx.xxx.xxx) icmp_seq=324 Destination Host Unreachable
From 188-xxxxx.cz (188.xxx.xxx.xxx) icmp_seq=325 Destination Host Unreachable
From 188-xxxxx.cz (188.xxx.xxx.xxx) icmp_seq=326 Destination Host Unreachable
From 188-xxxxx.cz (188.xxx.xxx.xxx) icmp_seq=327 Destination Host Unreachable
From 188-xxxxx.cz (188.xxx.xxx.xxx) icmp_seq=328 Destination Host Unreachable
From 188-xxxxx.cz (188.xxx.xxx.xxx) icmp_seq=329 Destination Host Unreachable
From 188-xxxxx.cz (188.xxx.xxx.xxx) icmp_seq=330 Destination Host Unreachable
From 188-xxxxx.cz (188.xxx.xxx.xxx) icmp_seq=331 Destination Host Unreachable
64 bytes from 188-xxxxx.cz (188.xxx.xxx.xxx): icmp_seq=332 ttl=54 time=16.4 ms
64 bytes from 188-xxxxx.cz (188.xxx.xxx.xxx): icmp_seq=333 ttl=54 time=15.9 ms
64 bytes from 188-xxxxx.cz (188.xxx.xxx.xxx): icmp_seq=334 ttl=54 time=15.8 ms
64 bytes from 188-xxxxx.cz (188.xxx.xxx.xxx): icmp_seq=335 ttl=54 time=16.4 ms

Jedná se připojení se staticky nastavenou IP adresou, zkoušel jsem kabeláž a ta se zdá být v pořádku (testováno notebookem). Myslíte, že by to mohlo být teplotou, sensors ukazuje:

M/B Temp:     +53.0°C  (low  = -127.0°C, high = +127.0°C)
temp3:        +76.5°C  (low  = -127.0°C, high = +127.0°C)

Disk (hddtemp) má teplotu 41°C

Myslíte, že už je to moc, nebo mám hledat chybu jinde? Pokud mě nakopnete směr kterým se mám vydat pro zjištění problém budu rád, já už fakt nevím co zkusit.

Odpovědi

Jendа avatar 13.6.2015 20:30 Jendа | skóre: 73 | blog: Výlevníček | JO70FB
Rozbalit Rozbalit vše Re: Výpadky připojení
Nemůže být chyba cestou? Co ping na poslední hop před routerem? Co ping z routeru na tento hop?
14.6.2015 07:39 Martin
Rozbalit Rozbalit vše Re: Výpadky připojení
Jako jistý si nejsem, ale když jsem posledně připojil ten notebook, tak jelo vše jak mělo. vrátil jsem to zpět do routeru a opět to bylo rozsekané, takže myslím že se musí prostě dít něco nekalého v něm. Ten ping vypadával také, bohužel nemůžu pingovat z routeru, když se na něj nepřipojím (je fyzicky daleko). Jak píšu momentálně to funguje dobře 0% ztrátovost, ale mám pocit, že když se to opravilo samo, tak se to opět vrátí jako i před těmi 7 dny.
13.6.2015 21:33 Milan Roubal | skóre: 25
Rozbalit Rozbalit vše Re: Výpadky připojení
Kdyz jsem podobne chovani resil naposled tak byly v siti 2 zarizeni se stejnou IP adresou.
14.6.2015 00:34 Martin
Rozbalit Rozbalit vše Re: Výpadky připojení
Je to veřejná IP adresa přidělena ISP, takže předpokládám, že tam snad nebude mít kolizi. Neodpovídalo by mi na ping to druhé "zařízení", pokud nemá blokované... Krom toho mi to s připojeným notebookem šlo (při tom minulém výpadku, jen nebyl před 14 dny ale 7, ale to je asi jedno).
13.6.2015 23:11 NN
Rozbalit Rozbalit vše Re: Výpadky připojení
Kde jsou pakety mezi ICMP sekvenci 315-323? Stracene/zahozene? Pakety dorazi/nedorazi na server? Odejdou, ze serveru, ale nevrati se? Pouzij tcpdump a over to.
14.6.2015 07:14 Martin
Rozbalit Rozbalit vše Re: Výpadky připojení
No problém je, že ten router(linux server) je fyzicky daleko ode mě, takže se k němu jen tak nepřipojím, když zrovna nejede. Ten ping je směrem k němu, chtěl jsem mít ukázku toho jak to vypadává. Jinak bez jakéhokoliv zásahu postupně k večeru klesala ztrátovost teď ráno byla na nule ale občas se taky ztratí do 1%.
14.6.2015 07:36 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Výpadky připojení
Tenhle výpis je k ničemu, protože v něm chybí IP adresy. Například je důležité, kdo odeslal Destination Host Unreachable.
14.6.2015 07:43 Martin
Rozbalit Rozbalit vše Re: Výpadky připojení
Ve výpisu je skrytá jen jedna IP adresa a to toho routeru.
14.6.2015 09:15 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Výpadky připojení

V tom případě někdo někde podvádí.

Destination Host Unreachable (ICMP typ 3, podtyp 1) se používá, když router nemůže odeslat packet stroji na lokální síti. V případě Ethernetu to znamená, že nemá jeho MAC adresu. Například když stroj je vypnutý. Pak ovšem ve výpisu pingu by jako zdrojová adresa chybovém zprávy byla adresa routeru, nikoliv nedosažitelného stroje.

Jinak řečeno, to že tam nemáte jinou adresu, je známkou, že váš ISP má rozbité svoje routery, nebo že váš stroj odesílá tuto chybovou zprávu zcela nesmyslně (sám o sobě tvrdí, že není dostupný), takže má třeba špatně nastavený firewall.

Poslední dobou vídávám takovéto zprávy z cloudových center, kdy se míchá dohromady linková a spojová vrtsva (například MACVLAN) a ještě do toho zasahuje překlad adres, který se snaží předstírat statické adresy.

Z časování zpráv to vypadá, že vše funguje, mezitím routeru ISP vyprší záznam s MAC adresou vašeho stroje, sedm sekund se poukouší přeložit ARPem adresu (to je to ticho), pak se mu to podaří a zase vše funguje.

Normálně se ARP dotaz pokládá ještě před vypršením záznamu, takže by to znamenalo, že zatímco packety s ICMP chodí, s ARP nechodí. To je docela blbost. Jedině že by někdo někde zahazoval broadcastové rámce. Nebo linka byla natolik ucpaná/zarušená, že projde jen pár packetů a zrovna to jsou ty s ICMP, ale žádný a ARP. To by se ale projevilo na náhodných ztrátách i ICMP, což z těch pár, co jsou ve výpisu, nevypadá.

Taky se normálně používá oportunistické učení MAC adres, takže když router ISP vidí ICMP rámce od vás, tak si z nich přečte MAC a nemusí se na ni znovu ptát. Tohle se tu také očividně neděje.

Tohle všechno jsou ale spekulace, které bez dalšího výzkumu nic neobjasní. Například logovat na vašem stroji ICMP a ARP, by bylo vidět, co přichází od ISP, když se vyskytne porucha, by bylo velmi vhodné.

14.6.2015 11:07 Martin
Rozbalit Rozbalit vše Re: Výpadky připojení
Příloha:
Já pinguji ten router (pc jako linuxem - NATem) přes internet. Momentálně se pohybuji se ztrátovostí kolem 10% :-/ Mám tam puštěný munin a ten neukazuje, nějaký abnormální trafic, ani počet spojení, pohybuje se to všechno v ročních průměrech, takže vytížené to asi nějak extra nebude, ale něco se asi stalo před těmi pár dny, když byl první výpadek, ale jestli je to něco co způsobuje tuto chybu nevím, viz. přiložený graf.

Jakým optimálním nástrojem logovat ať je to k něčemu použitelné?

Jendа avatar 14.6.2015 15:04 Jendа | skóre: 73 | blog: Výlevníček | JO70FB
Rozbalit Rozbalit vše Re: Výpadky připojení
Jakým optimálním nástrojem logovat ať je to k něčemu použitelné?
tcpdumpem, jak jinak. Pokud je to prehistorická verze, nezapomenout na parametr -s hodně.
14.6.2015 15:10 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Výpadky připojení
Agregované grafy jsou k ničemu. Potřebujete úplný záznam provozu z období chyby. To jest packet po packetu. Začít můžete s nástrojem tcpdump.
17.6.2015 12:27 Martin
Rozbalit Rozbalit vše Re: Výpadky připojení
Tak jsem trochu posledoval tcpdump a nezdají se mi tam nějaké věci, z veřejného rozhraní mi chodí nějaké dotazy s neveřejnou IP:
# tcpdump -i eth0|grep 192.168.
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:15:46.482933 IP 192.168.19.4.5678 > 255.255.255.255.5678: UDP, length 98
12:15:46.771615 IP 192.168.19.11.5678 > 255.255.255.255.5678: UDP, length 98
12:15:49.805162 IP 188-xxxxx.cz.3942 > 192.168.0.1.1900: Flags [S], seq 464587655, win 5840, options [mss 1460,sackOK,TS val 3653775 ecr 0,nop,wscale 1], length 0
12:15:49.809415 IP 188-xxxxx.cz.3033 > 192.168.0.1.1900: Flags [S], seq 453562137, win 5840, options [mss 1460,sackOK,TS val 3653431 ecr 0,nop,wscale 1], length 0
12:15:49.920191 IP 188-xxxxx.cz.3943 > 192.168.0.1.1900: Flags [S], seq 459674858, win 5840, options [mss 1460,sackOK,TS val 3653787 ecr 0,nop,wscale 1], length 0
12:15:49.932105 IP 188-xxxxx.cz.3034 > 192.168.0.1.1900: Flags [S], seq 464378535, win 5840, options [mss 1460,sackOK,TS val 3653443 ecr 0,nop,wscale 1], length 0
12:15:50.012810 IP 188-xxxxx.cz.3035 > 192.168.0.1.1900: Flags [S], seq 460494958, win 5840, options [mss 1460,sackOK,TS val 3653451 ecr 0,nop,wscale 1], length 0
12:15:50.043228 IP 188-xxxxx.cz.3944 > 192.168.0.1.1900: Flags [S], seq 461101675, win 5840, options [mss 1460,sackOK,TS val 3653799 ecr 0,nop,wscale 1], length 0
12:15:50.118928 IP 188-xxxxx.cz.3036 > 192.168.0.1.1900: Flags [S], seq 455199982, win 5840, options [mss 1460,sackOK,TS val 3653462 ecr 0,nop,wscale 1], length 0
12:15:50.120911 IP 188-xxxxx.cz.3945 > 192.168.0.1.1900: Flags [S], seq 456943227, win 5840, options [mss 1460,sackOK,TS val 3653807 ecr 0,nop,wscale 1], length 0
12:15:50.226986 IP 188-xxxxx.cz.3037 > 192.168.0.1.1900: Flags [S], seq 466132341, win 5840, options [mss 1460,sackOK,TS val 3653473 ecr 0,nop,wscale 1], length 0
12:15:50.240904 IP 188-xxxxx.cz.3946 > 192.168.0.1.1900: Flags [S], seq 457813199, win 5840, options [mss 1460,sackOK,TS val 3653819 ecr 0,nop,wscale 1], length 0
12:15:50.324793 IP 188-xxxxx.cz.3038 > 192.168.0.1.1900: Flags [S], seq 460404270, win 5840, options [mss 1460,sackOK,TS val 3653482 ecr 0,nop,wscale 1], length 0
12:15:50.334284 IP 188-xxxxx.cz.3947 > 192.168.0.1.1900: Flags [S], seq 456033724, win 5840, options [mss 1460,sackOK,TS val 3653828 ecr 0,nop,wscale 1], length 0
12:15:50.428977 IP 188-xxxxx.cz.3039 > 192.168.0.1.1900: Flags [S], seq 459672645, win 5840, options [mss 1460,sackOK,TS val 3653493 ecr 0,nop,wscale 1], length 0
12:15:50.436808 IP 188-xxxxx.cz.3948 > 192.168.0.1.1900: Flags [S], seq 459925799, win 5840, options [mss 1460,sackOK,TS val 3653838 ecr 0,nop,wscale 1], length 0
12:15:50.532836 IP 188-xxxxx.cz.3949 > 192.168.0.1.1900: Flags [S], seq 466710127, win 5840, options [mss 1460,sackOK,TS val 3653848 ecr 0,nop,wscale 1], length 0
12:15:50.534815 IP 188-xxxxx.cz.3040 > 192.168.0.1.1900: Flags [S], seq 452616629, win 5840, options [mss 1460,sackOK,TS val 3653503 ecr 0,nop,wscale 1], length 0
12:15:50.637651 IP 188-xxxxx.cz.3950 > 192.168.0.1.1900: Flags [S], seq 450809210, win 5840, options [mss 1460,sackOK,TS val 3653858 ecr 0,nop,wscale 1], length 0
12:15:50.638007 IP 188-xxxxx.cz.3041 > 192.168.0.1.1900: Flags [S], seq 463764187, win 5840, options [mss 1460,sackOK,TS val 3653514 ecr 0,nop,wscale 1], length 0
12:15:50.741721 IP 188-xxxxx.cz.3951 > 192.168.0.1.1900: Flags [S], seq 450855901, win 5840, options [mss 1460,sackOK,TS val 3653869 ecr 0,nop,wscale 1], length 0
12:15:50.743787 IP 188-xxxxx.cz.3042 > 192.168.0.1.1900: Flags [S], seq 458482915, win 5840, options [mss 1460,sackOK,TS val 3653524 ecr 0,nop,wscale 1], length 0
12:15:50.845510 IP 188-xxxxx.cz.3952 > 192.168.0.1.1900: Flags [S], seq 451569341, win 5840, options [mss 1460,sackOK,TS val 3653879 ecr 0,nop,wscale 1], length 0
12:15:50.853186 IP 188-xxxxx.cz.3043 > 192.168.0.1.1900: Flags [S], seq 465696165, win 5840, options [mss 1460,sackOK,TS val 3653535 ecr 0,nop,wscale 1], length 0
12:15:50.960321 IP 188-xxxxx.cz.3953 > 192.168.0.1.1900: Flags [S], seq 456815535, win 5840, options [mss 1460,sackOK,TS val 3653891 ecr 0,nop,wscale 1], length 0
12:15:50.962281 IP 188-xxxxx.cz.3044 > 192.168.0.1.1900: Flags [S], seq 457897976, win 5840, options [mss 1460,sackOK,TS val 3653546 ecr 0,nop,wscale 1], length 0
12:15:51.053071 IP 188-xxxxx.cz.3045 > 192.168.0.1.1900: Flags [S], seq 455730758, win 5840, options [mss 1460,sackOK,TS val 3653555 ecr 0,nop,wscale 1], length 0
12:15:51.053316 IP 188-xxxxx.cz.3954 > 192.168.0.1.1900: Flags [S], seq 452591486, win 5840, options [mss 1460,sackOK,TS val 3653900 ecr 0,nop,wscale 1], length 0
12:15:52.798223 IP 188-xxxxx.cz.3942 > 192.168.0.1.1900: Flags [S], seq 464587655, win 5840, options [mss 1460,sackOK,TS val 3654075 ecr 0,nop,wscale 1], length 0
12:15:52.806057 IP 188-xxxxx.cz.3033 > 192.168.0.1.1900: Flags [S], seq 453562137, win 5840, options [mss 1460,sackOK,TS val 3653731 ecr 0,nop,wscale 1], length 0
Taky se mi nezdá, že mi tam chodí toto, ne vždy tak najednou:
12:13:18.218971 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 4c:5e:0c:ee:4c:35 (oui Unknown), length 300
12:13:18.859055 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 4c:5e:0c:ff:6c:b3 (oui Unknown), length 300
12:13:18.886645 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 4c:5e:0c:dc:34:f9 (oui Unknown), length 300
12:13:19.194129 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 4c:5e:0c:2f:c4:31 (oui Unknown), length 300
12:13:19.252124 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 4c:5e:0c:ee:4c:35 (oui Unknown), length 300
12:13:19.254527 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 4c:5e:0c:dd:8b:c5 (oui Unknown), length 300
Může toto způsobovat nějakou chybu? Je toto moje chyba v konfuguraci nebo ISP?
17.6.2015 19:20 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Výpadky připojení
Může toto způsobovat nějakou chybu? Je toto moje chyba v konfuguraci nebo ISP?

To my nemůžeme vědět, protože nevíme, jak máte síť organizovanou, kdo má jaké rozsahy, které lze kam směrovat a tak dále. Nakonec z těch výpisu není poznat, jestli se jedná o odchozí nebo příchozí packety (to je ale problém tcpdumpu, že neukazuje směr; má jen přepínač --direction pro výběr zobrazeného směru).

17.6.2015 19:36 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Výpadky připojení
První dva záznamy jsou autodiscovery protokol mezi RouterOS. Pokusy připojit se na TCP port 1900 vypadají jako útok nebo blbě implementovaný SSDP, který má používat UDP. Zbytek je 5 DHCP klientů z továrny Mikrotiku toužících po IP adrese.
21.6.2015 14:14 Martin
Rozbalit Rozbalit vše Re: Výpadky připojení
Tak problém bude asi na rozhraní, jsem přehlédl ty errory a droppy:
eth0      Link encap:Ethernet  HWadr 00:30:xx:xx:xx:xx
          inet adr:188.xxx.xxx.xxx  Všesměr:188.xxx.xx.xx  Maska:255.255.255.240
          AKTIVOVÁNO VŠESMĚROVÉ_VYSÍLÁNÍ BĚŽÍ MULTICAST  MTU:1500  Metrika:1
          RX packets:214706 errors:60745 dropped:35288 overruns:0 frame:0
          TX packets:82175 errors:0 dropped:0 overruns:0 carrier:0
          kolizí:0 délka odchozí fronty:1000 
          Přijato bajtů: 85953800 (85.9 MB) Odesláno bajtů: 8618402 (8.6 MB)
Podle toho jak jsem googlil se jedná o problém, kdy se síťovky nedomluví na rychlosti a duplexu. Domluvená rychlost je 100/full, což mi přijde jako normální. Zkusím tam dojít a píchnout tam notebook a co si domluví z auto-negotiation on, když to s tím ntbkem jelo.

Nemáte nějaký tip co by to mohlo ještě způsobovat, na co se zaměřit?
14.6.2015 17:58 gogol
Rozbalit Rozbalit vše Re: Výpadky připojení
Akym typom linky si pripojeny k ISP ?

nejake bezdratove pojitko, alebo metalika/optika ?
14.6.2015 22:06 Martin
Rozbalit Rozbalit vše Re: Výpadky připojení
Jejich připojení je bezdrát do nějaké jejich krabice a pak z něj ethernet ke mě přímo do routeru. nevím jestli to ale může být jejich připojením, když notebookový test fungoval dobře.
14.6.2015 23:10 gogol
Rozbalit Rozbalit vše Re: Výpadky připojení
Notebookovy test mohol byt ok, pretoze si to skusal v "inom" case. Nepredpokladam, ze si pingal ten router aj notebook sucasne. Bezdrat je nevypocitatelny, zvlast ten v bezlicencnom pasme. Staci ak je obcas v dosahu rusiaca stanica a bude sa to spravat takymto sposobom. Obcas v dosahu znamena, ze moze byt vacsinu casu pod rozlisenim prijimaca, ale obcas za prihodnych poveternostnych podmienok sa moze signal zvysit a rusit. Doporucil by som pingat tu "jejich krabicu" z routra a sucasne tvoju IP na druhej strane. Bohuzial bezdrat ma dve strany, takze ak by to bolo bezdratom, tak bude asi potrebne urcit na ktorej strane je rusenie, pretoze moze byt na jednej, druhej, alebo aj na obidvoch stranach a navyse nesumerne.

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.