eth2ap and mqtt program at the same time

[mcqtom]

Hi.

I currently have a functioning MQTT client program on esp32 that uses ethernet to connect to the network. I wonder if it is possible to make something like eth2ap that runs alongside this program so that nearby wifi devices can connect to the network provided by the cable, but without capturing the traffic that needs to be received by my MQTT program. Ideally I would have the option to work like eth2ap (where wireless devices get DHCP from main router) and also work like softAP instead, but this would come later once the first part is complete.

I am using idf v4.1-rc so have access to the esp-netif API if this helps.

Can anyone tell me where to start.

Many Thanks

[ESP_morris]

The conflict is, eth2ap doesn't rely on lwip stack, but your mqtt application does.
So you might need to overrides the default Ethernet packet input path, by `esp_eth_update_input_path`.
And in there, you need to filter the Ethernet frames, maybe by MAC address?

[mcqtom]

Thanks for your response. I wonder if you can provide further assistance. I initialise wifi as in eth2ap example. Then I initialise ethernet as in ethernet-basic example but in the final steps after esp_eth_driver_install I do the following:

esp_eth_ioctl(eth_handle, ETH_CMD_S_PROMISCUOUS, (void *)true); //set to promiscuous mode
esp_netif_attach(eth_netif, esp_eth_new_netif_glue(eth_handle)); //attach netif to eth as usual
esp_eth_update_input_path(eth_handle, pkt_eth2wifi, (void *)true); //change the input path to fn pkt_eth2wifi
esp_eth_start(eth_handle)

pkt_eth2wifi is a modified version of that found in eth2ap example. it filters the MAC address, and if it matches that of the ESP32 it calls esp_netif_receive(eth_netif, buffer, sizeof(buffer), priv); which I thought would pass it to the LwIP stack. However there is an unhandled exception with little more information as to what went wrong.

[lcrocker]

I'd like to do a very similar thing (
and I'm sure there are lots of others who would as well--I can't believe this hasn't been touched in two years). _update_input_path() does not give any access to the former function it is replacing, otherwise it might be easy to "hook" that and filter out just the packets we don't want passed up the stack. There also seems to be no way to get the value of the "stack_input" field of the config structure.

[martins]

I have exactly the same problem ending up with exactly this:

pkt_eth2wifi is a modified version of that found in eth2ap example. it filters the MAC address, and if it matches that of the ESP32 it calls esp_netif_receive(eth_netif, buffer, sizeof(buffer), priv); which I thought would pass it to the LwIP stack. However there is an unhandled exception with little more information as to what went wrong.

I don't believe this could not work, but currently the esp_netif_receive() really only ends with Core register dump and single Backtrace address that cant be decoded.