Freesco, NND, CDN, EOS

odkąd zacząłem używać częściej emuła freesco zaczęło się wykrzaczać raz na dobę lub nawet częściej. najpierw myślałem że to wina kompa i zmieniłem go na inny. problem nie ustąpił, więc drążyłem temat gdzie tylko było można. okazało się, że to właśnie wina emuła (a przy okazji dowiedziałem się, że potrafi on zawieszać nawet sprzętowe routery, a to z powodu dużej ilości ilości połączeń, które nawiązuje). co do freesco to problem ten pojawił się dopiero w wersji 0.3.0 (w 0.2.7 nie występował, ale nie mogę go zainstalować, bo nie chce wykryć mojej sieciówki) i spowodowany jest wprowadzeniem obsługi ipsec (może nie bezpośrednio, ale do tego się to sprowadza). Ligtning (członek teamu freesco) udostępnił do testowania wersję jądra bez obsługi ipsec i nawet ktoś je przetestował z pozytywnym skutkiem (szczegół można znaleźć na forums.freesco.org, a raczej można było znaleźć, bo ostatnio bałwan jestem kiedy ono działa). chciałem tą wersję przetestować, ale nie mogę jej nigdzie znaleźć (na forums.freesco.org niby jest do tego link, ale nie działa, nie udało mi się również znaleźc tego pliku w innym miejscu). w związku z tym mam pytanie czy ktoś może ma tą wersję jądra (powinno się to nazywać kernel-no-ipsec), albo wie gdzie można to znaleźć, a przy okazji może pomogłem komuś rozwiązać jego problem

już mam tą jądro, dzisiaj zainstalowałem i narazie działa, ale czy rzeczywiście jest lepsze to powiem po kilku dniach testowania. dla niektórych napewno będzie nie do przyjęcia, bo nie obsługuje VPN i apache, ale dla mnie to akurat mniej istotne. jak ktoś ma podobny problem i chce to jądro też przetestować to mogę wysłać (bo link na forum.freesco.org w dalszym ciągu nie działa)

z kernel-no-ipsec freesco już się nie wiesza przy korzystaniu z emule i kazaa naraz (na różnych kompach). pojawia się inny problem, co kilkanaście minut cały ruch w sieci zamiera (nawet ping do routera w tepsie nie działa), trwa to około minutę i wszystko wraca do normy (ci którzy używają emule wiedzą że on się ropędza powoli, jak straci swoją kolej to potem znów musi długo czekać, więc jest to dosyć bolesne). i tak jest cały czas. odkryłem że zmiejszenie max connection w emule z 100 na 40 łagodzi problem (zatrzymywanie się transferów zdarza się rzadziej i na krócej), ale to nie rozwiązuje problemu (zwłaszcza że przy mniejszym max connection emule ściąga pliki dużo mniej efektywnie). ktoś ma jakiś pomysł co to może być? używam sdi i podłączone są tylko 3 osoby, więc freesco nie powinno być przeciążone. mam też zrobiony portforwarding dla emule i gadu-gadu.

U mnie jest dokładnie tak samo. Już od kilku dni szukam rozwiązania. Ludzie w sieci już się denerwują, że im połączenie zrywa, a ja nie chcę narazie rezygnować z eMula
Jeśli będziesz wiedział co z tym zrobić - napisz. Postaram się odwdzięczyć tym samym.

dowiedziałem się, że pomóc może tylko większa masq table (16k). wersja 0.3.1 ma taką mieć, ale jeszcze nie jest dostępna. jądro kernel-16k-masq-table.dat jest dostępne na stronie http://thetigger.dyndns.org, ale jest to wersja nieoficjalna i nie ma nawet opisu. może je dziś wypróbuję, ale narazie jestem w pracy. trzeba je ściągnąć i zastąpić nim orginalne (można to zrobić pod windowsem). jeśli możesz je przetestujesz szybciej niż ja to daj znać.

jądro wspomniane w poprzednim moim poście niezawiele pomaga niestety. pozostaje tylko czekać na freesco 0.3.1, albo zmienić parametry emule (zmiejszyć max connection, co trochę pomaga, albo może spróbować zmienić max new connection/5s)

Niestety. Też przetestowałem i nie pomaga
Cóż, trzeba szukać dalej.

Wiem, że to bluźnierstwo, ale ponieważ freesco nie radzi sobie z emule to może ktoś wie jak skonfigurować Coyote żeby działał na sdi? Na forum emule znalazłem informacje że nie stwarza on takich problemów, niestety tak jak freesco nie chce działać na sdi, pewnie również są potrzebne jakieś modyfikacje. Ktoś może wie jakie, lub wie gdzie takie informacje można znaleźć?

Po nieudanych próbach (zwisy co kilka godzin) z freesco 0.2.7 i 0.3.0, i udanym odpaleniu coyote na Neo+ rzeczywiście nie mam problemów. Chodzi bez przerwy. Oczywiście wtedy jak Neo+ nie padła. Próbowałeś stworzyć dyskietkę startową dla ppp Modem Dialup? O ile pamiętam SDI konfiguruje się tak jak dla modemu. Powodzenia

