Modifying ethernet netif mtu?

[indexds]

Hi,

I'm looking to make my ethernet netif's mtu match that of wireguard at 1420 to prevent fragmentation, but the default is 1500 and that doesn't seem changeable at all.
Since the rust wrappers are using the esp-netif api to create interfaces, the raw lwip interface is abstracted and we can't access the mtu. And even if we could (it's most likely possible through shenanigans) I'm pretty sure changing the mtu at runtime is gonna make everything explode.

Soooo... How do we create a netif with a custom mtu? Is it even possible?

From what I could see the mtu is hardcoded here,

/**
 * In this function, the hardware should be initialized.
 * Invoked by ethernetif_init().
 * @param netif lwip network interface which has already been initialized
 */
static void ethernet_low_level_init(struct netif *netif)
{
    netif->mtu = 1500;
    ...
}

And this function is called by

/**
 * @brief   LWIP's network stack init function for Ethernet
 * @param netif LWIP's network interface handle
 * @return ERR_OK on success
 */
err_t ethernetif_init(struct netif *netif);

Which should be the init function passed when initializing an ethernet netif.

[indexds]

My current workaround for this is to set the mtu of the ethernet netif on the computer to 1420 with

netsh interface ipv4 set subinterface "Ethernet" mtu=1420 store=persistent

This works, however it is not ideal.

[ivmarkov]

I think at this point you know about this stuff more than me. If you find a way - let me know. It is also always an option to open a bug in the ESP-IDF repo requesting this functionality.

[indexds]

Yeah I think that's what I'll do, this isn't really your problem at this point since you just use what's available from the lower layer. Thanks anyway!

[indexds]

So we might be getting this soon. However this would be merged into master for esp-idf right? So what's the relationship between the version of esp-idf-svc and the version of esp-idf?

I'm up for updating the wrappers here for them to match but from what I see we're still in 5.2.2?

Bit confused here.

[ivmarkov]

So we might be getting this soon. However this would be merged into master for esp-idf right?

Yes. If this is not a breaking change (it might NOT be if they just add a new field to a C struct because this is not considered a breaking change by ESP-IDF) they might even back-port it to release branches.
Otherwise, it will be available - besides master - also in ESP-IDF V5.5.0 once that one is released.

So what's the relationship between the version of esp-idf-svc and the version of esp-idf?

esp-idf-svc supports all ESP-IDF versions from 4.4.7 till 5.3.2 inclusive.

• Support for V5.4.X is imminent
• Support for master is always lagging behind and your mileage when building with master might vary, as this branch sees a lot of breaking changes.

In any case, once the new field is available in ESP-IDF, you can also introduce it in esp-idf-svc, but behind a cfg that checks that ESP-IDF is >= 5.5 (this is the version of master currently, until 5.5 is released)

[indexds]

Alright, well we shall see how it goes.