DHCP for bridge mode (IDFGH-3778) #5697

romatetemadze · 2020-08-04T19:36:06Z

Unable to make two clients connect via esp32 (ETH + WIFI AP)
Based on eth2ap example

Development Kit: [ESP32-Ethernet-Kit V1.1]
Module or chip used: [ESP32-WROVER-B]
IDF version: v4.1-rc
Build System: [CMake]
Compiler version: xtensa-esp32-elf-gcc (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a5) 5.2.0
Operating System: [Windows]
Using an IDE?: [Eclipse]
Power Supply: [USB]

Spent like two weeks trying to solve this, but apparently its not something I can do. My case is as follows:

I have to connect wifi client with ethernet client
None of them are running static IP's
WIFI client can not join the network without IP being provided (so I can't use 169.254.x.x subnet for DHCP-less setup)

DHCP interceptor in pkt_wifi2eth & pkt_eth2wifi

Guess its doable to pass the packet back if its a DHCP. Not sure if the MAC setting of the WIFI interface affects such approach.

I have tried to set WIFI AP as default with DHCP

Played a lot with custom subnets, tried NAT but well, its not right way, hence asking here. I believe that following changes can be made:

Let WIFI start even without ETH being UP
Let both interfaces wait for clients
If ETH is UP and WIFI AP has at least one station, enable bridge queue and stack_input = pkt_eth2wifi for ETH (this may be tricky to change on fly)
If either party is asking for an IP, provide them from single instance of DHCP (common lease base, IP range and etc).

This may be a nice solution for automotive industry, when car is ENET equipped, and most of modern software providers are working with Android/iOS for diagnostics and programming. In such case existence of single DHCP instance is vital on both interfaces

Alvin1Zhang · 2020-08-05T00:58:51Z

Thanks for raising this feature request.

liuzfesp · 2020-08-05T03:31:53Z

HI @romatetemadze,

Not sure I have understood your requirements:

The key point to your application is to configure the IP of WiFi and ETH client, right?
Your recommended solution is to support single DHCP server on ESP32 side and filter DHCP packets on ESP32
The NAT method is not suitable for you.

Could you give more description about why the NAT is not suitable for you?

romatetemadze · 2020-08-05T08:06:22Z

HI @romatetemadze,

Not sure I have understood your requirements:

The key point to your application is to configure the IP of WiFi and ETH client, right?

Your recommended solution is to support single DHCP server on ESP32 side and filter DHCP packets on ESP32

The NAT method is not suitable for you.

Could you give more description about why the NAT is not suitable for you?

Hello, thanks for answering.
I need single broadcast domain between eth/wifi clients due to UDP broadcast requirements. That makes NAT not suitable for the process. And in terms of the requirement, well, I just need to merge etherner & wifi AP on layer 2, but as well provide DHCP service for both.

You can think of an Ethernet+wifi switch that has DHCP server built in.

liuzfesp · 2020-08-05T11:19:16Z

Well, so it's a very special requirement and I'm afraid it's NOT common enough to put it into IDF.

If ETH is UP and WIFI AP has at least one station, enable bridge queue and stack_input = pkt_eth2wifi for ETH (this may be tricky to change on fly)

If only ETH is UP, will the TCPIP stack be up also? If yes, then it may be problematic, consider following scenario:

The ETH client already setup a TCP connection with ESP32
A station is connected to the ESP32 AP
Then the TCP connection will be affected since the TCPIP stack has been stopped.

romatetemadze · 2020-08-05T15:15:33Z

Well, so it's a very special requirement and I'm afraid it's NOT common enough to put it into IDF.

If ETH is UP and WIFI AP has at least one station, enable bridge queue and stack_input = pkt_eth2wifi for ETH (this may be tricky to change on fly)

If only ETH is UP, will the TCPIP stack be up also? If yes, then it may be problematic, consider following scenario:

The ETH client already setup a TCP connection with ESP32

A station is connected to the ESP32 AP
Then the TCP connection will be affected since the TCPIP stack has been stopped.

Thanks for the answer.
Well, my suggested scenario was just based on the eth2ap and the way it works. Ideally, transparency between ETH andAP is what I need (so, usual switching between Ethernet and WIFI on layer 2). There are no TCP connections with ESP32 itself (if I understood the watch-out correctly).

Will give you a live example. I have a small WIFI router at home, which can be put in BRIDGE mode, so WIFI is transparently translated to ethernet on MAC level, and vice versa. On the same time, it has some sort of a virtual interface (with it's OWN MAC address) which is running DHCP service (regardless of presence of clients at either side). This is what I want to achieve with ESP32.

So far, I can catch packet in the code below, analyze if it's DHCP, and respond back with DHCP offer/lease instead of forwarding to opposite media. Similar approach for pkt_wifi2eth side. However, it's already in DHCP driver in ESP, just need good understanding how to run such setup, which I am lacking.

bool dhcp_processor(flow_control_msg_t msg) {
    // check DHCP if discover or request
    if (msg.len>300 && msg.buffer[42]==0x01) {    // DHCP detected
    uint8_t mtype=msg.buffer[258];

        switch (mtype) {
        case 0x35:  // DHCP discover
            // RESPOND WITH OFFER AND PUT PRE-LEASE RECORD
            break;
        case 0x36:  // DHCP request
            // RESPOND WITH ACK AND PUT LEASE RECORD
            break;
        default:
            break;
      }
   }
}

// Forward packets from Ethernet to Wi-Fi
// Note that, Ethernet works faster than Wi-Fi on ESP32,
// so we need to add an extra queue to balance their speed difference.
static esp_err_t pkt_eth2wifi(esp_eth_handle_t eth_handle, uint8_t *buffer, uint32_t len, void* priv)
{
    esp_err_t ret = ESP_OK;
    flow_control_msg_t msg = {
        .packet = buffer,
        .length = len
    };

    // check if DHCP
    if (dhcp_processor(&msg)) {
        return ESP_OK;
    }

    if (xQueueSend(flow_control_queue, &msg, pdMS_TO_TICKS(FLOW_CONTROL_QUEUE_TIMEOUT_MS)) != pdTRUE) {
        ESP_LOGE(TAG, "send flow control message failed or timeout");
        free(buffer);
        ret = ESP_FAIL;
    }
    return ret;
}

freakyxue · 2020-08-17T07:41:32Z

hi @romatetemadze
I have a question:

Eth and WiFi will get the address through the DHCP request. Why do you need to get the address through the DHCP bridge.

At present, IP address is obtained by bridge, but IDF has not achieved this way.

romatetemadze · 2020-08-17T12:15:41Z

hi @romatetemadze
I have a question:

Eth and WiFi will get the address through the DHCP request. Why do you need to get the address through the DHCP bridge.

At present, IP address is obtained by bridge, but IDF has not achieved this way.

Hello,

The point is that in my setup neither side is running any DHCP, means clients end up with no IP. I would live with that, but Android is unable to join WIFI AP if IP is not provided.

I actually wrote a workaround that catches DHCP option 53 and provides IP/Route to either side, so I guess its good enough.

However, I believe such scenario may exist in many different cases, when we want to consolidate ETH and WIFI clients by providing them with IP's from esp32.

static void sendDhcp(int dType, uint32_t dTransId) {
    int res = 0;
    uint32_t timeout = 0;
    do {
        vTaskDelay(pdMS_TO_TICKS(timeout));
        timeout += 2;
        switch (dType) {
			case 2:	//offer

				// set Transaction ID for the offer
				dhcpOffer[61]	= lastDhpIp;
				dhcpOffer[46] 	= dTransId >> 24;
				dhcpOffer[47] 	= dTransId >> 16;
				dhcpOffer[48] 	= dTransId >> 8;
				dhcpOffer[49] 	= dTransId;

				// set response MAC
				for (int i=0;i<6;i++) {
					dhcpOffer[70+i] = lastDhpReqMac[i];
				}

				// set lease time
				dhcpOffer[295] = 0xFF;
				dhcpOffer[296] = 0xFF;

				res = esp_wifi_internal_tx(ESP_IF_WIFI_AP, dhcpOffer, sizeof(dhcpOffer));
				lastDhpIp++;
				break;
			case 5: //ack

				// set ACK to the requested IP
				dhcpAck[61]		= lastReqIp;

				// set Transaction ID for the offer
				dhcpAck[46] 	= dTransId >> 24;
				dhcpAck[47] 	= dTransId >> 16;
				dhcpAck[48] 	= dTransId >> 8;
				dhcpAck[49] 	= dTransId;

				// set response MAC
				for (int i=0;i<6;i++) {
					dhcpAck[70+i] = lastDhpReqMac[i];
				}

				// set lease time
				dhcpOffer[295] = 0xFF;
				dhcpOffer[296] = 0xFF;

				res = esp_wifi_internal_tx(ESP_IF_WIFI_AP, dhcpAck, sizeof(dhcpOffer));
				break;
			default:
				break;
        }

    } while (res && timeout < FLOW_CONTROL_WIFI_SEND_TIMEOUT_MS);
    if (res != ESP_OK) {
        ESP_LOGE(TAG, "WiFi send packet failed: %d", res);
    } else {
    	ESP_LOGI(TAG, "DHCP Sent DHCP type %i", dType);
    }
}

And then, on wifi receive, I am checking if its DHCP and responding back if yes. Otherwise, bridging to ETH:

// Forward packets from Wi-Fi to Ethernet, and handle DHCP.
static esp_err_t pkt_wifi2eth(void *buffer, uint16_t len, void *eb)
{
	if (len>281
			&& ((uint8_t *)buffer)[278]==0x63
			&& ((uint8_t *)buffer)[279]==0x82
			&& ((uint8_t *)buffer)[280]==0x53
			&& ((uint8_t *)buffer)[281]==0x63
		)
	{
		uint8_t type= ((uint8_t *)buffer)[282];

		if (type==0x35) {
			ESP_LOG_BUFFER_HEXDUMP("wifi2ETH", buffer, len, ESP_LOG_INFO);
			uint8_t subType= ((uint8_t *)buffer)[284];
			uint32_t transId=0;
			ESP_LOGI(TAG, "DHCP Traffic Detected");
			switch (subType) {
				case 0x01:  // Discover
					transId=((uint8_t *)buffer)[46] << 24 | ((uint8_t *)buffer)[47] << 16 | ((uint8_t *)buffer)[48] << 8 | ((uint8_t *)buffer)[49];
					for (int i=0;i<6;i++) {
						lastDhpReqMac[i] = ((uint8_t *)buffer)[70+i];
					}
					// Sending Offer
					sendDhcp(2, transId);
					ESP_LOGI(TAG, "DHCP Discover Detected from %02X%02X%02X%02X%02X%02X, TxID: %X. Offering IP: %i", lastDhpReqMac[0], lastDhpReqMac[1],lastDhpReqMac[2],lastDhpReqMac[3],lastDhpReqMac[4],lastDhpReqMac[5],transId, lastDhpIp);
					break;
				case 0x02:  // Offer
					ESP_LOGI(TAG, "DHCP Offer Detected");
					break;
				case 0x03:  // Request
					transId=((uint8_t *)buffer)[46] << 24 | ((uint8_t *)buffer)[47] << 16 | ((uint8_t *)buffer)[48] << 8 | ((uint8_t *)buffer)[49];
					lastReqIp=((uint8_t *)buffer)[299];
					ESP_LOGI(TAG, "DHCP Request Detected, TxID: %X. Confirmed IP: %i", transId, lastReqIp);
					sendDhcp(5, transId);
					break;
				case 0x05:  // Ack
					ESP_LOGI(TAG, "DHCP Ack Detected");
					break;
				default:
					break;
			}
		}
	}


    if (s_ethernet_is_connected) {
        if (esp_eth_transmit(s_eth_handle, buffer, len) != ESP_OK) {
            ESP_LOGE(TAG, "Ethernet send packet failed");
        }
    }
    esp_wifi_internal_free_rx_buffer(eb);
    return ESP_OK;
}

Need to do same for ETH inbound.

freakyxue · 2020-08-18T09:34:21Z

hi @romatetemadze
I think you can solve this problem by setting the static IP address. This method of DHCP bridge is not desirable

romatetemadze · 2020-08-18T09:53:06Z

hi @romatetemadze
I think you can solve this problem by setting the static IP address. This method of DHCP bridge is not desirable

Thanks for the response.
The CAR in my scenario does not provide any means to set IP manually.

As I correct solution, I believe this should be done:

Enable Bridge mode as is
Add new virtual esp32 net interface and join it the bridge, so all 3 interfaces are in same MAC space.
Run IP and DHCP on that new interface, so either side will be able to get response from it, and gain IP's as well as get ARP discovery responses about DHCP server IP.

There are many routers that allow doing such setup, which is not for general internet access, but mostly for local interconnection between wired and wireless embed clients.

I don't see why it may not be a desirable mode of operations?

freakyxue · 2020-08-26T07:57:29Z

hi @romatetemadze
I see what you mean. You want to add a virtual network card to IDF for bridge communication, right?
If yes, this is a new feature, but I feel that this feature uses very few scenarios

romatetemadze · 2020-08-27T13:32:37Z

hi @romatetemadze
I see what you mean. You want to add a virtual network card to IDF for bridge communication, right?
If yes, this is a new feature, but I feel that this feature uses very few scenarios

I believe quite of P2P application would be seeking for such solution. Regardless, I'd anyways provide a virtual interface feature, as its will be commonly used in quite of networking setups with interconnecting two different subnets without NAT'ing the traffic, but routing it.

Also, having DHCP standalone would allow interface to be brought down/up without having to restart the DHCP service, which could find some use too.

Would you suggest me to open a new feature request while closing this one? Re-reading the subject of this issue, I believe it does say what some applications are looking for - DHCP for interconnecting wired and wireless clients, I'd say it's somewhat

TCPIP network for mix of wired and wireless clients with common services (HTTP Server, DHCP, DNS, etc)

Sounds like a valuable feature, there are no SOC's which can provide it, and many standalone industrial provisioning servers could be built on ESP32 (there's still STA interface for centralized control or uplink provision if needed). Big mesh'es are usually providing "local" DHCP helpers to avoid huge broadcast traffic over wireless uplinks.

freakyxue · 2020-10-26T06:47:32Z

hi @romatetemadze
If you set both AP and eth to host mode, I think this problem can be solved. Because the DHCP server is bound to netif, they do not interfere with each other. Both AP's DHCP and eth's DHCP can assign IP addresses to the following nodes

romatetemadze · 2020-12-05T15:37:05Z

Hello folks,

So, any suggestion how to bring a virtual interface with DHCP server into the same bridge as eth/wifi? That definitely has quite of applications.

freakyxue · 2020-12-23T08:27:52Z

hi @romatetemadze
Summarize the above discussion．

　You want to implement a virtual interface between WiFi clients and Ethernet clients．
　A DHCP server is implemented on the virtual network card to assign addresses to WiFi clients and Ethernet clients in one network segment
　Without using NAT function, WiFi client and Ethernet client can transfer data through virtual network port

I think this is a big feature. We will discuss whether to add this function internally.

romatetemadze · 2021-01-19T00:03:50Z

Hello @freakyxue ,

Did any discussion happen on this matter so far? I am unable to fully solve this by intercepting DHCP traffic, as them comes ARP and some other services to make a "fake" interface. Furthermore, I would like to run a socket server on some of interfaces to server an application needs.

Another question for same problem:

Can I assign both, ethernet and wifi clients IP's from same subnet?
If yes, will ESP tcpip stack route the traffic between wifi and ethernet clients with IP_FORWARD enabled?

That would solve my problem in fact.
Thanks in advance,

xueyunfei998 · 2021-05-13T10:02:26Z

hi @romatetemadze
Now I'm doing a double port DHCP,
Esp32 is set to softAP and eth host mode，Eth host mode can assign IP address to Ethernet devices.

Mobile devices can communicate with Ethernet devices by connecting to SoftAP.
I set SoftAP to 4 network segments and eth host to 5 network segments.

After testing, I found that only need to open the IP_FORWARD, TCP UDP communication can be

established between mobile devices and Ethernet devices without opening NAT.

Do you think this plan is suitable for you？

Harvie · 2021-05-22T10:38:49Z

I think that being able to setup bridge between wifi and ethernet in such way that DHCP packets get passed is important in some cases.
Especialy with stuff like 802.3cg Ethernet. These technologies will gain popularity soon. I am currently working on LWIP support for similar (but proprietary) interface and it would make lot of sense to transparently bridge LAN with 802.3cg (and similar) networks including DHCP.
For example if you have critical building automation running in HVAC/boiler rooms and basement corridors, the wifi coverage is often at premium and traditional ethernet setup might be an overkill for such applications. Passive 802.3cg (or similar) network makes lot of sense and ESP32 is powerfull enough to provide cost effective bridge to wired/wireless bridge to this building automation network segment without having to setup routing to other appliances in such buildings.

xueyunfei998 · 2021-05-31T03:39:20Z

hi @Harvie

Now the dual network port function of DHCP has been developed. For example, as mentioned above, different network segments between Ethernet and WiFi can communicate normally.

This feature will be released in version 4.4.

Harvie · 2021-05-31T10:36:08Z

Now the dual network port function of DHCP has been developed.

Not sure why would i need that. I already have DHCP server in my network. So if there is properly implemented bridge on esp32 it will pass DHCP packets through it without need for any DHCP specific code running on ESP32. But it makes sense to run DHCP client on the bridge interface, so ESP32 can acquire dynamic adress from the network.

xueyunfei998 · 2021-05-31T12:26:34Z

hi @Harvie
esp-idf/examples/ethernet/eth2ap/main/ethernet_example_main.c

This example realizes the transmission from eth to AP. You can see if it can meet your needs?

romatetemadze · 2022-01-04T17:27:57Z

hi @Harvie

Now the dual network port function of DHCP has been developed. For example, as mentioned above, different network segments between Ethernet and WiFi can communicate normally.

This feature will be released in version 4.4.

This is awesome. Gotta test it 👍

romatetemadze · 2022-01-06T15:02:44Z

hi @Harvie

Now the dual network port function of DHCP has been developed. For example, as mentioned above, different network segments between Ethernet and WiFi can communicate normally.

This feature will be released in version 4.4.

Could you please point me to a source where I can learn about it? Thanks.

romatetemadze · 2022-01-28T14:52:43Z

hi @romatetemadze Now I'm doing a double port DHCP, Esp32 is set to softAP and eth host mode，Eth host mode can assign IP address to Ethernet devices.

Mobile devices can communicate with Ethernet devices by connecting to SoftAP.

I set SoftAP to 4 network segments and eth host to 5 network segments.
After testing, I found that only need to open the IP_FORWARD, TCP UDP communication can be
established between mobile devices and Ethernet devices without opening NAT.

Do you think this plan is suitable for you？

It sounds like exactly what I need. Can yoi kindly provide an example?

gmdriscoll · 2022-02-10T19:40:14Z

If I am following this thread correctly, would this solution also open up the possibility of allowing an ESP32 to OTA over wifi using another ESP32 running the new "bridge" mode as the internet access point? I have a battery operated wireless mesh esp32 that I am trying to update remotely, but no wifi routers are allowed in the environment. There is another ESP32 processor running the cloud access through hardwired ethernet.

xueyunfei998 · 2022-02-11T03:58:18Z

hi @gmdriscoll

Idf has existing solutions to your needs.

location: esp-idf/examples/ethernet/eth2ap/main/ethernet_example_main.c

The specific scheme is as follows：

gmdriscoll · 2022-02-11T14:16:31Z

@xueyunfei998 - Thank you. Not sure how I missed that.

mickeyl · 2023-05-23T15:41:11Z

I tried configuring the WiFi interface to be the DHCP server and the wired Interface being a DHCP client. In this scenario, the wired interface did not get a DHCP address from the WiFi interface

What is the use case for such setup (running both server and client on single bridge)? i don't think such setup would be possible out of the box even on linux OS. (unless you use some advanced configuration like network namespacing...)

It's the same scenario from the OP. A wired ethernet interface connected via the OBD2 plug into a car. The ESP32 acts as OBD2-adapter, handing out DHCP addresses to both the vehicle (via wired ethernet) and a mobile client connected via WiFi. To both the mobile client and the vehicle, it should look like as if they were connected via a Switch with a DHCP server running "somewhere".

Harvie · 2023-05-23T16:18:06Z

To both the mobile client and the vehicle, it should look like as if they were connected via a Switch with a DHCP server running "somewhere".

But then you only need to run DHCP server on that ESP32 bridge interface, not the DHCP client (that will run on car and phone)

mickeyl · 2023-05-23T16:36:58Z

To both the mobile client and the vehicle, it should look like as if they were connected via a Switch with a DHCP server running "somewhere".

But then you only need to run DHCP server on that ESP32 bridge interface, not the DHCP client (that will run on car and phone)

Yes. That sounds like the best way, if the bridge ethernet would work w/ WiFi yet. Until then I'm afraid the manual forwarder is the only working solution.

kostaond · 2023-06-05T06:30:06Z

You can find the very first "work in progress" version of bridge working with option to bridge WiFi AP at https://github.com/kostaond/esp-idf/tre ... ork/bridge

mickeyl · 2023-06-05T07:14:28Z

@kostaond Excellent. I will test and report. Thanks a lot.

kostaond · 2023-06-20T08:25:11Z

@mickeyl did you have time to test it? If so, do you have any feedback? Thanks.

mickeyl · 2023-06-28T08:58:18Z

@kostaond Sorry for the late response. I have just tested it on an ESP32C6 and it works perfectly:

I (102009) wifi:new:<1,0>, old:<1,1>, ap:<1,1>, sta:<255,255>, prof:1
I (102009) wifi:(trc)phytype:CBW20-LGI, snr:35, maxRate:0, highestRateIdx:1
I (102009) wifi:(trc)rate(L-MCS7, schedIdx:1), ampdu(rate:L-MCS7, schedIdx(1, stop:8)), snr:35, ampduState:wait operational
I (102019) wifi:ifidx:1, rssi:-63, nf:-98, phytype(0x2, CBW20-LGI), phymode(0x3, 11bgn), max_rate:0, he:0
I (102029) wifi:max ampdu length exponent:3(65535 bytes), mmss:6(8 us)
I (102039) wifi:station: 9c:76:0e:68:99:c4 join, AID=1, bgn, 20
W (102209) wifi:<ba-add>idx:4, ifx:1, tid:6, TAHI:0x101c499, TALO:0x680e769c, (ssn:0, win:64, cur_ssn:0), CONF:0xc0006005
I (103259) esp_netif_lwip: DHCP server assigned IP to a client, IP is: 192.168.4.2
I (104229) esp_netif_lwip: DHCP server assigned IP to a client, IP is: 192.168.4.2
I (104929) wifi:station: 9c:76:0e:68:99:c4 leave, AID = 1, bss_flags is 134243, bss:0x4081e724
I (104929) wifi:ifidx:1, rssi:-56, nf:-98, phytype(0x2, CBW20-LGI), phymode(0x3, 11bgn), max_rate:0, he:0
I (104939) wifi:max ampdu length exponent:3(65535 bytes), mmss:6(8 us)
I (104939) wifi:new:<1,0>, old:<1,0>, ap:<1,1>, sta:<255,255>, prof:1
I (104949) wifi:<ba-del>idx:4, tid:6
I (109739) wifi:new:<1,0>, old:<1,0>, ap:<1,1>, sta:<255,255>, prof:1
I (109749) wifi:(trc)phytype:CBW20-LGI, snr:32, maxRate:0, highestRateIdx:1
I (109759) wifi:(trc)rate(L-MCS6, schedIdx:2), ampdu(rate:L-MCS6, schedIdx(2, stop:8)), snr:32, ampduState:wait operational
I (109759) wifi:ifidx:1, rssi:-66, nf:-98, phytype(0x2, CBW20-LGI), phymode(0x3, 11bgn), max_rate:0, he:0
I (109769) wifi:max ampdu length exponent:3(65535 bytes), mmss:6(8 us)
I (109779) wifi:station: 9c:76:0e:68:99:c4 join, AID=1, bgn, 20
W (109799) wifi:<ba-add>idx:4, ifx:1, tid:6, TAHI:0x101c499, TALO:0x680e769c, (ssn:0, win:64, cur_ssn:0), CONF:0xc0006005
I (110919) esp_netif_lwip: DHCP server assigned IP to a client, IP is: 192.168.4.2
I (112549) wifi:[ADDBA]TX addba request, tid:0, dialogtoken:1, bufsize:64, A-MSDU:0(not supported), policy:1(IMR), ssn:0(0x0)
I (112559) wifi:[ADDBA]RX addba response, status:0, tid:0/tb:1(0xa1), bufsize:32, batimeout:0, txa_wnd:32
I (204589) eth_bridge_example: Ethernet (0x4087de84) Link Up
I (204589) eth_bridge_example: Ethernet HW Addr 40:4c:ca:40:1a:0f
I (225909) esp_netif_lwip: DHCP server assigned IP to a client, IP is: 192.168.4.3

I wonder about the multiple outputs for DHCP assigning to 192.168.4.2, since I didn't force reconnecting. But it doesn't seem to interfere with the traffic. I have tested "normal" mixed TCP traffic and iperf3 between 192.168.4.2 (connected via WiFi) and 192.168.4.3 (connected via W5500).

This is just great. I'd love to use this for my current project -- what's the best way to get myself a 5.1 release with these changes included? Thanks a lot!

kostaond · 2023-06-28T10:40:20Z

@mickeyl great to here it works as expected! It will take some time the update gets to official release. Currently the update is in internal review and then you will have to wait for official release. Or you could patch it from master to your branch once the update is reviewed and merged.

Extended LwIP bridge example to support WiFi AP interface and DHCP Server #5697

mickeyl · 2023-08-28T13:08:45Z

@kostaond Is it feasible to perhaps rebase your changes to 5.1.1 release? I'd be happy with an unofficial / unsupported release of the LWIP bridging code.

kostaond · 2023-08-29T06:01:22Z

@mickeyl I think, it should work, cherry pick this commit.

mickeyl · 2023-12-28T11:50:48Z

FWIW, I'm happy to report that this is in 5.2-beta1 and works fine. Thanks again for your work, @kostaond and the whole Espressif team.

kostaond · 2024-01-02T08:30:40Z

FWIW, I'm happy to report that this is in 5.2-beta1 and works fine. Thanks again for your work, @kostaond and the whole Espressif team.

Thank you! It's great to hear it serves you well.

ortegafernando · 2024-02-27T17:18:56Z

Hi, does it source code work with W5500 ? Thanks a lot. I want to create an ethernet AP to expand my own wifi to remote place where I can reach by cable.

mickeyl · 2024-02-27T18:04:50Z

Yes, it works very well. My setup is using a W5500 here as well.

kostaond · 2024-02-27T20:01:09Z

Hi, does it source code work with W5500 ? Thanks a lot. I want to create an ethernet AP to expand my own wifi to remote place where I can reach by cable.

Yes, of course . You can configure it in menuconfig.

mickeyl · 2024-03-11T19:52:08Z

@kostaond The WiFi->ETH bridge still works great and I'm getting good bandwidth, especially considering that the W5500 is an SPI-bottleneck.

I have a related question though.... can I provide a TCP service on the bridge interface by the ESP32S3 in parallel to the bridge functionality? Ideally I would have the bridge working, but still being able to offer a web service via WiFi.

kostaond · 2024-03-12T06:44:31Z

@mickeyl yes, that's possible. You can see that bridge example has IP address assigned to bridge interface from DHCP server. You can even set static address to bridge and make the bridge DHCP server itself.

mickeyl · 2024-03-20T16:32:51Z

@kostaond As the bridge example has a very elaborate setup, I wonder about the proper shutdown sequence. Could you perhaps give some information about how to completely shutdown the ethernet, wifi, bridge + glue?

kostaond · 2024-03-21T07:59:41Z

@mickeyl frankly speaking, I've actually never tried it yet. It's not that usual on embedded systems. However, we observe similar requests more frequent recently. Therefore we gradually updating the examples to provide deinit sequences too. It's not high priority task though...

Feel free to try it by yourself in the meantime ;) The new API should always have delete counterpart. So stop the Ethernet and then delete/deinit the objects in the opposite order of initialization.

