Compile-time configurable MAX_DOFF (handle large files)

[mullerch]

Actually, cert files are limited to MAX_DOFF=65535 :

basicstation/src/sys.c

Line 148 in bd17e53

fsize > MAX_DOFF ||

As mbedTLS support certificates bundles, user may give to the Basic Station the system certificate bundle (e.g. /etc/ssl/certs/ca-certificates.crt), it may occur that those bundles are bigger than that. A Debian system ca-certificates bundle is typically 200KB.

I suggest raising this limit up to 1MB at least to handle standard system bundles. By the way, I would suggest printing a specific error message to this error as it is actually hard to diagnose (it prints errno which is not set and refers to an older function call error).

[beitler]

Station abstracts chunks of memory in the dbuf_t structure which maintains offsets of type doff_t. To accommodate for small platforms, those offsets are 16 bits long by default:

basicstation/src/rt.h

Lines 70 to 71 in bd17e53

	typedef u2_t doff_t;
	enum { MAX_DOFF = 0xFFFF };

In principle, the code made provisions for allowing larger offsets (thus larger buffers), but at this time is not a supported mode of operation. It is something we could choose to expose as a compile time option in the future.

As for your specific case of large trust files: The primary paradigm of Basic Station is that connection security parameters are fully managed centrally in a self contained way via the CUPS protocol. We believe that on the long run, over large fleets of gateways, maintaining security credentials centrally is more robust than relying on local device-level configurations. Relying on the system bundle of certificates, you implicitly rely on the OS's package manager to update the bundle accordingly. Basic Station tries to minimize error prone dependencies to third party systems. Hence, using the system bundle as a trust source is not a recommended approach. Nevertheless, I agree that in some conditions under controlled environments, a user may want to use large trust stores and Basic Station should not prevent that. The option that I laid out above should enable this use case in the future.

Concerning error reporting: Definitely, the error reporting for that case should be fixed. Thanks!

[mullerch]

Thanks for clarification. So if I understand correctly, settings MAX_DOFF to 0xFFFFFFFF should work just fine (to be tested).

[mullerch]

I've been able to read larger files by setting MAX_DOFF to 0xFFFFFFFF and using u4_t type for doff_t:

typedef u4_t doff_t;
enum { MAX_DOFF = 0xFFFFFFFF };