1

(63 odpowiedzi, napisanych Sprzęt / Hardware)

Witam,
i mnie spotkał ten sam problem z adresami MAC, M60 z 'dwupaku' prosto z pudełka wgrane openwrt przez recovery zakończone sukcesem.
Dziś podmiana sprzętów i jakie zdziwienie gdy w konfiguracji MF286D -> 2x M60 jako dumpAP działa tylko z jedną sztuką.
Spotkało mnie dublowanie adresów MAC na lan i wlan...
Aktualnie pozmieniane ręcznie na interfejsach.
Czy istnieje może jakiś patch który na istniejącym już systemie przywróci adresy do normalności?

# hexdump -v -n 6 -s 0x83 -e '5/1 "%02x:" 1/1 "%02x"' /dev/mtd6
powyższy odczyt działa u mnie zgodnie z naklejką na obudowie

Pozdrawiam

pytonlon napisał/a:

mac address

M60 dwupack

Box nr 1
odczytany mac za pomocą hexdump -v -n 6 -s 0x83 -e '5/1 "%02x:" 1/1 "%02x"' /dev/mtd6 daje dc:ea:e7:ae:ba:40;
etykieta dc:ea:e7:ae:ba:41
czyli zgodnie z informacjami z Commit b3ce08e
WAN dc:ea:e7:ae:ba:40
LAN dc:ea:e7:ae:ba:41
WLAN MAC(2.4) dc:ea:e7:ae:ba:42
WLAN MAC (5.0) dc:ea:e7:ae:ba:45

a system zwraca jak poniżej patrz output ip link

Box nr 2
odczytany mac za pomocą hexdump -v -n 6 -s 0x83 -e '5/1 "%02x:" 1/1 "%02x"' /dev/mtd6 daje dc:ea:e7:ae:ba:36;
etykieta dc:ea:e7:ae:ba:37
czyli zgodnie z informacjami z Commit b3ce08e
WAN dc:ea:e7:ae:ba:36
LAN dc:ea:e7:ae:ba:37
WLAN MAC(2.4) dc:ea:e7:ae:ba:38
WLAN MAC (5.0) dc:ea:e7:ae:ba:3b

a system też zwraca jak poniżej patrz output ip link

 
root@OpenWrt:~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1504 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 06:00:dc:ea:e7:af brd ff:ff:ff:ff:ff:ff
3: internet: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
    link/ether 06:00:dc:ea:e7:ae brd ff:ff:ff:ff:ff:ff
4: lan1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP mode DEFAULT group default qlen 1000
    link/ether 06:00:dc:ea:e7:af brd ff:ff:ff:ff:ff:ff
5: lan2@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
    link/ether 06:00:dc:ea:e7:af brd ff:ff:ff:ff:ff:ff
6: lan3@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
    link/ether 06:00:dc:ea:e7:af brd ff:ff:ff:ff:ff:ff
7: lan4@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
    link/ether 06:00:dc:ea:e7:af brd ff:ff:ff:ff:ff:ff
8: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 06:00:dc:ea:e7:af brd ff:ff:ff:ff:ff:ff
9: phy0-ap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP mode DEFAULT group default qlen 1000
    link/ether 06:00:dc:ea:e7:b0 brd ff:ff:ff:ff:ff:ff
10: phy1-ap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP mode DEFAULT group default qlen 1000
    link/ether 06:00:dc:ea:e7:b3 brd ff:ff:ff:ff:ff:ff

wiec oba boxy są tak samo identyfikowane w sieci

2

(2 odpowiedzi, napisanych Sprzęt / Hardware)

Sprzęt oddany, ogłoszenie nieaktualne.

Witam,
dziś przez przypadek /roztargnienie/ podłączyłem zasilacz 24v do MF286D - sprzęt się nie uruchamia, zwarcie na pinach zasilania.
Chciałem przenieś ruter na strych i podłączyłem nie ten zasilacz.

Jeżeli ktoś chce na testy to oddam za koszt wysyłki paczkomatem (ale podeśle etykietę).

Temat rozwiązany.
Wylutowałem pamięć 25l644 (w układzie nie odczytywała się), przy pomocy HxD wgrałem do odczytanego obrazu u-boot, kernel i rootfs z softu oryginalnego MX5.5.6 i wgrałem ponownie - sprzęt uruchomiony.

U-Boot 1.1.4.2-s594 (Dec 5 2012 - 15:23:07)
#:    name            size                    offset            mask_flags    size
0:    u-boot            0x00040000    0x00000000    0                  256k
1:    u-boot-env    0x00010000    0x00040000    0                    64k
2:    kernel            0x00100000    0x00050000    0                    1024k
3:    rootfs            0x00660000    0x00150000    0                    6528k
4:    cfg                    0x00040000    0x007b0000    0                   256k
5:    EEPROM            0x00010000    0x007f0000    0                    64k

Dziękuję wszystkim za pomoc.

Niestety pomysł z użyciem https://github.com/HorstBaerbel/ubootwrite też się nie udał.
Po doprowadzeniu skryptu to stanu wykonywania oczekuje na /prompt/.
tak samo idąc do źródła https://github.com/rvalles/brntool i wykonując --read nie otrzymuje żadnego odczytu.

Mimo zmiany na eth1 interfejsem głównym ciągle jest eth0:

Environment size: 520/65532 bytes
ar7240> setenv ethact eth1
ar7240> setenv serverip 192.168.1.20
ar7240> tftpboot 80600000 openwrt.bin
Using eth0 device
TFTP from server 192.168.1.20; our IP address is 192.168.1.20
Filename 'openwrt.bin'.
Load address: 0x80600000

Próbowalem tego na początku - niestety nie działa.

Nie ma obsługi lady/loadz.
Skrypt w pythonie wygląda na ciekawy, mv jest obsługiwane, ale szczerze nie czuje się w tym momencie na siłach aby to ogarnąć (terminal linux).
Szukam nadal rozwiązanie nad zmianą w urescue z eth0 na eth1.

---
ar7240> help
?       - alias for 'help'
base    - print or set address offset
boot    - boot default, i.e., run 'bootcmd'
bootd   - boot default, i.e., run 'bootcmd'
bootelf - Boot from an ELF image in memory
bootm   - boot application image from memory
cmp     - memory compare
cp      - memory copy
crc32   - checksum calculation
echo    - echo args to console
erase   - erase FLASH memory
flinfo  - print FLASH memory information
go      - start application at address 'addr'
help    - print online help
iminfo  - print header information for application image
imls    - list all images found in flash
loop    - infinite loop on address range
md      - memory display
mii     - MII utility commands
mm      - memory modify (auto-incrementing)
mtdparts- define flash/nand partitions
mtest   - simple RAM test
mw      - memory write (fill)
nm      - memory modify (constant address)
ping    - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
protect - enable or disable FLASH write protection
reset   - Perform RESET of the CPU
run     - run commands in an environment variable
saveenv - save environment variables to persistent storage
setenv  - set environment variables
sleep   - delay execution for some time
tftpboot- boot image via network using TFTP protocol
urescue - start TFTP server and wait for firmware
version - print monitor version
autoscr - run script from memory
ar7240> printenv
ethaddr=0x00:0xaa:0xbb:0xcc:0xdd:0xee
filesize=690000
fileaddr=80010000
bootdelay=4
baudrate=115200
mtdids=nor0=ar7240-nor0
partition=nor0,0
mtddevnum=0
mtddevname=u-boot
mtdparts=mtdparts=ar7240-nor0:256k(u-boot),64k(u-boot-env),1024k(kernel),6528k(rootfs),256k(cfg),64k(EEPROM)
bootcmd=bootm 0x9f050000
bootargs=console=ttyS0,115200 root=31:03 rootfstype=squashfs init=/init
ethact=eth0
serverip=192.168.1.254
ipaddr=192.168.1.20
product=N5N
stdin=serial
stdout=serial
stderr=serial
ubntaddr=80200020
appinitdone=true

Environment size: 520/65532 bytes

---

Witam,
Posiadam Nanostation M5 z uszkodzonym portem eth0 (MAIN) - dziala zasilanie przez PoE, lecz interface nawet nie linkuje. Eth1 dziala bez problemu.
Po wgraniu openwrt (downgrade do unsigned -> wgranie przez webUI openwrt).
Niestety cos poszlo nie tak i aktualnie u-boot zatrzumuje sie na /bad magic number/.
Po podlaczeniu przez uart i wykonaniu polecenia ‚urescue’ uruchamia sie polaczenie tftp ale na domyslnym porcie ETH0.
Proba zmiany przez ‚setenv ethact eth1’  i ‚saveenv’ nie zmienia portu eth0 na eth1 przy komendzie ‚urescue’.
Czy jest mozliwosc zmiany eth0 na eth1 w jakis sposob?
Jest mozliwosc ‚podgladniecia’ makra urescue tak aby z reki wykonac je zmieniajac interfejsy?
Mozna za pomoca u-boot’a wgrac oprogramowanie przez UART?

Z gory dziekuje za pomoc.