Example of Ethernet deint sequence:

esp_eth_driver_uninstall(eth_handle);
phy->del(phy);
mac->del(mac);

romatetemadze added the Type: Feature Request Feature request for IDF label Aug 4, 2020

github-actions bot changed the title ~~DHCP for bridge mode~~ DHCP for bridge mode (IDFGH-3778) Aug 4, 2020

romatetemadze closed this as completed Aug 5, 2020

romatetemadze reopened this Aug 5, 2020

espressif-bot assigned kostaond Jun 8, 2023

espressif-bot added Status: In Progress Work is in progress Status: Reviewing Issue is being reviewed and removed Status: Done Issue is done internally Resolution: Done Issue is done internally Status: In Progress Work is in progress labels Jun 8, 2023

espressif-bot added Status: Done Issue is done internally Resolution: NA Issue resolution is unavailable and removed Status: Reviewing Issue is being reviewed labels Jul 11, 2023

espressif-bot pushed a commit that referenced this issue Jul 14, 2023

feat(network/examples): extended LwIP bridge example

3288f83

Extended LwIP bridge example to support WiFi AP interface and DHCP Server #5697

mickeyl mentioned this issue Mar 21, 2024

Ethernet driver deinitialization (IDFGH-12421) #13443

Open

DHCP for bridge mode (IDFGH-3778) #5697

