Project

General

Profile

Ethercard smaller buffer possible ?

Added by DaveOB about 2 years ago

I know very little about ethernet and packets, but have had some very positive results with the ethercard library using an ENCJ2860 module on a Mega 2560.

I am now at a point where I would like to know if it is possible to make the Ethernet::buffer smaller.

I am not downloading large amounts of data ( average 2000 bytes, so 4 packets of 512 byte data every few hours ), so would like to sacrifice having to retrieve more packets and have more memory free in my sketch.

At present, the Ethernet::buffer is set to 650 bytes, which is enough for the offset and data passed to the callback function by the ENCJ2860 module.

My code is saving the Ethernet::buffer data to a file on an SD card. Working perfectly, but if I reduce the Ethernet::buffer size ( for example to 400 ), using the ether.begin code :

if (ether.begin(sizeof Ethernet::buffer, mymac, 46) == 0){
    Serial.println(F("Failed to access Ethernet controller"));
}else{
    ether.staticSetup(static_ip,static_gw,static_dns);
    Serial.println(F("Ethercard Started"));
}

then the data being written to the SD card is cut off.

So either the 512 bytes of data in each packet can not be changed ( is it a ethernet standard, or maybe set by the ENCJ2860 module ? ), so making the buffer smaller is simply saying " give me the first 400 bytes of the 512 bytes of data and dump the rest ", or I just have not found where to change it in the library.

Any pointers would be appreciated.


Replies (1)

RE: Ethercard smaller buffer possible ? - Added by tochinet over 1 year ago

In the Xively example dated 2013 (so relatively “new” compared to most ENC28J60 posts), the buffer is set to 350 bytes. So that should be usable.
But indeed, this could imply that the end of bigger packets is truncated. Hopefully without any out-of-bounds writing, a well-known method to attack computers.

The standard at “Ethernet” layers is around 1500 bytes. That’s the maximum size of the physical/electrical packet on the wire.
At the IP layer, the maximum size is fixed by a parameter called MTU that can be smaller or bigger. When bigger, the IP layer needs to support “segmenting”.
Apparently, the Ethercard stack does not handle this itself, but the client web browser does :

From tcipip.cpp :

// The TCP implementation uses some size optimisations which are valid
// only if all data can be sent in one single packet. This is however
// not a big limitation for a microcontroller as you will anyhow use
// small web-pages. The web server must send the entire web page in one
// packet. The client “web browser” as implemented here can also receive
// large pages.

So in theory, the buffer should be 1500 bytes to be sure not to miss anything.
In practice, it depends whether your program plays client or server, and probably also a few other things.

    (1-1/1)