O šokové změně 

Je zajímavé, jak se Vám celý svět dokáže rozplynout před očima doslova lusknutím prstu. Ještě v pátek 31. října 2008 jsem usínal s pocitem radosti, že se mi na poslední chvíli přeci jen podařilo přeladit strahovské vysílání DVB over IP na nové digitální sítě 1 a 2, a těšil jsem se, jak budu o týden později na exkurzi na petřínské lanovce a týden na to v českém Rozhlase. Přišla sobota 1. listopadu a s ní naprosto nečekaná zdravotní komplikace. Vzhledem k tomu, že si s ní nebyl s to poradit lékař na pohotovosti v sobotu, poslal mě v pondělí za odborníky. Odborný lékař prohlásil: "Vás si tady necháme." Zcela šokován jsem za pár chvil ležel na nemocniční posteli. Pak jsem vystřízlivěl a řekl si, že třeba to bude jen pár dní a za týden budu v pořádku. Druhý šok přišel dnes, kdy se mi konečně podařilo lékaře odchytit a zeptat se na pár otázek. Odpověděl, že léčba potrvá 2-3 měsíce a bude zakončena operací. Jediné světlé místo na tom celém je, že většinu léčby strávím v domácím ošetřování. Nicméně se školou je konec a s tím i naděje na to, že bych byl s to školu dokončit v řádném termínu. Ve skutečnosti nejde zas o takovou tragédii, spousta lidí nastavuje školu jen z rozmaru, ale pro mě to bylo naprosté zhroucní všech základů, na kterých můj svět stojí.

V souvislosti s touto událostí jsem tedy nucen omluvit se ze všech plánovaných akcí a zřejmě i z přispívání na tento weblog.

Přeji všem svým čtenářům hodně zdraví. A pokud vám v těle funguje všechno jak má, pochvalte ho někdy. Člověku to připadá jako naprostá samozřejmost, ale tak samozřejmé to zdaleka není.
[ zobrazit záznam ] ( 797 zobrazení ) trvalý odkaz ( 3 / 10898 )
Jak měřit teplotu prostřednictvím PC 

Meření teploty počítačem je věčné téma. Způsobů, jak jí měřit je také mnoho. Můj bratr na mě přišel s požadavkem, měřit nějak teplotu ve sklepě, aby věděl, zda už nastal čas zazimovat tam želvu :)

Prohrabal jsem šuplíkové zásoby a našel integrovaný teploměr pro SMBus DS1631 s přesností 0,5 stupně Celsia. Tak jsem si říkal, že by bylo dobré prostě ho připojit na sběrnici SMBus nějakého PC a jeho obsah číst přes standardní balík LM-sensors.

Ale narazil jsem. První problém byl v tom, že žádný počítač, co jsem měl k dispozici, neměl sběrnici SMBus vyvedenou do patřičného konektoru. A pájet přímo na nožičky SPD EEPROM u DIMM modulů mi připadalo nevhodné.


Začal jsem tedy přemýšlet, kde ještě v počítači je sběrnice I2C. A záhy mě napadl kanál DDC, pomocí kterého komunikuje monitor s grafickou kartou, aby sdělil svá podporovaná rozlišení. Po chvilce Gůglení jsem našel i stránku, příznačně nazvanou 25 cent I2C adapter, která prostřednictvím krásných obrázků informuje, že kromě I2C se ve VGA konektoru najde i +5V pro napájení teplotního čidla a že v linuxu takové řešení funguje s kartami ATI a NVidia.

Našel jsem tedy nějakou starou kartu ATI, vyrobil jednoduchou redukci z VGA na VGA s odbočkou a připojil. i2cdetect čip skutečně našel, a dokonce jsem z příkazového řádku podle datasheetu dokázal přečíst teplotu z čipu. Druhý zádrhel ovšem nastal s ovladači teplotního čidla z balíku lm-sensors. Součástí jádra totiž je ovladač pro DS1621 - starší model, se kterým je DS1631 zpětně kompatibilní. I když jsem však modul zavedl s příznakem force a nastavil adresu, na které senzor byl, ovladač odmítl spolupracovat.
Číst dále...
[ zobrazit záznam ] ( 4896 zobrazení ) trvalý odkaz související odkaz ( 3 / 10460 )
Jak v linuxu přehrát videa z archivu České televize 

