Přihlášení | Registrace

napište » Zprávičky

dnes 01:22 | Komunita

Konsorcium Linux Foundation představilo svůj nejnovější projekt s názvem OpenSearch Software Foundation zastřešující další vývoj OpenSearch a OpenSearch Dashboards. OpenSearch je forkem vyhledávače Elasticsearch a OpenSearch Dashboards je forkem souvisejícího nástroje pro vizualizaci dat Kibana. V roce 2021 přešly projekty Elasticsearch a Kibana z licence Apache 2.0 na duální licencování pod Server Side Public License (SSPL) a

… více »

Ladislav Hagara | Komentářů: 0

Valkey 8.0.0

včera 18:33 | Nová verze

Valkey, tj. svobodný fork již nesvobodného Redisu, byl vydán v první major verzi 8.0.0 (GitHub). Ve čtvrtek proběhne ve Vídni Valkey Developer Day.

Ladislav Hagara | Komentářů: 0

TamaGo, na SoC s programovacím jazykem Go

včera 12:55 | Zajímavý projekt

TamaGo je open source framework pro programování ARM a RISC-V systémů na čipu (SoC) v programovacím jazyce Go. Prezentace projektu z OSFC (Open Source Firmware Conference) v pdf na GitHubu.

Ladislav Hagara | Komentářů: 0

Konference OpenAlt 2024 hledá přednášející, dobrovolníky a partnery

15.9. 21:44 | Komunita

Konference OpenAlt 2024 – jedinečné fórum, kde se každoročně sdružují lidé se zájmem o vývoj a využití svobodného a otevřeného softwaru a hardwaru, tvorbu, zpracování a zpřístupňování otevřených dat, svobodný přístup k informacím a vzdělávání – hledá přednášející, dobrovolníky a partnery. Konference proběhne 2. a 3. listopadu v prostorách FIT VUT v Brně. Vstup je zdarma.

Ladislav Hagara | Komentářů: 0

Linux 6.11

15.9. 19:44 | Nová verze

Po 9 týdnech vývoje od vydání Linuxu 6.10 oznámil Linus Torvalds vydání Linuxu 6.11. Z Vídně, jelikož tam zítra začíná Open Source Summit Europe. Přehled novinek a vylepšení na LWN.net: první a druhá polovina začleňovacího okna. Později také na Linux Kernel Newbies.

Ladislav Hagara | Komentářů: 0

Grocy, ERP systém pro správu domácností

15.9. 12:00 | Zajímavý software

Grocy je open source ERP systém. Ne však pro plánování zdrojů v podnicích ale v domácnostech. Spravovat lze zásoby, povinnosti a úkoly. Vytvářet nákupní seznamy. Ověřovat dostupnost surovin pro recepty. Plánovat jídelníčky. Vyzkoušet lze online demo. Vývoj probíhá na GitHubu.

Ladislav Hagara | Komentářů: 8

Týden v GNOME a Týden v KDE (13. září 2024)

14.9. 19:44 | Komunita

Na čem aktuálně pracují vývojáři GNOME a KDE? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE.

Ladislav Hagara | Komentářů: 0

3D tiskárny Original Prusa MK4S (a MK4) mají certifikaci UL 2904 GREENGUARD

13.9. 23:11 | IT novinky

3D tiskárny Original Prusa MK4S (a MK4) v kombinaci s Prusamenty PLA a PETG mají mezinárodně uznávanou certifikaci UL 2904 GREENGUARD, která potvrzuje splnění přísných bezpečnostních standardů pro VOC a UFP.

Ladislav Hagara | Komentářů: 2

Haiku R1/beta5

13.9. 22:11 | Nová verze

Byla vydána verze R1/beta5 open source operačního systému Haiku (Wikipedie). Přehled novinek i s náhledy v poznámkách k vydání.

Ladislav Hagara | Komentářů: 7

Sovereign Tech Fund podpoří Sambu částkou 688 800 eur

13.9. 16:33 | Komunita

