OpenWrt installation on Meraki MR33 (Timeout in tftp)

Hi everybody,

I am trying to install OpenWRT in the Meraki MR33. I'm following the google drive instructions however I am stuck in the tftp upload process.

The new u-boot upload was OK

U-Boot 2012.07-ga8496ca-dirty [local,local] (Mar 10 2018 - 09:10:50)

DRAM:  242 MiB
machid : 0x8010001

COM: Product: meraki_Stinkbug
NAND:  ONFI device found
128 MiB
Using default environment

In:    serial
Out:   serial
Err:   serial
machid: 8010001

COM: Net:   
COM: MAC0 addr:0:3:7f:ba:db:ad
PHY ID1: 0x4d
PHY ID2: 0xd072
ipq40xx_ess_sw_init done
eth0
Hit any key to stop autoboot: 11 
CO10 
...
CO 0
Hello from MR33 U-BOOT
Creating 1 MTD partitions on "nand0":
0x000000c00000-0x000007c00000 : "mtd=0"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:    126976 bytes
UBI: smalle
  • In the minicom connected to rs232 I can see the logs:
Welcome to minicom 2.7.1

OPTIONS: I18n 
Compiled on May  6 2018, 08:02:47.
Port /dev/ttyUSB0, 05:09:39

eth0 PHY1 up Speed :1000 Full duplex
Using eth0 device
Listening for TFTP transfer on 192.168.1.1
Load address: 0x84000000
Loading: T T T T T T T T T T 
Retry count exceeded; starting again
eth0 PHY1 up Speed :1000 Full duplex
Using eth0 device
Listening for TFTP transfer on 192.168.1.1
Load address: 0x84000000
Loading: T T T T T T T 
  • I renamed the itb file to "openwrt-ipq40xx-meraki_mr33-initramfs-fit-uImage.itb" as I see in the manual pdf (page 6/step 6) that it mentioned that same name in the tftp command.
  • When I enter the tftp command (in linux debian) I got a transfer timeout
echo -e "binary\nput openwrt-ipq40xx-meraki_mr33-initramfs-fit-uImage.itb" | tftp 192.168.1.1
tftp> tftp> Transfer timed out.
  • Using atftp I have the same issue
$ atftp --trace --option "timeout 1" --option "mode octet" --put --local-file openwrt-ipq40xx-meraki_mr33-initramfs-fit-uImage.itb 192.168.1.1
Trace mode on.
Option timeout = 1
Option mode = octet
sent WRQ <file: openwrt-ipq40xx-meraki_mr33-initramfs-fit-uImage.itb, mode: octet <timeout: 1>>
timeout: retrying...
sent WRQ <file: openwrt-ipq40xx-meraki_mr33-initramfs-fit-uImage.itb, mode: octet <timeout: 1>>
timeout: retrying...
sent WRQ <file: openwrt-ipq40xx-meraki_mr33-initramfs-fit-uImage.itb, mode: octet <timeout: 1>>
timeout: retrying...
sent WRQ <file: openwrt-ipq40xx-meraki_mr33-initramfs-fit-uImage.itb, mode: octet <timeout: 1>>
timeout: retrying...
  • I am able to ping the device 192.168.1.1
$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.04 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=1.20 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.978 ms

Any ideas?

Thank you in advance

Did you set a static IP for your LAN? Otherwise I would guess it is a timing/sensing issue between your router and your PC LAN port.
You could try to use a (fast) switch between your PC and router to circumvent this issue. You could try to use another PC with faster/better NIC driver/os combination. What I can say is I made bad experiences with Realtek NICs under Linux when it comes to tftp flashing.

1 Like

Hi @pwned thanks for your comment. Yes, I have assigned the static IP 192.168.1.50 and I have connected a cable from my pc directly to the meraki. I'm going to try with a switch as you suggest.

In another case with other device I had some issues to and I have to stop network services but same trick is not working in this case. I hope it works with the switch.

Regards

Hi, today I have tried using a switch with no luck. I'm posting in case I have any news.

Regards

I don't know anything about this specific device or its flash procedure. But most devices have only a short gap accepting tftp commands. Some of them indicating this timeframe with a certain flashlight state.
You could try to increase the timeout from your tftp commandline e. g. 5 seconds and/or spam the command continiously during the start process for like a minute.

1 Like

did you try to disable the firewall on the debian/linux machine ?

3 Likes

Yess... thank you @frtz you did it !!

I saw in several posts that some people had problems in the first part of the procedure, flashing the hacked u-boot with ubootwrite.py, mainly because of the python versions. I built a docker image for this part, so I'm sharing here the content so any other can use it as well.

FROM python:2.7
COPY ubootwrite.py /opt/
COPY mr33-uboot.bin /opt/
WORKDIR /opt
RUN python -m pip install pyserial
CMD ["/bin/bash"]

Steps are:

  • Generate Dockerfile with the above content
  • Build docker image
    $ docker build -t ubootwrite -f Dockerfile .
  • Run container
    $ docker run --rm -it --device=/dev/ttyUSB0 ubootwrite
  • Inside de container invoke flashing
    $ python ./ubootwrite.py --verbose --serial=/dev/ttyUSB0 --write=./mr33-uboot.bin

Thank you @frtz @pwned

1 Like

Well, I would never thought about the firewall. Great find @frtz and great work @barrenaedu for improving process and sharing that.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.