Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Ondřej Caletka

Stran: 1 ... 12 13 [14] 15 16 ... 55
196
Sítě / Re:Rychlost připojení O2
« kdy: 07. 06. 2019, 10:19:52 »
Kolik ta nová rychlost má být a kolik je ve skutečnosti? Modem píše, že se spojil na 55/5 Mbps, s tím že je ochoten jít až na 134/34 Mbps.

Data Rate                                  55103 kbps     5118 kbps
Max Rate                                134492 kbps   34561 kbps

197
Sítě / Re:Mikrotik, IPv6 a ISP Metronet
« kdy: 15. 05. 2019, 09:34:24 »
Dekuji, dekuji, dekuji. Ano to byl ten chybejici stripek do skladacky. Vubec me nenapadlo zkusit znova dhcpv6 klienta po tom, co sem dostal novou technickou specifikaci s IPv6 WAN.
Tim se veskere nastaveni IPv6 u Metronetu na mikrotiku smrsklo na rucni nastaveni IPv6 wan a pak uz klasicky DHCPv6 klient s prislusenstvim :) Zase sem se neco naucil.
Myslím si, že ani ruční adresu WAN nastavovat není potřeba. Když tam nebude žádná, router si půjčí pro sebe svou adresu z LAN. Prostě, mělo by to fungovat Plug&Play, tedy kromě MikroTiku, kde ve výchozím stavu podpora IPv6 vůbec není.

198
Sítě / Re:Mikrotik, IPv6 a ISP Metronet
« kdy: 13. 05. 2019, 20:21:59 »
Takze ted od nich mam:
IPv6 WAN: xxxx:yyyy:D5:3D::/64
IPv6 LAN: xxxx:yyyy:D501:3400: :/56

Podle mě to bez DHCPv6 klienta nebude fungovat. Na straně operátora totiž musí existovat záznam ve směrovací tabulce pro /56 LAN prefix směrem k vašemu routeru a ten se obvykle vyrábí dynamicky na základě analýzy DHCPv6 zpráv, které přes zařízení poskytovatele prochází. Pokud si tedy o prefix neřeknete, tohle zařízení se nedozví, kam má data směřující do vašeho LAN prefixu posílat.

Můžete to vyzkoušet tak, že traceroutujete svůj LAN prefix z internetu. Posledním hopem by měl být WAN prefix vašeho routeru. Pokud se ve skutečnosti bude směrování cyklit někde dřív, je to chybějící záznam ve směrovací tabulce. Pokud jsem správně odanonymizoval adresy tazatele, vypadá to přesně na tenhle případ.

Kód: [Vybrat]
$ traceroute 2a01:510:d504:3400::
traceroute to 2a01:510:d504:3400:: (2a01:510:d504:3400::), 30 hops max, 80 byte packets
 6  * * *
 7  2001:1a48:ffff::52 (2001:1a48:ffff::52)  9.756 ms  9.769 ms  9.755 ms
 8  2a01:510:0:90dd::1 (2a01:510:0:90dd::1)  12.421 ms  10.426 ms  10.416 ms
 9  2a01:510:0:90dd::2 (2a01:510:0:90dd::2)  10.406 ms  10.399 ms  10.839 ms
10  2a01:510:0:90dd::1 (2a01:510:0:90dd::1)  10.369 ms  10.388 ms  10.382 ms
11  2a01:510:0:90dd::2 (2a01:510:0:90dd::2)  13.500 ms  13.903 ms  13.930 ms
12  2a01:510:0:90dd::1 (2a01:510:0:90dd::1)  10.889 ms  10.888 ms *
13  2a01:510:0:90dd::2 (2a01:510:0:90dd::2)  110.929 ms  113.123 ms  114.105 ms

199
Software / Re:Vlastnoruční podepisovaní přes tablet
« kdy: 25. 04. 2019, 09:19:30 »
Tohle někdo akceptuje s nenulovou právní váhou? (jako už jsem to také zažil, pošťák po mně chtěl něco nakreslit na displej)
V ČSOB se některé dokumenty (banka je tak velká, že má různé agendy v různých systémech, takže ne všechny dokumenty) podepisují právě na tabletu Samsung Galaxy Tab pomocí pera S-pen. Nevím, co to je za aplikaci, pravděpodobně nějaká jejich vlastní. V každém případě z toho soudím, že i u běžného komoditního hardwaru je možné docílit podpisu s nenulovou právní váhou.

Edit: podle referencí se zdá, že jde o ten výše zmíněný systém Signatus.

200
Server / Re:NTP Servery, timezone
« kdy: 16. 04. 2019, 14:40:41 »
A ještě pro jistotu doplním, že NTP žádná časová pásma neřeší, přenáší vždy UTC. Převod z UTC do lokálního času je vždy záležitost prezentace v konkrétním koncovém systému.

