No mistakes, the files are there, that’s the first thing I checked, to see where I made some mistakes
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.
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.
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
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.
Now it boots up with IP 192.168.1.1, 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 192.168.1.1 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 192.168.1.1.
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.
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
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.
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
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.
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.
