Clarification about fragmentation?

[nxtfsm]

Thanks for the tremendous work on these libraries -- it's been a lot of fun and very informative getting things plugged together by working my way through the OSI stack and seeing how the libraries correspond. I've hit an odd(?) block at the Gateway level --and holding open the possibility that it could be something to do with radio interference / or my hardware/serial/raspian config-- I hope you (or anyone else) can clear something up that I think might have to do with the setting on RPi in RF24Network/RF24Network_Config.h for #define MAIN_BUFFER_SIZE.

Following the YouTube walkthrough I've set this to 1514 + 10, but the comment above says the result of MAIN_BUFFER_SIZE - 10 must be divisible by 24. I've been trying to figure out where the exception is, or what's going on to transform the result, and am coming up short.

On the Arduino side, in RF24Ethernet/uip_conf.h I've set #define UIP_CONF_LLH_LEN 0.

The result is this:
/examples/ncurses/RF24Gateway_ncurses is fully functional using SimpleClient_Mesh, and mostly functional with InteractiveServer_Mesh -- InteractiveServer is routable and responds to pings, but bashClient and curl calls return binary. Using RF24Gateway_ncursesInt, neither SimpleClient nor InteractiveServer are able to join the mesh, and the RF24Network Info Interrupt Errors counter increments steadily.

Anyway, thanks again for your time -- obviously I'm happy to post any other settings or output, if the issue doesn't jump out right away, but I'm just not sure where else to look or what would be relevant.

[TMRh20]

With the buffer sizes, there was previously an issue related to the max payload size of the radios ( 8 byte header + 24 bytes of data) so the buffer needed to be aligned in size to multiples of 24. I don't think this is currently an issue, but setting it to 1536 should ensure that it is not a problem.

InteractiveServer is routable and responds to pings, but bashClient and curl calls return binary

Not sure what you mean, like you are getting binary data instead of html data?

With ncursesInt, the sketch expects the radio interrupt pin to be connected and defined at the beginning of the sketch. The sketch periodically polls the radio for data, and increments the interrupt errors counter if data arrives that is not handled via interrupt. Essentially this indicates the pin is not connected or not defined correctly.

[TMRh20]

Just FYI I was updating RF24Network and decided to look into the 'divisible by 24' thing, and it is related to reassembly. Basically the only way the recipient knows the size of the incoming data initially is by the number of packets to be sent. (an 8bit value) So for example, a payload of 24 bytes would require 1 payload, but 25 bytes requires two. The recipient needs to be able to allocate 48 bytes to received two fragmented payloads, so the buffer needs to be 48 bytes at least to handle a >=25 byte payload.

Its because the only place to include the size in the header was the reserved field which is 8-bits, so would only work for <=255 byte payloads. Thus we use # of packets. (255 packets * 24 bytes = 6.1 KBytes)

Hope that explains things. I update the info in the documentation to clarify a bit too.