Sovereign Tech Fund (Wikipedie), tj. program financování otevřeného softwaru německým ministerstvem hospodářství a ochrany klimatu, podpoří Sambu částkou 688 800 eur.

Ladislav Hagara | Komentářů: 57

Centrum | Napsat | Starší

Rozcestník

AbcLinuxu

HDmag.cz

AbcLinuxu:/ Poradna / Linuxová poradna / Velká odezva přes OpenVPN tunel (>10s)

Štítky: Internet, modul, net, OpenVPN, ovladac, ping, problém, realtek, router, r8169, sítě, spojení, TCP, tcpdump, UDP, VPN

Dotaz: Velká odezva přes OpenVPN tunel (>10s)

14.1.2016 18:16 Electronic | skóre: 3
Velká odezva přes OpenVPN tunel (>10s)

Přečteno: 526×

Odpovědět | Admin

Příloha:

tcpdump2.txt (7890 bytů)

Dobrý den, řeším již třetím dnem problém na mém routeru. Když se připojím přes OpenVPN z venku tak vše funguje normálně, ale pouze chvíli. Po připojení k VPN zapnu ping na stroj v lokální síti (skrz tunel) a přibližně tak po 100-150 paketech na chvíli vypadne spojení (viz příloha). Když VPN jela přes udp, pakety byly samozřejmě ztraceny. Přes tcp se pakety s odezvou kolem 15s vrátí zpět. Na routeru jsem spustil tcpdump a je vidět že router odesílá hodně paketů se špatným kontrolním součtem TCP a když dojde k výpadku tak i nulové délky.

Na routeru jsou síťové karty Realtek RTL8111/8168B, které původně používaly ovladač r8169. Nyní jsem zkompiloval nový modul ze stránek výrobce ale problém přetrvává.

Myslíte, že jde o hardwarový problém nebo softwarový? Nesetkal jste se někdo s něčím podobným ?

Předem děkuji za odpovědi.

Ping skrz tunel

64 bytes from <LOCAL NET ADDR>: icmp_seq=59 ttl=63 time=89.6 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=60 ttl=63 time=85.9 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=61 ttl=63 time=104 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=62 ttl=63 time=95.9 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=63 ttl=63 time=125 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=64 ttl=63 time=93.0 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=65 ttl=63 time=91.8 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=66 ttl=63 time=91.7 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=67 ttl=63 time=98.2 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=68 ttl=63 time=126 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=69 ttl=63 time=103 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=70 ttl=63 time=93.8 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=71 ttl=63 time=91.9 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=72 ttl=63 time=90.8 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=73 ttl=63 time=88.9 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=74 ttl=63 time=87.8 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=75 ttl=63 time=98.2 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=76 ttl=63 time=96.7 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=77 ttl=63 time=94.7 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=78 ttl=63 time=98.6 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=79 ttl=63 time=88.8 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=80 ttl=63 time=95.8 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=81 ttl=63 time=96.0 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=82 ttl=63 time=92.8 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=83 ttl=63 time=93.7 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=84 ttl=63 time=91.7 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=85 ttl=63 time=99.9 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=86 ttl=63 time=88.0 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=87 ttl=63 time=88.8 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=88 ttl=63 time=87.7 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=89 ttl=63 time=85.7 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=90 ttl=63 time=93.8 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=91 ttl=63 time=93.8 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=92 ttl=63 time=93.8 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=93 ttl=63 time=92.8 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=94 ttl=63 time=111 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=95 ttl=63 time=92.8 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=96 ttl=63 time=163 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=97 ttl=63 time=135 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=98 ttl=63 time=92.1 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=99 ttl=63 time=19111 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=100 ttl=63 time=20872 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=101 ttl=63 time=19873 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=102 ttl=63 time=18873 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=103 ttl=63 time=17873 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=104 ttl=63 time=16873 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=105 ttl=63 time=15873 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=106 ttl=63 time=14873 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=107 ttl=63 time=13873 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=108 ttl=63 time=12874 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=109 ttl=63 time=11874 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=110 ttl=63 time=10874 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=111 ttl=63 time=9874 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=112 ttl=63 time=8920 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=113 ttl=63 time=7920 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=114 ttl=63 time=6920 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=115 ttl=63 time=5920 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=116 ttl=63 time=4920 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=117 ttl=63 time=3920 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=118 ttl=63 time=2920 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=119 ttl=63 time=1920 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=120 ttl=63 time=921 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=121 ttl=63 time=46.5 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=122 ttl=63 time=52.9 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=123 ttl=63 time=49.9 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=124 ttl=63 time=58.8 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=125 ttl=63 time=48.8 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=126 ttl=63 time=44.9 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=127 ttl=63 time=45.8 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=128 ttl=63 time=54.9 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=129 ttl=63 time=51.8 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=130 ttl=63 time=61.8 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=131 ttl=63 time=65.9 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=132 ttl=63 time=103 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=133 ttl=63 time=48.9 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=134 ttl=63 time=47.6 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=135 ttl=63 time=55.4 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=136 ttl=63 time=53.9 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=137 ttl=63 time=52.8 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=138 ttl=63 time=49.7 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=139 ttl=63 time=58.0 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=140 ttl=63 time=93.8 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=141 ttl=63 time=81.1 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=142 ttl=63 time=46.2 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=143 ttl=63 time=47.0 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=144 ttl=63 time=63.8 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=145 ttl=63 time=92.8 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=146 ttl=63 time=92.8 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=147 ttl=63 time=93.9 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=148 ttl=63 time=91.7 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=149 ttl=63 time=100 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=150 ttl=63 time=90.0 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=151 ttl=63 time=89.8 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=152 ttl=63 time=89.8 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=153 ttl=63 time=98.5 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=154 ttl=63 time=89.0 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=155 ttl=63 time=89.0 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=156 ttl=63 time=106 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=157 ttl=63 time=90.4 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=158 ttl=63 time=97.2 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=159 ttl=63 time=86.9 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=160 ttl=63 time=86.7 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=161 ttl=63 time=85.9 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=162 ttl=63 time=103 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=163 ttl=63 time=95.0 ms
64 bytes from <LOCAL NET ADDR>: icmp_seq=164 ttl=63 time=184 ms

Výpis tcpdump

    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [P.], cksum 0x55ba (incorrect -> 0xb7c5), seq 17974:18101, ack 15767, win 11528, options [nop,nop,TS val 261908 ecr 4992474], length 127
    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [P.], cksum 0x55ba (incorrect -> 0x089e), seq 18101:18228, ack 15894, win 11528, options [nop,nop,TS val 262159 ecr 4992725], length 127
    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [P.], cksum 0x55ba (incorrect -> 0xf92b), seq 18228:18355, ack 16021, win 11528, options [nop,nop,TS val 262410 ecr 4992975], length 127
    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [P.], cksum 0x55ba (incorrect -> 0x0e77), seq 18355:18482, ack 16148, win 11528, options [nop,nop,TS val 262660 ecr 4993225], length 127
    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [P.], cksum 0x55ba (incorrect -> 0x624b), seq 18482:18609, ack 16275, win 11528, options [nop,nop,TS val 262910 ecr 4993476], length 127
    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [P.], cksum 0x55ba (incorrect -> 0x0ae1), seq 18609:18736, ack 16402, win 11528, options [nop,nop,TS val 263161 ecr 4993726], length 127
    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [P.], cksum 0x55ba (incorrect -> 0x2fa6), seq 18736:18863, ack 16529, win 11528, options [nop,nop,TS val 263413 ecr 4993977], length 127
    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [P.], cksum 0x55ba (incorrect -> 0x2170), seq 18863:18990, ack 16656, win 11528, options [nop,nop,TS val 263660 ecr 4994227], length 127
    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [P.], cksum 0x55ba (incorrect -> 0xe2a2), seq 18990:19117, ack 16783, win 11528, options [nop,nop,TS val 263910 ecr 4994477], length 127
    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [P.], cksum 0x55ba (incorrect -> 0xf47b), seq 19117:19244, ack 16910, win 11528, options [nop,nop,TS val 264161 ecr 4994727], length 127
    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [P.], cksum 0x55ba (incorrect -> 0x3fc5), seq 19244:19371, ack 17037, win 11528, options [nop,nop,TS val 264411 ecr 4994978], length 127
    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [P.], cksum 0x55ba (incorrect -> 0xa01c), seq 19371:19498, ack 17164, win 11528, options [nop,nop,TS val 264663 ecr 4995228], length 127
    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [P.], cksum 0x55ba (incorrect -> 0xc461), seq 19498:19625, ack 17291, win 11528, options [nop,nop,TS val 264913 ecr 4995478], length 127
    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [P.], cksum 0x55ba (incorrect -> 0xa255), seq 19625:19752, ack 17418, win 11528, options [nop,nop,TS val 265163 ecr 4995728], length 127
    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [P.], cksum 0x55ba (incorrect -> 0xab8b), seq 19752:19879, ack 17545, win 11528, options [nop,nop,TS val 265413 ecr 4995978], length 127
    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [P.], cksum 0x55ba (incorrect -> 0x47f1), seq 19879:20006, ack 17672, win 11528, options [nop,nop,TS val 265664 ecr 4996228], length 127
    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [P.], cksum 0x55ba (incorrect -> 0xb1ea), seq 20006:20133, ack 17799, win 11528, options [nop,nop,TS val 265913 ecr 4996478], length 127
    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [P.], cksum 0x55ba (incorrect -> 0x3191), seq 20133:20260, ack 17926, win 11528, options [nop,nop,TS val 266163 ecr 4996728], length 127
    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [P.], cksum 0x55ba (incorrect -> 0x3340), seq 20260:20387, ack 18053, win 11528, options [nop,nop,TS val 266413 ecr 4996979], length 127
    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [P.], cksum 0x55ba (incorrect -> 0x5bc7), seq 20387:20514, ack 18180, win 11528, options [nop,nop,TS val 266663 ecr 4997229], length 127
    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [P.], cksum 0x55ba (incorrect -> 0x5d2b), seq 20514:20641, ack 18307, win 11528, options [nop,nop,TS val 266913 ecr 4997479], length 127
    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [P.], cksum 0x55ba (incorrect -> 0x5ce0), seq 20514:20641, ack 18307, win 11528, options [nop,nop,TS val 266988 ecr 4997479], length 127
    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [.], cksum 0x5547 (incorrect -> 0x9433), seq 20641, ack 18307, win 11528, options [nop,nop,TS val 266990 ecr 4997556,nop,nop,sack 1 {18180:18307}], length 0
    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [.], cksum 0x5547 (incorrect -> 0x939b), seq 20641, ack 18307, win 11528, options [nop,nop,TS val 267065 ecr 4997633,nop,nop,sack 1 {18180:18307}], length 0
    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [P.], cksum 0x55ba (incorrect -> 0x5bb0), seq 20514:20641, ack 18307, win 11528, options [nop,nop,TS val 267138 ecr 4997633], length 127
    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [.], cksum 0x5547 (incorrect -> 0x9266), seq 20641, ack 18307, win 11528, options [nop,nop,TS val 267220 ecr 4997787,nop,nop,sack 1 {18180:18307}], length 0
    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [P.], cksum 0x55ba (incorrect -> 0x59e9), seq 20514:20641, ack 18307, win 11528, options [nop,nop,TS val 267439 ecr 4997787], length 127
    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [.], cksum 0x5547 (incorrect -> 0x8ffb), seq 20641, ack 18307, win 11528, options [nop,nop,TS val 267530 ecr 4998096,nop,nop,sack 1 {18180:18307}], length 0
    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [P.], cksum 0x55ba (incorrect -> 0x565b), seq 20514:20641, ack 18307, win 11528, options [nop,nop,TS val 268040 ecr 4998096], length 127
    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [.], cksum 0x5547 (incorrect -> 0x8b27), seq 20641, ack 18307, win 11528, options [nop,nop,TS val 268148 ecr 4998714,nop,nop,sack 1 {18180:18307}], length 0
    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [P.], cksum 0x55ba (incorrect -> 0x4f3d), seq 20514:20641, ack 18307, win 11528, options [nop,nop,TS val 269244 ecr 4998714], length 127
    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [.], cksum 0x5547 (incorrect -> 0x812b), seq 20641, ack 18307, win 11528, options [nop,nop,TS val 269470 ecr 4999948,nop,nop,sack 1 {18180:18307}], length 0
    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [P.], cksum 0x55ba (incorrect -> 0x4107), seq 20514:20641, ack 18307, win 11528, options [nop,nop,TS val 271648 ecr 4999948], length 127
    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [P.], cksum 0x5623 (incorrect -> 0x094f), seq 20641:20861, ack 18307, win 11528, options [nop,nop,TS val 272247 ecr 4999948,nop,nop,sack 1 {19715:20720}], length 220
    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [.], cksum 0x553b (incorrect -> 0xf4af), seq 20861, ack 20720, win 12976, options [nop,nop,TS val 272357 ecr 5002923], length 0
    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [P.], cksum 0x55ba (incorrect -> 0x6d64), seq 20861:20988, ack 20720, win 12976, options [nop,nop,TS val 272358 ecr 5002923], length 127
    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [.], cksum 0x5abb (incorrect -> 0x0b64), seq 20988:22396, ack 20720, win 12976, options [nop,nop,TS val 272358 ecr 5002923], length 1408
    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [P.], cksum 0x59a7 (incorrect -> 0x720e), seq 22396:23528, ack 20974, win 14384, options [nop,nop,TS val 272368 ecr 5002946], length 1132
    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [P.], cksum 0x55ba (incorrect -> 0xd00d), seq 23528:23655, ack 21101, win 14384, options [nop,nop,TS val 272401 ecr 5002979], length 127
    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [P.], cksum 0x55ba (incorrect -> 0xdde3), seq 23655:23782, ack 21228, win 14384, options [nop,nop,TS val 272653 ecr 5003229], length 127
    <ROUTER IP 1>.1194 > 37.188.130.55.4894: Flags [P.], cksum 0x55ba (incorrect -> 0x0a67), seq 23782:23909, ack 21355, win 14384, options [nop,nop,TS val 272903 ecr 5003479], length 127

Řešení dotazu:

Komentář #9 (Electronic, 1 hlasů)

Nástroje: Začni sledovat (0) ?

Odpovědi

14.1.2016 21:34 xms
Rozbalit Rozbalit vše Re: Velká odezva přes OpenVPN tunel (>10s)

Možná nápověda: MTU, mssfix, fragment.

15.1.2016 05:46 Electronic | skóre: 3
Rozbalit Rozbalit vše Re: Velká odezva přes OpenVPN tunel (>10s)

Ano, toto jsem zapoměl zmínit. Na OpenVPN serveru jsem spouštěl MSU-TEST, který vohdil nastavení mtu 1514. I přes to jsem nastavil hodnotu nižší 1300 u MSS-FIX a TUN-MTU. Fragmentace nešla nastavit jelikož server běží na tcp.

Děkuji

15.1.2016 09:17 NN
Rozbalit Rozbalit vše Re: Velká odezva přes OpenVPN tunel (>10s)

Jak je stabilni ping ciste mezi verejnou a verejnou adresou bez tunelu? Co za zarizeni je na klientske strane?

15.1.2016 11:27 Electronic | skóre: 3
Rozbalit Rozbalit vše Re: Velká odezva přes OpenVPN tunel (>10s)

Z venku na router bohužel pingnout nejde - vždy vyprší TTL, ať už jsem na chvíli otevřel celý firewall, pakety se evidentně někde dříve zacyklovaly. Na klientské straně jsem zkoušel Windows 7 s Openvpn 2.3.9 a ještě Linux Mint (nevím přesně verzi OpenVPN). Jinak ping např. na google.cz z routeru je vcelku stabilní pod 10ms, ale včera když jsem to zkoušel tak byla ztrátovost asi 8% z nějakých 650 paketů. Až dnes přídu domů tak ještě vyzkouším. Mám podezření že začaly odcházet již zmíněné síťovky.

