Messages

Hezky den,

Jestli je ten Celeron ještě k dispozici a vydrzi bezet dyl jak 1hodinu,
tak bych měl zájem.


Emailové spojení: 
       #!/usr/bin/bash
       ja=ledvinka
       mail $ja@gmail.com     

                 Diky
                     T. L.

Překvapuje mě, že se tady nějak všichni shodnete na tom, že AVG ne. Namáte nějaký odkaz na argumenty, proč a v čem je konkurence lepší? Díky předem.

T.L.

SLAX ?? Zvědavost mi nedá... co to umí, co neumí KNOPPIX ?

Mozna se zaznamenava vsechno a mozna uz dlouho...

Především dotazy na Google: Teď když nemůže GWB zjistit, na co se ptají  Kladěňáci přímo od Googlu, bude to potřebovat z logů klfree.

Dobré ráno,

zdá se, že naši pokročilí universitní admini nasadili novou a lepší kontrolu na dvě služby SSH a SMTP.  Obě se tváří, že jsem zloduch s nekosistentním DNS záznamem. Zatímco SSH není příliš konkrétní

$ ssh -v x.y.z.cuni.cz
OpenSSH_3.9p1, OpenSSL 0.9.7d 17 Mar 2004
debug2: ssh_connect: needpriv 0
debug1: Connecting to x.y.z.cuni.cz [195.113.x.y] port 22.
debug1: Connection established.
debug1: identity file /home/ledvinka/.ssh/identity type -1
debug1: identity file /home/ledvinka/.ssh/id_rsa type -1
debug1: identity file /home/ledvinka/.ssh/id_dsa type -1
debug1: ssh_exchange_identification: 421-*******************************************************
debug1: ssh_exchange_identification: 421-******** ACCESS DENIED ****** PRISTUP ODMITNUT ********
debug1: ssh_exchange_identification: 421-*******************************************************
debug1: ssh_exchange_identification: 421-
debug1: ssh_exchange_identification: 421--------------------------------------------------------
debug1: ssh_exchange_identification: 421-          Your computer's DNS info is bogus.          
debug1: ssh_exchange_identification: 421-          Vas pocitac nema platny DNS zaznam.          
debug1: ssh_exchange_identification: 421--------------------------------------------------------
debug1: ssh_exchange_identification: 421-This is not a temporary error. Trying again won't help.
debug1: ssh_exchange_identification: 421-  Toto neni docasna chyba. Nepomuze zkouset to znova.  
debug1: ssh_exchange_identification: 421 -------------------------------------------------------
ssh_exchange_identification: Connection closed by remote host

emaily odesílané  přes SMTP.klfree.net se mi vracejí s konkrétnějším oznámením

Rejected. The client's IP [62.240.168.31] has inconsistent reverse and forward DNS record.
It's a common attribute of unsolicited mail and mail containing viruses.
Please contact your netadm for assistance.  

Zatím mám cestu jak to obejít, nicméně kdyby někdo kdo se vyzná v téhle DNS magii tušil jako to opravit, byl bych vděčný.

Asi na tom něco bude, protože z venku to vypadá takhle

$ dig -x 62.240.168.31
....
;; ANSWER SECTION:
31.168.240.62.in-addr.arpa. 21600 IN    PTR     goldheart.klfree.cz.
....

zatímco

$ dig goldheart.klfree.cz
....
;; ANSWER SECTION:
goldheart.klfree.cz.    300     IN      A       62.240.168.3
.....

            S pozdravem,

                   T. Ledvinka

...skript nepobere, kdyz ping vrati hodnotu < 1 ms

Opraveno.

Omlouvám se za to, že je potřeba perl. Ze souboru

http://downloads.activestate.com/ActivePerl/Windows/5.8/ActivePerl-5.8.7.815-MSWin32-x86-211909.zip

ale stačí jen soubor perl.exe a perl58.dll strčit do stejného adresáře jako ten skript a pak vytvořit shortcut na příkaz "perl mping.pl". I když je to pořád jednodušší, než instalovat na lokální počítač http server s podporou php, je to otrava. Původně to měl být html dokument s javascriptem a použivat  asynchronní XMLHttpRequest na www servery po cestě, jenže se mi nepodařilo přesvědčit PrivilegeManager, že html soubor na lokálním disku smí lézt po webu a koukat se, kdo je vzhůru.

Pokud český ping stráví parametry "ping -w 100 -n 1  1.2.3.4" je upravená verse jeho české hlášení již s to přežvýkat.

Na sledování stavu sítě a na názorné zobrazní příčiny potíží existuje velké množství SW, tak velké, že jsem si radši napsal něco malého . Kdo má pod windows instalován perl, může studování traceroute nahradit prohlížením obrázků:



a pak je posílat na vyšší místa ...

[permanentní]

podle me den dva testu je lepsi nez tyhle permanentni vypadky....

Pro upřesnění: za výše uvedených 13 dni jsem nezaznamenal výpadek spojení na Rebecu.  Proto bych slovo permanentní přeci jen považoval za příliš silné.

[třinácti]

... jenze edvinovi se do toho nechce, aby prej lidi nebyli bez netu....

