Support Fritzbox 7490

For Developers
187

That would be these two patches: https://github.com/jschwartzenberg/openwrt/tree/feature/add-avm-wasp-target

I could at least build this without issues, but didn't test.

I have some ideas on my mind. I hope to find time and try them out. One thing I was wondering about was whether the lantiq binaries would run on the ath79 too. In that case they could share parts of the filesystem.

188

Userspace binaries, yes. Both lantiq/xrx200 and ath79 are using mips_24kc.

189

In that case I am thinking of an approach where only an ath79 linux kernel image would be built. There'd be a package that would provide an init script on the lantiq side that:

  1. Creates a directory structure for the wasp root, let's say inside /var/run/wasp
  2. Bind mounts the respective host directories /bin, /lib, /usr, etc. in there (read-only)
  3. Points directories like /etc and /var to writeable persistent space
  4. Exports this root directory over NFS using the link-local address (fe80::...) of the wasp interface (I imagine this might require the userspace NFS daemon)
  5. Boots the WASP using a kernel argument to use NFS root with the link-local address and structure set up in the previous steps
  6. Possibly adds some Netfilter rules to enable easy access to the WASP's SSH and HTTP(S) ports through the lantiq (possibly embed a working link inside LuCI)
  7. When calling the script with stop, it would remove the Netfilter rules, shut down the WASP and remove the structure below /var/run/wasp

The userspace on the lantiq and ath79 sides would be identical, but as they use a different spot for their configuration they would behave accordingly. New packages would be installed on the lantiq side and could be used on the ath79 side if so desired.

This approach would reduce the WASP image to just a WASP/ath79 linux kernel. I imagine it would be doable to have an OpenWrt package recipe that builds a bare WASP/ath79 linux kernel. This would not be intrusive with regards to the existing OpenWrt build structure.

Do you think an approach like that might work? Of course I'm not asking for guarantees this actually gets merged. It would need to be created in an independent package feed first and would still involve significant reviewing and possibly reworking some areas if it would somehow manage to reach a mergeable stage at all. I am mainly asking if there are any technicalities already visible that could be an obstacle for this approach.

190

Again, I'm not the one taking decisions about this.
Very personally, this approach feels rather messy and fragile to me, both in terms of apk integrity (for both systems, but at least the ath79 side will always be wrong) and synchronization (ath79 won't notice changes on the lantiq side, lantiq won't even expect changes from the ath79 side). I would suggest a way more targeted overlap (and /lib/ will hold quite a few 'surprises' for you, ranging from kernel modules to preinitd, upgrade, netifd, etc.).

191

Many thanks for your feedback! I realized the kernel modules issue indeed (was already thinking to avoid modules for the ath79 side), but I was not aware of the other aspects.

I'm curious if you have anything in mind with regards to a more targeted overlap?

All clear! I'm just trying to brainstorm possible approaches. Your feedback is great!

192

You can't do that, the kernel is shared among all devices of a common subtarget (and you won't be able to introduce a new ath79 subtarget, just for the ath79 initramfs image).

193

I was actually thinking of letting the package build its own kernel with a specific .config although I don't know how hard that would be. It seems you are kind of answering my earlier question though. Would it be acceptable if I would create a PR that enables the remote processor infrastructure for lantiq devices? This needs to be there to allow the wasp module to build successfully. At the same time it seems useless for almost all other devices.

At this point I'm also not fully sure what the advantages of a module are over a userspace utility. I have been successfully bringing up the extra PLC/G.hn chip which boots in a similar way on Devolo's devices. There it is handled it with a separate daemon and this seems to work out quite well.

194

With the explicit disclaimer that I'm not an OpenWrt developer and not the one deciding anything (yes, I'm repeating myself, but you really shouldn't take my advice as gospel).
Technically possible, but I don't see a snowflake's chance in hell to get that merged. The human cost of keeping that maintained would exceed its usefulness by several orders of magnitude. Keep in mind, it needs continued maintenance, bumping to new stable kernels 1-3 times a week, bumping to a new LTS kernel once a year, that is a lot of work - and on top of that it still needs to cooperate with the mac80211 backports. Then the normal -unmodified- mainline kernel won't do either, you'd need a lot of OpenWrt's generic and ath79 specific patches on top of that - and you have a perfect combination that will explode on your within weeks.

My suggestion would still be to start in the easiest/ least intrusive way possible - and extend from there. But I'm extrapolating with my experience of the cursed Vodafone Easybox 904 xDSL (special non-default BBT signature for the NAND, two-stage switch cascade with special VLAN considerations, RaLink rt3883 iNIC wireless (roughly similar to the F!B 3490/ 7490 situation) and a display).

195

Started working on a package feed. Nothing tested yet.

Adding src-git fritzboxpackages https://codeberg.org/jschwart/openwrt-fritzbox-packages.git to feeds.conf should work.

196

Found the answer, the userspace utility actually relies on patches applied to Linux:

Notably wasp_uploader_stage1 relies on IOCTLs that are not there by default, those would be added by 2001-NET-MIPS-lantiq-add-mdio-ioctl.patch.

That seems quite a bit more involved than just enabling the remote processor framework that's already there, so moving forward with the WASP kernel object does make more sense.

197

It seems NFS won't work indeed. The userspace NFS daemon isn't packaged for OpenWrt (unsure why not) and the kernel NFS server won't be able to deal with all the overlay stuff.

Another idea I came up with that would possibly be simpler to start off with. Using iSCSI with a backing file.
OpenWrt has the tgt package which supports "SBC: a virtual disk drive that can use a file to store the content."

This could then be used by the ath79 side as an overlay mount on top of the filesystem that's there now.

Curious to hear what people think :slight_smile:

198

since I do not understand so deep developer things, I just want to mention this idea, if it is about both firmware images and getting them on the device:
would it be possible to first have the user flash the image that makes the internet connection and then have a package in this system use attended upgrade to get the image for the wifi system? (and then automatically save it, and use it next boot or so.)
The downloaded firmware would of course need to be some kind of subtarget that is available, and that has some specific addon which allows it to talk with the main firmware.
But like this, one could maybe circumvent the chicken-egg problem of including one firmware into the other..?
This would of course only work initially on devices that do not get internet over wifi, but I suspect most do not do this...

199

Not really attended sysupgrade, but download and store, yes (depends on a working internet connection, which is not great - but hey, it's just an scp -O away…). But you're putting the cart before the horses