DHCP for bridge mode (IDFGH-3778) #5697

Comments

romatetemadze commented Aug 4, 2020 • edited Loading

Alvin1Zhang commented Aug 5, 2020

liuzfesp commented Aug 5, 2020

romatetemadze commented Aug 5, 2020 • edited Loading

liuzfesp commented Aug 5, 2020

romatetemadze commented Aug 5, 2020 • edited Loading

freakyxue commented Aug 17, 2020

romatetemadze commented Aug 17, 2020 • edited Loading

freakyxue commented Aug 18, 2020

romatetemadze commented Aug 18, 2020 • edited Loading

freakyxue commented Aug 26, 2020

romatetemadze commented Aug 27, 2020 • edited Loading

freakyxue commented Oct 26, 2020 • edited Loading

romatetemadze commented Dec 5, 2020

freakyxue commented Dec 23, 2020

romatetemadze commented Jan 19, 2021

xueyunfei998 commented May 13, 2021

Harvie commented May 22, 2021

xueyunfei998 commented May 31, 2021

Harvie commented May 31, 2021 • edited Loading

xueyunfei998 commented May 31, 2021 • edited Loading

romatetemadze commented Jan 4, 2022

romatetemadze commented Jan 6, 2022

romatetemadze commented Jan 28, 2022