Jo, jo, my konzervy se (po třicítce) řídíme pravidlem "Když něco funguje, tak se do toho nemá šťourat."

Před třinácti dny jsem touto dobou navštívil dva právě aktiví uživatele bittorrentu, kvůli kterým jsem zrovna musel AP resetovat, a poprosil je o omezení počtu spojení v jejich klientech.  Výsledek se dostavil:

Alias Name:            Hrebecska 2648
Uptime:                13day:0h:2m:27s
Firmware Version:   V1.03H

+

X:\>wget "http://10.102.24.1/test.cgi?5"
--15:49:29--  http://10.102.24.1/test.cgi?5
          => `test.cgi@5.1'
Connecting to 10.102.24.1:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 5,242,880 (5.0M) [application/octet-stream]

100%[====================================>] 5,242,880    169.44K/s    ETA 00:00

15:49:51 (244.83 KB/s) - `test.cgi@5.1' saved [5242880/5242880]

+

X:\>ping www.seznam.cz

Pinging www.seznam.cz [194.228.32.18] with 32 bytes of data:

Reply from 194.228.32.18: bytes=32 time=11ms TTL=57
Reply from 194.228.32.18: bytes=32 time=9ms TTL=57
Reply from 194.228.32.18: bytes=32 time=11ms TTL=57
Reply from 194.228.32.18: bytes=32 time=13ms TTL=57

Ping statistics for 194.228.32.18:
   Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
   Minimum = 9ms, Maximum =  13ms, Average =  11ms

Myslím, že bottleneck je teď sama technologie WiFi připojení a nepředpokládám, že by výše změřené parametry připojení bylo možno s pomocí APPro vylepšit.

... ale kdyby se nekam napsalo, kdo prijde tahat na strechu tricetikilovou trojnozku a 10 kyblu pisku, tak to bude bez odpovedi.

Jenže na news.klfree.net-work je za poslední půlrok jediná zpráva. Kdybych dostatečně dopředu věděl, že se klfree pořádá zdarma návštěvu posilovny, neváhám.

Mimochodem: na straně "Přehled informačních zdrojů" t.j. http://www.klfree.net/view.php?cisloclanku=2004122802 na níž je odkaz z hlavní webové stránky sdružení je špatne link na gomen/twiki (ale ani tam jsem teď nenašel seznam prací i když jsem tam snad kdysi něco takového viděl).

Aby nevzikly pochybnosti, když píšu do tohodle legračního threadu: Připadá mi obdivuhoné jak rada a spol. klfree spravují a BSovy poznámky se mi zdají mimo mísu.

Děkuji za všechny odpovědi,

co se týče souvislosti zatuhávání našeho Ovise a nestřídmých bittorent klinetů na naší LAN: není pochyb. Mluvil jsem s lidmi, kteří to provozují v okamžiku, kdy to nastalo. Charaktristické pro tento stav je 80% ztráta při pingu po LAN, což by nemělo souviset se zmatky v aetheru.

Pokud jste někdo tenhle appro 1.0.6 úspěšně spustil na WL 1120 AP, prosím o zaslání md5 součtu toho APPro*.bin, abych věděl, že mám ten správný.

Přiznám se, že přeflashování firmware nepatří k mým oblíbeným činnostsem, protože to může špatně dopadnout a 10 lidí skončí bez spojení.

Právě proto, že nové WL 1120AP již nelze sehnat, bych potřeboval vědět, kdo poradí v případě že dojde k poruše během zapisování  do flash.

Jinak- uživatele Bittorrent klientů jsem poprosil o omezení počtu spojení.

Protože u nás v domě budeme muset stejně přejít na 5GHz nebo když se domluvíme s nějakým sousedním domem tak snad i spojení převěsem, myslím že setrvání v současném provizoriu je snesitelné.

Vážím totiž tedy mezi 1% pravděpodobností, že budeme týden bez spojení, než v bazaru, či kde seženu náhradního Ovise, nebo vyšší pravděpodobností, že se zase sousedi zapomenou, ale downtime bude výrazně kratší....

Jakmile budu mít vyřešen krizový scénář pro případ, že krachne přeflashování Ovise, pustím se do toho.

                T. L.

Až do Vános byl Ovis obdivuhodně stabilní (tři měsíce uptime).
Beru ale na vědomí exsitenci APLite.firmware, prozatím zkusím kontaktovat člověka, který to nejspíš způsobuje, aby snížil počet spojení v bittorent klientovi, stejně mu to takhle, když ucpe Ovise, nemůže fungovat a tak
to jistě rád omezí.

Popravdě část problému je i u nás v domě. Buď  se po roce provozu  roznemohl náš Ovis 1120 nebo o Vánocích začal u nás v domě někdo provozovat nějaký síťově náročný program, v každém případě čas od času dojde k "zahlcení" Ovise do té míry, že téměř nedopovídá na ping ani z naší LAN, ani se k němu skoro nejde přihlásit přes http. Také se ale jen s obtížemi dá dostat skrze něj a spojení do světa pak stojí za houby.
Zatím pomáhá reboot a tak pokud bude problém přetrvávat budu provádět powercycle někdy ve 3 v noci. A uvidí se.

            T. L.