15.1.2016 11:27 Electronic | skóre: 3
Rozbalit Rozbalit vše Re: Velká odezva přes OpenVPN tunel (>10s)

15.1.2016 09:23 pet I. | skóre: 12
Rozbalit Rozbalit vše Re: Velká odezva přes OpenVPN tunel (>10s)

Chápu-li to správně, tak se teď jedná o kombinaci dvou problémů.

1. problém: Po navázání spojení začne něco chybovat a v důsledku toho se ztrácejí pakety.

2. problém: Uživatel se pokusil 1. problém občůrat použitím tcp. Důsledkem je tzv tcp_in_tcp problém, kdy na spojení tunelovaném přes nespolehlivé tcp spojení prudce naroste zpoždění.

Řešení 2. problému: Vrátit se k udp a řešit 1. problém.

Řešení 1. problému: Někde na spojení je něco, co chybuje. Může to být ethernetka, hub, nalomený kabel, .... Konkrétně mě když před lety doma začal odcházet switch, tak na notebooku jsem musel nastavit 10 Mbps/simplex aby to komunikovalo, pak za pár týdnů switch umřel úplně.

15.1.2016 11:01 nelson | skóre: 17 | blog: jakesi_cosi
Rozbalit Rozbalit vše Re: Velká odezva přes OpenVPN tunel (>10s)

+1, řekl bych, že problém je v nespolehlivé lince a tcp VPN vyřešila problém se ztrátovostí, ale logicky za cenu zpoždění.

Dovolím si rýpnout, že se simplex způsobem komunikace byste si moc na Internetu nezakomunikoval :-)

Určitě šlo o halfduplex.

18.1.2016 09:54 pet I. | skóre: 12
Rozbalit Rozbalit vše Re: Velká odezva přes OpenVPN tunel (>10s)

Dovolím si rýpnout, že se simplex způsobem komunikace byste si moc na Internetu nezakomunikoval Určitě šlo o halfduplex.

Jojo, moje blbost, samozřejmě že šlo o halfduplex. (Neznáte někdo smajlík "sypu si popel na hlavu"?)

15.1.2016 11:19 Electronic | skóre: 3
Rozbalit Rozbalit vše Re: Velká odezva přes OpenVPN tunel (>10s)

Původně běžel server jen přes udp a chtěl jsem zjistit zda se pakety ztrácejí úplně (hardware) nebo se je zpožďují tak, že už je zpětně nezachytím. Na routeru jsou dvě již zmíněné síťovky RTL8111/8168B. Jedna je pro WAN druhá pro LAN. Když pustím tcpdump na LAN tak najde také plno paketů se špatným kontrolním součtem (viz výpis). Zkoušel jsem síťovky přepnout z 1000Mb/s full-duplex na 100Mb/s full-duplex ale žádná změna. Zkusím ještě níž a half-duplex. Díky

18.1.2016 22:39 beny
Rozbalit Rozbalit vše Re: Velká odezva přes OpenVPN tunel (>10s)

Spatny kontrolni soucet v dumpu vypada jako checksum offloading na sitovce. Muzete ho zkusit vypnout, jestli se neco zmeni. Dnes je to docela normalni/ocekavana situace.

Řešení 1× (Electronic (tazatel))

16.1.2016 18:30 Electronic | skóre: 3
Rozbalit Rozbalit vše Re: Velká odezva přes OpenVPN tunel (>10s)

Tak se omlouvám. Skutečně to vypadá na problém u ISP ztrátovost paketů kolem 6% někdy i přes 11% tak snad se to brzy vyřeší. Všem moc děkuji za odpovědi.

Založit nové vlákno • Nahoru

Tiskni Sdílej:

Píšeme jinde

ISSN 1214-1267 www.czech-server.cz

Redakce | Inzerce | Podmínky použití | Osobní údaje