Witam, właśnie wczoraj zaktualizowałem mój 1043nd 1.5.10.7 do 1.5.10.10 (gargoyle-1.5.10.10-ar71xx-tl-wr1043nd-v1-squashfs-sysupgrade) przez www i niestety ruter nie wstał. Nie wiem dlaczego może przez to że zaznaczyłem opcję zachowania konfiguracji. hm... nie ważne.
Pytanie, czy jestem w stanie stwierdzić czy połączenie po rs'ie cokolwiek da ? czy boot jest ok ? po podłączeniu rutera dwa razy migną wszystkie diody i nic. Po podłączeniu do portów link jest.

no nic dam sobie luz, nie mam glodpinów a transformatorówką nie chce mi się męczyć, nawiasem mówiąc od dawna miałem ochotę na tl-wdr3500. Także narazie odłożę na półkę 1043nd i lecę po wdr3500

w mojej okolicy widzę 50zł różnicy a nie bardzo wierzę w ten gigabit, 1043nd też niby miał a nigdy tego gigabita nie widziałem, pewnie to kwestia mojego okablowania, z dlna wyciągnę i tak max. 8-9MB/s, ale zobaczę, przyszłościowo może i warto.

no tylko żeby tplink chciał go fabrycznie wgrywać

Potwierdzam - ale być może u mnie to akurat związane jest z zachowanym konfigiem z poprzedniej wersji.

https://github.com/pepe2k/u-boot_mod

Musisz sobie ściągnąć moje źródła i skompilować albo poczekać na wydanie gotowych obrazów.

Niedługo.

Nie.

Skoro kolega pruszył problem ogólnie błędów w gargoyle to i ja pozwolę sobie na "krótkie" ukazanie i opisanie błędu:

Gdy zmienię MAC na WAN i widnieje cały czas zaznaczony - ten nowy - z ptaszkiem obok numeru - czyli logicznie z domysłu ma tak być bo teoretycznie (nie zawsze się tak dzieje - to drugi problem obok pierwszego lub jego rozwinięcie) gdybym go odhaczył ma wrócić stary (oryginalny lub ostatni sprzed aktualizacji - nawet jak nie jest oryginalny). Ok, tu wszystko wydaje się logiczne. Ale w praktyce tak nie jest - już nadmieniłem w poprzednim nawiasie w poprzednim zdaniu o co chodzi. Kolejna sprawa - przed aktualizacją ów zmieniony adres MAC jest cały czas widoczny jako inny względem oryginalnego (czy poprzedniego z przed ostatniej aktualizacji) jest opatrzony ptaszkiem - natomiast w ostatnich dwóch buildach jest feler - po aktualizacji i owszem - nr. MAC na szczęście zostaje - natomiast ptaszek znika. Wszytko to w zakładce "Konfiguracja podstawowa".
I teraz najciekawsze - przy niektórych zmianach ustawień w tej zakładce fakt odhaczonego ptaszka skutkuje tym, że adres MAC powraca do oryginalnego a przy innych nie !
Nie było by to problemem gdyby na zdrowy rozum wystarczyło zwyczajnie na istniejącym (tym zmienionym z oryginalnego na swój) i aktywnym adresie MAC na WAN dodać ptaszek i w domyśle mieć pewność, że jakiekolwiek zmiany w tej zakładce nie zagrożą zmianie MAC na WAN - a problem jest w tym, że klikanie ptaszka i zachowanie zmian nie skutkuje pojawieniem się owego ptaszka - czyli jakiejś (przynajmniej wizualnie i w domyśle) pewności, że manipulacja różnymi, innymi ustawieniami w tej zakładce nie zmieni nam MAC na WAN na oryginalny (lub ten sprzed aktualizacji) bo wszakże ów ptaszek (blokada) nie może być wcześniej wywołany i zapisany. Czyli taka spora loteria w tej zakładce z dokonywaniem jakichś zmian - np. zwolnienie dzierżawy DNS raz skutkuje zmianą MAC na WAN a raz nie - nie ma w tym logiki "dlaczego ?".
Problem nabiera na znaczeniu jak mamy wykupioną domenę i okresowo zmienne IP i zależy nam by w danym okresie jakiego możemy być pewni nie zmieni się nam IP po zmianie MAC, co np. u mojego ISP (UPC) jest natychmiastowe. Zwyczajnie serwuję czy to amatorsko, czy dla zabawy, czy z innych względów kilka serwisów webowych na swoim kompie i dla ciągłości domeny adres IP po prostu musi być dostępny cały czas i niezmiennie ten sam (przynajmniej w tym przewidywalnym i wcale nie tak krótkim okresie - średnio raz na 4-5 m-cy). Zdaję sobie sprawę, że zwyczajnie można uzyskać niezmienność dostępu do domeny zarządzaniem zewnętrznymi usługami DNS, CloudFlare, i.t.d. - ale nie w tym rzecz - po prostu oczekiwał bym by mechanizm związany w gargoyle ze zmianą adresów MAC na WAN/LAN/WLAN zawsze był pewny i przewidywalny.
Stąd wniosek po tych moich spostrzeżeniach, że jest to jednak jakaś forma błędu w samym gargoyle, coś na styku javascript z silnika gargoyle i oprogramowania czysto linuksowego w samym firmware routera.

To tyle - wiem, że może trochę "przy długo" ale starałem się jasno i szczegółowo opisać problem.

@build000: dokładnie, bo to właśnie kwestia ustawień nie mechaniki jest. W1 /etc/config/firewall dokładnie.
@mlb: nie ma Xeye w domyślnych obrazach. Jak zrobiłeś upgrade i skórkę zgubiłeś.

Ja też pozwolę sobie zapytać Cezarego apropo's MAC na WLAN - czy udało Ci się już dokonać symulacji błędu - sytuację zmiany MAC na WIFI z podwójnym radiem i zachowanie/reakcję/funkcjonalność/i.t.d. się pod tym kątem gargoyle ?

@build000: nie, nic nie sprawdzałem czy i co się dzieje.