Wiem że niby sdi działa jak modem, ale jednak jakieś różnice są, bo Coyote skonfigurowany na dial up nie działa. Może init string jest nie odpowiedni, ale nie wiem na jaki zmienić. Freesco na sdi różni się od zwykłego plikiem connect (to chyba skrypt do łączenia), może podobną zmianę trzeba wprowadzić w Coyote, ale nie wiem jak (jest dużo informacji w sieci na temat sdi pod linuxem, ale coyote jest troszkę inny i co najgorsze nie można modifikować dyskietki spod windy tak jak w freesco). Wieć pytam czy ktoś już Coyote na freesco uruchomił.

ps: jakby u mnie można było sobie neo+ założyć to bym się chyba nie rypał tylko kupił router ze switchem i stacją bazową wireless za 130$ i po kłopocie (ale na zwykłym adsl też nie ma takich problemów jak z sdi przy freesco i innych routerach softwarowych)

Wiem już jak Coyote uruchomić na sdi (i mogę nawet poradzić komuś jak ma z tym problem), ale niestety okazała się jeszcze gorszy niż freesco we współpracy z emule (chyba że coś zrypałem, co też możliwe). Aktualnie testuję freesco 0.3.1, ciekawe czy będzie lepszy. A może to jednak wina sdi, a nie oprogramowania na serwerze?

Wersje 0.3.0 z kernel-no-ipsec i 0.3.1 nie zawieszają się z emule, a chwilowe zaniki wszelkiego ruchu internetowego o których pisałem są prawdopodobnie spowodowane obciążeniem sieci (dokładnie to routera obsługującego sdi w tepsie) lub złą konfuguracją sdi (nad czym jeszcze będę pracował). Występują one również w innych systemach operacyjnych nawet bez współdzielenia łącza.

Przepraszam skąd można zassać tego kojota.

Przepraszam już mam

U mnie było to samo ale...
zrobiłem tak i spoko-

ten wpis w rc_masq zmienia czasy dla pakietów

ipfwadm -M -s 600 10 60 # Timeouts TCP, after TCP, UDP

Ja miałem podobny problem, tylko że z eDonkey2000 0.45. Wszystko zawiodło aż metodą prób i błędów doszedłem (chyba) do rozwiązania. W tej chwili mam freesco 0.3.1, na SDI. Chodzi o to że połączenie co chwile zamierało na około 1 min(freesco 0.3.1) do nawet 6 min(freesco 0.2.7). Działo się to tylko przy ściąganiu plików o naprawde dużej ilości źródeł. Problem rozwiązałem ustawiając na routerze i na swoim koputerze (tak, koniecznie takie same jak na routerze) wartości MTU, MRU na 750. Port dla TCP i UDP w eDonkey'ju mam ustawiony taki sam (u mnie w tej chwili 5527). Od tej pory problem zniknął, freesco przestało się blokować, i wszyscy w sieci są szczęśliwi . Acha, nie radze ustawiać zbyt dużej ilości połączeń w ośle, bo wtedy też może się blokować. 75 połączeń powinno wystarczyć.

Upd: Nie urzywajcie tych programów w połączeniu z kazą.

do | -_- |: używam windows me i nigdzie w windzie nie zmienia się MTU i MRU (a przynajmniej nie wiem gdzie). mapowanie portów mam zrobione i high id w emule mam, problem tylko z tymi przywieszkami. na forum edonkeya wyczytałem, że to routery w półkach dostępowych tepsy są za temu winne, ale jeszcze bym spróbował z tym MTU i MRU.

ps: wróciłem do tej sprawy z ciekawości, żeby sprawdzić czy to wina tepsy, czy freesco, bo i tak już muła na sdi nie używam na codzień. skłonił mnie do tego artykuł na temat konroli jakości usługi sdi i neo+ w tepsie.

Najłatwiej zrobić to programem TweakMaster, ale MTU możesz "ręcznie" zmienić w rejestrze, tylko że sam mam XP więc moge ci tylko powiedzieć gdzie to powinno być. Oprócz MTU zmień też "TCP Recive Window"(TweakMaster) czy "DefaultRcvWindow"(rejestr) na 8520:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\NetTrans\000n
Tam gdzieś poszukaj klucza "MaxMTU" z zmień mu wartość na 750.

Wejdź jeszcze do ...
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VxD\MSTCP
... i zmień "DefaultRcvWindow" na wartość 8520.

Wtedy tylko zostaje ustawienie MTU i MRU na routerze na 750 i powinno działać. Sam nie wiem dlaczego akurat przy tak dobranych ustawieniach chodzi (u mnie) bez większych problemów ... Odpowiedz czy Tobie to pomogło.

w windows me nie ma takich kluczy w rejestrze, więc narazie zmieniłem mtu tylko we freesco i co się stanie. w tej chwili mogę tylko powiedzieć, że napewno zmiana timeoutów na proponowane przez fx'a u mnie nie pomaga (to dziwne trochę, bo po paru godzinach zwyczajnie nie ma w ogóle sieci, a freesco chodzi i w logu żadnych komunikatów nie pokazuje). wyłączenie kompresji nagłówka też niewiele zmienia. jak będę miał trochę czasu to podłączę sdi bezpośrednio do swojego kompa żeby się przekonać czy to wina freesco. jeszcze dodam, że jak nie używam emule'a to freesco chodzi bez problemu miesiącami (no może są jakieś chwilowe zaniki transferu, ale jak nie ma statystyk w emule to się tak nie rzuca w oczy:-D).