Když jsem začínal s Echolinkem neobešel jsem se bez proxy serveru (mám ho dosud v provozu tam kde je přístup k veřejné adrese). V minulých dnech jsem dělal "ruční" reinstalaci NB. Současně jsem se dohadoval s providerem o průchodnosti UDP paketů v souvislosti s potřebami SDR Perseus - vykázal mne, že to nejde, že musím mít veřejnou IP adresu (jsem na wifi za několika routery). Jenže když jsem začal NB plnit aplikacemi a ověřovat jestli jsou funkční, tak mne zarazilo že připojení na test server je funkční, tak jsem nahlédl na kartu proxyny a vykulil oči - já byl připojený bez proxy. Tak jsem honem přes Echolink z NB zavolal známého hama - a ono to skutečně bez ohledu na mé připojení funguje bez proxy. Tak-že - změnilo se něco v ovládání Echolinku, že už není proxy potřeba? Nebo se providerovi něco povedlo a ani o tom neví (nechci se ho ptát, aby mě to zase nezrušil hi). Jo-ještě - Perseovi to ale nepomohlo (připojí se, ale je hluchej), takže UDP pakety se ztrácí, ale to může být nastavením portů. Co nato fundovanější?

Nechci se mylit, ale vyzkousej, jestli to take pujde obracene, t.j. jestli kamos dovola Tobe (nech to treba 10 min v klidu a pak at to zkusi) Zalezi jak to ma provider nakonfigurovany, v urcitem pripade muze dojit k tomu, ze paklize aktivita pochazi od Tebe, tak se udela docasny oboustranny kanal a ten drzi po urcitou dobu spojeny a proto to bez proxy muze jit. Jakmile prestane byt pro toto spojeni aktivita, tak ho rozpoji a zapomene. Zvenku uz se pak postavit neda. Timeouty muzou byt ruzne od jednotek sekund az po minuty.

tehle technologii se rika firewall udp punching. Jde o to, ze kdyz posilas UDP ramce jednim smerem a pak z tehoz vzdaleneho stroje na tentyz port zacnou packety chodit na firewall, tak je firewall pusti dovnitr a router je naroutuje na Tvuj stroj. Duvodem je to, ze si mysli, ze jde o packety ze stejneho spojeni. Nicmene tohle funguje jen tehdy, kdyz jdou UDP ramce obema smery, presneji, musi od Tebe zacit odchazet, az pak se firewall otevre smerem dovnitr a router zacne routovat. Takhle se otevira spojeni napr pro skype - obe volajici strany jsou za firewallem, nejdriv se spoji pres proxy a pak proxy na obe strany posle "zmena IP adresy" a necha klienty mirit proti sobe - firewally se prvnim par packetum brani, ale pak je navzajem pusti dovnitr.
edit: kdyz budes na server posilat UDP ramce na jeho port jeste pred pripojenim SDR, je mozne, ze se firewall provozovatele otevre a pusti UDP tok ze serveru k Tobe.

Zase jednou proxy pro Echolink.
Jak běžel čas tak se můj hostitel (soukromý byt s veřejnou IP adresou) přestěhoval, a moje proxyna skončila v igelitové tašce. No v tom čase mezi proxynami echolinku kraloval Pája, a tak jsem se nijak nesnažil najít náhradní řešení (a také jsem Echolink méně používal). V nabídce co do množství proxyn začal kralovat OK9DTZ, má to ale drobnou vadu, najít která je funkční je časově náročný horor. Chtěl jsem se zeptat přímo OK9DTZ (ale nepřišel jsem na to jak) - zobrazené Pájovo (OK1PJV) proxyny byly vždy funkční, teď se zobrazuje cca 16 proxyn OK9DTZ, ale než se najde která je funkční - tak zestárne důvod pro spojení. Většina reakcí je:

Dělám něco špatně já? Dík za moudra.

zobrazené Pájovo (OK1PJV) proxyny byly vždy funkční, teď se zobrazuje cca 16 proxyn OK9DTZ, ale než se najde která je funkční - tak zestárne důvod pro spojení. Většina reakcí je:
Echolink.jpg

Dělám něco špatně já? Dík za moudra.

Problémy s proxynami mě mrzí :/ Zkusil jsem se teď připojit z telefonu (Android) ale "bohužel" vše mi zafungovalo napoprvé, takže jsem nic moc nezjistil. Kontroloval jsem verzi programu ale i ta je aktuální.. S prvními verzemi byly určité problémy ale to se povedlo odladit přímo s PE1CHL.

Pokud problémy přetrvávají, bylo by možné mi zaslat např. výstup příkazu telnet?

telnet 85.92.62.69 8100
Trying 85.92.62.69...
Connected to 85.92.62.69.
Escape character is '^]'.
368dd6a7

Tohle by to mělo vrátit. Případně:

Trying 85.92.62.69...
Connected to 85.92.62.69.
Escape character is '^]'.
368dd6a7
403 This is an EchoLink Proxy, not a Web Proxy! Go away!

This is an EchoLink Proxy, not a Web Proxy! Go away!

Pokud jsou zaslána data, která nemají na echolink proxy co dělat (to je ochrana proti těm, kteří se proxyny snažili používat jako http proxy - v prvních verzích to žralo CPU a plnilo logy, pak se přidala tato ochrana).

Aktuálně tam mám připojených několik uživatelů, podle logu se spousta z nich vrací opakovaně a přenáší dost dat, tak to vypadá, že jim to funguje. Je ale samozřejmě možné, že to náhodně blbne (na http://www.echolink.org/proxylist.jsp se stavy aktualizují se zpožděním, moje proxyny jsou hned nahoře - je možné, že se občas setká víc požadavků, případně někdo zkouší proxynu, která je už pár sekund obsazená..).

V každém případě budu rád za info, pokud by to zlobilo a nepodařilo se najít řešení, tak je raději vypnu.