Initial Setup GL-MT300N-00a

No mistakes, the files are there, that’s the first thing I checked, to see where I made some mistakes :slight_smile:

My shadow file is definitely in files/etc/shadow but the device still has its own. Very odd but maybe related to the ‘too big’ error somehow and some things are not making it into the build?

I also found that a package we install which runs fine on other ramips based devices doesn’t run on this one. It installs then is never found. Again, could also be related to something missing in the build.

I think I need to get past this build issue first. It makes no sense that it is complaining. Maybe I need to use something other than trunk.


rule one: computer will not make mistakes.

So, pls check everything.

I know what should be happening and it is not. Also, as I said, I have checked everything that I know of to check and my files are there. I think the ‘too big’ error is related and that some files are getting left out of my build. If you think you know something else, please feel free to share.

Ok, so, this is really weird. I had not thought about checking how much space is left on the device.

df -h

Filesystem Size Used Available Use% Mounted on
/dev/root 2.5M 2.5M 0 100% /rom
tmpfs 29.7M 64.0K 29.6M 0% /tmp
/dev/mtdblock6 11.8M 548.0K 11.2M 5% /overlay
overlayfs:/overlay 11.8M 548.0K 11.2M 5% /
tmpfs 512.0K 0 512.0K 0% /dev

None! So, which is messed up? Openwrt or the device?


This is all that is installed on it.

base-files - 168-r49276
bash - 4.3.42-1
busybox - 1.24.2-1
ca-certificates - 20160104
curl - 7.48.0-1
dropbear - 2015.71-3
fstools - 2016-04-25-89847de58a17dacedab36ef07ec4c12ef8c0e84a
hostapd-common - 2016-01-15-2
iw - 4.3-1
jshn - 2016-02-26-5326ce1046425154ab715387949728cfb09f4083
jsonfilter - 2014-06-19-cdc760c58077f44fc40adbbe41e1556a67c1b9a9
kernel - 4.4.7-1-e52d172a70159a6f481440d646522d71
kmod-cfg80211 - 4.4.7+2016-01-10-1
kmod-eeprom-93cx6 - 4.4.7-1
kmod-gpio-button-hotplug - 4.4.7-2
kmod-leds-gpio - 4.4.7-1
kmod-lib-crc-ccitt - 4.4.7-1
kmod-lib-crc-itu-t - 4.4.7-1
kmod-mac80211 - 4.4.7+2016-01-10-1
kmod-mt76 - 4.4.7+2016-03-04-1
kmod-nls-base - 4.4.7-1
kmod-rt2800-lib - 4.4.7+2016-01-10-1
kmod-rt2800-mmio - 4.4.7+2016-01-10-1
kmod-rt2800-pci - 4.4.7+2016-01-10-1
kmod-rt2800-soc - 4.4.7+2016-01-10-1
kmod-rt2x00-lib - 4.4.7+2016-01-10-1
kmod-rt2x00-mmio - 4.4.7+2016-01-10-1
kmod-rt2x00-pci - 4.4.7+2016-01-10-1
kmod-usb-core - 4.4.7-1
kmod-usb-dwc2 - 4.4.7-1
libblobmsg-json - 2016-02-26-5326ce1046425154ab715387949728cfb09f4083
libc - 1.1.14-1
libcurl - 7.48.0-1
libgcc - 5.3.0-1
libjson-c - 0.12-1
libjson-script - 2016-02-26-5326ce1046425154ab715387949728cfb09f4083
libncurses - 5.9-3
libnl-tiny - 0.1-5
libpolarssl - 1.3.16-1
libpthread - 1.1.14-1
libstdcpp - 5.3.0-1
libubox - 2016-02-26-5326ce1046425154ab715387949728cfb09f4083
libubus - 2016-01-26-619f3a160de4f417226b69039538882787b3811c
libuci - 2016-02-02.1-1
libuclient - 2016-01-28-2e0918c7e0612449024caaaa8d44fb2d7a33f5f3
mtd - 21
netifd - 2016-03-04-da687c2689f7ff2af1dccc9a428806dd15c3d554
opkg - 9c97d5ecd795709c8584e972bfdf3aee3a5b846d-12
procd - 2016-03-09-b12bb150ed38a4409bef5127c77b060ee616b860
rt2800-pci-firmware - 2016-01-25-52442afee9907bc32a058f22bb3295d040677c26-1
swconfig - 10
terminfo - 5.9-3
ubox - 2016-03-07-fd4bb41ee7ab136d25609c2a917beea5d52b723b
ubus - 2016-01-26-619f3a160de4f417226b69039538882787b3811c
ubusd - 2016-01-26-619f3a160de4f417226b69039538882787b3811c
uci - 2016-02-02.1-1
uclient-fetch - 2016-01-28-2e0918c7e0612449024caaaa8d44fb2d7a33f5f3
usign - 2015-05-08-cf8dcdb8a4e874c77f3e9a8e9b643e8c17b19131
vnstat - 1.12-1


Building images for ramips - GL-MT300N

Packages: base-files bash busybox ca-certificates dropbear fstools kernel kmod-gpio-button-hotplug kmod-leds-gpio kmod-mt76 kmod-rt2800-pci kmod-rt2800-soc kmod-usb-dwc2 libc libgcc libpthread libstdcpp mtd netifd opkg swconfig uci uclient-fetch

Warning (reg_format): “reg” property in /pcie@10140000/pcie-bridge/mt76@0,0 has invalid length (20 bytes) (#address-cells == 2, #size-cells == 1)
Warning (avoid_default_addr_size): Relying on default #address-cells value for /pcie@10140000/pcie-bridge/mt76@0,0
Warning (avoid_default_addr_size): Relying on default #size-cells value for /pcie@10140000/pcie-bridge/mt76@0,0
/clients/cc-15-05-trunk/staging_dir/host/bin/patch-dtb /clients/cc-15-05-trunk/build_dir/target-mipsel_24kec+dsp_musl-1.1.14/linux-ramips_mt7620/vmlinux-gl-mt300n /clients/cc-15-05-trunk/build_dir/target-mipsel_24kec+dsp_musl-1.1.14/linux-ramips_mt7620/GL-MT300N.dtb
/clients/cc-15-05-trunk/staging_dir/host/bin/lzma e /clients/cc-15-05-trunk/build_dir/target-mipsel_24kec+dsp_musl-1.1.14/linux-ramips_mt7620/vmlinux-gl-mt300n -lc1 -lp2 -pb2 /clients/cc-15-05-trunk/build_dir/target-mipsel_24kec+dsp_musl-1.1.14/linux-ramips_mt7620/vmlinux-gl-mt300n.bin.lzma

if [ stat -c%s "/clients/cc-15-05-trunk/build_dir/target-mipsel_24kec+dsp_musl-1.1.14/linux-ramips_mt7620/openwrt-ramips-mt7620-gl-mt300n-squashfs-sysupgrade.bin" -gt 16121856 ]; then echo “Warning: /clients/cc-15-05-trunk/build_dir/target-mipsel_24kec+dsp_musl-1.1.14/linux-ramips_mt7620/openwrt-ramips-mt7620-gl-mt300n-squashfs-sysupgrade.bin is too big” >&2; else cp -fpR /clients/cc-15-05-trunk/build_dir/target-mipsel_24kec+dsp_musl-1.1.14/linux-ramips_mt7620/openwrt-ramips-mt7620-gl-mt300n-squashfs-sysupgrade.bin /clients/cc-15-05-trunk/bin/ramips/openwrt-ramips-mt7620-gl-mt300n-squashfs-sysupgrade.bin; fi

Seems I’m very lucky not to have lost this device since there is no space at all left on it.

What next? I’m out of ideas and as too often is the case, no replies on openwrt forums.


Why? You only have 2.5M for the firmware and 11.8M space free.

Yes, you’re right. I didn’t notice the difference in the df on this device.

So why can’t I build with the packages I want then? Why am I seeing that ‘too big’ error? How do I fix it since everything looks right to me. It must be an openwrt bug?


I suggest you use the same method i suggested. Use our github openwrt 1505. You still can put your config in [openwrt]/files/ and have you own config in your firmware.

Yes but as mentioned, we have our own software, scripts and a bunch of things that we need built into the device. It’s easier to create a working build that we can replicate as often as we need. Since this has fallen in my hands for a while, I’m not as familiar with doing this work than the dev we had working on this but usually, it’s pretty straight forward.

In this case, this build should work. There is no good reason for the ‘too big’ error and what seems to be missing packages. This is no longer a gl.inet issue, I think it is an openwrt one.




Now I have another weird issue. I pressed the reset switch so I could log into it in fail safe mode.
I then put it away for a while and powered it back up just now but it will no longer pick up a dhcp IP.
It was working fine (other than the above package problem) before I powered it off.


Things keep getting stranger.

Now it boots up with IP, no dhcp requests.
A few seconds later, it no longer responds to pings at that IP.
I then put it back into fail safe mode and the reset button broke. No I was not pushing it very hard.

When in fail safe mode, only telnet should be active right? Nope, only ssh is active on the device.
It is as if the build I put on it is gone BUT, ssh remains active and now had to use a password to log in.
Funny, it was the password I originally set in /etc/shadow. So, if this is fail safe mode, it’s not trying to get a DHCP IP and it’s using IP which is the default so, something didn’t work.

Looking at the /etc/config/network file, I see that it is mine yet it is not picking up DHCP and is somehow using

config interface ‘loopback’
option ifname ‘lo’
option proto ‘static’
option ipaddr ‘’
option netmask ‘’

config interface ‘lan’
option ifname ‘eth0 eth1’
option type ‘bridge’
option proto ‘dhcp’

Again, I believe all of this is related to something with openwrt.



I didn’t test failsafe mode, but I don’t think it works as you expected. It works using its own rules, which need to be explored.

In failsafe mode, seems it still uses the password, because you built the password in your shadow file. But it drops the network configuration, which is not a surprise.

I don’t think you messed up. You are creating a working image which is good. The only thing is to make the configurations work. This needs experience because OpenWrt is not so docs as Raspberry Pi etc.

I suggest you get a USB->UART adapter and connect the serial. It is a MUST for development. It will be a big surprise if you succeed without it.

Check docs here: Overview - GL.iNet Docs

I’ve built lots of firmware files and often get help from the openwrt forums but in this case, something is not right with the profile. I don’t know. I’ve posted my results and am hoping someone on openwrt will reply and help then I can update here.
It is software so anything can happen :slight_smile:

Are there any other forums where I can get help with this? I have been trying to get this device working for days now.
I cannot find much on the net, no one is replying in the openwrt forums, I’m not sure if I found a bug and not sure where to post it if I have.
I need to get ImageBuidler working with the mt300N so I can put our software on it and start testing it.

seems it is not big of image builder. Let me try it tomorrow.

If you can send me your files, pls send to me via email. Also tell me what you want to achieve and why is the problems, again

Alzhao at

Thanks for the offer!

Just put a 5K file in the files/temp/ directory. That is where we put a startup script which runs when the device starts which in turn downloads what it needs. I cannot send any files as they are proprietary so not mine to hand over. Obviously, if we were ordering a 5K units, then I think we would talk about pre-installing :slight_smile:

As for the config, I am needing this device to simply be a bridged device, physical nic1 to nic2 so I can use tcpdump to read packets.
The WAN port will be connected to the router and the LAN port to the LAN. The device picks up an IP from the router.

If you get it to work, maybe we can compare notes.

This is the version I am using;

So just bridge wan and Lan right?

At least you need to share your etc/config/network and etc/config/wireless file.

No need for any wireless, no router functions, no firewall, no DHCP or other services, only sshd.
This device is to be used as a pass-through, DHCP client only so I can connect the WAN port to the upstream, the LAN port to the LAN then ssh into it from the LAN side.

The test for this device is to find out what speeds it can handle on the physical NICs without losing packets. I had asked in another post on this site what speed the interfaces could handle but no one really knew.

How do you know the IP address of the device in order to ssh into it?