Mastodon (Wikipedie) - sociální síť, která není na prodej - byl vydán ve verzi 4.5. Přehled novinek s náhledy v oznámení na blogu.
Německo zvažuje, že zaplatí místním telekomunikačním operátorům včetně Deutsche Telekom, aby nahradili zařízení od čínské firmy Huawei. Náklady na výměnu by mohly přesáhnout dvě miliardy eur (bezmála 49 miliard Kč). Jeden scénář počítá s tím, že vláda na tento záměr použije prostředky určené na obranu či infrastrukturu.
Po dvaceti letech skončil leader japonské SUMO (SUpport.MOzilla.org) komunity Marsf. Důvodem bylo nasazení sumobota, který nedodržuje nastavené postupy a hrubě zasahuje do překladů i archivů. Marsf zároveň zakázal použití svých příspěvků a dat k učení sumobota a AI a požádal o vyřazení svých dat ze všech učebních dat.
Úřad pro ochranu hospodářské soutěže zahajuje sektorové šetření v oblasti mobilních telekomunikačních služeb poskytovaných domácnostem v České republice. Z poznatků získaných na základě prvotní analýzy provedené ve spolupráci s Českým telekomunikačním úřadem (ČTÚ) ÚOHS zjistil, že vzájemné vztahy mezi operátory je zapotřebí detailněji prověřit kvůli možné nefunkčnosti některých aspektů konkurence na trzích, na nichž roste tržní podíl klíčových hráčů a naopak klesá význam nezávislých virtuálních operátorů.
Různé audity bezpečnostních systémů pařížského muzea Louvre odhalily závažné problémy v oblasti kybernetické bezpečnosti a tyto problémy přetrvávaly déle než deset let. Jeden z těchto auditů, který v roce 2014 provedla francouzská národní agentura pro kybernetickou bezpečnost, například ukázal, že heslo do kamerového systému muzea bylo „Louvre“. 😀
Z upstreamu GNOME Mutter byl zcela odstraněn backend X11. GNOME 50 tedy poběží už pouze nad Waylandem. Aplikace pro X11 budou využívat XWayland.
Byl publikován plán na odstranění XSLT z webových prohlížečů Chrome a Chromium. S odstraněním XSLT souhlasí také vývojáři Firefoxu a WebKit. Důvodem jsou bezpečnostní rizika a klesající využití v moderním webovém vývoji.
Desktopové prostředí LXQt (Lightweight Qt Desktop Environment, Wikipedie) vzniklé sloučením projektů Razor-qt a LXDE bylo vydáno ve verzi 2.3.0. Přehled novinek v poznámkách k vydání.
Organizace Open Container Initiative (OCI) (Wikipedie), projekt nadace Linux Foundation, vydala Runtime Specification 1.3 (pdf), tj. novou verzi specifikace kontejnerového běhového prostředí. Hlavní novinkou je podpora FreeBSD.
Nový open source router Turris Omnia NG je v prodeji. Aktuálně na Allegro, Alternetivo, Discomp, i4wifi a WiFiShop.
ip -s -s link show dev eth1
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb qlen 1000
link/ether 00:1d:92:23:6b:fe brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
747473035 103966270 9 0 0 0
RX errors: length crc frame fifo missed
0 0 0 9 13326
TX: bytes packets errors dropped carrier collsns
4222548359 108744074 0 0 0 0
TX errors: aborted fifo window heartbeat
0 0 0 0
Google toho moc neví, někde jsem našel vysvětlení, že se obě strany linky nedokáží domluvit na rychlosti. Tohle jsem vyloučil postupnout výměnou: Routeru (HW i OS), kabelu, switche. Vše je jiné.
Jediný problém může být v softu. Proběhla změna OS z Fedora4 na CentOS 5.0. Routování (staticky cca 100 cest), nastavení rozhranní, shaping (htb) zůstalo stejné.
Na daný packet loss nemá vliv: vypnuté shapování (tc qdisc del root), vypnutý fw (iptables -F), ani trafic. Začínám mít pocit, že mi tam straší
Dotazy:
Co všechno může způsobit chyby v RX Error Missed?
Jak může vzniknout PL na samotném routeru?
Kudy ten kabel vedeš? Neni tam nějaký rušení? Píšeš že si vyměnil OS, zkoušel si jiné jádro resp. jinou verzi ovladače?
136k 118k 136k 139k 136k 139k 142k 22k 200k 20k 172k 136k 118k 136k ...Průměr tedy odpovídá. Ale když v jedné sekundě dojde k výpadku, tak v další přijde dvojnásobek dat. Tedy i data z toho výpadku a klient jede rychlostí vyšší než má v HTB. Kolega paří WOW a říkal, že vše co se "během" výpadku stane mu přijde (a od něj odejde) o tu sekundu později. Pak to jede opět normálně. Tomu bych u TCP rozumněl, ale proč přijde naráz dvojnásobek dat je mi také záhadou.
ethtool eth1
Settings for eth1:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0x00000001 (1)
Link detected: yes
Zkoušel jsi ten switch restartovat ?
Je vyměněn
. Byl tam zcela jiný. Byly tam VLANy, teď je default. Proč si myslíš, že to bude v tom switchi?
Se všemi síťovkami se to chovalo stejně (tedy blbě). Sítovka na to nemá vliv. Celkově bylo vyzkoušeno cca 6 různých kombinací síťovek / switchů. Stále stejné (špatné) chování. Tím to nebude. Problém bude v nastavení toho routeru. :- (
Tak Ti mě napadá,jaký trafic jde přes ten router?
cca 10Mb/s. Nadměrná zátěž tu nikde není, vše je měřeno. Ten router se fláká (doufám, že by to load, htop atd ukázal). Počet konektů hluboko pod maximem. Po snížení TCP timetoutu to ještě více kleslo. Ještě doplním, že přímo na tento router není připojeno žádné domácí PC. Jsou na něm servery (nulový trafic, navíc omezeno v HTB) a další routery a až za nimi obyč PC lidí.
A teď mě napadá, co takle odpojit switch od routeru a připojit jen jedno pecko k routeru a zkusit přez něj komunikovat ven ? Víš bez dalších stanic ...
Ano, tohle bude asi jediná možnost. Jenže, po jednom restartu routeru to vydrží třeba dva dny bez jediného vypadlého packetu. Po dalším restartu je loss okamžitý. Odpojit celou síť na dva dny si nemuho dovolit.
Ano, tohle bude asi jediná možnost. Jenže, po jednom restartu routeru to vydrží třeba dva dny bez jediného vypadlého packetu. Po dalším restartu je loss okamžitý. Odpojit celou síť na dva dny si nemuho dovolit.Co by se stalo, kdybys nic nerestartoval, a rovnou místo toho switche bouchnul PCčko o kterém víš, že je vpořádku a pak začal komunikovat přes ten router ven ? Bylo by to s chybama, které uvádíš ? Tím nechci říct, že by switch, ba ani router nebyly OK, ale pokusil bych se alespoň odstranit doměnku, že si ti dva "nepadly" do oka. Já vím, je to taková šamanština , ale co když ... Jinak , já nevím, mě nic jiného momentálně nenapadá ... Dobrou noc :o)
A nějakej debug to neosvětlí, logování s nejvyšší úrovní?
eth1 Link encap:Ethernet HWaddr 00:10:4B:1C:52:0F
inet addr:80.188.227.18 Bcast:80.188.227.23 Mask:255.255.255.248
inet6 addr: fe80::210:4bff:fe1c:520f/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:10884428 errors:0 dropped:0 overruns:0 frame:0
TX packets:9087140 errors:0 dropped:0 overruns:0 carrier:129
collisions:2632 txqueuelen:1000
RX bytes:1079902235 (1.0 GiB) TX bytes:1594204219 (1.4 GiB)
Interrupt:18 Base address:0xe000
pomohlo nastaveni na 10Mbit:
root@nat:~# ethtool eth1 Settings for eth1: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Full Advertised auto-negotiation: Yes Speed: 10Mb/s Duplex: Full Port: MII PHYAD: 24 Transceiver: internal Auto-negotiation: on Current message level: 0x00000001 (1) Link detected: yespak prestali v ciscu a na eth1 ty kolize ... chybu z dmesg si nepamatuju a pravdepodobne se jednalo o jiny problem, jen stejna sitovka ... Ja nevim, s 3comama, mam vzdy nejakou chybu, zatim co s realtekama za 90 korun ne ...
A nedochazelo ke zpozdeni a ani vypadavani pingu i OpenVPN jela ok ..
root@nat:~# lspci 00:0a.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78) 00:0c.0 Ethernet controller: 3Com Corporation 3c900B-TPO Etherlink XL [Cyclone] (rev 04) 00:13.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
Procházel jsem i zdrojáky jádra, abych zjistil co to vlastně znamená a nikde nic.Je to deklarované v linux/netdevice.h, resp. linux/if_link.h. Např. ovladač 8139too (drivers/net/8139too.c) mění tento čítač na třech místech. Váš případ bude asi funkce rtl8139_weird_interrupt(), která je volána při přerušení z důvodu chyby (na PCI sběrnici, příjmu poškozeného rámce, přetečení fronty v síťovce). Počítadlu je přičtena hodnota, která se bere přímo z registru na kartě. Takže bych chybu viděl mezi síťovou kartou a switchem. Ujistit se můžete zapnutím ladění v modulu předefinováním symbolu RTL8139_DEBUG na nenulovou hodnotu (linux-2.6.24.3/drivers/net/8139too.c:129).
na PCI sběrnici, příjmu poškozeného rámce, přetečení fronty v síťovce
Díky. Ano, tohle by tomu odpovídalo, zejména chyba v rámci. To stále více to ukazuje na problém switche. Dám tam ještě lepší a uvidím. Zatím pomáhá restart toho switche (pomůže tak na jeden den) a nastavení 100base TX-HD. Vypadá to, že v něm něco přetéká.
Tiskni
Sdílej: