Kevin Lin zkouší využívat chytré brýle Mentra při hraní na piano. Vytváří aplikaci AugmentedChords, pomocí které si do brýlí posílá notový zápis (YouTube). Uvnitř brýlí běží AugmentOS (GitHub), tj. open source operační systém pro chytré brýle.
Jarní konference EurOpen.cz 2025 proběhne 26. až 28. května v Brandýse nad Labem. Věnována je programovacím jazykům, vývoji softwaru a programovacím technikám.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Prosím o radu.
Mám Slackware 10.0 jako router. Na ETH1 (připojeném k poskutovateli) mám spuštěn dhclient (Internet Systems Consortium DHCP Client V3.1.0).
Adresu normálně dostanu, ale v MESSAGES se mi množí záznamy
Sep 20 03:40:05 router dhclient: DHCPREQUEST on eth1 to 10.193.24.1 port 67
Sep 20 03:40:38 router last message repeated 2 times
Sep 20 03:41:50 router last message repeated 5 times
v dhclient.leases mám
lease {
Z toho usuzuji, že DHCP server uvádí svojí IP adresu jako 10.193.24.1 - přitom ale když na to dojde, tak se adresa klienta obnoví z DHCP na adrese 89.103.163.1 - (viz. opět MESSAGES)
interface "eth1";
fixed-address 89.103.163.xxx;
option subnet-mask 255.255.255.0;
option time-offset 7200;
option routers 89.103.163.1;
option dhcp-lease-time 381587;
option dhcp-message-type 5;
option domain-name-servers 213.46.172.36,213.46.172.37;
option dhcp-server-identifier 10.193.24.1;
option broadcast-address 255.255.255.255;
renew 4 2009/09/24 04:43:18;
rebind 6 2009/09/26 04:59:38;
expire 6 2009/09/26 18:14:37;
}
Sep 22 10:14:33 router dhclient: DHCPREQUEST on eth1 to 10.193.24.1 port 67
Co s tím? Dá se nějak dhclient donutit, aby ignoroval tu adresu 10.193.24.1? Nebo jsou moje předpoklady špatné?
Sep 22 10:14:50 router dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67
Sep 22 10:14:50 router dhclient: DHCPACK from 89.103.163.1
Sep 22 10:14:50 router dhclient: IP address changed to 89.103.163.xxx
Sep 22 10:14:51 router dhclient: bound to 89.103.163.132 -- renewal in 160107 seconds.
Sep 24 06:43:18 router dhclient: DHCPREQUEST on eth1 to 10.193.24.1 port 67
Sep 24 06:43:51 router last message repeated 3 times
Sep 24 06:44:59 router last message repeated 5 times
Děkuji za rady. Pokud mě odkážete no google, tak prosím s přesnou frází, hledám už dost dlouho (cca 2 roky
Ještě na závěr - ta adresa 10.193.24.1 mi (snad) ani neprojde kvůli firewallu, a rád bych to tak nechal i nadále...
V tvé síti ISP používá DHCP Relay 10.193.24.1
. Samotný DHCP server pak sídlí na 89.103.163.1
. Je možné, že mají nějakou chybu v konfiguraci, protože podle výpisu na žádost Relay neodpovídá a teprve na broadcast se uráčí odpovědět Server. Ten do odpovědi vkládá informaci o Relay, takže se tvůj klient místo přímého RENEW/REQUEST na Server ptá místo toho zase na Relay (který neodpovídá).
Mohl bys zkusit přes direktivu supersede přepsat dhcp-server-identifier
na prázdný řetězec nebo, pokud to dhclient nespolkne, na 89.103.163.1
. (Přes direktivu reject se dá zakázat, s jakým DHCP Serverem se nechceš bavit, a ačkoliv to není tvůj případ, můžeš zkusit.) Viz man 5 dhclient.conf a případně RFC 5107. Stálo by za to zeptat se tvého ISP a přiložit k tomu výpisy, které jsi poskytnul zde (mimochodem, chválím za precizně specifikovaný dotaz).
Děkuji za odpověď, zase jsem trochu chytřejší. Bohužel dhclient mi jako dhcp-server-identifier
nezbaštil ani prázdný řetězec, ani 255.255.255.255
.
Každopádně - asi si to tady přečetl o noční někdo z UPC, protože v 7 hodin ráno se mi obnovila adresa (z toho 89.103.163.1
), a od té doby v messages není jediná zmínka o 10.193.24.1
V dhclient.leasses je sice pořád napsaná ta adresa 10.193.24.1
, ale messages se neplní. Moc tomu nerozumím - každopádně však doufám, že to vydrží, a děkuji
Jsem se trošku unáhlil, že to pár hodin nechodilo, bylo způsobeno spíš asi momentálním rozpoložením dhclienta.
Každopádně si už s UPC (mým poskytovatelem) dopisuji, a napoprvé jsem se dozvěděl, že to je vlastně v pořádku. Zkuil jsem to popsat ještě jednou, ještě více polopatě - tak uvidím... :-\
A zkoušel jsi do dhclient.conf napsat "supersede dhcp-server-identifier 89.103.163.1
"?
Nemám tušení, jak je organizována síť tvého ISP a kde překládají adresy (když se tam objevila IP z privátního rozsahu), ale tohle (viz výše) je příčina, proč se tvůj DHCP klient pořád ptá 10.193... pokládá ji za relay. Když mu nedovolíš tuhle volbu přepsat a místo toho tam dáš přímo adresu DHCP serveru, který ti odpovídá, uvidíš, jestli se něco bude dít.
Nezkoušel - předpokládám, že to fungovat bude - a asi to tak budu muset použít - jenže mi to přijde jako silně nesystémově řešení (já vím, jde o domácí internet, ale jsem zvyzklej fungovat jinak...).
Problém je v tom, že podpora zcela automaticky předpokládá, že se baví s debilem - proto dotaz evidentně jenom přelítnou očima, a pošlou odpověď.
Jak jinak si vysvětlit:
Vážený pane xxx,
ptal jsem se na správě sítě. 89.103.163.1 není DHCP, ale CMTS, po prvním broadcastu probíhá komunikace s DHCP, ale přes CMTS (10.193.24.1) pomocí unicastu. Vše je v pořádku.
V případě, že budete reagovat na tento e-mail, využijte prosím opět standardního formuláře, který naleznete na http://web.upc.cz/klpoz/cz/
S pozdravem a přáním příjemného dne
M. yyy
Specialista technické podpory datových služeb UPC
UPC Česká republika, a. s.
Jako odpověď na:
Pěkný den,
obdržel jsem odpověď "vypadá to na requesty na DHCP server o přidělení nové IP. Co je s tímto v nepořádku? DHCP samozřejmě reaguje jen na broadcast packety."
- což chápu, problém je v tom, že žádám DHCP server na adrese "10.193.24.1".
Na tuto adresu se obracím proto, že mi server "89.103.163.1" (který se ozve po broadcastu) pošle "server-identifier 10.193.24.1;",
což znamená, že se můj klient snaží domlouvat právě s "10.193.24.1"
Tudíž si myslím, že by server "89.103.163.1" neměl posílat ono "server-identifier 10.193.24.1;" (a nebo by ta adresa "10.193.24.1" měla reagovat na moje requesty).
Jelikož se domnívám, že jde o chybu ve Vašem nastavení, upozorňuji na ni.
Minule poslané výýpisy jsem posílal právě z toho důvodu, že je tam celý průběh relativně srozumitelně vidět.
S pozdravem
K.G.
Já se domnívám, že mě žádnej CMTS nezajímá - s tím ať se domlouvá modem. Problém je asi v tom, že i modem má IP adresu (právě 10.x.x.x) - a chybu vidím v tom, že mi posílaj těch "10.193.24.1" i když se ptám z jiné sítě (resp. to co přichází by asi bylo dobře, kdyby se ptal modem - ten má totiž na rozhraní do kabelovky adresu 10.193.26.167.
Každopádně děkuji za rady. S poskytovatelem si budu dopisovat zase až budu mít náladu, a dostatek času... :-\
Udělej traceroute na 89.103.163.1 a zjisti, jaké L3 prvky ti stojí v cestě. Pokud žádné, není potřeba DHCP relay a jejich konfigurace dhcp-server-identifier je chybná. To CMTS by mohlo totiž běžet v bridge-mode, tedy na L2. Pokud se ve výpisu objeví nějaké mezilehlé uzly, situaci to samozřejmě změní, viz poslední předposlední souvětí mého třetího odstavce.
Hlavní důvod, proč ti ten stroj 10.193.24.1 neodpoví, vidím v tom, že pro tuhle síť nemusí existovat routa - je to privátní síť a poskytovatel stěží provozuje NAT 1:1 s přístupem zvenku. Zkus na něj z PC poštvat ping a svěř se, s jakou zprávou (Destination Unreachable nebo Host Unreachable) ti bylo odpovězeno. Ty na něj jdeš přes výchozí bránu, ale otázka zní, jestli pakety dorazí... Unlikely.
Z odpovědi helpdesku, hned první věty, jsem vedle. Selským rozumem (a podle IP, kterou má rozhraní tvého kabelového modemu) je CMTS na 10.193.24.1. Je možné, že na něm běží DHCP pro připojené modemy a ten tvůj od něj dostal adresu .26.167, ale mohl to popsat lépe. Dovedu si představit i to, že mají v síti jeden DHCP server (89.103.163.1), který přiděluje adresy klientům z řad modemů i PC a CMTS běží v router-mode, takže je na něm i DHCP Relay. Nesedí tam ovšem ta privátní síť. Uvidíme, co ukáže traceroute.
Takže traceroute to 89.103.163.1 (89.103.163.1), 30 hops max, 38 byte packets
1 ip-89-103-163-1.karneval.cz (89.103.163.1) 25.085 ms * 35.437 ms
A ping nevypíše vůbec nic, po Ctrl+C akorát píše 100% lost. Z "iptraf" jsem vykoukal toto:
ICMP dest unrch (port) (56 bytes) from 10.193.24.1 to 89.103.163.132
Každopádně jsem to včera stejně nevydržel, a napsal jsem
Ještě jednou pěkný den.
Prostě s Vám snažím vysvětlit, že DHCP server musí při dotazu ze sítě "89.x.x.x" posílat jako server-identifier adresu "89.103.163.1".
A pouze při dotazu ze sítě "10.x.x.x" (to se ptá modem na svou adresu) má poslat jako server-identifier adresu "10.193.24.1".
Na té adrese "10.193.24.1" je patrně DHCP Relay agent, který ze sítě "10.x.x.x" zprostředkovává komunikaci ze serverem DHCP.
Nepředpokládám totiž, že routujete mezi sítěmi "89.x.x.x" a "10.x.x.x"
Takže - chápu, co se mi snažíte vysvětlit - ovšem je to chybně.
Můj počítač je ve zcela jiné síti než CMTS (tím nemyslím fyzicky, samozřejmě), a spojení mezi modemem a CMTS pro mě je transparentní.
Ano - chápu celkem dobře, jak probíhá komunikace mezi klientem a serverem DHCP.
Ano - chápu, že můj unicast na "89.103.163.1" je fyzicky přenášen z PC -> modem -> CMTS -> (nevím) -> stroj "89.103.163.1".
Ještě prosím o laskavost - jestli to nechcete řešit - neřešte to. Nesnažte se mě ale prosím opít rohlíkem
Děkuji.
A dostalo se mi odpovědi:
V tuto chvíli bych si dovolil schrnout naší debatu a to, že jste nás chtěl upozornit na problém, který ovšem z naší strany jako problém nevidíme a je to dobře nastaveno. Vám toto situace nevadí. Proto bych tedy, jak sám navrhujete, tuto situaci již dál neřešil. Pokud jsem korespondenci špatně pochopil či se vyskytla jiná chyba, kontaktujte nás.
(Mimochodem podepsán jiný řešitel, než u předchozích psaní.) Takže výsledek pro mě - DHCP si nastavím natvrdo na 89.103.163.1, a v mé mysli jepodpora UPC banda trubek (teda alespoň doufám, že kdyby si to přečetl některý ze správců, tak by korespondence probíhala jinak).
P.S. Ale nějak se mi to rozlejží v hlavě, a asi ten boj s větrnými mlýni nevzdám tak snadno. Udělám si z toho dopisování nejspíš dalšího koníčka. Někdo sbírá známky, a někdo si píše s UPC... :-\
Tiskni
Sdílej: