[MOD] Tomato by shibby
|
shibby |
Dodano 20-07-2013 15:51
|
SysOp
Posty: 17112
Dołączył: 15/01/2009 20:30
|
no i będzie tak. Tak zrobili teraz usb_modeswitch i ja nie będę od ich standardu odbiegał bo to utrudni mi jego późniejszą aktualizację. Znasz default product i vendor to zwyczajnie podaj je jako parametry. Jeżeli w twoim przypadku jest to:
DefaultVendor= 0x12d1
DefaultProduct=0x1f01
no to:
usb_modeswitch -Q -c /etc/usb_modeswitch.d/12d1:1f01 -v 12d1 -p 1f01
i gotowe.
Router: Unifi Cloud Gateway Max
Switch: Netgear MS510TXPP
Switch: Unifi USW-Flex-Mini - szt. 2
Wi-Fi: Unifi U6-Lite - szt. 2
Proxmox VE: i5-13400T, 64GB RAM, 2x 512GB NVMe, 3x 2TB SSD, Intel X710-DA2 SFP+
VM #1: Synology SA6400
VM #2: Debian, WWW
VM #3: Home Assistant OS
|
|
|
|
lazik |
Dodano 20-07-2013 20:25
|
Power User
Posty: 356
Dołączył: 09/12/2011 13:09
|
OK, rozumiem. Prosiłbym zatem o aktualizację tutoriala dotyczącego e3131 w wersji hilink i aero.
Dodatkowo w tutku przy rt-n66u oprócz wymienionych commitów do nvram trzeba zmienić wandevs na eth3
|
|
|
|
Adooni |
Dodano 21-07-2013 22:46
|
VIP
Posty: 2359
Dołączył: 02/02/2011 04:29
|
z kazda nowa wersja tomato jest coraz lepsze.
Jedno mnie tylko wpienia. Ludzie piszą ze w najnowszej wersji to i to nie dziala, cos zostalo popsute.
W wiekszosci przypadkow nie maja oni racji - nauczcie sie pisac
"Nie potrafie tego i tego uruchomic. Jestem za cienki w uszach zeby to odpalic kto mi pomoze"
Orange 300/50 Mb/s + ONT Terminal
HPE MS gen8 Proxmox 7.0-11 VMs: Router OPNsense 23.X-amd64 and OMV
HPE MicroServer gen8: Xeon E3-1265Lv2, 16GB (2x KTH-PL316E/8G), HP 331T, 4x4TB WD RED
Asus RT-AC68U AccessPoint
|
|
|
|
lazik |
Dodano 21-07-2013 23:09
|
Power User
Posty: 356
Dołączył: 09/12/2011 13:09
|
Chłopie stuknij się w łepetynę. Tutorial przeczytaj a później pisz dyrdymały. W changelogu nie ma wzmianki że modeswitch trzeba inaczej odpalać i tutek nie jest też poprawiony. Oleju i wyrozumiałości życzę.
|
|
|
|
shibby |
Dodano 22-07-2013 08:15
|
SysOp
Posty: 17112
Dołączył: 15/01/2009 20:30
|
@lazik w changelogu jest wzmianka, o aktualizacji usb_modeswitch. Jest też poprawiony skrypt przełączający, tak więc z automatu działa wszystko poprawnie i zgodnie ze sztuką. To że ty odpalasz coś inaczej, ręcznie to już inna inszość. Przecież ja nie jestem w stanie pisać co się w danej wersji pakietu zmieniło, że do tej pory coś się robiło tak czy tak a w nowej już inaczej. Taki zamysł miał autor i nic na to nie poradzę. Tak więc sama informacja, o zmianie wersji danego pakietu powinna dać ci do zrozumienia, że zmiany mogły być kosmetyczne lub kolosalne.
Co do tutorialu to jest on poprawny, ponieważ idąc jego krokami sami tworzymy plik przełączający a w nim są podane wartości default product i vendor, tak więc tutorial jest poprawny i spójny. Ale, żeby nie było, to wczoraj go dopieściłem o wartości domyślne w parametrach i to przed twoją powyższą wypowiedzą (twój fail). O eth3 nie będę pisał bo to indywidualna sprawa każdego z routerów (lub każdego z nas, bo jak ktoś zrobi np wifi 5Ghz mod na RT-N16 to też będzie miał inne eth). Wyraźnie w tutorialu jest zaznaczone by zajrzeć do loga i zobaczyć jaki interfejs został wykryty.
Cytat Oleju i wyrozumiałości życzę
dokładnie, a tego ostatniego w szczególności.
Router: Unifi Cloud Gateway Max
Switch: Netgear MS510TXPP
Switch: Unifi USW-Flex-Mini - szt. 2
Wi-Fi: Unifi U6-Lite - szt. 2
Proxmox VE: i5-13400T, 64GB RAM, 2x 512GB NVMe, 3x 2TB SSD, Intel X710-DA2 SFP+
VM #1: Synology SA6400
VM #2: Debian, WWW
VM #3: Home Assistant OS
|
|
|
|
lazik |
Dodano 22-07-2013 21:21
|
Power User
Posty: 356
Dołączył: 09/12/2011 13:09
|
@shibby: powiedz mi czy patrząc że dana rzecz się zaktualizowała czytasz tonę changeloga (ba trzeba jeszcze wiedzieć od której wersji był dany pakiet aktualizowany) np. modeswitcha żeby się dowiedzieć że zamiast:
usb_modeswitch -c /jffs/hilink
teraz trzeba wpisać:
usb_modeswitch -c /jffs/hilink -v 12d1 -p 1f01
Zobacz kiedy poprawiłeś tutek a kiedy było pytanie. Dodatkowo w tutku jest niepotrzebny galimatias po aktualizacji do v110. Ano:
plik hilink nie musi wyglądać tak jak piszesz:
DefaultVendor= 0x12d1
DefaultProduct=0x1f01
TargetVendor= 0x12d1
TargetProduct= 0x14db
MessageContent="55534243123456780000000000000a11062000000000000100000000000000"
NoDriverLoading=1
a może:
TargetVendor= 0x12d1
TargetProduct= 0x14db
MessageContent="55534243123456780000000000000a11062000000000000100000000000000"
NoDriverLoading=1
nie trzeba go wrzucać do jffs bo jest już jako /etc/usb_modeswitch.d/12d1:1f01. Dodatkowo jak przyjmniesz uruchamianie z wersji pierwotnej to ten dopisek -v 12d1 -p 1f01 jest zbędny.
nie trzeba do jffsa wrzucać mii.ko - też jest w obrazie. cdc_ether i usbnet mimo uwag na końcu tutka do obrazu nie zostały dodane - szkoda
Moja uwaga co do dwuzakresowego jest taka że wymieniasz że dla niego najprawdopodobniej będzie eth3 i masz całkowitą rację i IMVHO warto by było dodać że trzeba dla dwuzakresowca dodatkowo zmienić
nvram wandevs=vlan3
na
nvram wandevs=eth3
O tym nie ma wzmianki tylko o
nvram set wan_iface=eth2
nvram set wan_ifname=eth2
nvram set wan_ifnameX=eth2
nvram set wan_ifnames=eth2
nvram commit
I tyel do dodania. O czytaniu przez ZU changeloga zmienianych modułów w tomato radzę głębiej pomyśleć.
|
|
|
|
xentis |
Dodano 22-07-2013 22:59
|
User
Posty: 29
Dołączył: 30/10/2012 19:07
|
Witam
Mam pytanie odnośnie DDNS
na samej górze strony "Dynamiczny DNS" jest opcja "Adres IP" i domyślnie wybrany "Użyj adresu IP WAN..."
A następna opcja "Automatyczne odświeżanie co" I tu pytanie czy ta funkcja wymusza aktualizację niezależnie od funkcji znajdującej się w konfiguracji konta DNS1 opcja "Zapisz stan kiedy zmieni się IP (nvram commit)" bo jeśli dobrze rozumiem to inicjuje update przy wykryciu zmiany IP. Z kolei jak wykrywa zmianę skoro zazwyczaj zmiana następuje podczas resetu modemu a to ma miejsce zazwyczaj podczas zaniku zasilania czyli router też zalicza reset, więc jak porównuje czy obecne IP się zmieniło w stosunku do tego sprzed resetu skoro soft nie jest w stanie nic trwale zapisać w pamięci (oczywiście nie biorę pod uwagę podmontowanych pamięci zewnętrznych)?
Pozdrawiam
NETGEAR WNR-3500Lv2
|
|
|
|
dkozlows |
Dodano 23-07-2013 20:48
|
User
Posty: 46
Dołączył: 26/03/2012 23:00
|
Shibby : czy jest możliwość dodania informacji o sile sygnału 3G ? Ostatnio widziałem taki routerek TP-LINK MR3220 i tam było to całkiem ładnie przedstawione
|
|
|
|
Larus |
Dodano 23-07-2013 21:33
|
User
Posty: 54
Dołączył: 03/07/2006 10:56
|
Cytat kamilj napisał(a):
Małe pytanie do osób które korzystają z PPPoE.
Czy ktoś z was zauważył problemy z rozłączaniem się połączenia bez powodu kilka razy dziennie, a następnie problemy z ponownym połączeniem?
Niestety tak. Ja przypuszczam, że to nie jest wina klientów PPPoE, tylko serwerów. U mnie Neostrada i PPPoE rozłącza losowo co kilka/kilkanaście godzin. Modem Thomson/Tplink/whatever. Na PPPoA jak skała 24h, na PPPoE (bridge) disconnecty. Wg logów rozłącza "druga" strona. Firmware 093, ale na starszych też to było, jak i oryginalnym Tomato 1.28.
|
|
|
|
jack78 |
Dodano 23-07-2013 23:12
|
OL Maniac
Posty: 1365
Dołączył: 22/04/2007 22:28
|
Ja z tym nie mam problemów jak już pisałem wcześniej. Od soboty mam 20mbit, ale przy szumach jakie są na mojej linii mam tylko 14-16mbit (o czym wiedziałem przy zmienianiu umowy), ale łącze stabilne jak skała
unknown daemon.info pppd[6601]: Connect time 1440.0 minutes.
wszystkie resety połączeń mam z tym czasem, a więc dokładnie 24h.
Modem WAG200G w trybie bridge lub Thomson SpeedTouch 546 v6.
Mikrotik hAP ac2
UniFi AP AC v2-OFW, UniFi AP PRO- OpenWRT,
Linksys E1000v2 - Tomato-RT-N5x-MIPSR2-116-Hyzoom.4M-Mini
Tenda AC10 - AC1200 OFW
NAS - HP Microserver Gen8 i3-3220T, 8GB RAM 5x 3TB WD RED | Xpenology
|
|
|
|
Larus |
Dodano 23-07-2013 23:35
|
User
Posty: 54
Dołączył: 03/07/2006 10:56
|
Doczytałem, że to może zależeć od tego jak serwer ISP'a odpowiada na lcp-echo - jeśli masz 100% odpowiedzi, to problem się nie ujawni. U mnie są okresy, gdzie właśnie jest 1440 min, a czasem losowe 7, 74, 128 min itp.
Znalazłem taki posting w necie:
http://www.linksysinfo.org/index.php?...aio.61366/
W skrócie - licznik lcp-echo-failure nie jest resetowany po "echo reply sucess" i przy domyślnym limicie 5, po wystąpieniu 4 braków odpowiedzi, mimo, że xxx następnych będzie OK, to przy choćby jednym kolejnym (4+1) osiągnie limit 5 i rozłącza sesję. Pytanie do Shibby - czy mógłbyś się temu przyjrzeć czy to ma sens ?
Edytowany przez Larus dnia 23-07-2013 23:40
|
|
|
|
shibby |
Dodano 24-07-2013 08:05
|
SysOp
Posty: 17112
Dołączył: 15/01/2009 20:30
|
u siebie nie mam pppoe (na szczeście) tylko stały publiczny ip (dhcp). U rodziców jest co prawda dialog (pppoe) ale tak mam jakąś archiwalną wersję tomato i nie widzę potrzeby zmieniać (sieć osiedlowa, więc sąsiedzi będą się pluć, że się bawię). Nie mam więc jak tego sprawdzić.
Potrzebuję więc konkretnych informacji typu: na tej i tej wersji chodziło wszystko super, od tej wersji jest problem. Wtedy ja patrze na zmiany między wersjami i może w ten sposób uda się namierzyć problem i go rozwiązać.
Jedyne czego jestem pewien to neo na v104 chodzi poprawnie (modem siemens 4100 w bridge). Spróbuję u kolegi podnieść tomato do v111 (jak wydam na dniach) i zobaczymy.
Router: Unifi Cloud Gateway Max
Switch: Netgear MS510TXPP
Switch: Unifi USW-Flex-Mini - szt. 2
Wi-Fi: Unifi U6-Lite - szt. 2
Proxmox VE: i5-13400T, 64GB RAM, 2x 512GB NVMe, 3x 2TB SSD, Intel X710-DA2 SFP+
VM #1: Synology SA6400
VM #2: Debian, WWW
VM #3: Home Assistant OS
|
|
|
|
Larus |
Dodano 24-07-2013 10:41
|
User
Posty: 54
Dołączył: 03/07/2006 10:56
|
Dzięki za odzew przede wszystkim.
Dla testu zmieniłem wczoraj wartość lcp-echo-failure z 5 na 2 i zgodnie z przewidywaniami z losowych disconnectów zrobiła się katastrofa - regularne rozłączanie w przedziale 5-15 min.
Jul 24 06:29:29 swistak daemon.info pppd[17091]: Connect time 5.9 minutes.
Jul 24 06:36:45 swistak daemon.info pppd[17438]: Connect time 7.1 minutes.
Jul 24 06:42:38 swistak daemon.info pppd[17781]: Connect time 5.8 minutes.
Jul 24 06:49:54 swistak daemon.info pppd[18125]: Connect time 7.2 minutes.
Jul 24 06:55:56 swistak daemon.info pppd[18468]: Connect time 5.9 minutes.
Jul 24 07:02:57 swistak daemon.info pppd[18815]: Connect time 6.9 minutes.
Jul 24 07:08:54 swistak daemon.info pppd[19161]: Connect time 5.8 minutes.
Jul 24 07:16:06 swistak daemon.info pppd[19502]: Connect time 7.2 minutes.
Jul 24 07:21:32 swistak daemon.info pppd[19845]: Connect time 5.4 minutes.
Jul 24 07:28:49 swistak daemon.info pppd[20195]: Connect time 7.2 minutes.
Jul 24 07:34:35 swistak daemon.info pppd[20542]: Connect time 5.7 minutes.
Jul 24 07:41:57 swistak daemon.info pppd[20891]: Connect time 7.2 minutes.
Jul 24 07:47:58 swistak daemon.info pppd[21235]: Connect time 5.9 minutes.
Jul 24 07:55:15 swistak daemon.info pppd[21581]: Connect time 7.1 minutes.
Jul 24 08:05:32 swistak daemon.info pppd[21909]: Connect time 10.2 minutes.
Jul 24 08:11:28 swistak daemon.info pppd[22255]: Connect time 5.8 minutes.
Jul 24 08:18:45 swistak daemon.info pppd[22599]: Connect time 7.2 minutes.
Jul 24 08:24:31 swistak daemon.info pppd[22945]: Connect time 5.6 minutes.
Jul 24 08:31:43 swistak daemon.info pppd[23289]: Connect time 7.1 minutes.
Jul 24 08:45:10 swistak daemon.info pppd[23638]: Connect time 13.4 minutes.
Jul 24 08:52:19 swistak daemon.info pppd[24061]: Connect time 7.1 minutes.
Jul 24 08:58:13 swistak daemon.info pppd[24405]: Connect time 5.7 minutes.
Wynika z tego, że jest to dobry kierunek poszukiwań. Dzisiaj ustawiłem dla testu duużą wartość (20) i będę raportował.
Piszesz, że masz dostęp do starego Tomato z Dialogiem, więc miałbym prośbę: czy mógłbyś wkleić konfigurację pppd z tamtej wersji ?
Mam na myśli plik options pppd:
cat /tmp/ppp/wanoptions
Ta sama prośba do jack78.
PS. Ja zatrzymałem się na ver. 093. Jakoś te nowsze na moim zabytku (WRT54GL) gorzej chodzą (stabilność, wifi, ...).
I domyślne wartości to:
root@swistak:/tmp/home/root# cat /tmp/ppp/wanoptions
unit 0
user 'xxx'
lcp-echo-adaptive
defaultroute
usepeerdns
default-asyncmap
nopcomp
noaccomp
novj
nobsdcomp
nodeflate
noauth
refuse-eap
maxfail 0
lcp-echo-interval 10
lcp-echo-failure 5
persist
holdoff 30
password 'xxx'
plugin rp-pppoe.so
nomppe nomppc
nic-vlan1
mru 1492 mtu 1492
mp
debug
|
|
|
|
goabroad |
Dodano 24-07-2013 11:17
|
User
Posty: 82
Dołączył: 22/07/2006 16:08
|
Cytat shibby napisał(a):
u siebie nie mam pppoe (na szczeście) tylko stały publiczny ip (dhcp). U rodziców jest co prawda dialog (pppoe) ale tak mam jakąś archiwalną wersję tomato i nie widzę potrzeby zmieniać (sieć osiedlowa, więc sąsiedzi będą się pluć, że się bawię). Nie mam więc jak tego sprawdzić.
Potrzebuję więc konkretnych informacji typu: na tej i tej wersji chodziło wszystko super, od tej wersji jest problem. Wtedy ja patrze na zmiany między wersjami i może w ten sposób uda się namierzyć problem i go rozwiązać.
Jedyne czego jestem pewien to neo na v104 chodzi poprawnie (modem siemens 4100 w bridge). Spróbuję u kolegi podnieść tomato do v111 (jak wydam na dniach) i zobaczymy.
Witam,
U znajomych w usłudze Neo mam postawione RT-N10U + modemy w trybie bridge (ZTE, Speedstream 4100)
W 1 lokalizacji: Tomato Firmware 1.28.0000 MIPSR2-109 K26 USB Nocat-VPN
Brak problemów z pppoe
W 2 lokalizacji: Tomato Firmware 1.28.0000 MIPSR2-100 K26 USB Nocat-VPN
Brak problemów z pppoe
Raz miałem problemy w lok. 1 ale wtedy SNRy były niskie (okazało się że na słupie trzeba kale poprawić). Generalnie na obu routerach mam zaschedulowany pppoe reconnect o 3.30 każdego dnia i reboot co tydzień. Odpukać nie ma problemów. Sesja pppoe jest nawiązywana bez problemu i nie zrywa.
Przykładowe parametry linii w lokalizacji z routerem1:
adsl: ADSL driver and PHY status
Status: ShowtimeRetrain Reason: 8000
Channel: INTR, Upstream rate = 1301 Kbps, Downstream rate = 12446 Kbps
Link Power State: L0
Mode: ADSL2+
Channel: Interleave
Trellis: U.ON /D.ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 8.3 6.1
Attn(dB): 23.5 11.9
Pwr(dBm): 0.0 12.8
Max(Kbps): 21836 1308
Rate (Kbps): 12446 1301
Pzdr.
Pozdrawiam,
Goabroad
-------------------------
- RB2011UAS-2HnD-IN ROS 6.38.1
- RB951U ROS 6.38.1
- RT-N10U + Tomato Firmware 1.28.0000 MIPSR2-109 K26 USB Nocat-VPN
- Fritz7170
- Hik DS-2CD2032 3Mpix
- Raspberry Pi 3B
- QNAP TS-251
|
|
|
|
genek |
Dodano 24-07-2013 20:16
|
User
Posty: 7
Dołączył: 14/07/2007 03:12
|
Witam,
Wgralem najnowsza wersje tomato-ND-1.28.5x-110-VPN do routera WRT54GSv.4 i wszystko fajnie tylko necior nie chula z predkoscia 50MB a tylko 30MB. Mam lacze 50MB jak podlacze komp bezposrednio download mam bez problemu 50MB. Czy ktos moze wie daczego Linksys wyciaga tylko 30MB??
|
|
|
|
shibby |
Dodano 24-07-2013 20:25
|
SysOp
Posty: 17112
Dołączył: 15/01/2009 20:30
|
bo tam jest za słaby procesor do takiego łącza. Ten router nadaje się super do łącza max 20Mbps.
Router: Unifi Cloud Gateway Max
Switch: Netgear MS510TXPP
Switch: Unifi USW-Flex-Mini - szt. 2
Wi-Fi: Unifi U6-Lite - szt. 2
Proxmox VE: i5-13400T, 64GB RAM, 2x 512GB NVMe, 3x 2TB SSD, Intel X710-DA2 SFP+
VM #1: Synology SA6400
VM #2: Debian, WWW
VM #3: Home Assistant OS
|
|
|
|
Sigma |
Dodano 24-07-2013 20:29
|
Power User
Posty: 382
Dołączył: 01/09/2011 08:32
|
Stary router. To chyba max co on wyciąga po prostu
[small]Netgear WNR3500L powered by Tomato Firmware 1.28.0000 MIPSR2-130 K26 USB BTGui
Netgear WNDR4300 powered by OpenWrt Chaos Calmer 15.05 (r47662)
TP-Link TL-WDR4300 v1 powered by OpenWrt Chaos Calmer 15.05 (r47662)
[b]TP-Link T
|
|
|
|
genek |
Dodano 24-07-2013 21:01
|
User
Posty: 7
Dołączył: 14/07/2007 03:12
|
wlasnie zapodalem wersje "tomato RAF 1.28.121006. This version guarantees WAN-LAN 80Mb throughput. For WRT54G/GS/GL. Dated, February 20th, 2011" i router bez problemu ciagnie powyzej 50MB, wiec argument za procesor za slaby jest troche nie ten tego...
|
|
|
|
b3rok |
Dodano 24-07-2013 21:33
|
Administrator
Posty: 621
Dołączył: 10/01/2008 18:40
|
@genek - to inaczej, bardziej obrazowo, spróbuj uruchomić WinXP (bez service packów) na PC z procesorem np. 800Mhz i 256 RAM potestuj jak działa, a potem WinXP z SP3 na tym samym sprzęcie... Ciekawe czy zauważysz różnicę i też napiszesz "wiec argument że procesor za słaby i RAMu za mało jest trochę nie ten tego..."
I. Huawei HG8240 + 1x Netgear r7000 @FreshTomato + Synology DS1512+
II. TP-Link TL-WDR4300 @Obsy OpenWRT Gargoyle
III. TP-Link TL-WDR3600 @Obsy OpenWRT Gargyle
|
|
|
|
genek |
Dodano 24-07-2013 22:48
|
User
Posty: 7
Dołączył: 14/07/2007 03:12
|
@b3rok, dobrze dobrze nie mozna porownywac paprokow z Microsoftu do Shibbiego
a wracajac do problemu...
Shibby czy moglbys potwiedrdzic ze jak by twoj build mial zaimplementowanego fast NAT to ta predkosc moglaby wzrosnac?
Z tego to wygrzebalem nie stosuje sie tego ze wzgledu na problem z QoS.
pomijajac predkosc to wole twoja kompilacje
|
|
|