abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    dnes 15:55 | Nová verze

    Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.

    Ladislav Hagara | Komentářů: 0
    dnes 13:44 | IT novinky

    Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.

    Ladislav Hagara | Komentářů: 0
    dnes 04:44 | Nová verze

    Po roce vývoje od vydání verze 1.24.0 byla vydána nová stabilní verze 1.26.0 webového serveru a reverzní proxy nginx (Wikipedie). Nová verze přináší řadu novinek. Podrobný přehled v souboru CHANGES-1.26.

    Ladislav Hagara | Komentářů: 0
    dnes 04:33 | Nová verze

    Byla vydána nová verze 6.2 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.14.

    Ladislav Hagara | Komentářů: 0
    dnes 04:22 | Nová verze

    Byla vydána nová verze 30.0.0 frameworku pro vývoj multiplatformních desktopových aplikací pomocí JavaScriptu, HTML a CSS Electron (Wikipedie, GitHub). Chromium bylo aktualizováno na verzi 124.0.6367.49, V8 na verzi 12.4 a Node.js na verzi 20.11.1. Electron byl původně vyvíjen pro editor Atom pod názvem Atom Shell. Dnes je na Electronu postavena celá řada dalších aplikací.

    Ladislav Hagara | Komentářů: 0
    dnes 04:11 | Nová verze

    Byla vydána nová verze 9.0.0 otevřeného emulátoru procesorů a virtualizačního nástroje QEMU (Wikipedie). Přispělo 220 vývojářů. Provedeno bylo více než 2 700 commitů. Přehled úprav a nových vlastností v seznamu změn.

    Ladislav Hagara | Komentářů: 0
    včera 23:22 | IT novinky

    Evropský parlament dnes přijal směrnici týkající se tzv. práva spotřebitele na opravu. Poslanci ji podpořili 584 hlasy (3 bylo proti a 14 se zdrželo hlasování). Směrnice ujasňuje povinnosti výrobců opravovat zboží a motivovat spotřebitele k tomu, aby si výrobky nechávali opravit a prodloužili tak jejich životnost.

    Ladislav Hagara | Komentářů: 4
    včera 16:11 | Nová verze

    Bylo oznámeno (cs) vydání Fedora Linuxu 40. Přehled novinek ve Fedora Workstation 40 a Fedora KDE 40 na stránkách Fedora Magazinu. Současně byl oznámen notebook Slimbook Fedora 2.

    Ladislav Hagara | Komentářů: 18
    včera 13:44 | Upozornění

    ČTK (Česká tisková kancelář) upozorňuje (X), že na jejím zpravodajském webu České noviny byly dnes dopoledne neznámým útočníkem umístěny dva smyšlené texty, které nepocházejí z její produkce. Jde o text s titulkem „BIS zabránila pokusu o atentát na nově zvoleného slovenského prezidenta Petra Pelligriniho“ a o údajné mimořádné prohlášení ministra Lipavského k témuž. Tyto dezinformace byly útočníky zveřejněny i s příslušnými notifikacemi v mobilní aplikaci Českých novin. ČTK ve svém zpravodajském servisu žádnou informaci v tomto znění nevydala.

    Ladislav Hagara | Komentářů: 26
    včera 13:33 | Komunita

    Byla založena nadace Open Home Foundation zastřešující více než 240 projektů, standardů, ovladačů a knihoven (Home Assistant, ESPHome, Zigpy, Piper, Improv Wi-Fi, Wyoming, …) pro otevřenou chytrou domácnost s důrazem na soukromí, možnost výběru a udržitelnost.

    Ladislav Hagara | Komentářů: 0
    KDE Plasma 6
     (72%)
     (9%)
     (2%)
     (17%)
    Celkem 714 hlasů
     Komentářů: 4, poslední 6.4. 15:51
    Rozcestník

    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: 515×
    Příloha:
    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:


    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)
    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. Díky
    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á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.