Výzkumníci ukazují, jak mohou otevřené tunely a IPv6 Extension Headers synchronizovat pakety do krátkých provozních špiček. V kontrolovaném experimentu naměřili přes 180násobnou koncentraci paketového toku vůči průměrné rychlosti odesílání — nikoli 180násobné zvětšení objemu dat. Článek obsahuje metodiku, limity měření i mitigace pro GRE, IPIP a další tunely.
Po velkém úspěchu prvního MobileLinux Hackdaye se vracíme do Českých Budějovic s druhým ročníkem. V pátek 30. října 2026 od 10:00 se v prostorách Jihočeské univerzity uskuteční Embedded & MobileLinux Hackday #2. Těšit se můžete na témata jako Immutable Linux na telefonech (BengalOS), U-Boot a upstream vývoj, AI optimalizace pro embedded systémy nebo otevřený hardware. Nebude chybět praktické hackování, sdílení zkušeností a možnost … více »
Dne 21. října 2026 vydal projekt Node.js bezpečnostní aktualizace opravující deset zranitelností, včetně jedné umožňující potenciální vzdálené spuštění kódu (RCE). Nejzajímavější je CVE-2026-111497, chyba dekodéru Brotli, kterou objevili výzkumníci využívající OpenAI Codex Security. Chyba je v nativním dekodéru Brotli, nikoli v samotném JavaScriptu. Speciálně vytvořený komprimovaný vstup způsobí, že dekodér zamění
… více »Francouzský výrobce kabelů Nexans upozornil na napjaté dodávky elektrických kabelů. Výstavba nové výrobní linky pro některé typy kabelů může trvat přibližně tři roky. Datacentra potřebují rozsáhlé nízkonapěťové a středněnapěťové rozvody. Poptávka roste současně s modernizací elektrických sítí. Někteří odběratelé proto uzavírají výrazně delší dodavatelské smlouvy [Reuters].
Představena byla (𝕏) virtuální platforma FLYBENCH FPV, která nováčky provede zapojením a konstrukcí dronů.
Google Chrome 156 byl prohlášen za stabilní. Přehled novinek v poznámkách k vydání. Opraveno bylo 353 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Indická společnost eMudhra po bezpečnostním incidentu, tj. kompromitaci soukromých klíčů osmi mezilehlých certifikátů své certifikační autority, opouští globální byznys s SSL/TLS certifikáty.
Dle Phoronixu zveřejnila společnost Trend Micro prostřednictvím programu Zero Day Initiative (ZDI) několik hlášení bezpečnostních zranitelností přímo na veřejném mailing listu LKML, přestože některé chyby dosud nemají opravu začleněnou do hlavní větve jádra. Mezi hlášenými problémy jsou dvě zranitelnosti s hodnocením CVSS 9.0, týkající se SMB Direct a KSMBD, které mohou umožnit vzdálené spuštění kódu. Další hlášení se týkají … více »
Správce hesel KeePassXC byl vydán ve verzi 2.8.0. Přechází na Qt 6, podporuje vkládání hesel s Waylandem, rychlé odemykání pomocí Polkitu nebo možnost nastavení klávesových zkratek (seznam změn).
Dobrý den. Mám USB bluetooth adaptér MSI Star Key 2.0 v2 a telefon Sharp GX33. Distro Debian sid, kernel 2.6.22-3-amd64. Nainstaloval jsem všechny dostupné balíčky kolem Bluez a Obex. Spárování funguje, z telefonu jdou do počítače nahrávat soubory (konkrétně obrázky z foťáku, jiné tam nemám). Spojení ale nikdy nevydrží dlouho, když chci znova komunikovat třeba po minutě, musím telefon znovu spárovat (přitom "čas odpojení" v mobilu mám nastaven na hodinu).
Nicméně Wammu telefon vůbec nenajde. Taky se nevytváří zařízení /dev/rfcomm0 ani žádné podobné, takže v KMobileTools nemám co zadat. Když napíšu hcitool scan, telefon se někdy objeví a někdy ne (!), obdobně v Konqueroru když zadám bluetooth:/ tak telefon tam někdy vidět je, někdy ne (někdy jsou tam vidět i jiné telefony, asi od sousedů). Předpokládám, že USB dongle je v pořádku:
$ hcitool dev
Devices:
hci0 00:11:67:8D:5E:D1
$ /usr/sbin/hciconfig -a
hci0: Type: USB
BD Address: 00:11:67:8D:5E:D1 ACL MTU: 1021:8 SCO MTU: 48:10
UP RUNNING PSCAN
RX bytes:19421 acl:77 sco:0 events:666 errors:0
TX bytes:4059 acl:73 sco:0 commands:237 errors:0
Features: 0xff 0xfe 0x8d 0x3e 0x88 0x19 0x00 0x00
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH HOLD SNIFF PARK
Link mode: SLAVE ACCEPT
Name: 'rb1j110-0'
Class: 0x180100
Service Classes: Capturing, Object Transfer
Device Class: Computer, Uncategorized
HCI Ver: 2.0 (0x3) HCI Rev: 0x2c6 LMP Ver: 2.0 (0x3) LMP Subver: 0x2c6
Manufacturer: Integrated System Solution Corp. (57)
Možná to nějak souvisí s absencí balíčku bluez-sdp (aptitude píše "K balíku bluez-sdp nebyla nalezena kandidátská verze").
Nevíte někdo, jak to řešit? Nebo aspoň, jestli je to jeden problém, nebo víc problémů? Díky.
ad rfcomm - po spusteni "rfcomm bind all" se zarizeni vytvori?
nevytvoří, příkaz nevypíše žádnou chybu, ale nic se nevytvoří.
ad nestabilita - zkusil bych adapter vytahnout a zase zasunout
zkusil jsem to a zatím to vypadá, že hcitool scan teď vidí telefon při každém pokusu, i v konqueroru je přes bluetooth:/ vidět pokaždé, tak uvidím, jestli to vydrží.
stalo za to, vedet, co je to za telefon
je to Sharp GX33, už jsem to psal výše:) pravda, v databázi telefonů Gammu je GX-20 jako "not supported", zato GX17 jako funkční (ale jen s ovladačem at115200, čili asi přes kabel).
když dám ve Wammu autodetekci telefonu, tak se zastaví na "Vyhledávám zařízení Bluetooth pomocí PyBluez" a dál nedojde.. když to zkusím ručně, nabídne mi adresu telefonu (tu co najde hcitool scan), ale když ji vyberu, řekne, že zařízení neexistuje..
no a v KMobileTools nemám jak zadat to zařízení, když ho v /dev/ nemám..
Tak jsem to nakonec (skoro úplně) vyřešil.. ve Wammu bylo potřeba nastavit ovladač "bluerfat" místo "blueat" (s obexem si ani neškrtne..), načež se zdařil import kontaktů, hovorů i sms, takže jsem spokojen.
S tou stabilitou spojení je to pořád takové zvláštní.. když na telefon hrabe Wammu, ikonka bluetooth v systray KDE svítí stále modře, jinak ale po chvilce zhasne a telefon se pak musí znova spárovat (nastavení času odpojení na "neomezeně" na to nemělo vliv) .. to mě zase tolik netrápí, protože stejně většinou nedělám s telefonem víc věcí po sobě; předpokládám, že data z něj budu stahovat vždy jednou za čas a přímo během přenosu se to nikdy nepřeruší, takže to se nějak zvládne. (Napadlo mě, že signál může být slabý kvůli kovové konstrukci stolu, pod nímž je PC umístěno, jakože to je taková Faradayova klec:), ale to už nesouvisí s Linuxem.)
No jen tedy zbývá nemožnost využít KMobileTools kvůli absenci zařízení v /dev/.. škoda, že se KMobileTools neumí spojit přes tu MAC adresu (nebo co to je), jako Wammu.
rfcomm bind 0 00:1C:EE:19:5E:5B 1" (00:1C:EE:19:5E:5B je MAC adresa telefonu, kterou vypíše "hcitool scan"). Vytvořilo se zařízení /dev/rfcomm0 a to jsem pak zadal v KMobileTools. Nicméně tam je problém, že mnoho SMS to stáhne nějak zmršeně.. místo většiny znaků jsou tam nějaké řecké znaky, nechápu proč (a zkoušel jsem změnit kódování z 8859-1 na GSM i ASCII, ani jedno nepomohlo.. a nakonec KMobileTools spadly a bylo třeba je zabít). Ale ve Wammu jsou všechny SMS v pořádku (jen mně trochu štve, že Wammu je jediná GUI aplikace, kterou používám a není Qt:) ).
Tiskni
Sdílej: