lwip DHCP Server running on esp-hosted/master as SOFTAP

[claydonkey]

1. A DHCP Server on esp-hosted is setup to lease IPS from the SOFTAP.
2. The PC connects to the SOFTAP over WIFI successfully on Channel 1.

3. The PC gets an IP in the range of 192.168.2.2-254.

   Wireless LAN adapter WiFi:
   
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Intel(R) Wireless-AC 9560 160MHz
   Physical Address. . . . . . . . . : 18-1D-EA-81-60-3C
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 192.168.2.2(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : 14 November 2023 21:17:44
   Lease Expires . . . . . . . . . . : 14 November 2023 23:30:14
   Default Gateway . . . . . . . . . : 0.0.0.0
   DHCP Server . . . . . . . . . . . : 192.168.2.1
   DNS Servers . . . . . . . . . . . : 192.168.2.1
   NetBIOS over Tcpip. . . . . . . . : Disabled`

That side of things seems taken card of.

4. Host receives no packets from the pc after this.

The code seems pretty trivial:

dhcps_t *dhcps;

void lwip_init(uint8_t mac_address[6]) {
    /* Initialize the LwIP stack with RTOS */
    ip4_addr_t lwip_ip, lwip_netmask, lwip_gw;
    /* set MAC hardware address length */
    gnetif.hwaddr_len = ETHARP_HWADDR_LEN;

    /* set MAC hardware address */
    memcpy(gnetif.hwaddr, mac_address, NETIF_MAX_HWADDR_LEN);
    IP4_ADDR(&lwip_ip, 192, 168, 2, 1);
    IP4_ADDR(&lwip_netmask, 255, 255, 255, 0);
    IP4_ADDR(&lwip_gw, 0, 0, 0, 0);

    /* add the network interface (IPv4/IPv6) with RTOS */
    netif_add(&gnetif, &lwip_ip, &lwip_netmask, &lwip_gw, NULL, ethernetif_init_low, tcpip_input);
    gnetif.linkoutput = myif_link_output;
    gnetif.output = etharp_output;
    gnetif.hwaddr_len = 6;
    gnetif.mtu = 1500;
    gnetif.name[0] = 's';
    gnetif.name[1] = 't';
    gnetif.flags |= NETIF_FLAG_BROADCAST | NETIF_FLAG_ETHARP | NETIF_FLAG_LINK_UP;

    /* Registers the default network interface */
    netif_set_default(&gnetif);

    if (netif_is_link_up(&gnetif)) {
        /* When the netif is fully configured this function must be called */
        netif_set_up(&gnetif);
    } else {
        /* When the netif link is down this function must be called */
        netif_set_down(&gnetif);
    }

    /* Start DHCP negotiation to a network interface (IPv4) */

        dhcps = dhcps_new();
        dhcps_set_new_lease_cb(dhcps, dhcps_callback, &gnetif); // callback just sets 
        dhcps_set_option_info(dhcps, SUBNET_MASK, (void*) &lwip_netmask, sizeof(lwip_netmask));
        dhcps_start(dhcps, &gnetif, lwip_ip);
        netif_set_addr(&gnetif, &lwip_ip, &lwip_netmask, &lwip_gw);
    }
}

[mantriyogesh]

Hello @claydonkey, the 91650704ae589585778bd07c4ab1b55161062d94 is just pushed with the changes..

https://github.com/espressif/esp-hosted/commit/91650704ae589585778bd07c4ab1b55161062d94#diff-bb7ce95059c113766ecf6c2fbb0c430a7940650b7cba263ba24ebc903a034fefR559-R561 is something you need to see.

Apart from that, in your example, new directory components/esp_wifi_remote with: esp_wifi_remote.tgz would be needed for ESP as host.

You can add this code in your compilation for now anywhere you feel correct for your MCU. Also, please take a note of #if 0 part in here: https://github.com/espressif/esp-hosted/blob/feature/esp_as_mcu_host/host/drivers/transport/spi/spi_drv.c#L506-L523

esp_wifi_remote is just concept/wrapper, where you have understanding that you are going to use the Wi-Fi from slave (and not native, as in case of ESP, it is available)

Little stuff to digest, but just let me know, I can further explain or do code changes for you.

The SDIO change is tested fine. please check the port layer changes in above commit.. the test results (SDIO throughput) are also mentioned as part of commit info..

[mantriyogesh]

any update?

[claydonkey]

Thanks @mantriyogesh. I tried editing the new features branch for the stm32 but I'm finding it a bit overwhelming. I think the bulk of my confusion lies in the wifi area - specifically esp_wifi.h (esp_wifi_types.h + wifi_drv.c). I was working with your patches on the master b4... Is this patch for the patched version or the features branch? I assume the features branch...

So I came to a grinding halt at wifi_drv.c. There seemed to be no #include "rpc_api.h" So are you saying - replace the call to esp_wifi_init with remote_esp_wifi_init_slave in wifi_remote_init.c ? I see that esp_wifi_init has been replaced with in tgz archive - phew So I've ditched esp_wifi.h esp_wifi.c wifidrv.c for the remote... files. I'm on Terra Firma now.

Alas, esp_wifi.h still leads to a missing #include "rpc_api.h"

[mantriyogesh]

Actually, you seem to mix the two branches together.

Can you do a simple test first, with ESP - ESP on new branch? If no, then I think you can selectively take a change from the new branch. Anyway, this is lesson for us that much work would be needed to streamline portable layer in new branch.

Actually, the required headers and dependency files / modules are directly taken from esp-idf in case of ESP as host. for example esp_wifi.h was a replica in local branch and ESP-IDF. As local copy would be very bad idea, we removed such code, same is for esp_event, esp_netif etc modules/drivers.

Anyway, we would try to get you onboard with older branch if you could reliably go to older commit.

[claydonkey]

Your advice is heeded. I am confusing myself. I see that all components are now pointing to esp-idf and that makes sense but will need closer examination to implement a new host.... I think I will start from scratch getting the esp as host compiled from the features branch and see where changes will be necessary for the stm32. The problem is that I am not fully versant with the features branch since the (master + patches). If I could patch the 4840528 patched version then I would be good to go but I realise that the differences between this and the features branch have become unmanagable Another problem is that I have no idea how to prepare any IDE/toolchains for esp - my experience with the esp32 only goes back a month or two.

[mantriyogesh]

you can actually work on the branch directly (new branch), if you decide to work on feature/esp_as_mcu_host. You would get confused with multiple commits manually maintaining, would not recommend..

If you work on the commits from older transient branch, that is okay. We will try to get you sorted with those commits itself. we anyway have internal repo for that, so should not be problem for us. It's just that we thought of discarding that branch considering feature/esp_as_mcu_host would advance.

I think priority is not choosing which commit/branch to work upon. I think important for you is to get reliable netif working. Let us know which one you stick to.

Another problem is that I have no idea how to prepare any IDE/toolchains for esp - my experience with the esp32 only goes back a month or two.

This should be fairly simple, just follow https://github.com/espressif/esp-idf/tree/release/v5.1 Please note the branch to be used: release/v5.1 Once you have idf.py in your development machine, you can use esp <-- spi or sdio --> esp

[claydonkey]

It looks like I'll proceed with the features branch. I've managed to get it compile with the stm32 compiler - I hope it's a case of shoeing in the stm32 SDIO HAL which is working nicely for esp-hosted master...