ericpaulbishop / gargoyle

Gargoyle Router Management Utility
http://www.gargoyle-router.com
465 stars 222 forks source link

ath79 config fixes #966

Closed aimacintyre closed 1 year ago

aimacintyre commented 1 year ago

This set of commits gets all selected ath79 devices in the default profile (86 of them) building on the 22.03 base. It comes at the price of 8MB flash devices with USB ports being restricted to the -basic profile as the images are too big if the -usb profile is used.

Kernel options are further pruned to minimise flash requirements, several packages are removed that aren't dependencies of any required packages for gargoyle and packages that are only required for the -usb or -large profiles are set =m so they're built and included in those profile images but not included in -basic profile images.

lantis1008 commented 1 year ago

What state of functionality does this leave the usb port at? I'm uncomfortable producing images for devices with usb that doesn't work, I'd rather abandon those images. Will they still do 3/4/5G dongles for example? Can/should the usb storage plug-in dependencies be broken out further?

Have you tested QoS is ok without tc-mod-iptables?

aimacintyre commented 1 year ago

At the moment, no 8MB USB (ath79 or mt76x8, not looked at other targets) profile device image is buildable because of the size issue.

I thought I'd sent a forum private message about some of these matters, but I can't find any trace of it :-(.

I tried the vpn-only profile idea previously floated but that also fails for size reasons - the dependency on openssl-utils (via openssl-easy-rsa) appears to be the back-breaker. However we might be able to do a cutdown vpn type setup with just wireguard and tor?

I also tried the usb net-only profile idea which built ok and seemed to leave sufficient potential space in most 8MB USB images to save settings. I didn't include a patch for this profile in this PR as it seemed to be out of scope, but I can add one if you want to see what it would look like.

I was wondering which package dependencies of plugin-usb-storage-noshare would comprise the minimum set sufficient to support extroot configuration for the usb devices without the usb-net packages - the idea being that the 8MB USB device users could use extroot to make up for the lack of available space. Travel routers though would probably be better off with the usb-net profile idea. Hmmm... after some searching, I found an extroot discussion in addition to the OpenWrt wiki entry which suggests this might be possible as a lightened version of plugin-usb-storage-noshare (swap/ext4 storage only, no networking or other filesystems). Thoughts?

As an 8MB USB device owner (albeit mt76x8 though that is similarly afflicted) I'd be unhappy if the 8MB USB devices were dropped just because complete USB support couldn't be built while 8MB basic devices were retained - except for travel router type devices (e.g. TL-WR902ac v1), it seems to me that the 8MB USB devices would still be quite usable as basic wifi routers without the USB features... If you're going to move in that direction, perhaps better to just jettison 8MB devices now (I've seen a reference to OpenWrt perhaps not supporting them beyond a 23.xx release due to the flash space crunch and kernel size growth so they may not have a lot of life left anyway).

I haven't tested QoS with tc-mod-iptables removed - I was operating on the premise that if it's required it should be referenced somehow in a gargoyle package makefile as a direct or runtime dependency, or in a config.in file, but I can't find it if that is the case. If it is actually required, where would it best be identified so I can add a patch to the PR to resolve this and ensure it's included through the gargoyle packages or defaults?

Although I don't think it's ever been used this way it seems to me that gargoyle's target profiles could support multiple builds for the same devices, so 8MB USB device images could be built for both usb-net and extroot profiles. It reintroduces duplication of packages that I was hoping to reduce via use of the profile meta-packages, but the flexibility might be worth that cost...

aimacintyre commented 1 year ago

Addendum: the usb-net profile mentioned above would support 3/4/5G dongles and at least Android tethering (iOS tethering for network connection purposes might also be supportable, but the extra iOS tethering functionality couldn't be due to the size of required packages).

lantis1008 commented 1 year ago

I don't think there's a good solution to the problem. We can eliminate usb support for this round of releases, but an explanation must be provided of the ones with ports which will be non-functional. It will be a disappointing reality that they'll have to be cut eventually. I'm not very keen on some of the block size and kernel symbol stripping, but it is what it is. It can make my life harder lol.

I'll accept this PR, thanks again as always

lantis1008 commented 1 year ago

tc-mod-iptables will not be required

aimacintyre commented 1 year ago

That's good news.

While testing whether a lightened plugin-gargoyle-usb-storage-noshare package would build, found 2 more minor fixes.

The lightened version lacks the hfs+ and ntfs file system support and the nls support kmods - I left in the msdos and vfat fs kmods as they weren't big and can be useful with flash drives. I selected the C7 v1 and WR902ac v1 as test cases for building and both built with sysupgrade images at least 500kB smaller than OpenWrt's respective declared maximum image size so would be viable and permit enabling extroot as best I can tell.

I created the lightened version as an additional package in the plugin-gargoyle-usb-storage-noshare package makefile, so with extroot enabled the -noshare (or full) packages could be added. To do it properly, the scripts and javascript for the plugin would be just in the -extroot package and the -noshare package would become a meta-package to pull in the additional file systems and NLS kmods.

Are you prepared to consider adding this so that 8MB USB devices at least have some functionality? I'd particularly like to see the WR902ac v1 and v3 (mt76x8) have USB networking to be usable as travel routers (the extroot functionality isn't as useful for these devices in that role as they only have 1 USB port each).

lantis1008 commented 1 year ago

Yes absolutely. Do you want that to be a separate PR or should I hold off merging here?

aimacintyre commented 1 year ago

I'll put that in a separate PR after I've PRed the ipq40xx and mt76x8 target configs.

lantis1008 commented 1 year ago

I'm going to try and attack ramips this weekend and clean it up using the same strategy

aimacintyre commented 1 year ago

If you set all the 8MB ramips devices to the basic profile, after I PR the changes to the noshare plugin to add the extroot package I'll PR changes to convert all the 8MB USB devices to use the usb profile. I had a quick look at the ramips profiles and think that the mt7620 and mt7620_usb profiles could be merged as has been done for ath79.

I noticed that there are a quite a number of potentially interesting mt7621 devices available in 22.03 in addition to those we already had, particularly from DLink, Linksys, Netgear and TP-Link, nearly all of which seem to have at least 16MB of flash. I have an Archer A6 v3 to test in addition to the R6220 I added in 1.13.x.

A bit later I'll also PR a couple of minor cleanups to the ipq806x target along with an extra device (Netgear XR500).

aimacintyre commented 1 year ago

A follow-up alternative approach thought for mt7620: separate 8MB and 16+MB devices into mt7620 and mt7620_large (or mt7620_small and mt7620 respectively) with the former having the kernel size saving tweaks in the config and the latter having standard kernel/image settings. This way, when the time comes to drop the "small" devices it's simply a matter of dropping the small profile (at least until 16MB becomes "small" anyway...). If that's a goer, doing similarly for ath79.default might be worth consideration too. Pity about the potential churn, but going from 19.07 to 22.03 is a pretty big churn in it's own right and if it helps settle things for the longer term I think it might be worth the effort (I'm happy to actually do the work in that event).