EDIT: Nová verze zde.

Česká televize má na svém webu http://www.ceskatelevize.cz/vysilani/ poměrně rozsáhlý archiv pořadů. V linuxu je tento archiv bohužel jen těžko přehratelný, protože závisí na zásuvných modulech do prohlížeče. Rozjet to v případě 64-bitového prohlížeče a 32-bitového binárního realplayera považuji za nadlidský úkol. A zbytečný. Navíc i když se mi to u 32bitového počítače povedlo, výsledek nebyl dobrý. Přehrávač nenabízel režim full screen a tak bylo potřeba dívat se na malé okno.

Když jsem si dal práci a vyzobal ze zdrojového kódu sáhodlouhý odkaz na video, podařilo se mi ho bez problémů přehrát v mplayeru. Tak jsem vyrobil skriptík, co několikeré vyzobnutí adresy streamu provede za mě:
#!/bin/bash
exec 2>/dev/null

URL="$1"
if (echo $URL | grep -qv '?streamtype'); then
URL="${URL}?streamtype=RH"
fi
#echo $URL

SMILURL=$(wget -O - "$URL" |grep '<param name="src"' | sed -r 's/.*value="([^"]+)".*/http:\/\/www.ceskatelevize.cz\1/')
#echo $SMILURL

RAMURL=$(wget -O - "$SMILURL" |grep http://ct1stream | sed -r 's/^.*(http:\/\/[^"]+ram).*$/\1/')
#echo $RAMURL

RAWURL=$(wget -O - "$RAMURL")
echo $RAWURL
Skriptíku stačí předat URL stránky s pořadem ve formátu Real rychlé a jeho výstupem je odkaz na rtsp stream, který již mplayer (s příslušnými kodeky) bez problému přehraje. Dá se to použít tedy třeba takto:
$ mplayer $(ctstream.sh http://www.ceskatelevize.cz/vysilani/04 ... ridic.html)
Pokud chcete záznam achivovat u sebe, je to také snadné, stačí k předchozímu přidat -dumpstream -dumpfile zaznam.rm

Přeji příjemné sledování! :)
[ zobrazit záznam ] ( 983 zobrazení ) trvalý odkaz související odkaz ( 3 / 12950 )
Jaká jaký je U:fonův Internetový balíček? 

Tak je to tady. U:fon konečně sehnal datové kabely a začal k mobilním telefonům nabízet datové služby, za podmínek, které anoncoval již červnu. Včera jsem ho byl koupit. Podle všeho jde opravdu jen o kabel, neobsahuje žádnou elektroniku. Za cenu 220 Kč se pravděpodobně ani nevyplatí vyrábět alternativní, neboť samotný systémový konektor telefonu bude jistě stát alespoň 100 Kč. (Mimochodem, jedná se pravděpodobně o nějaký běžný korejský konektor, neboť jsem zjistil, že minimálně nabíječka je zaměnitelná s nabíječkami telefonů LG). O tom, že USB je implementováno přímo v mikropočítači telefonu jako firmware svědčí i fakt, že pokud kabel připojím k telefonu, který se právě zapíná, skončí proces USB enumerace někde v půli cesty a Windows například vyhodí bublinku "Zařízení USB nebylo rozpoznáno".

Součástí kabelu bylo malé 8cm CD a velice strohý návod. Samozřejmě se mi po zasunutí CD do počítače nic neobjevilo, pokud bych se tedy držel striktně návodu, nikam bych se nedostal. Místo toho jsem mobil rovnou připojil k PC s linuxem. Jádro zařízení nalezlo, lsusb -v mimo jiné vypsalo:
  bDeviceClass            2 Communications
idVendor 0x1529
idProduct 0x3100
iManufacturer 1 UBIQUAM Co., Ltd.
iProduct 2 UBIQUAM CDMA USB Modem
iSerial 3 Serial Number

Kabel tedy podle všeho funguje a mobil se dokonce představil. Co víc, mobil nemá třídu ff - tedy vendor specific, ale 2 - Communications! Takže stačí v jádru zapnout volbu:
<M>     USB Modem (CDC ACM) support
a mobil se chytne a objeví v systému jako zařízení /dev/ttyACM0. Nutno přiznat, že v prvním počítači, do kterého jsem mobil zapojil jsem daný ovladač neměl a zařízení tak zůstalo bez obsuhy. I tak se mi ho podařilo zprovoznit pomocí generického ovladače usb-serial fíglem, který byl už kdysi popsán na Rootovi, jen s použitím Vendor ID / Product ID 0x1529 / 0x3100. Zařízení vzniklé tak či onak je obyčejný sériový port, takže pro jednoduché vyzkoušení funkčnosti stačí namířit na něj minicom a poslat AT. Mobil poslušně odpoví OK, takže vidíme, že vše funguje jak má. Není to však úplně stejný modem, jako ty v GSM mobilech. Když jsem zkusit vyvolit normální hlasové volání příkazem ATDxxxyyyzzz;, mobil místo prostého vytočení okamžitě snaží navazovat datové spojení (i přesto, že je na konci středník) a za pár sekund vyhlásí NO CARRIER. Pokud se pokusíme vyvolit číslo #777, což je přístupové číslo k Internetu, mobil okamžitě odpoví CONNECT a to i v případě, že služba není na daném přístroji vůbec aktivována.
Číst dále...
[ zobrazit záznam ] ( 4858 zobrazení ) trvalý odkaz související odkaz ( 3 / 14514 )
Skrytá hrozba jménem MTU 

Po dlouhé době opět jedna drobnost, která mě stála spousty přemýšlení. Jednoduchá modelová situace: Počítač s linuxem, sloužící jako firewall-NAT-router zakončuje PPPoE spojení od ADSL modemu (v režimu bridge) a prostřednictvím maškarády, potažmo SNATu (víte vůbec někdo, jaký je v tom rozdíl?) sdílí internetové připojení ostatním zařízením v lokální síti.

Jenže teď to nějak nefungovalo. Ne, že by to nefungovalo vůbec. Spíše šlo o typickou skrytou závadu - při pokusu cíleně odhalit její příčinu se neprojevila. Šlo o to, že určité www stránky se nenačítaly, či se jim pouze načetl titulek a pak bylo spojení ukončeno. Jiné stránky šly v pohodě. Pokud se ale použil http proxy server, běžící přímo na firewallu, šlo vše v pohodě.

Příčina těchto záhad se skrývala, jak již titulek napovídá, v nastavení MTU. Jak známo, ethernet umí přenést nejvýše 1500 B na paket, což vychází na hodnotu MTU 1460 B. Jenže díky 8 B záhlaví PPPoE je nejvyšší hodnota MTU na PPPoE spoji jen 1452 B. Zatímco počítač, na kterém byl PPP spoj přímo zakončen tuto informaci měl, ostatní počítače v síti o žádném PPP spojení nevěděly. Proto v záhlaví TCP segmentů s příznakem SYN nesprávně signalizovaly, že jsou schopni zpracovat větší množství dat, než odpovídalo realitě. Jak jsem zjistil zachycením komunikace na PPP rozhraní Wiresharkem, došlo k tomu, že příliš dlouhý paket byl na vzdálené straně PPP spojení zahozen. Protokol TCP sice zajistil opakování vysílání, ale i opakovaný segment byl zahozen. Za nějakou chvíli vypršel časový limit a spojení bylo zrušeno.

Nabízí se ovšem otázka, proč to tedy občas fungovalo? Zdůvodnění je dvojí - buď (1) nedošlo k naplnění celé velikosti paketu (například u telnetu, čí ssh) a/nebo (2) při zahození segmentu z důvodu překročení délky by měl prvek, který zahození provede, vygenerovat zdroji ICMP zprávu, ve které žádá o rozdělení segmentu na menší části. Takovouto zprávu pak server správně zpracuje a data rozdělí na menší kousky. Bohužel, někteří síťoví administrátoři mají takovou hrůzu ze zpráv protokolu ICMP, že je pro jistotu filtrují firewallem, někdy i včetně požadavku na odezvu (ping).

No a na závěr: Jak to spravit?
Takto:
# iptables -t mangle -I FORWARD 1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
[ zobrazit záznam ] ( 1513 zobrazení ) trvalý odkaz ( 3 / 12845 )

<<První <Zpět | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | Další> Poslední>>