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 string

Natomiast 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.

2

(16 odpowiedzi, napisanych Oprogramowanie / Software)

Taka sytuacja może wystąpić jeżeli swap zostanie najpierw aktywowany i potem zniknie z jakiegokolwiek powodu (usb-modeswitch na modemach resetujących usb-storage):

Przykładowy błąd (Timestamp i adres nieistotne):
[ 1684.720000] Write-error on swap-device (8:0:872)

$ swapon -s
Filename                                Type            Size    Used    Priority
/dev/sda3\040(deleted)                  partition       265212  404     -1

$ dmesg |egrep 'sd[a-z]'
[   63.430000] Adding 265212k swap on /dev/sda3.  Priority:-1 extents:1 across:265212k
[   65.300000] EXT4-fs (sda4): couldn't mount as ext3 due to feature incompatibilities
[   65.400000] EXT4-fs (sda4): couldn't mount as ext2 due to feature incompatibilities
[   65.600000] EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: (null)
[   87.180000] sd 1:0:0:0: [sda] Synchronizing SCSI cache
[   87.180000] sd 1:0:0:0: [sda]  Result: hostbyte=0x01 driverbyte=0x00
[   89.480000] sd 3:0:0:0: [sdb] 31264768 512-byte logical blocks: (16.0 GB/14.9 GiB)
[   89.480000] sd 3:0:0:0: [sdb] Write Protect is off
[   89.490000] sd 3:0:0:0: [sdb] Mode Sense: 0f 00 00 00
[   89.640000] sd 3:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   89.670000]  sdb: sdb1 sdb2 sdb3 sdb4
[   89.950000] sd 3:0:0:0: [sdb] Attached SCSI removable disk

Niestety trwałym rozwiązaniem tego problemu pozostanie reboot gdyż nie ma możliwości usunięcia takiego 'skasowanego' swapa:

$ swapoff /dev/sda3
swapoff: /dev/sda3: No such file or directory
$ touch /dev/sda3
$ swapoff /dev/sda3
swapoff: /dev/sda3: Invalid argument
$ ln /dev/sdb3 /dev/sda3
$ ls -la /dev/sdb3 /dev/sda3
brw-r--r--    2 root     root        8,  19 Mar 17 02:07 /dev/sda3
brw-r--r--    2 root     root        8,  19 Mar 17 02:07 /dev/sdb3
$ swapoff /dev/sda3
swapoff: /dev/sda3: Invalid argument

Huawei E353u-2 i E353u-2 działają poprawnie z MR-3420 na backfire.

Na trunku dla MR-3020 u-2 działa poprawnie bez żadnych błędów (na s-2 nie testowałem). Do standardowego trunka należy dograć usb-modeswitch, usb-modeswitch-data i moduł option ('opkg update && opkg list |grep option').

Extroot na obu modemach działa stabilnie. Nie było problemów z zapisem/odczytem na kartę SD jak z K3805-z. Extroot tradycyjnie wymaga wcześniejszego przełączenia modemu na etapie preinit_mount przez modeswitch'a z /tmp/overlay'a (przed pivotem extroota ze skryptu 50_determine..). Prosta regułka w /lib/preinit załatwi sprawę.

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 smile

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

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 firmware

Procedura opisana na http://wiki.openwrt.org/doc/howto/generic.uninstall

Zaznaczam że po flashowaniu sprawdziłem że reboot działa (wielokrotnie).

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.

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.

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.

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.

10

(46 odpowiedzi, napisanych Oprogramowanie / Software)

Cezary - Podaj może wersję routera z której korzystasz, może problem jest od niej zależny. Mój MR-3420 jest w rewizji 1.2.
Z informacji na http://wiki.openwrt.org/toh/tp-link/tl-mr3420 wynika że różne rewizje różnią się flash chip'em.

Czy Twoim zdaniem można ubić ten router zmianami w /overlay na routerze?

A jeśli system się wykłada po starcie to dlaczego? W jakich okolicznościach/sposób squashfs może ulec uszkodzeniu?

Może coś powiedzą Tobie okoliczności zaistnienia problemu:
Po zmianie zawartości wewnętrznego /overlaya (modem z extrootem był odpięty) i rebootem puściłem dla pewności sync a potem halt. Po tym odpiąłem i wpiąłem zasilanie, po czym router już niestety nie wstał. Odczekałem chwilę (router potrafił wstawać ze 2-3 minuty). Dioda SYS migała przez cały czas jednostajnie. Przeprowadziłem (nie udaną) próbę resetu firmware'u, odpinając zasilanie i pulsacyjne przyciskając QSS przez dobre 20 sekund od momentu wpięcia zasilania.

11

(46 odpowiedzi, napisanych Oprogramowanie / Software)

Cały czas mówię że korzystam z Twojej wersji Gargoyle PL 1.5.4. Niestety zawiodłem na możliwościach failsafe'a.

Jeśli uda mi się mimo wszystko naprawić w standardowy sposób bez seriala sprostuję od razu.

12

(46 odpowiedzi, napisanych Oprogramowanie / Software)

ad. PS. Dowodzi to jedynie tego że failsafe w Twojej kompilacji raz działa (w Twoim przypadku) a raz nie (u mnie). Kategoryczne stwierdzenie że

Działa i działał od zawsze.

jest więc najmniej nie na miejscu. Ale nie chodzi o udowadnianie czegokolwiek tylko rozwiązanie problemu.

