[Solved by reboot] 26.7 Update-> "failed, signature invalid"

[danmac]

So -a has a history for us: https://github.com/opnsense/update/issues/90

Blimey lol :/ thanks for the link, I also skimmed 7825

So the danger is that fetch -a can retry forever getting nowhere. Also I see some confusion regarding the -T flag, as we discussed earlier I thought it was connect timeout only ... (?)

I can understand the difficulty of devising a solution that makes everybody happy, with their own little networks broken in their own little ways ;)

If it's on the roadmap to switch to curl anyway, it occurs to me I'm in danger of wasting your time with this ... although as previously noted, curl failed in just the same way, at least for me. curl does seem to have more levers to influence the retry logic though, eg. --retry, --retry-max-time, --connect-timeout, --max-time, etc

I also don't quite get what's happening here:

Downloading kernel-26.7.8-amd64.txz with remote size 33253768:
kernel-26.7.8-amd64.txz                        88% of  31 MB  691 kBps    05s
fetch: kernel-26.7.8-amd64.txz appears to be truncated: 29328007/33253768 bytes
kernel-26.7.8-amd64.txz                                31 MB  634 kBps    06s
Verifying signature with trusted certificate pkg.opnsense.org.20260608... done

It's truncated and complained loudly, then soft-resumed at the end of the transfer or started anew? And then it downloads all and verifies ok?  Why doesn't it work the first time? This isn't a client-side riddle IMO.

Yeah it just resumes the remaining portion of the transfer after it hits the unceremonious yet highly predictable SSL EOF - I end up with everything fully downloaded and verified.

I still can't help but suspect these woes are (P)MTU / MSS related. Firmware updates seem to be a particular pain-point with 5G, and the guy in issue 90 had some wacky VPN + proxy setup. (on that note I wonder if the fetch -T timeout is satisfied by the connection to the proxy rather than actually contacting the mirror) May also explain why some say changing mirrors helps. I never had this problem on the exact same firewall via VDSL (1500 MTU, ethernet @ 1508 MTU to a Draytek modem in bridge mode, OPNsense handling PPPoE) it's only an issue now I'm on 5G. (1380 MTU)

I had the AI waifu check my MTU configs (at least in theory) last night, bit of a long story, funny to see its "thinking" loops similar to my wetware when I'm handling MTU calculations haha :/ "hmmm ... wait ... let me recompute cleanly ..." xD

Maybe in amongst these ramblings (sorry) will be a clue or two for someone down the line. I'm still new to 5G and it was installed in haste/anger on an 8+ year old somewhat complicated install so I should probably return with a fresh install and wireshark, et al. I'll even stop ignoring the new firewall rules page ;)

o7 thx, appreciate your time Franco :)

[franco]

Back then I think what fetch needed was a limit to the retries to escape the vicious cycle, but such an option doesn't exist. I trade a ticket for investigating if that would make sense: then we could re-introduce -a but limit it to e.g. 2-3 retries max.


Cheers,
Franco

[danmac]

I'm in a bit of a rush just now will come back later but pulled up the source for fetch quickly (not really a C guy so bear with) but I can't see a way of politely prodding fetch itself into that kind of behaviour as it stands.

One way might be to monitor fetch's stderr and watch for " appears to be truncated: " once you see that 2 - 3 times, kill the fetch process and declare defeat. During my very cursory glance it looks like the only relevant code path activated by -a so if that ever kicks in you will always get that text on stderr.

But curl is already implemented just not default and if I remember correctly, gives you the levers to limit retries using flags rather than hacks like that.

https://github.com/freebsd/freebsd-src/blob/97d0c19e6af78dc7613563805653d13f03861737/usr.bin/fetch/fetch.c#L823 (do a CTRL-F for a_flag)

cheers o7