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 ] ( 5071 zobrazení ) trvalý odkaz související odkaz ( 3 / 34085 )
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 ] ( 1617 zobrazení ) trvalý odkaz ( 3 / 29136 )
Zpřístupnění komentářů 

Hlad po hře World of Warcraft je zřejmě nekonečný. Jak jinak si vysvětlit, že se našel spammer, co si dal práci s tím, aby pomocí OCR rozpoznal CAPCHA obrázek a cíleným útokem na blogy, poháněné Simple PHP blogem, je zahltil odkazy s nabídkou WoW.

To mě konečně vybudilo k tomu, trošku se v kódu blogu povrtat a vyměnit techniku s nedokonalým CAPCHA obrázkem (která navíc znepřístupňuje komentování nevidomým a slabozrakým) za techniku jednoduchého kvízu, doplněného javascriptovou nápovědou, podle návodu zde.. Vymyslel jsem pár triviálních otázek a odpovědí, ale pokud máte zapnutý javascript, ani si jich nevšimnete - vyplní správnou odpověď za vás. Řešení počítá s tím, že spamovací robot neumí spouštět javascript.

Tak jsem zvědav, jaký to bude mít efekt na četnost spamů. Zdrojové kód úprav (patche) záměrně neuvádím, protože (a) je to prasárna, a z toho vyplývá (b) by v tom ještě někdo mohl najít díru :). Případnému zájemci ale kód rád pošlu.
[ zobrazit záznam ] ( 1671 zobrazení ) trvalý odkaz související odkaz ( 3 / 33310 )
Jak na numerickou klávesnici ve Wine přes VNC 

Zmiňovaný problém mi dal docela zabrat. Samostaný VNC Xserver Xvnc zřejmě nemapuje správně numerickou klávesnici, takže ačkoli to v některých programech, jako třeba xterm chodí, v jiných, jako třeba Wine nikoli. Nakonec jsem našel řešení zde. A pro případ, že by nevydrželo, tak ho sem radší zkopíruju:

1) Vytvořit soubor ~/.xmodmap s následujícím obsahem:
! initialization,
! Ensure that we have all keysyms we're going to use assigned to something.

keycode any = KP_Insert
keycode any = KP_End
keycode any = KP_Down
keycode any = KP_Next
keycode any = KP_Left
keycode any = KP_Begin
keycode any = KP_Right
keycode any = KP_Home
keycode any = KP_Up
keycode any = KP_Prior
keycode any = KP_Delete

! Set the keypad to numeric mode.
! You may need to adjust KP_Next/KP_Prior; possible alternatives
! are KP_Page_Down/KP_Page_Up or just Next/Prior.
! just Next.
keysym KP_Insert = KP_0
keysym KP_End = KP_1
keysym KP_Down = KP_2
keysym KP_Next = KP_3
keysym KP_Left = KP_4
keysym KP_Begin = KP_5
keysym KP_Right = KP_6
keysym KP_Home = KP_7
keysym KP_Up = KP_8
keysym KP_Prior = KP_9
keysym KP_Delete = KP_Decimal

2) zařídit, aby se po spusštění Xvnc serveru zavolalo xmodmap ~/.xmodmap
[ zobrazit záznam ] ( 21973 zobrazení ) trvalý odkaz související odkaz ( 3 / 23698 )
Automatická konfigurace DNS a DHCP serverů pro síť LAN 

Jako semestrální práci z předmětu X32PRS jsem si zvolil úlohu "Síť LAN". V ní jde o to, z jednotné databáze počítačů, obsahující jméno počítače, IP adresu a MAC adresu, vygenerovat patřičné konfigurační soubory pro server dhcpd a named, tak aby pro každý počítač existoval statický záznam v DHCP a zároveň dopředný a zpětný záznam v DNS. Výsledek mého snažení je zde. Nakonec se to mělo odevzdávat i s prezentací, tak jsem k tomu za pár minut spíchnul tuto prezentaci.

Tak pokud se to někdo rozhodnete nasadit, přeji hodně štěstí.
[ zobrazit záznam ] ( 1675 zobrazení ) trvalý odkaz související odkaz ( 3 / 40113 )

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