201
Sítě / Re:Síť po dvou drátech
« kdy: 15. 04. 2019, 16:10:35 »
Dva DSL routery určitě fungovat nebudou, na jedné straně musí být DSLAM. Co ale může fungovat a může být poměrně levné je použití powerline modemů, které jsou určené pro komunikaci po elektrické síti. Ale pokud ty telefonní dráty nejsou dimezovány na síťové napětí (jako že asi nejsou), vyžaduje to úpravu těch powerline modemů.

202
K těm vypínačům na prodlužce. Standardně by měly vypínat fázi, ale neplatí to vždy. Pokud máte třeba rozbočovač do T, nebo v zásuvce obráceně fázi nebo to výrobce prodlužky popletl, tak vám to vypne nulu místo fáze. Z hlediska bezpečí tedy nanic.
Tedy, nemyslím si, že původní záměr tazatele byl vypínat počítač za účelem zvýšení bezpečnosti proti úrazu elektrickým proudem. Zvlášť pokud se bavíme o vypínání na dobu, kdy člověk není doma.

Jinak žiju v přesvědčení, že u přístrojů s pohyblivým přívodem je snad už nějakých pár let standardem dvoupólové vypínání obou pracovních vodičů. Někde jsem to četl ve výkladu nějaké normy. Rozhodně všechny běžně prodávané prodlužky jsou tak zapojeny. Naopak orientace pracovních vodičů v zásuvce je pouze doporučená, nikdo se na ni nemůže spoléhat. Tím spíš, že většina vidlic jde zapojit i do „něměckých“ Schuko zásuvek, kde není orientace pracovních vodičů garantovaná vůbec.

203
Odkladiště / Re:Náhrada Google+ open source
« kdy: 26. 03. 2019, 20:50:14 »
Dobrý večer, za cca týden končí Google+, mám tam poměrně dost galerií s obrázky a videi. Nemáte nějaký tip na open source alternativu?
Galerie s obrázky a videi už dávno nejsou součástí Google Plus, ale jsou vyděleny do samostatné služby Google Photos. Ta rozhodně nekončí.

204
Sítě / Re:IPv6 za NATem
« kdy: 15. 03. 2019, 12:21:29 »
Řešení je samozřejmě požádat ISP o přidělení IPv6. Zrovna nedávno jsem na jednom setkání ISP byl a někteří z nich říkali: „Dáváme IPv6 každému, kdo si řekne. Loni si třeba neřekl nikdo.“ Pokud jde o GPONovou síť, ta téměř jistě IPv6 podporuje a stačí to pouze nakonfigurovat.

Jako řešení poslední záchrany existují třeba IPv6 tunely od vpsFree.cz.

205
Sítě / Re:Raspberry Zero W - pripojenie k WiFi hotspotu
« kdy: 08. 03. 2019, 12:26:50 »
Střílím od boku: Mobil používá kanál číslo 12 nebo 13 a na Raspberry je špatně nastavená regulační doména, takže tyto kanály vůbec nevidí. Ale jak to opravit, netuším.

206
Jestli hledas neco s DP alternate mode, tak to bude krabicka co ma JENOM display vystupy (hdmi nebo DP), jiste nebude mit v sobe USB3 hub nebo Gigabit ethernet. To proste dohromady nejde, nelze mit dva profily naraz aktivni! (u nekterych zustava pouzitelne jeste Usb2).
To není pravda. V USB konektoru typu C jsou 4 vysokorychlostní linky, z toho USB používá pouze dvě. Kombinace vysokorychlostního USB (5 nebo 10 Gbps) a DP alt mode je zcela běžná a běžně podporovaná, například v tomto zařízení (to i vlastním a potvrzuji, že funguje).

Wikipedie k tomu píše:
Citace
One, two or all four of the differential pairs that USB uses for the SuperSpeed bus can be configured dynamically to be used for DisplayPort lanes. In the first two cases, the connector still can carry a full SuperSpeed signal; in the latter case, at least a non-SuperSpeed signal is available.

207
Sítě / Re:Problém s fragmenty IPv6
« kdy: 18. 02. 2019, 20:12:31 »
Markovi Majkowskemu, který testovací nástroj napsal jsem problém nahlásil.
Marek dnes upravil velikost IPv6 fragmentů na 1280, takže v tuhle chvíli už test funguje i pro jádra 4.19 - 5.0.

208
Sítě / Re:Problém s fragmenty IPv6
« kdy: 18. 02. 2019, 10:00:27 »
...takže ten commit se asi v dohledné době bude revertovat, ale nejdřív bude potřeba změnit implementaci fragment queue pro IPv6 na rbtree (místo lineárního seznamu), stejně jako to už je u IPv4.
Ta změna už je v net-next stromě a měla by se tedy dostat do 5.1-rc1.
To je ale škoda. Tohle chování dávalo smysl a podle mě by byla lepší cesta jít s tím do IETF a takovéto chování standardizovat. Byť to bude jistě náročné, vzhledem k tomu, že se jedná o editaci RFC 8200, což je po tolika letech konečně Internet Standard.

