Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
eko.one.pl → Oprogramowanie / Software → cegiełka mr-3420 na Gargoyle PL 1.5.4
Strony Poprzednia 1 2
Zaloguj się lub zarejestruj by napisać odpowiedź
Wygląda na to że najnowszy trunk^H^H^H^H^H backfire + oficjalne gargoyle 1.5.4 uwzględnia zmiany naprawiające bug z przyciskami
backfire_rev=30752
gargoyle/downloaded/backfire-${backfire_rev}/target/linux/ar71xx/files/arch/mips/ar71xx/mach-tl-mr3420.c
Nie mamy powodów sądzić że Twoja kompilacja Gargoyle PL 1.5.4 sprzed paru dni nie uwzględnia tej poprawki sprzed 2 miesięcy.
Ok, /etc/preinit dziala w skrócie w nastepujacy sposob:
1. source'uje wszystkie pliki z /lib/preinit :
for pi_source_file in /lib/preinit/*; do
. $pi_source_file
done2. po czym odpala na samym końcu wszystkie funckcje/procedury zdefiniowane w powyższych skryptach jako preinit_main
boot_run_hook preinit_main3. poniżej widzimy kolejność w jakiej odpalane są te funkcje/procedury z kategorii preinit_main z powyższych skryptów:
root@xxx:/lib/preinit$ grep preinit_main *
05_enable_reset_button_ar71xx:boot_hook_add preinit_main preinit_enable_reset_button
05_set_iface_mac_ar71xx:boot_hook_add preinit_main preinit_set_mac_address
05_set_preinit_iface_ar71xx:boot_hook_add preinit_main set_preinit_iface
10_indicate_preinit:boot_hook_add preinit_main preinit_ip
10_indicate_preinit:boot_hook_add preinit_main pi_indicate_preinit
30_failsafe_wait:boot_hook_add preinit_main failsafe_wait
40_run_failsafe_hook:boot_hook_add preinit_main run_failsafe_hook
50_indicate_regular_preinit:boot_hook_add preinit_main indicate_regular_preinit
60_init_hotplug:boot_hook_add preinit_main init_hotplug
70_initramfs_test:boot_hook_add preinit_main initramfs_test
80_mount_root:boot_hook_add preinit_main do_mount_root
90_restore_config:boot_hook_add preinit_main restore_config
99_10_run_init:boot_hook_add preinit_main run_init
root@xxx:/lib/preinit$ 4. widac z powyzszego, ze OS czeka na przyciski failsafe (30_failsafe_wait) duzo wczesniej zanim montowanie wszelakich file systemów (80_mount_root). Poniżej jeszcze pokazałem co jest robione przez 80_mount_root. Odpala wszystkie funkcje/procedury zdefiniowane jako preinit_mount_root:
root@xxx:/lib/preinit$ cat 80_mount_root
#!/bin/sh
# Copyright (C) 2006 OpenWrt.org
# Copyright (C) 2010 Vertical Communications
do_mount_root() {
boot_run_hook preinit_mount_root
}
boot_hook_add preinit_main do_mount_root
root@xxx:/lib/preinit$ grep preinit_mount_root *
10_check_for_mtd:boot_hook_add preinit_mount_root check_for_mtd
20_check_jffs2_ready:boot_hook_add preinit_mount_root check_for_jffs2
40_mount_jffs2:boot_hook_add preinit_mount_root do_mount_jffs2
41_merge_overlay_hooks:boot_hook_add preinit_mount_root merge_overlay_hooks
50_determine_usb_root:boot_hook_add preinit_mount_root determine_external_root
55_determine_extroot_sysupgrade:boot_hook_add preinit_mount_root determine_extroot_sysupgrade
60_pivot_usb_root:boot_hook_add preinit_mount_root external_root_pivot
70_pivot_jffs2_root:boot_hook_add preinit_mount_root rootfs_pivot
80_mount_root: boot_run_hook preinit_mount_root
90_mount_no_jffs2:boot_hook_add preinit_mount_root do_mount_no_jffs2
99_10_mount_no_mtd:boot_hook_add preinit_mount_root do_mount_no_mtd
root@xxx:/lib/preinit$Wniosek z powyższego jest taki, że obsługa failsafe jest robiona dużo dużo wcześniej zanim jeszcze podmontowany jest jffs2 ( /dev/mtdblock3 najpierw w /tmp/overlay a pozniej w zależności czy jest extroot czy nie, to /tmp/overlay jest odmontowany całkowicie i montowany extroot, albo zrobiony pivot do /overlay). Czyli failsafe jest robiony całkowicie z squashfs, wiec albo w obrazie Backfire jest bug albo wydarzyło się to co napisał Cezary:
1.1 wg obudowy.
Nie można, bo to zwykła zmiana w jffs jest. Natomiast zdarzały się przypadki na innych modelach, że zrobienie czegoś w systemie powodowało uszkodzenie obrazów ze squashfs.
Innych możliwości niestety nie ma skoro system jest pingowalny wiec się musiał w jakimś stopniu załadować i przynajmniej początkowa część preinita musiała się wykonać (chociażby aby ustawić defaultowe IP i uruchomic sieć)....
Akademicko zaczyna się powoli robić. Jeżeli nie możesz się do niego dostać, jeżeli nie możesz zrobić failsafe to wynik jest jeden - uwaliłeś go. Zostaje Ci tylko kabel szeregowy żeby go odzyskać.
Cezary - Twoja strona o Gargoyle PL 1.5.4 prosi się o adnotację że failsafe może nie zadziałać na tym routerze z nieznanych przyczyn.
Jeśli w wyniku operacji które nie powinny mieć wpływy na możliwość bootowania się do failsafe, nie ma możliwości wbicia się do routera, zgodzisz się chyba ze mną, że taki failsafe jest niewiele wart.
Ok będziemy próbować go wskrzesić po serialu. Jeśli istnieje możliwość podglądu procesu bootowania jak na standardowym serialu to z czystej ciekawości sprawdzę co jest nie tak.
Cezary - Twoja strona o Gargoyle PL czy MR-3420 prosi się o adnotację że występują bricki na tym rouerze bez możliwości bootowania się do failsafe'a na tej rewizji której użyłeś (i prawdopowdobnie innych) z nieustalonych przyczyn (niezwiązanych z bugiem 29661).
Jeśli w wyniku operacji które nie powinny mieć wpływu na możliwość bootowania się do failsafe, nie ma możliwości wbicia się do routera, zgodzisz się chyba ze mną, że taki failsafe jest niewiele wart.
mdx54: to że uszkodziłeś router nie oznacza że takie coś występuje. Cały czas próbujesz zrzucić winę na firmware, określoną rewizję czy nie wiadomo co jeszcze. Osobiście nie udało mi uwalić żadnego mr3420 (w przeciwieństwie do pierwszych wersji 1043), więc nie zakładam że coś z nimi jest nie tak.
Failsafe jest przydatny i działa prawidłowo, o ile system może działać i się uruchomić. To że zepsułeś router nie ma żadnego odbicia w sensowności działania mechanizmu failsafe na openwrt. Ponieważ jest to właściwość softu a nie routera, o ile soft nie działa to nie działa także i failsafe.
Trzymajmy się może meritum: w jaki sposób miało zaistnieć to uszkodzenie w moim przypadku?
Czy w krokach które opisałem jest coś Twoim zdaniem niestandardowego? Miałem wiele routerów, flashowałem wiele razy ale bricki zdażyły mi się jedynie na tym sprzęcie.
Nie mam pojęcia co zrobiłeś. Zakładam jednak ze jest uszkodzony obraz skoro już na tak wczesnym stanie uruchomienia ma problem.
Czy możliwe jest uszkodzenie routera flashując pełne factory 1.5.4 pl (czyli jeśli dobrze rozumiem - pełny obraz fw) z wersji 1.5.3 pl?
# mtd -r write /tmp/openwrt-ar71xx-tl-mr3420-v1-squashfs-factory.bin firmwareProcedura opisana na http://wiki.openwrt.org/doc/howto/generic.uninstall
Zaznaczam że po flashowaniu sprawdziłem że reboot działa (wielokrotnie).
Nie, sysupgrade w sumie robi to w dokładnie w ten sam sposób.
Kolego Cezary powtórzenie nawet sto razy nie zmieni faktów. Mój ruter też jest już cegłą po wczorajszej aktualizacji firmware. Przyciski nie działały od razu. Po zalogowaniu i zrobieniu restartu już się do niego nie zaloguje.
Włączam - miga dioda sys - miga wlan - świecą obie - ("siec_wifi" jest też widoczna) ale się nie można połączyć.
Failsafe też nie działa. Dziwnym trafem potrzebuje też działających przycisków.
Na przyszłość będe unikał TP-LINKa, żeby mi nie przyszedł przypadkiem do głowy pomysł na instalowanie OpenWRT.
Nadal twierdzę że moje firmware działa poprawnie. Testowane i sprawdzone - działa.
Tak poza tematem - sieć wifi nie jest domyślnie włączona, ani w openwrt ani w gargoyle. Więc nie możesz jej widzieć od razu po instalacji.
Kol - opisz najdokładniej robiłeś (upgrade z której wersji/czy wracałeś do oryginalnych ustawień/czyściłeś do standardowych ustawień przed upgrade'm/ile czekałeś zanim router wstanie itd). Podaj wersję sprzętu. Im więcej dokładnych opisów tym lepiej, może razem uda się ustalić co powoduje te bricki.
I nie obrażaj się na TP-LINKa, te routery oferują obecnie najlepszy stosunek jakości do ceny. Jeśli do czegoś można mieć zastrzeżenia to działanie failsafe'a na openwrt/gargoyle. Chociaż po prawdzie support dla MR-3420 został dodany stosunkowo niedawno więc pewne bugi mogły zostać nierozwiązane i trudno mieć o to do kogokolwiek pretensje.
Kabelek do naprawy kosztuje parenaście złoty więc może warto zainwestować (i mieć możliwość 'wskrzeszenia' sprzętu)? A ile zabawy 
Mam zamiar wkrzesić swój routerek bo szkoda mi tego sprzętu i dość słuchania że działa/nie ma buga/itd. Jak jest to go znajdziemy.
A temat problemów z resetem za pomocą QSS przewija się w różnych wątkach, np. http://eko.one.pl/forum/viewtopic.php?pid=35178#p35178
Widzę, że temat aktywny, dotyczy 3220/3420 i podlinkowano mój temat. Ja uwaliłem starszą wersję openwrt, nie Gargoyle. I nie robiłem żadnej całej aktualizacji, router wywalił się z mojej głupoty.
I z podpiętym kablem szeregowym na openwrt na moim 3220 z tego, co zaobserwowałem:
Startuje bootloader - wszystkie diody poza wifi świecą
"Autoboot in 1..." w konsoli - wszystkie diody poza power wyłączone
Startuje openwrt - zaczyna mrugać sys, zaświecają się diody portów eth. <- tutaj router stoi na 192.168.1.1/24 i odpowiada na pingi przez kilkadziesiąt sekund, brak dhcp, telnetu, ssh, vlany nie działają; routery z jedym switchem (lan i wan razem) tutaj przepuszczają wszystko
Chyba dopiero tutaj ładowana jest konfiguracja z overlaya - eth gaśnie, zaświeca się, wifi się zaświeca itd., wszystko zależnie od konfiguracji. Domyślnie dioda sys świeci, nie mruga.
Do failsafe: jak zaczyna mrugać dioda sys naciskam i przytrzymuje qss. Dioda sys zaczyna mrugać częściej - jest failsafe, można puścić przycisk. Jak przycisk przytrzymam od momentu gdy włączam router failsafe nie działa. To openwrt, nie wiem jak jest z Gargoyle.
Witam,
TP-link został odratowany. Failsafe nie udało się uruchomić.
Użyłem:
- kabel od Samsunga E700
- http://pinouts.ru
- lutownica
- instrukcja na eko.one.pl
- i wolny w sumie około 1 dzień
Teraz działa tak jak powinien jako AP na Gargoyle PL. Nie instalowałem jeszcze modemu: brak czasu. Na fabrycznym miałem wrażenie,że za długo "myśli" zanim coś zrobi. Pingi wydawały się prawidłowe.
mdx54 - zainstalowałem przez fabryczne oprogramowanie, następnie: zalogowałem się --> włączyłem wi-fi --> ustawiłem radio na B-G --> lan na 192.168.223.1 --> zapisałem ustawienia -->ruter zaświecił wszystkie diody tak jakby robił restart i komunikacja z ruterem została zakończona. Tylko przez serial się dało.
To teraz poćwicz i zobacz czy failsafe Ci działa.
Cezary, ha ha ha ha ale się uśmiałem.
Taka ciekawostka. Włączyłem ruter przez miernik mocy.
Oprogramowanie fabryczne:
Ruter jako AP - internet WAN 5 W
Podpięty modem Huawei E122 lub E173u-2 6-7 W
Gargoyle PL:
Ruter jako AP - internet WAN 3-4 W
Podpięty modem Huawei E122 dioda niebieska 4 W
dioda turkusowa 5-6 W
Modem Huawei E173u-2 występuje przesył danych 5-6 W
gdy dane nie są przesyłane 4 W
Kolor diody nie ma znaczenia.
Huawei E122 - OFnK około 22% wg top_netinfo
Huawei E173u-2 - Play około 22% wg top_netinfo
Wi-Fi jedno podłączone urządzenie.
Jakby nie patrzeć oszczędność jakaś jest. Szczególnie w czasie jak modem nie przesyła danych.
Ruter co 180 sekund przesyła niecałe 0,5 kB danych. Zastanawia mnie gdzie i po co?
Modem E122 karta OFnK podłączony pod komputer nawet na cały dzień nie prześle ani bajta i nie rozłączy (dioda niebieska).
Serio sprawdź. Uparcie twierdziliście że failsafe nie działa i to wina mojego softu. Ja twierdzę co innego.
Ja podzielę się innymi liczbami.
MR3020 - sam to 0.5W, dołączenie kabla ethernet (rj45) to +0.3W
MR3020 + E3131 z Aero2 (połączony - led turkusowy) - wskazania miernika to 2.2W, dołączenie kabla +0.3W
Po skonstruowaniu kabla serialowego, udało się ustalić przyczynę cegiełki. Tak jak podejrzewałem, winna byłą literówka w pliku na overlayu (swoją drogą polecam poniższą metodę debugowania, zwłaszcza jeśli nie działają rzeczy związane z extrootem):
root@(none):~$ sh -x /sbin/mount_root 2>&1
+ . /tmp/preinit-hook-merge/50_determine_usb_root
/sbin/mount_root: /tmp/preinit-hook-merge/50_determine_usb_root: line 8: syntax error: unterminated quoted stringNatomiast co do problemu dlaczego przycisk reset/qss nie pozwala na przywrócenie wartości domyślnych, też znamy odpowiedź:
root@(none):/lib/modules/2.6.32.27$
Ces/2.6.32.27$ ls
k�ko ip_tables.ko sch_red.ko
act_mirred.ko ipt_ECN.ko sch_sfq.ko
act_police.ko ipt_LOG.ko sch_tbf.ko
aes_generic.ko ipt_MASQUERADE.ko sch_teql.ko
arc4.ko ipt_NETMAP.ko scsi_mod.ko
ath.ko ipt_REDIRECT.ko sd_mod.ko
ath9k.ko ipt_REJECT.ko sierra.ko
ath9k_common.ko ipt_SET.ko slhc.ko
ath9k_hw.ko ipt_bandwidth.ko ts_bm.ko
button-hotplug.ko ipt_ecn.ko ts_fsm.ko
cbc.ko ipt_set.ko ts_kmp.ko
cdc-acm.ko ipt_timerange.ko tun.ko
cfg80211.ko ipt_webmon.ko usb-storage.ko
cls_flow.ko ipt_weburl.ko usbcore.ko
cls_fw.ko iptable_filter.ko usbserial.ko
cls_route.ko iptable_mangle.ko vfat.ko
cls_tcindex.ko iptable_nat.ko x_tables.ko
cls_u32.ko iptable_raw.ko xt_CLASSIFY.ko
compat.ko leds-gpio.ko xt_CONNMARK.ko
crc-ccitt.ko ledtrig-usbdev.ko xt_DSCP.ko
crc16.ko mac80211.ko xt_HL.ko
deflate.ko mbcache.ko xt_IMQ.ko
ecb.ko nf_conntrack.ko xt_MARK.ko
ehci-hcd.ko nf_conntrack_ftp.ko xt_NOTRACK.ko
em_cmp.ko nf_conntrack_ipv4.ko xt_TCPMSS.ko
em_meta.ko nf_conntrack_irc.ko xt_comment.ko
em_nbyte.ko nf_conntrack_tftp.ko xt_connbytes.ko
em_text.ko nf_defrag_ipv4.ko xt_connmark.ko
em_u32.ko nf_nat.ko xt_conntrack.ko
ext2.ko nf_nat_ftp.ko xt_dscp.ko
fat.ko nf_nat_irc.ko xt_helper.ko
gpio_buttons.ko nf_nat_tftp.ko xt_hl.ko
imq.ko nls_base.ko xt_iprange.ko
input-core.ko nls_cp437.ko xt_layer7.ko
input-polldev.ko nls_iso8859-1.ko xt_length.ko
ip_set.ko option.ko xt_limit.ko
ip_set_iphash.ko ppp_async.ko xt_mac.ko
ip_set_ipmap.ko ppp_generic.ko xt_mark.ko
ip_set_ipporthash.ko pppoe.ko xt_multiport.ko
ip_set_ipportiphash.ko pppox.ko xt_recent.ko
ip_set_ipportnethash.ko sch_dsmark.ko xt_state.ko
ip_set_iptree.ko sch_esfq.ko xt_statistic.ko
ip_set_iptreemap.ko sch_gred.ko xt_string.ko
ip_set_macipmap.ko sch_hfsc.ko xt_tcpmss.ko
ip_set_nethash.ko sch_htb.ko xt_tcpudp.ko
ip_set_portmap.ko sch_ingress.ko xt_time.ko
ip_set_setlist.ko sch_prio.ko
root@(none):/lib/preinit$ cat 05_enable*
05_enable*
���ɥ��с/lib/ar71xx.sh
preinit_enable_reset_button() {
insmod gpio-button-hotplug
}
boot_hook_add preinit_main preinit_enable_reset_button
root@(none):/lib/preinit$ lsmod
k�����ze Used by Not tainted
leds_gpio 1456 0 Wygląda na to że w romie Gargoyle 1.5.4 by Obsy brakuje modułu gpio-button-hotplug.ko. Po zresetowaniu do wartości fabrycznych mamy takie moduły:
root@Gargoyle:/$ lsmod |egrep 'button|gpio|hotplug'
k��}���ѽ�
input_polldev 1360 1 gpio_buttons
input_core 17056 3 gpio_buttons,input_polldev
leds_gpio 1456 0 Przyczyną zatem nie był uszkodzony rom a brak modułu odpowiedzialnego za obsługę przycisku.
Serio sprawdź. Uparcie twierdziliście że failsafe nie działa i to wina mojego softu. Ja twierdzę co innego.
Uparcie twierdze, że przy pierwszym wgraniu gargoile failsafe nie działało. Po użyciu kabla szeregowego i zainstalowaniu ponownym failsafe działa prawidłowo. Wystarczy wcisnąć na 2s przycisk w odpowiednim momencie i dioda mruga jak szalona. Pozostałe funkcje przycisków, w odróżnieniu od pierwszej instalacji, też działają.
czyli co, wgrałeś nie działało, wgrałeś, działa. I ma być wina softu, tak?
Strony Poprzednia 1 2
Zaloguj się lub zarejestruj by napisać odpowiedź
eko.one.pl → Oprogramowanie / Software → cegiełka mr-3420 na Gargoyle PL 1.5.4
Forum oparte o PunBB, wspierane przez Informer Technologies, Inc