gmdriscoll commented Feb 10, 2022

xueyunfei998 commented Feb 11, 2022

gmdriscoll commented Feb 11, 2022

mickeyl commented May 23, 2023 • edited Loading

Harvie commented May 23, 2023

mickeyl commented May 23, 2023

kostaond commented Jun 5, 2023

mickeyl commented Jun 5, 2023

kostaond commented Jun 20, 2023

mickeyl commented Jun 28, 2023 • edited Loading

kostaond commented Jun 28, 2023

mickeyl commented Aug 28, 2023

kostaond commented Aug 29, 2023

mickeyl commented Dec 28, 2023

kostaond commented Jan 2, 2024

ortegafernando commented Feb 27, 2024

mickeyl commented Feb 27, 2024

kostaond commented Feb 27, 2024

mickeyl commented Mar 11, 2024

kostaond commented Mar 12, 2024

mickeyl commented Mar 20, 2024

kostaond commented Mar 21, 2024

romatetemadze commented Aug 4, 2020 •

edited

Loading

romatetemadze commented Aug 5, 2020 •

edited

Loading

romatetemadze commented Aug 5, 2020 •

edited

Loading

romatetemadze commented Aug 17, 2020 •

edited

Loading

romatetemadze commented Aug 18, 2020 •

edited

Loading

romatetemadze commented Aug 27, 2020 •

edited

Loading

freakyxue commented Oct 26, 2020 •

edited

Loading

Harvie commented May 31, 2021 •

edited

Loading

xueyunfei998 commented May 31, 2021 •

edited

Loading

mickeyl commented May 23, 2023 •

edited

Loading

mickeyl commented Jun 28, 2023 •

edited

Loading