209
Sítě / Re:Problém s fragmenty IPv6
« kdy: 17. 02. 2019, 20:26:21 »
Ta změna je skutečně od jádra 4.19. Myslím, že to je bezpečné, na rozdíl od IPv4, kde je minimální MTU definované tak nízko, že o něm nemá cenu mluvit (68 Bajtů, navíc to zřejmě není úplně jednoznačné), je u IPv6 jasně řečeno, že každá linka má minimálně 1280 B. Akceptování menších fragmentů naopak může být bezpečnostní riziko, protože fragmenty často používají útočníci k ošálení First Hop Security funkcí na switchích.

Markovi Majkowskemu, který testovací nástroj napsal jsem problém nahlásil.

ODVR posílají UDP odpovědi o velikosti payloadu 1240 B, což spolu s 40B IPv6 hlavičkou dává přesně 1280, tedy minimální MTU. Můj Linux to v každém případě neodmítá. I když, jak to teď testuju, tak mi to úplně dobře neprochází a to dokonce u dvou různých operátorů. Oni fragmentovaný provoz nemají rádi – v normálním provozu se prakticky nevyskytuje, zato při zaplavovacích útocích tvoří velkou část provozu a nedá se prakticky nijak filtrovat.

Takže je možné, že problém s fragmenty skutečně někde bude.

210
Sítě / Re:Problém s fragmenty IPv6
« kdy: 17. 02. 2019, 18:17:31 »
Pro ověření nastavení používám http://icmpcheckv6.popcount.org/ a všiml jsem si, že mi to teď hlásí chybu s příjmem fragmentů.

Tohle je skvělá služba, tu jsem neznal! Jen na IPv6 nefunguje kontrola fragmentů úplně dobře. Ve Wiresharku příchozí fragmenty vidím, ale spojení skutečně timeoutuje:

Kód: [Vybrat]
$ curl -v -s http://icmpcheckv6.popcount.org/frag -o /dev/null -6
* Expire in 0 ms for 6 (transfer 0x5609092c7610)
*   Trying 2a01:7e01::f03c:91ff:fe16:a2e9...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x5609092c7610)
* Connected to icmpcheckv6.popcount.org (2a01:7e01::f03c:91ff:fe16:a2e9) port 80 (#0)
> GET /frag HTTP/1.1
> Host: icmpcheckv6.popcount.org
> User-Agent: curl/7.64.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Sun, 17 Feb 2019 16:42:27 GMT
< Content-Type: text/plain; charset=utf-8
< Connection: close
< Transfer-Encoding: chunked
<
{ [14 bytes data]
* Recv failure: Spojení zrušeno druhou stranou
* Closing connection 0

Ve wiresharku to vypadá takhle:
Kód: [Vybrat]
    4 0.035154828 JÁ → ONI HTTP 178 GET /frag HTTP/1.1 
    5 0.067141431 ONI → JÁ TCP 86 80 → 45658 [ACK] Seq=1 Ack=93 Win=28672 Len=0 TSval=2835193871 TSecr=4138280037
    6 0.067171239 ONI → JÁ TCP 244 80 → 45658 [PSH, ACK] Seq=1 Ack=93 Win=28672 Len=158 TSval=2835193871 TSecr=4138280037 [TCP segment of a reassembled PDU]
    7 0.067196896 JÁ → ONI TCP 86 45658 → 80 [ACK] Seq=93 Ack=159 Win=64896 Len=0 TSval=4138280069 TSecr=2835193871
    8 0.126013863 ONI → JÁ IPv6 574 IPv6 fragment (off=0 more=y ident=0xee4e5889 nxt=6)
    9 0.126074900 JÁ → ONI ICMPv6 622 Parameter Problem (erroneous header field encountered)
   10 0.126106083 ONI → JÁ IPv6 574 IPv6 fragment (off=512 more=y ident=0xee4e5889 nxt=6)
   11 0.126119450 JÁ → ONI ICMPv6 622 Parameter Problem (erroneous header field encountered)
   12 0.126130690 ONI → JÁ TCP 283 80 → 45658 [ACK] Seq=159 Ack=93 Win=28672 Len=1213 TSval=2835193871 TSecr=4138280037 [TCP segment of a reassembled PDU]

Je vidět, že můj počítač aktivně odmítá hned přijetí prvního fragmentu ICMPv6 chybu Parameter Problem s podproblémem „erroneous header field encountered“ a offsetem chyby 40, tedy za posledním bajtem IPv6 hlavičky. V hlavičkových souborech Linuxu se o vyslání této chyby stará funkce icmpv6_param_prob a hodnota „erroneous header field encountered“ je kódovaná definicí ICMPV6_HDR_FIELD.

Grepování zdrojáků jádra mě dovedlo do souboru resassembly.c. A k vyvolání této výjimky dojde v okamžiku, kdy je přijat fragment kratší než minimální MTU pro IPv6, což je 1280. Protože služba posílá fragmenty délky 512 bajtů, nemůže to s aktuálním Linuxem fungovat nikdy.

Ovšem pokud fragmenty nevidíš ani v tcpdumpu/tsharku/wiresharku, je problém i někde jinde.


Stran: 1 ... 12 13 [14] 15 16 ... 55