I'm currently looking at customising the firmware on a Teltonika RUT-955, right now I'm using the factory-supplied sources (which are built on OpenWRT 14.07, quite dated now). Specifically, I'm trying to get the OpenThread Border Router installed and ported.
In short, the symptom is that ip -6 addr add ADDRESS dev DEV (wpantund tries to do this with ioctls) fails with a "permission denied" error when DEV is a tun device.
If I use buildroot to build a chroot environment, copy that to a USB stick plugged into the router and chroot into it and try the same thing, it works fine, so I suspect it's a quirk of µClibc. I note my buildroot environment used µClibc-ng and modern OpenWRT seems to prefer musl, thus I'm wondering whether it's worth trying to keep OpenWRT 14.07, or whether to move up to 18.06.1.
In the recovery methods, there is talk about "U-Boot web recovery", and link to this page: https://openwrt.org/inbox/docs/recovery/u-boot_web_recovery … which is blank. I've tried doing a Google search on the matter, and I get little in the way that looks authoritative.
I haven't bricked the device yet, and don't want to… but in the event that I do by mistake, I was wondering if someone could fill me in on how this feature works and how it is activated?
Hrmm, okay, my IPv6 issue had a simpler solution: one of my firmware flashing attempts wiped out my overlay, so it restored to factory defaults which have IPv6 support disabled (/proc/sys/net/ipv6/conf/all/disable_ipv6 was 0). I'll have to figure out where in the build environment I can set that to make it default to 1.
My question still stands though, and long-term I'd like to move this up to something more recent as I had to patch a lot of things to get the older firmware to build on modern Linux (e.g. e2fsprogs, mtd-tools and the SquashFS tools all needed patches for changes to sysmacros.h in newer glibc), and for the security fixes.
If you're talking about a "fancy" border-router package, then the security disadvantage of a known-insecure kernel, application software, and protocols from over four years ago should answer that one "No!" quickly for you.
I suspect your IPv6 challenges will "go away" with current software without having to disable IPv6. Disabling IPv6 completely breaks current Linux applications in subtle ways, such as them expecting to be able to bind to ::1 loopback.
Actually, I do not want to disable IPv6… quite the opposite, as this device will be participating on a 6LoWPAN mesh, thus needs to talk IPv6.
I'm finding now that toolchain issues have forced my hand into moving to a newer OpenWRT release (laws of diminishing returns, etc).
Irrespective though, this doesn't tell me how this U-Boot Web Recovery option is supposed to work, which is actually what I asked about.
The images supplied on that page for the Teltonica RUT900 (both .bin files), are not recognised as valid firmware images by OpenWRT's firmware update, so I'm finding myself having to compile from scratch. Thus, there is a heightened risk of bricking the device.
To quote my earlier post (emphasis added):
In the recovery methods, there is talk about "U-Boot web recovery", and link to this page: https://openwrt.org/inbox/docs/recovery/u-boot_web_recovery … which is blank. I've tried doing a Google search on the matter, and I get little in the way that looks authoritative.
I haven't bricked the device yet , and don't want to… but in the event that I do by mistake, I was wondering if someone could fill me in on how this feature works and how it is activated?
I've selected the factory image from the OpenWRT website, we'll see how that goes. At the moment, the web interface is allegedly flashing the firmware.
Okay, so the U-Boot updater didn't like that 18.06.1… but the good news is it's not bricked yet, I was able to power-cycle and repeat to get back to that screen. When I tested a known good image, I got this:
The LAN LEDs blink in an ordered pattern for a bit, then go blank, at this point the router is unresponsive. I might need to go chase up the console connections on this thing to recover it.
Yep, that's the correct way to do it. I usually release the button after the 4th or 5th slow blink. If you hold it longer sometimes it will not work. Maybe there is a timing window you need to hit.
Well, it seems to do something, it'll sit there, apparently flashing the code to serial flash, then it appears to reset. At this point is where it hangs.
The boot-loader itself is there, so if I can get into U-Boot's console environment, I should be able to load something via TFTP and get it working again. It'll be a matter of maybe separately flashing the kernel, root SquashFS image and then erasing some partitions for JFFS2.
I would have been going to the firmware address (index.html) not the bootloader one.
As it happens, the router after sitting in a box for a few months waiting for the day I'd attack it with a TTL-UART adaptor, decided to mysteriously start working with its stock firmware. So I think it is now recovered.
