Knihovna FFmpeg byla vydána ve verzi 8.0 „Huffman“. Přibyla mj. podpora hardwarově akcelerovaného kódování s využitím API Vulcan, viz seznam změn.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) vydal Zprávu o stavu kybernetické bezpečnosti ČR za rok 2024 (pdf). V loňském roce NÚKIB evidoval dosud nejvíce kybernetických bezpečnostních incidentů s celkovým počtem 268. Oproti roku 2023 se však jedná pouze o drobný nárůst a závažnost dopadů evidovaných incidentů klesá již třetím rokem v řadě. V minulém roce NÚKIB evidoval pouze jeden velmi významný incident a významných incidentů bylo zaznamenáno 18, což oproti roku 2023 představuje pokles o více než polovinu.
Byl publikován aktuální přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie). Servo mimo jiné nově zvládne animované obrázky APNG a WebP.
Na chytré telefony a počítačové tablety v Rusku bude od začátku příštího měsíce povinné předinstalovávat státem podporovanou komunikační aplikaci MAX, která konkuruje aplikaci WhatsApp americké společnosti Meta Platforms. Oznámila to dnes ruská vláda. Ta by podle kritiků mohla aplikaci MAX používat ke sledování uživatelů. Ruská státní média obvinění ze špehování pomocí aplikace MAX popírají. Tvrdí, že MAX má méně oprávnění k přístupu k údajům o uživatelích než konkurenční aplikace WhatsApp a Telegram.
Společnost PINE64 stojící za telefony PinePhone nebo notebooky Pinebook publikovala na svém blogu srpnový souhrn novinek. Kvůli nedostatečnému zájmu byla ukončena výroba telefonů PinePhone Pro.
Po pěti měsících vývoje byla vydána nová verze 0.15.1 programovacího jazyka Zig (GitHub, Wikipedie). Verze 0.15.0 byla přeskočena. Přispělo 162 vývojářů. Přehled novinek v poznámkách k vydání.
Před sedmi lety společnost Valve představila fork projektu Wine s názvem Proton umožňující v Linuxu přímo ze Steamu hrát počítačové hry do té doby běžící pouze ve Windows. Aktuální přehled podporovaných her na stránkách ProtonDB
Společnost DuckDuckGo rozšířila svůj AI chat Duck.ai o GPT-5 mini (𝕏). Duck.ai umožňuje anonymní přístup bez vytváření účtů k několika modelům umělé inteligence. Aktuálně k GPT-4o mini, GPT-5 mini, Llama 4 Scout, Claude Haiku 3.5 a Mistral Small 3.
Marek Tóth v příspěvku DOM-based Extension Clickjacking: Data ve správcích hesel v ohrožení na svém blogu popsal novou clickjacking techniku s několika variantami útoků a otestoval ji proti 11 správcům hesel. Výsledkem bylo nalezení několika 0-day zranitelností, které mohly ovlivnit uložená data desítek milionů uživatelů. Jedno kliknutí kdekoliv na webové stránce kontrolované útočníkem umožňovalo ukrást uživatelská data ze
… více »Na dnešní akci Made by Google 2025 (YouTube) byly představeny telefony Pixel 10 s novým čipem Google Tensor G5 a novými AI funkcemi, hodinky Pixel Watch 4 a sluchátka Pixel Buds 2a.
ole amigos.
mam problem s netbackupom nad tagovanym interfacom(resp. bondingom)
situacia je taka ze robim bonding bond0 z eth0 a eth2, pre produkcny DB konekt v nativnej VLANe, a nad nim tagovany bond0.3016 pre backup traffic. no a tu sa to chova cudne, DB traffic je OK, ale backup traffic je zle. Netbackup sa konektne na klienta ..vymenia si par info a padne to. akonahle pustim ten backup nad netagovanym hocijakym interfacom z toho bondingu tak to pekne prebehne.
Mate niekto podobnu skusenost?
log z netbackupu
13:46:45.616 [18090] <2> vnet_pbxConnect: pbxConnectEx Succeeded
13:46:45.617 [18090] <2> logconnections: BPRD CONNECT FROM 172.24.76.13.49317 TO 172.24.76.20.1556 fd = 9
13:46:45.641 [18090] <16> VssCredRenew: (../../libVnbat/vss_auth.cpp,3665): vrtsAtCredentialRenew returned FAILURE
13:46:45.642 [18090] <8> vnet_vxss_renew_cred: [vnet_vxss_helper.c:2079] VssCredRenew failed 17 0x11
13:46:45.642 [18090] <8> vnet_vxss_renew_cred: [vnet_vxss_helper.c:2086] cannot renew credential 36 0x24
13:46:45.642 [18090] <8> vnet_setup_vxss_socket: [vnet_vxss_helper.c:198] non-fatal vnet_vxss_import_credential() failed 36 0x24
13:46:45.643 [18090] <8> vnet_get_oc: [vnet_vxss_helper.c:3122] Invalid Argument: vxss_coninfo
13:46:45.643 [18090] <8> vnet_check_vxss_client_magic_with_info: [vnet_vxss_helper.c:922] VxSS magic 1450726227 0x56785353
13:46:45.643 [18090] <8> vnet_check_vxss_client_magic_with_info: [vnet_vxss_helper.c:923] *use_vxss 2 0x2
13:46:45.845 [18090] <2> brm_update_local_resiliency: changed = 0
13:46:45.847 [18090] <2> ConnectionCache::connectAndCache: Acquiring new connection for host XXXXXXXXXXXXXX, query type 223
13:46:45.850 [18090] <2> vnet_pbxConnect: pbxConnectEx Succeeded
13:46:45.851 [18090] <2> logconnections: BPDBM CONNECT FROM 172.24.76.13.49319 TO 172.24.76.20.1556 fd = 9
13:46:45.874 [18090] <16> VssCredRenew: (../../libVnbat/vss_auth.cpp,3665): vrtsAtCredentialRenew returned FAILURE
13:46:45.875 [18090] <8> vnet_vxss_renew_cred: [vnet_vxss_helper.c:2079] VssCredRenew failed 17 0x11
13:46:45.875 [18090] <8> vnet_vxss_renew_cred: [vnet_vxss_helper.c:2086] cannot renew credential 36 0x24
13:46:45.875 [18090] <8> vnet_setup_vxss_socket: [vnet_vxss_helper.c:198] non-fatal vnet_vxss_import_credential() failed 36 0x24
13:46:45.876 [18090] <8> vnet_get_oc: [vnet_vxss_helper.c:3122] Invalid Argument: vxss_coninfo
13:46:45.876 [18090] <8> vnet_check_vxss_client_magic_with_info: [vnet_vxss_helper.c:922] VxSS magic 1450726227 0x56785353
13:46:45.876 [18090] <8> vnet_check_vxss_client_magic_with_info: [vnet_vxss_helper.c:923] *use_vxss 2 0x2
13:46:45.879 [18090] <2> db_CLIENTsend: reset client protocol version from 0 to 8
13:46:45.922 [18090] <2> db_end: Need to collect reply
13:46:45.922 [18090] <2> db_freeEXDB_INFO: ?
13:46:55.938 [18090] <2> vnet_pbxConnect: ../../libvlibs/vnet_pbx.c.666: pbxSetAddrEx/pbxConnectEx return error 62:Timer expired
13:46:55.938 [18090] <8> do_pbx_service: [vnet_connect.c:2034] vnet_pbxConnect() failed 18 0x12
13:46:55.938 [18090] <8> do_pbx_service: [vnet_connect.c:2035] save_errno 62 0x3e
13:46:55.938 [18090] <8> do_pbx_service: [vnet_connect.c:2036] use_vnetd 0 0x0
13:46:55.938 [18090] <8> do_pbx_service: [vnet_connect.c:2037] cr->vcr_service bpcd
13:46:55.938 [18090] <8> async_connect: [vnet_connect.c:1630] do_service failed 18 0x12
Network je nastaveny uplne bezne,,tam to imo nebude...podozrive su tym padom bud 8021q alebo appka samotna...
Dik
D.
Řešení dotazu:
Ten popis je nějaký zmatený… Raději ukažte výstup
ip addr show ip route show cat /proc/net/bond/bond0
a napište, jaké adresy používají klient a server.
ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 qlen 1000
link/ether 38:ea:a7:d3:57:f8 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast master bond1 qlen 1000
link/ether 38:ea:a7:d3:57:fc brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 qlen 1000
link/ether 38:ea:a7:d3:57:f8 brd ff:ff:ff:ff:ff:ff
5: eth3: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast master bond1 qlen 1000
link/ether 38:ea:a7:d3:57:fc brd ff:ff:ff:ff:ff:ff
6: sit0: <NOARP> mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0
7: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether 38:ea:a7:d3:57:f8 brd ff:ff:ff:ff:ff:ff
inet 172.24.0.154/24 brd 172.24.0.255 scope global bond0
inet6 fe80::3aea:a7ff:fed3:57f8/64 scope link
valid_lft forever preferred_lft forever
8: bond1: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000 qdisc noqueue
link/ether 38:ea:a7:d3:57:fc brd ff:ff:ff:ff:ff:ff
inet 172.24.193.50/24 brd 172.24.193.255 scope global bond1
inet6 fe80::3aea:a7ff:fed3:57fc/64 scope link
valid_lft forever preferred_lft forever
11: bond0.3016@bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether 38:ea:a7:d3:57:f8 brd ff:ff:ff:ff:ff:ff
inet 172.24.112.116/22 brd 172.24.115.255 scope global bond0.3016
inet6 fe80::3aea:a7ff:fed3:57f8/64 scope link
valid_lft forever preferred_lft forever
ip route show
172.24.193.0/24 dev bond1 proto kernel scope link src 172.24.193.50
172.24.0.0/24 dev bond0 proto kernel scope link src 172.24.0.154
172.24.76.0/24 via 172.24.112.1 dev bond0.3016
172.24.112.0/22 dev bond0.3016 proto kernel scope link src 172.24.112.116
169.254.0.0/16 dev bond0.3016 scope link
default via 172.24.0.1 dev bond0
cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.4.0-2 (October 7, 2008)
Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: eth0
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
Slave Interface: eth0
MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 38:ea:a7:d3:57:f8
Slave Interface: eth2
MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 80:c1:6e:70:1d:c0
Nad bond0 je este bond0.3016 cez ktoru tecie ten backup traffic ..a presne ten je problemovy
cat /etc/sysconfig/network-scripts/ifcfg-bond0.3016
DEVICE=bond0.3016
BOOTPROTO=none
IPADDR=172.24.112.116
NETMASK=255.255.252.0
ONBOOT=yes
BOOTPROTO=none
VLAN=yes
D.
funkcne aj nefunkcne spojenie je cez tie iste ipky aj cesty..jediny rozdiel je v tom ze raz je pouzity na klientovy tagovany interface a raz nie...
toto nic nema s routingom, nastavenim siete atd...je to len o tom ci sa s tym niekto nestretol
ale poviem to takto..asi to nema velky vyznam je to velmi specificka situacia, skusim este prehodit drajvre na sietovkach a uvidime.
Dakujem aj tak.
D.
Nějak dneska nemám náladu hrát si na výslech. Takže asi takhle: buď popište funkční a nefunkční konfiguraci včetně toho, mezi jakými adresami má být to spojení (a nejlépe i to, co z něj vlastně nefunguje, tj. který směr a kam až se pakety dostanou), nebo se obraťte na nějaké fórum, kde se scházejí jasnovidci.
toto nic nema s routingom, nastavenim siete atd
Z čeho jste to vyvodil?
skusim este prehodit drajvre na sietovkach
Co přesně myslíte výrazem "prehodit drajvre"?
absoultne uznavam, ze som to napisal ako tatar, ale podla mna sa jedna o tak specificku zalezitost, ze mnou uvedeny popis uplne na zaciatku by trkol len cloveka, ktory sa stretol s presnymi, alebo podobnymi symptomami.
Nebudem to dalej rozvijat.
D.
Ok takze sme to vyriesili, po milion kadejakych pokusov s MTU nastavenim kariet a siete zabralo az vypnutie offloadingov a checksumingov na kartach.
D.
Tiskni
Sdílej: