Is anyone share your firmware mx65... ican't build .. thanks a lot
After I converted my CISCO Meraki MX65 over to Openwrt, I came across a note that showed how to gain flash space of nearly 1GB before converting fully to Openwrt. My device, already converted to Openwrt, was showing about 300MB which was very adequate for my needs. However, for experimenting I tried to increase and succeeded so I am sharing the steps.
After the MX65 booted to OpenWrt, I scp the sysupgrade flash to temp using the following command:
scp -0 openwrt-24.10.0-bcm53xx-generic-meraki_mx65-squashfs.sysupgrade.bin root@192.168.1.1:/tmp
Then SSH into the device and examined and removed the not useful partition to me as I absolutely wasn't going back to CISCO firmware in any condition:
root@MX65-2D51:/sys/devices/virtual# ubinfo -a
UBI version: 1
Count of UBI devices: 1
UBI control device major/minor: 10:127
Present UBI devices: ubi0
ubi0
Volumes count: 8
Logical eraseblock size: 253952 bytes, 248.0 KiB
Total amount of logical eraseblocks: 4058 (1030537216 bytes, 982.7 MiB)
Amount of available logical eraseblocks: 0 (0 bytes)
Maximum count of volumes 128
Count of bad physical eraseblocks: 2
Count of reserved physical eraseblocks: 78
Current maximum erase counter value: 17195
Minimum input/output unit size: 4096 bytes
Character device major/minor: 251:0
Present volumes: 0, 1, 2, 3, 4, 5, 6, 7
Volume ID: 0 (on ubi0)
Type: static
Alignment: 1
Size: 132 LEBs (33521664 bytes, 31.9 MiB)
Data bytes: 33476608 bytes (31.9 MiB)
State: OK
Name: part.old
Character device major/minor: 251:1
-----------------------------------
Volume ID: 1 (on ubi0)
Type: dynamic
Alignment: 1
Size: 13 LEBs (3301376 bytes, 3.1 MiB)
State: OK
Name: kernel
Character device major/minor: 251:2
-----------------------------------
Volume ID: 2 (on ubi0)
Type: dynamic
Alignment: 1
Size: 1 LEBs (253952 bytes, 248.0 KiB)
State: OK
Name: board-config
Character device major/minor: 251:3
-----------------------------------
Volume ID: 3 (on ubi0)
Type: dynamic
Alignment: 1
Size: 2115 LEBs (537108480 bytes, 512.2 MiB)
State: OK
Name: storage
Character device major/minor: 251:4
-----------------------------------
Volume ID: 4 (on ubi0)
Type: static
Alignment: 1
Size: 38 LEBs (9650176 bytes, 9.2 MiB)
Data bytes: 9428992 bytes (8.9 MiB)
State: OK
Name: diagnostic1
Character device major/minor: 251:5
-----------------------------------
Volume ID: 5 (on ubi0)
Type: static
Alignment: 1
Size: 121 LEBs (30728192 bytes, 29.3 MiB)
Data bytes: 30490624 bytes (29.0 MiB)
State: OK
Name: part.safe
Character device major/minor: 251:6
-----------------------------------
Volume ID: 6 (on ubi0)
Type: dynamic
Alignment: 1
Size: 32 LEBs (8126464 bytes, 7.7 MiB)
State: OK
Name: rootfs
Character device major/minor: 251:7
-----------------------------------
Volume ID: 7 (on ubi0)
Type: dynamic
Alignment: 1
Size: 1524 LEBs (387022848 bytes, 369.0 MiB)
State: OK
Name: rootfs_data
Character device major/minor: 251:8
root@MX65-2D51:/sys/devices/virtual#
Then I removed the partition not useful to me:
root@MX65-2D51:/sys/devices/virtual# ubirmvol /dev/ubi0 -N part.old
root@MX65-2D51:/sys/devices/virtual# ubirmvol /dev/ubi0 -N storage
root@MX65-2D51:/sys/devices/virtual# ubirmvol /dev/ubi0 -N diagnostic1
root@MX65-2D51:/sys/devices/virtual# ubirmvol /dev/ubi0 -N part.safe
root@MX65-2D51:/sys/devices/virtual#
After this I applied the sysupgrade:
root@MX65-2D51:/tmp# sysupgrade openwrt-24.10.0-bcm53xx-generic-meraki_mx65-squashfs.sysupgrade.bin
The router went into the reboot cycle after the upgrade. I logged into it using ssh again and did the check:
root@MX65-2D51:~# ubinfo -a
UBI version: 1
Count of UBI devices: 1
UBI control device major/minor: 10:127
Present UBI devices: ubi0
ubi0
Volumes count: 4
Logical eraseblock size: 253952 bytes, 248.0 KiB
Total amount of logical eraseblocks: 4058 (1030537216 bytes, 982.7 MiB)
Amount of available logical eraseblocks: 0 (0 bytes)
Maximum count of volumes 128
Count of bad physical eraseblocks: 2
Count of reserved physical eraseblocks: 78
Current maximum erase counter value: 17196
Minimum input/output unit size: 4096 bytes
Character device major/minor: 251:0
Present volumes: 0, 1, 2, 3
Volume ID: 0 (on ubi0)
Type: dynamic
Alignment: 1
Size: 13 LEBs (3301376 bytes, 3.1 MiB)
State: OK
Name: kernel
Character device major/minor: 251:1
-----------------------------------
Volume ID: 1 (on ubi0)
Type: dynamic
Alignment: 1
Size: 11 LEBs (2793472 bytes, 2.6 MiB)
State: OK
Name: rootfs
Character device major/minor: 251:2
-----------------------------------
Volume ID: 2 (on ubi0)
Type: dynamic
Alignment: 1
Size: 1 LEBs (253952 bytes, 248.0 KiB)
State: OK
Name: board-config
Character device major/minor: 251:3
-----------------------------------
Volume ID: 3 (on ubi0)
Type: dynamic
Alignment: 1
Size: 3951 LEBs (1003364352 bytes, 956.8 MiB)
State: OK
Name: rootfs_data
Character device major/minor: 251:4
root@MX65-2D51:~#
The rootfs_data is nearly 1 GB. Also attached are the screenshots.
1 Like
Is there a link for the latest copy of uboot_mx65?
Or confirm if this link from clayface on github is the latest.
Many thanks.
Folks
I configured the the MX65 today to be my firewall after abandoning an earlier effort to do this because of duplicate on my pings.
I flashed with the latest 24.10.0 and configured again, and I got the same duplicate problem. Instead of dismantling, I have kept the same configuration in case I made a mistake or there is a bug.
There are two devices:
MX65 and Onhub 1900 (as an AP).
One Wan1 connected to ATT (192.168.1.1/24, Gateway 192.168.1.254).
Two interfaces on MX65
iot: 192.168.116.1/24 DHCP server 125 leases starting at 125.
lan: 192.168.111.1/24 DHCP server 125 leases starting at 125 (same 12h).
Responses:
agarg@LM5550AG:~$ ping 192.168.111.1
PING 192.168.111.1 (192.168.111.1) 56(84) bytes of data.
64 bytes from 192.168.111.1: icmp_seq=1 ttl=64 time=1013 ms
64 bytes from 192.168.111.1: icmp_seq=1 ttl=64 time=1013 ms (DUP!)
64 bytes from 192.168.111.1: icmp_seq=2 ttl=64 time=2.98 ms
64 bytes from 192.168.111.1: icmp_seq=2 ttl=64 time=3.31 ms (DUP!)
64 bytes from 192.168.111.1: icmp_seq=3 ttl=64 time=2.84 ms
64 bytes from 192.168.111.1: icmp_seq=3 ttl=64 time=3.22 ms (DUP!)
64 bytes from 192.168.111.1: icmp_seq=4 ttl=64 time=1.03 ms
64 bytes from 192.168.111.1: icmp_seq=4 ttl=64 time=1.34 ms (DUP!)
64 bytes from 192.168.111.1: icmp_seq=5 ttl=64 time=2.60 ms
64 bytes from 192.168.111.1: icmp_seq=5 ttl=64 time=2.60 ms (DUP!)
^C
--- 192.168.111.1 ping statistics ---
5 packets transmitted, 5 received, +5 duplicates, 0% packet loss, time 4015ms
rtt min/avg/max/mdev = 1.025/204.656/1013.327/404.335 ms, pipe 2
agarg@LM5550AG:~$ sudo arping -D -I wlp0s20f3 -c 3 192.168.111.1
ARPING 192.168.111.1 from 0.0.0.0 wlp0s20f3
Unicast reply from 192.168.111.1 [E0:CB:BC:12:2D:51] 2.988ms
Sent 1 probes (1 broadcast(s))
Received 1 response(s)
agarg@LM5550AG:~$ echo $?
1
agarg@LM5550AG:~$
Much appreciate any help and thanks a ton for the attention.
Yes, that's the latest uboot for mx65.
1 Like
I tried several approach without avail.
There is a bridge of Lan3 ... Lan12
Software VLAN for LAN and VLAN IOT
I made sure the last digit of MAC address used Hexadecimal A, B to make it distinct by hard coding in the devices.
Rebooted. It is the only device on the Firewall (also openwrt). The Firewall pings dont gove DUP! but the MX65 responds back with DUP!.
I am not even sure if its a bad thing (sound like it though!).
The fping results are a bit less alarming:
agarg@LM5550AG:~$ fping 192.168.111.3 -s
192.168.111.3 is alive
1 targets
1 alive
0 unreachable
0 unknown addresses
0 timeouts (waiting for response)
1 ICMP Echos sent
1 ICMP Echo Replies received
0 other ICMP received
2.74 ms (min round trip time)
2.74 ms (avg round trip time)
2.74 ms (max round trip time)
0.003 sec (elapsed real time)
agarg@LM5550AG:~$
Any pointers?
Could you post the contents of /etc/config/network?
Might help to diagnose
I wasn't sure and so tried unique Hexadecimal mac codes to avoid duplicates on ping but that also did not work. It gives duplicates for all devices downstream. Here is network file:
root@MX65-252C:~# cat /etc/config/network
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fd85:d002:928a::/48'
option packet_steering '1'
config device
option name 'br-lan'
option type 'bridge'
list ports 'MX65.111'
option macaddr 'E0:55:3D:6B:25:2C'
option ipv6 '0'
config device
option name 'wan1'
option macaddr 'e0:55:3d:6b:25:30'
config device
option name 'wan2'
option macaddr 'e0:55:3d:6b:25:30'
config device
option type 'bridge'
option name 'MX65'
list ports 'lan3'
list ports 'lan4'
list ports 'lan5'
list ports 'lan6'
list ports 'lan7'
list ports 'lan8'
list ports 'lan9'
list ports 'lan10'
list ports 'lan11'
list ports 'lan12'
list ports 'wan1'
list ports 'wan2'
option ipv6 '0'
config bridge-vlan
option device 'MX65'
option vlan '100'
list ports 'wan1'
list ports 'wan2'
config bridge-vlan
option device 'MX65'
option vlan '111'
list ports 'lan3:t'
list ports 'lan4:t'
list ports 'lan5:t'
list ports 'lan6:t'
list ports 'lan7:t'
list ports 'lan8:t'
list ports 'lan9:t'
list ports 'lan10:t'
list ports 'lan11:t'
list ports 'lan12:t'
config bridge-vlan
option device 'MX65'
option vlan '116'
list ports 'lan3:t'
list ports 'lan4:t'
list ports 'lan5:t'
list ports 'lan6:t'
list ports 'lan7:t'
list ports 'lan8:t'
list ports 'lan9:t'
list ports 'lan10:t'
list ports 'lan11:t'
list ports 'lan12:t'
config device
option type 'bridge'
option name 'br-sos'
list ports 'MX65.100'
option macaddr 'E0:55:3D:6B:25:2A'
option ipv6 '0'
config interface 'sos'
option proto 'static'
option device 'br-sos'
option ipaddr '10.10.10.1'
option netmask '255.255.255.0'
option delegate '0'
config device
option type 'bridge'
option name 'br-iot'
list ports 'MX65.116'
option macaddr 'E0:55:3D:6B:25:2B'
option ipv6 '0'
config interface 'iot'
option proto 'dhcp'
option device 'br-iot'
option delegate '0'
config interface 'lan'
option proto 'dhcp'
option device 'br-lan'
option delegate '0'
root@MX65-252C:~#
PS: An update.
The MX65 is connected as a smart switch to the firewall TP-Link Onhub using a trunk. The Dup message appears when I am connected to it using a wlan radio of the TP-Link Onhub. When I connect directly to the switch (I had to turn one port on MX65 as untagged) then the dup message disappears. I also checked this using my older Netgear R6100 as the firewall with the same firewall configuration as TP-Link onhub and then connect to the R6100 radio. The Dup disappears. I suspect that the dup comes due to something unique to TP-Link Onhub. Will try another gateway to see if this dup comes back again.
For now my problem is gone as i have gone back to Netgear R6100 and my DSL is not that fast in this WUI area.
Have you tried removing all the "option macaddr"?
Yes. Earlier I had none. I thought that since two interfaces have an identical Mac address that might be the source of dup even if on separate vlan. I got to changing half byte hex Mac address because I was getting the DUP. Although it's hard for non tech to determine but I suspect that onhub may be returning more than on response to ping request. Also as fping does not show any errors, I wonder if that ignores the duplicate address.
Does this mean any data between the 3 groups (WAN1/2 or LAN3-7 or LAN8-12) goes via the CPU but inter-device traffic is fast/direct?
Any prospect of this being fixed? I don't have experience with this low level stuff but would be interesting to try!
No. The crucial part:
This doesn't imply traffic going through the CPU.
I tried that with qca8k, but failed miserably - the driver doesn't yet support inter-switch connections, FWIW.
Apologies. I don't quite understand. What effect does the lack of the qca8k implementation have on the traffic between and within the 2 switches (QCA8337-AL3C) and the 2 ports on the soc (BCM58625).
I'm considering getting the mx65, just want to contemplate the restrictions and/or workarounds I should do in wiring to avoid any issues.
Ah that sucks. Appreciate you trying. Fingers crossed it is implemented at some point.
Not much, unless you attempt to transfer more than 1Gbps between 1st and 2nd half of the LAN ports. If internal link between QCA switches worked, the traffic would go there directly, now - it will steal some bandwitdth from BCM switch, which also handles WAN ports and the CPU. Not that this CPU is that much capable - with SQM enabled I maxed the device at around 600Mbps routing.
1 Like
Thinking to buy few mx64 as a managed switch running Openwrt.
How to identify the chipset is not A0 before buying, part number/something on the sticker?
Is it possible for wan(internet) interface to be bridged with lan?
Is serial interface connection compulsory for flashing Openwrt?
Sorry, if above looks as too many questions 
I would suggest an MX65 as a managed switch. I'm running openwrt on it and so far it's stable and reasonably fast. In my case all the ports are bridged (wan1-2 with lan3-12) and with vlan filtering active. The only thing missing in the official image is the POE out support (hopefully this will be addressed soon). The installation is not trivial though, IIRC there is only a sysupgrade image available but you need to flash an initramfs package at first. Installation via serial interface is not a requisite.
1 Like
Where did you find initramfs? Did you measure NAT performance?
Regarding NAT, I don't use it as a router, I have it configured as a managed switch with vlans, so no routing/nat. Out of curiosity I tested the wireguard performance and the throughput was 280-300 mbit/s.
1 Like
I see that some mx64/mx65 are sold on ebay with claimed/unclaimed status, does this effect ability to install Openwrt?