Byla vydána (𝕏) nová major verze 17 softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech GitLab (Wikipedie). Představení nových vlastností i s náhledy a videi v oficiálním oznámení.
Sovereign Tech Fund, tj. program financování otevřeného softwaru německým ministerstvem hospodářství a ochrany klimatu, podpoří vývoj FFmpeg částkou 157 580 eur. V listopadu loňského roku podpořil GNOME částkou 1 milion eur.
24. září 2024 budou zveřejněny zdrojové kódy přehrávače Winamp.
Google Chrome 125 byl prohlášen za stabilní. Nejnovější stabilní verze 125.0.6422.60 přináší řadu oprav a vylepšení (YouTube). Podrobný přehled v poznámkách k vydání. Opraveno bylo 9 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Textový editor Neovim byl vydán ve verzi 0.10 (𝕏). Přehled novinek v příspěvku na blogu a v poznámkách k vydání.
Byla vydána nová verze 6.3 ž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.15.
Dnes ve 12:00 byla spuštěna první aukce domén .CZ. Zatím největší zájem je o dro.cz, kachnicka.cz, octavie.cz, uvycepu.cz a vnady.cz [𝕏].
JackTrip byl vydán ve verzi 2.3.0. Jedná se o multiplatformní open source software umožňující hudebníkům z různých částí světa společné hraní. JackTrip lze instalovat také z Flathubu.
Patnáctý ročník ne-konference jOpenSpace se koná 4. – 6. října 2024 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytváří všichni účastníci, se skládá z desetiminutových
… více »Program pro generování 3D lidských postav MakeHuman (Wikipedie, GitHub) byl vydán ve verzi 1.3.0. Hlavní novinkou je výběr tvaru těla (body shapes).
Ahoj, snazim se zjistit pricinu male propustnosti tunelu GRE over IPSec v LTE modemu Conel SPECTRE v3. Na druhe strane je jak GRE, tak IPSec terminovan na malem Ciscu 871.
V modemu je dost osekany Linux (kernel 3.12.10) s busyboxem a minimem diagnostickych nastroju. Konfigurace je provedena prostrednictvim nastroju weboveho rozhrani modemu, ale ty v podastate pouzivaji standardni "ip" pro vytvoreni GRE tunnelu a pluto jako IKE daemona (ale jako implementaci IPSecu to pouziva kernelovy NETKEY). Aby to nebylo tak jednoduche, tak ma modem v ramci LTE dynamicky pridelovanou neverejnou IP adresu, takze se pouziva jeste NAT-T. Pro registraci GRE endpointu je pouzity OpenNHRP.
Za modemem na jedne strane a za Ciscem na druhe jsou dva pocitace, na nichz pouzivam iperf v UDP rezimu pro mereni propustnosti. Kdyz se posilaji data ze stany Cisca na stranu modemu, tak dosahnu cca 8Mbps, v opacnem smeru mi ale jede prenos pouze cca 500Kbps. Pri komunikaci v ramci Internetu (mimo IPSec tunnel) dosahuji pres modem rychlosti cca 22Mbps download a 17Mbps upload.
Co jsem se snazil vyloucit:
processor : 0 model name : ARMv7 Processor rev 2 (v7l) Features : swp half fastmult vfp edsp neon vfpv3 tls vfpd32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x3 CPU part : 0xc08 CPU revision : 2 Hardware : Generic AM33XX (Flattened Device Tree) Revision : 0000 Serial : 0000000000000000Vysledek "openssl speed aes-256-cbc" na modemu je navic radove srovnatelny s mym intel laptopem:
# openssl speed aes-256-cbc Doing aes-256 cbc for 3s on 16 size blocks: 3019223 aes-256 cbc's in 2.98s Doing aes-256 cbc for 3s on 64 size blocks: 811793 aes-256 cbc's in 2.98s Doing aes-256 cbc for 3s on 256 size blocks: 210625 aes-256 cbc's in 2.98s Doing aes-256 cbc for 3s on 1024 size blocks: 53233 aes-256 cbc's in 2.98s Doing aes-256 cbc for 3s on 8192 size blocks: 6672 aes-256 cbc's in 2.99s OpenSSL 1.0.2h 3 May 2016 built on: reproducible build, date unspecified options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) idea(int) blowfish(ptr) compiler: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -O3 -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-256 cbc 16210.59k 17434.48k 18093.96k 18292.14k 18279.94k
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
gre1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:xxx.xxx.xxx.xxx P-t-P:xxx.xxx.xxx.xxx Mask:255.255.255.255
UP POINTOPOINT RUNNING MTU:1472 Metric:1
RX packets:45 errors:0 dropped:0 overruns:0 frame:0
TX packets:704 errors:30 dropped:4547 overruns:0 carrier:30
collisions:0 txqueuelen:0
RX bytes:6599 (6.4 KB) TX bytes:768264 (750.2 KB)
usb0 Link encap:Ethernet HWaddr DE:AD:BE:EF:00:00
inet addr:/modem_ip/ Bcast:100.255.255.255 Mask:255.255.255.255
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:401 errors:0 dropped:0 overruns:0 frame:0
TX packets:1121 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:176854 (172.7 KB) TX bytes:897120 (876.0 KB)
Nedari se mi ale zjistit kde a proc se ty ramce ztraceji. Snazil jsem se chytat pomoci tcpdumpu ramce na gre rozhrani i na WAN/LTE(usb0) rozhrani. Prijde mi, ze na GRE vidim vsechny, ale ve streamu na WAN rozhrani jsou videt "diry" IPSecovych ESP sequence #:
No. Time Source Destination Protocol Length Info
115 0.098272 /modem_ip/ /cisco_ip/ ESP 1326 ESP (SPI=0x1a975dd3)
Frame 115: 1326 bytes on wire (10608 bits), 300 bytes captured (2400 bits)
Ethernet II, Src: de:ad:be:ef:00:00 (de:ad:be:ef:00:00), Dst: 02:50:f3:00:00:00 (02:50:f3:00:00:00)
Internet Protocol Version 4, Src: /modem_ip/ (/modem_ip/), Dst: /cisco_ip/ (/cisco_ip/)
User Datagram Protocol, Src Port: ipsec-nat-t (4500), Dst Port: ipsec-nat-t (4500)
UDP Encapsulation of IPsec Packets
Encapsulating Security Payload
ESP SPI: 0x1a975dd3 (446127571)
ESP Sequence: 3807
No. Time Source Destination Protocol Length Info
116 0.000393 /modem_ip/ /cisco_ip/ ESP 1326 ESP (SPI=0x1a975dd3)
Frame 116: 1326 bytes on wire (10608 bits), 300 bytes captured (2400 bits)
Ethernet II, Src: de:ad:be:ef:00:00 (de:ad:be:ef:00:00), Dst: 02:50:f3:00:00:00 (02:50:f3:00:00:00)
Internet Protocol Version 4, Src: /modem_ip/ (/modem_ip/), Dst: /cisco_ip/ (/cisco_ip/)
User Datagram Protocol, Src Port: ipsec-nat-t (4500), Dst Port: ipsec-nat-t (4500)
UDP Encapsulation of IPsec Packets
Encapsulating Security Payload
ESP SPI: 0x1a975dd3 (446127571)
ESP Sequence: 3808
No. Time Source Destination Protocol Length Info
117 0.000181 /modem_ip/ /cisco_ip/ ESP 1326 ESP (SPI=0x1a975dd3)
Frame 117: 1326 bytes on wire (10608 bits), 300 bytes captured (2400 bits)
Ethernet II, Src: de:ad:be:ef:00:00 (de:ad:be:ef:00:00), Dst: 02:50:f3:00:00:00 (02:50:f3:00:00:00)
Internet Protocol Version 4, Src: /modem_ip/ (/modem_ip/), Dst: /cisco_ip/ (/cisco_ip/)
User Datagram Protocol, Src Port: ipsec-nat-t (4500), Dst Port: ipsec-nat-t (4500)
UDP Encapsulation of IPsec Packets
Encapsulating Security Payload
ESP SPI: 0x1a975dd3 (446127571)
ESP Sequence: 3899
No. Time Source Destination Protocol Length Info
118 0.103109 /modem_ip/ /cisco_ip/ ESP 1326 ESP (SPI=0x1a975dd3)
Frame 118: 1326 bytes on wire (10608 bits), 300 bytes captured (2400 bits)
Ethernet II, Src: de:ad:be:ef:00:00 (de:ad:be:ef:00:00), Dst: 02:50:f3:00:00:00 (02:50:f3:00:00:00)
Internet Protocol Version 4, Src: /modem_ip/ (/modem_ip/), Dst: /cisco_ip/ (/cisco_ip/)
User Datagram Protocol, Src Port: ipsec-nat-t (4500), Dst Port: ipsec-nat-t (4500)
UDP Encapsulation of IPsec Packets
Encapsulating Security Payload
ESP SPI: 0x1a975dd3 (446127571)
ESP Sequence: 3905
Podle toho mi to pripada, jakoby se modemu podarilo nejak zasifrovat a pripravit data pro ESP packet, ale problem nastal az pri encapsulaci do UDP a data se mu nakonec nepodarilo odeslat. Nevim ale, kam se dal podivat, co proverit, pripadne nastavit.
Moje google-fu me zradilo, jedine podobne zoufale lidi jsem nasel u mikrotiku, jinak nic 
Nemate s tim prosim nekdo zkusenost, nenapada vas neco?
Diky.
Nevim, jestli to neoveruju nejak divne. Zkousel jsem jeste chovani toho samotneho IPSecu v tunnel rezimu, bez GRE. Kdyz posilam ze strany modemu stream 5Mbps, tak na druhou stranu dorazi 20% - tedy ten 1Mbps, jak jsem psal vcera. Jenze kdyz generuju ze strany modemu stream 50Mbps, tak na druhou stranu dorazi zase zhruba 20%, tedy cca 9Mbps. Pri 80Mbps streamu zase 20% ~ 14Mbps. Vic jsem nezkousel. V kazdem pripade je ten sycak schopny tech 14Mbps vzit, zasifrovat, encapsulovat a po LTE poslat na druhou stranu.
Kdyz vratim konfiguraci s GRE, tak to tohle chovani kopiruje, jen s tim rozdilem, ze na druhou stranu dorazi jen 10%. Tedy pri streamu 5Mbps je to tech 500Kbps, pri 50Mbps streamu projde na druhou stranu 5Mbps.
Pricemz kdyz rikam, ze nedorazi na druhou stranu, tak ve skutecnosti ani neodejdou z modemu do LTE site.
Ma to doknce 3 eth port, pricemz ten treti je sam o sobe jeste triportovy switch. Zkusil jsem nastavit IPSec v tunnel rezimu proti pocitaci na druhe strane ethernet kabelu. Je to o pidu rychlejsi, ale jinak se to chova stejne. Ciste po ethernetu, bez IPSecu to jelo cca 93Mbps - to mi ukazal iperf jak v TCP, tak i v UDP rezimu. Kdyz jsem ned tim spustil ten IPSec, tak mi to pri tom 50Mbps UDP streamu na druhe strane ukazalo cca 11Mbps (namisto 9 pri komunikaci pres LTE). Kdyz jsem tam zkusil poslat 95Mbps stream, tak se na druhou stranu dostalo 20Mbps. Kdyz jsem vyzkousel vykon tcp, na kolik se to rozjede, tak se to pohybovalo kolem 8Mbps.
Ano, firmware je tam 6.0.1 ze zacatku zari.
Ano, diky, vyzkousim to. Prijde mi, ze honim nejake duchy kolem casovani, interruptu, nebo neceho podoneho a to jeste na certvijake architekture, na ktere je to postavene. Jen je mi divne, a jsem ze sebe zklamany, ze z zadneho cat /proc/* , ani z ip xfrm, ani whack cokoliv, ani z niceho podobneho nejsem schopny zjistit, kde se to v tom kernelu ztraci, co ma presne za problem. Ted, kdyz nepouzivam ani ten GRE tunnel, kde alespon naskakoval ten dropped counter, tak se tvari uplne vsechno jako v poradku, pritom zahazuje 80% packetu.
24.9.2016 22:09
Max | skóre: 72
| blog: Max_Devaine
tracepath -n IP_stroje_za_tunelemA pak projistotu pingem :
ping -c 1 -M do -s 1400 IP_stroje_za_tunelemJá totiž osobně nevím, jak se iperf chová, zda posílá DF (dont fragment), nebo ne. Když mi něco v síti straší, raději to zkontroluji více nástroji.
24.9.2016 22:15
Max | skóre: 72
| blog: Max_Devaine
tracepath dopadne takhle:
[root@server ~]# tracepath -n /za_modemem/
1: xxx.xxx.xxx.xxx 0.161ms pmtu 1500
1: xxx.xxx.xxx.xxx 0.866ms
1: xxx.xxx.xxx.xxx 0.792ms
2: xxx.xxx.xxx.xxx 5.250ms
3: xxx.xxx.xxx.xxx 1.551ms
4: xxx.xxx.xxx.xxx 1.620ms pmtu 1472
4: /modem/ 268.024ms
5: /za_modemem/ 31.419ms reached
Resume: pmtu 1472 hops 5 back 60
[root@za_modemem ~]# tracepath -n /server/
1?: [LOCALHOST] pmtu 1500
1: /modem/ 5.504ms
1: /modem/ 3.000ms
2: /modem/ 2.020ms pmtu 1414
2: no reply
3: no reply
4: no reply
5: no reply
6: no reply
7: no reply
8: no reply
9: no reply
10: no reply
11: /server/ 40.301ms reached
Resume: pmtu 1414 hops 11 back 5
Ping projde:
[root@proxy ~]# ping -c 1 -M do -s 1400 /za_modemem/ PING /za_modemem/ (/za_modemem/) 1400(1428) bytes of data. 1408 bytes from /za_modemem/: icmp_seq=1 ttl=60 time=259 ms --- /za_modemem/ ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 259ms rtt min/avg/max/mdev = 259.837/259.837/259.837/0.000 ms
Pokud se tyka iperfu, tak alespon u tech UDP datagramu, se kterymi to zkousim, DF nenastavuje. Navic skutecne bere v potaz velikost zadanou parametrem -l na prikazove radce. Datagramy, ktere pak generuje, vypadaji takhle:
Frame 38: 1242 bytes on wire (9936 bits), 300 bytes captured (2400 bits)
Internet Protocol Version 4, Src: /za_modemem/ (/za_modemem/), Dst: /server/ (/server/)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
Total Length: 1228
Identification: 0xc490 (50320)
Flags: 0x00
0... .... = Reserved bit: Not set
.0.. .... = Don't fragment: Not set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: UDP (17)
Header checksum: 0xd366 [validation disabled]
Source: /za_modemem/ (/za_modemem/)
Destination: /server/ (/server/)
User Datagram Protocol, Src Port: 62251 (62251), Dst Port: targus-getdata1 (5201)
Data (258 bytes)
Pral bych si, aby to byl problem s MTU. Sice bych si pripadal trapne, ze jsem na to neprisel, protoze to take byla prvni vec, co me napadla a kterou jsem se snazil vyloucit, ale i tak bych to bral 
jaka verze IOSu je na 871 muzete ji zmenit ? #----------------------------- neco podobneho mi delalo cisco<->cisco ... diry v ipsecu ... v tunelovacim modu pokud na lince nastal trochu jam v zavislosti na delce paketu .... kdyz jsem to debugoval tak to bylo nekde okolo fragmentace .... ted verzi nevim .... ale v podstate po 2 dnech trapeni a loveni duchu byla oprava nahranim posledni stable advipserv.. a rychle pryc .... #------------------------------------- ios na ozkouseni muzu poslat nebo to zaridit i legalne ale 871 uz asi pod supportem nebude ta je end-off-vsechno #--------------------------------brandejs maelstrom vertix.cz
Diky, je pravda, ze je tam nejaka vykopavka s ios 12.4, ale to Cisco jsem myslim temi pokusy s PC routerem zapojenym primo na LAN vyloucil.
I v pripade, kdy jsem mel linuxovy router terminujici IPSec zapojeny na druhem rozhrani toho modemu, se to chovalo prakticky stejne.
Zkousel jsem ze strany modemu posilat stream udp datagramu velky 1200b a postupne jsem zvysoval datovy tok. Zacal jsem na 50Kbps, to prochazelo v poradku. Kdyz jsem se dostal na cca 200Kbps (a tedy asi 20pps), tak zacaly vypadavat prvni packety. Procento vypadnuvsich packetu se se vzrustajicim tokem postupne zvysovalo. Na tom by asi nebylo nic divneho (kdyby se to tedy cele neodehravalo pri tak malych tocich), jenze pri cca 5Mbps, kdy vypadavalo 80% packetu se zacala ztratovost drzet na stejne procentualni hodnote a celkova propustnost dale rostla. Pri 5Mbps tedy prosel cca 1Mbps, pri 50Mbps proslo 10Mbps a pri 80Mbps cca 16Mbps. Od 90Mbps se ztratovost zacala zase zvysovat, ale za to bych se na nej uz nezlobil .
Sorry, datagramy byly pochopitelne velke 1200B.
Jinak i kdyz jsem pak velikost datagramu zmensoval, az na nejakych 200B, tak k prvnim vypadkum zacinalo dochazet stale pri tech cca 20pps, tedy pri daleko nizsi prenosove rychlosti.
Tiskni
Sdílej:
