I have a new SXR80 with stock firmware. We can use it to test and document everything needed to switch to openwrt?
Great, it's probably worth testing out the telnet method so there's an option without the serial documented.
I should have a chance to draft some instructions over the weekend, but if you haven't found it already the telnet option is enabled via http://[ip of device]/debug.htm
Yes I was allready connected with telnet. Do you have a link how to start over telnet?
With the last build, I run in network problemes. I user 4 Networks with 3 wifi SIDs.
Vlans for:
MGMT
IoT
LAN
Guest
2.4 Ghz wifi is working normal, all Clients can access Netzwork, Internet ans also get an ip.
If I also enable 5 Ghz wifi the clients can not get an IP address and also the arp tabel of my switch do not see the mac addesses from the clients.
Looks like it happen only for the 5 Ghz Wifi.
Is that built with the changes I pushed today? I noticed something similar with the previous build (a few days ago) so not sure if it has been fixed in the latest Openwrt master...
The behaviour I saw was similar to you, I couldn't get an address assigned via DHCP but did see lots of log entries about DHCP packet received which has no address.
I'm not using these devices for DHCP I've got another DHCP server for assigning addresses.
My DHCP is also external, not the openwrt router. But the network comunication over 5ghz wifi is not possible. I was one build behind.
Not sure if the problem is allready fixed.
edit: so looks like the 5Ghz is working again and network comunications is possible.
Something else, I use an networkscanner app on android and saw some hidden ssids. After a reboot of the ap the hidden ssid shows again the right name.
I tried a newer build but saw the same thing, even after a reboot. However when I toggled the 5GHz networks off:
- The devices switched to 2.4GHz and started working fine
- When I re-enabled the 5GHz SSIDs the devices reconnected and don't seem to have experienced the same problems since even after rebooting.
I wonder if toggling the 5GHz has cleared out some stale config somewhere?
re-enable the 5 GHz interface helps.
I am not sure, but if the 5 GHz is not working normal, there is always one wifi device connectet, but can not be pinged.
I am now on you build SNAPSHOT r24410-d25bdf7b56
I still have a stock unit myself, I don't have a build env setup at the moment though, but if you could give me pre-built images I can test them.
If you want to test I can send you the image files.
It looks like the install instructions bricked my RBS. The reason for that appears to be, that the env didn't exist/was never written to the partition and apparently only exists as part of u-boot so it used the defaults. The RBR I used worked, but I tweaked the env from u-boot there before. I would assume that a single saveenv from u-boot would have prevented the brick.
Was that using fw_setenv to set them from the Netgear firmware over telnet? I thought that fw_setenv under the covers did the equivalent of setenv followed by saveenv?
I used a unit that I restored via factory reset to test the instructions so those variables would have already existed in u-boot. But it sounds like if those variables don't already exist then they aren't saved?
Yes it was. fw_setenv does not set serverip and possibly other vars. It even assumes a wrong default bootcmd. The entire env is written to a partition usually. u-boot has a certain default embedded if that partition doesn't contain a valid env. fw_setenv does not know that default in u-boot. I think you could change bootcmd to env default -a; saveenv; reset and it should create an env, save it and reboot to the stock firmware. Then you should be able to continue with step 4 (yes, 4 and not 5, the bootcmd before doing this is invalid as it's some default but not the right one!).
@PhoenixG36 might be worth holding off trying the instructions if you haven't started on your stock unit yet until we can test @Flole's suggestion.
It looks like the env get written to mtd14 (0:appsblenv), there's also what looks like the defaults stored in mtd15 (0:appsbl) - I presume as part of the u-boot binary.
@Flole so fresh out of the box you think the appsblenv data is missing or invalid until it's saved via saveenv?
fw_printenv is telling me, that it is invalid on the stock firmware.
1 Like
Stock Unit with FW V3.1.1.102
output from fw_printenv:
Warning: Bad CRC, using default environment
bootcmd=bootp; setenv bootargs root=/dev/nfs nfsroot=${serverip}:${rootpath} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off; bootm
bootdelay=5
baudrate=115200
and output with FW V4.3.2.100
Warning: Bad CRC, using default environment
bootcmd=bootp; setenv bootargs root=/dev/nfs nfsroot=${serverip}:${rootpath} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off; bootm
bootdelay=5
baudrate=115200
this is the output from the bootloader over serial:
printenv:
baudrate=115200
bootargs=console=ttyMSM0,115200n8
bootcmd=mii write 0x0 0x0 0x800; sleep 1; nmrp; bootdni; boot_DNI_secureboot
bootdelay=2
eth1addr=94:a6:7e:61:78:29
eth2addr=94:a6:7e:61:78:2a
eth3addr=94:a6:7e:61:78:2b
eth4addr=ff:ff:ff:ff:ff:ff
eth5addr=ff:ff:36:4b:59:32
ethact=eth0
ethaddr=94:a6:7e:61:78:28
fdtcontroladdr=4a9574a0
ipaddr=192.168.1.1
machid=8010000
netmask=255.255.255.0
serverip=192.168.1.10
soc_version_major=2
soc_version_minor=0
stderr=serial@78B3000
stdin=serial@78B3000
stdout=serial@78B3000
Environment size: 562/262140 bytes
Same issue I had, if you continue you'll brick your device. I'd suggest to use the commands I mentioned above to get u-boot to create a valid env in that partition.
Is it possible to do that without serial?
The env that @PhoenixG36 posted above which the device actually boots from must be stored somewhere, whether it can be changed within the stock firmware is another matter.
Otherwise the instructions are going to be much simpler if serial is a requirement for the initramfs boot...
What do I need to change?
First command like this?:
fw_setenv bootcmd 'env default -a; saveenv; reset'