Nie będę wnikał czego dotyczyły zmiany lub też na jakiej rewizji backfire Twoja kompilacja stoi ale nawet oficjalna strona dla tego routera mówi o problemach z failsafe'm na pewnych wersjach.

PS.

temat widzę nie jest nowy.

13

(46 odpowiedzi, napisanych Oprogramowanie / Software)

Spróbuj zatem zmodyfikować jakiś plik w /lib/preinit (z literówka, np. pojedynczym "), sync, halt, i reboot. Na wewnętrznym /overlayu (nie extroot).

Co sugerujesz przy braku możliwości telnetowania się na urządzenie?

Dla mnie ten failsafe w 1.5.4 jest po prostu zawodny i tyle!

14

(46 odpowiedzi, napisanych Oprogramowanie / Software)

Miga w takim tempie jak zazwyczaj podczas normalnego bootu bez względu na przyciskanie.

A czy u Ciebie działa na tym samym firmwarze? Może po prostu zakładasz że skoro działało w wersji poprzedniej. Nie jest przecież wykluczone że coś uległo zmianie.

15

(46 odpowiedzi, napisanych Oprogramowanie / Software)

Tak właśnie robię, jak w FAQ czyli 'przyciskam pulsacyjnie' - nie odnosi skutku. Ping ok, telnet nie.

16

(46 odpowiedzi, napisanych Oprogramowanie / Software)

Ok, to po kolei:

0. Ustawiam adres 192.168.1.2/24 na kliencie.
1. Wpinam kabel power do routera.
2. Przyciskam QSS przez ok 30 sekund (od momentu wpięcia zasilania). W tym czasie zapala się PWR i migający SYS. Podczas wciskania QSS nie zmienia się częstotliwość migania SYS.
3. Router zaczyna odpowiadać na pingi. 'telnet 192.168.1.1' zwraca cały czas błąd.

Co więc robię źle?

Probowałem powyższe również z przyciskiem reset - bez efektu.

Nie za bardzo rozumiem jak zmiana na pliku w /overlay mogła zepsuć coś w rom'ie który z definicji jest read only.

Wniosek - failsafe nie działa prawidłowo w Gargoyle 1.5.4 PL.

17

(46 odpowiedzi, napisanych Oprogramowanie / Software)

przez kilka sekund naciskać pulsacyjnie dowolny przycisk na ruterze.

Który? Na http://wiki.openwrt.org/toh/tp-link/tl-mr3420 mowa o QSS ale ani on ani reset nie działa, tzn. nic nie nasłuchuje na porcie telnet/23.

W jaki sposób firmware mógł zostać uszkodzony przez zmianę plików które z definicji zapisywane są na overlay?

O ile nie robię czegoś źle to failsafe na 1.5.4 nie działa.

18

(46 odpowiedzi, napisanych Oprogramowanie / Software)

Jeśli naprawdę działa, to jak uruchomić ten tryb failsafe (nie po serialu)?

Przycisk QSS ani reset u mnie nie działają.

Custom skript jest autorstwa kolegi i służy do montowania extroota na modemach które resetują urządzenia podczas modeswitch'a. Na 1.5.3 działał wyśmienicie i montował extroota na modemach Huawei E353 i Vodafone K3805-z. Na 1.5.4 przestał działać.

Witam serdecznie,

Mam problem zbootowaniem po instalacji Gargoyle PL 1.5.4 i drobnych zmianach.

Gargoyle Pl 1.5.4 był instalowany przez mtd z wcześniejszego 1.5.3 (cały firmware nadpisany, nie sysupgrade), wartości zostały zresetowane do domyślnych. Bootowanie działało poprawnie.

Ponieważ przestał działać custom preinit script do extroota, zaczałem testować różne zmiany w skryptach preinit i na tym etapie pojawił się jakiś błąd (prawdopodobnie literówka w którymś skrypcie /lib/preinit - przy czym nie był to skrypt 00 button) po czym router odmówił bootowania się.

Cały czas miga dioda sys. Jakiś pomysł jak to rozwiązać? Rozumiem że przyciśnięcie przycisku QSS przy boocie powinien przywrócić oryginalne ustawienia. Boot do failsafe'a nie odnosi skutku, choć router odpowiada na icmp na 192.168.1.1.

Na http://wiki.openwrt.org/toh/tp-link/tl-mr3420 znajduję taką informację:

Failsafe may not work in Backfire before r29661, so it's confirmed to not work at Backfire 10.03.1 launch (r29592). Be extremely cautious on what you're doing or go directly to serial recovery.

Czy ten bug się stosuje do tej wersji Gargoyle PL?

Nazwa modemu: Vodaphone K3805-z

VID:PID 19d2:1001/1003 (po usb_modswitchu)
interfejs do połączenia: /dev/ttyACM0
interfejs do diagnostyki: /dev/ttyACM1

P:  Vendor=19d2 ProdID=1003 Rev= 0.01
S:  Manufacturer=Vodafone
S:  Product=K3805-z

Inne:
Kompatybilny z wymaganiami Aero2.

Nie działa stabilnie pod extroot'em (wymaga dodatkowego skryptu w /lib/preinit dla usb_modswitcha). U mnie na dysku microsd (2GB) w tym modemie (+router MR 3420) pojawiają się po pewnym czasie błędy IO na dysku (z dziwnego powodu nie raportowane w log'u czy dmesg'u) w postaci nie działających binarek i bibliotek oraz literówek w plikach konfiguracyjnych. U kolegi podobnie.

Jeśli macie informacje które z Waszych modemów działają stabilnie pod extroot'em, będę wdzięczny za info.