esp_wifi_repeater
esp_wifi_repeater copied to clipboard
martin-ger
Static client IPs
Am I missing something or the DHCP is not able to assing a static IP address table to specific MAC addresses? I need my clients to have the same IP after every connect.
Try "save dhcp" - this save the current DHCP mapping to flash and uses the same after restart.
Tried that... but my clients connect on and off all the time and the IPs are different every time..
Problem is the clients are smart bulbs... haven't figured out how to get into them to do that...
Are you really sure, that "dhcp save" doesn't work? How many devices do you have? Please connect all devices, type "show stats" - do you see all DHCP mappings? Now type "save dhcp" - restart and type "show stats" - do you see the old DHCP mappings? If so, the devices still get new addresses?
Yes that works until the clients disconnect and re connect... they get totally new IPs I only have 5 clients
How many entries in the DHCP table do you see when you type "show stats"? Only 5 or more?
I see 6... I am 100% sure that the IPs keep on changing after connect/disconnect. I have tried saving dhcp a few times and doesn't do anything to the MAC address/IP address
curious as to how you got the smart bulb to see the hue app. i am running a light on Diyhue throught the repeater and i cant find it on my network. all others work fine
Will get back to you in a few days.. out of country at the moment...
On December 24, 2018 23:39:58 patrol420 [email protected] wrote:
curious as to how you got the smart bulb to see the hue app. i am running a light on Diyhue throught the repeater and i cant find it on my network. all others work fine — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
I am seeing similar behavior. I have 3 ESP8266's with temperature sensors connecting the repeater. When I do a cold start they get an ip-range from 192.168.4.1/3. I think last time I did that was right before Christmas. After a couple of days I checked and everything was still fine.
When I just checked there is one that has IP 192.168.4.3, the others are 192.168.4.70, 192.168.4.80 and 192.168.4.83
I did the save dhcp command in the console.
i need to have a static IP range set aside and the rest needs to be dynamically assigned (DHCP). right now, if the device crashes (ping <nonsense.name> will do it) and restarts, the original IPs of connecting devices are not preserved. the only solution i have is to use static IPs for the devices that need them and hope that other devices won't be given the same, and that this issue will be fixed sometime soon...
The ESP's DHCP server uses addresses from x.x.x.2/24 to x.x.x.128/24. Any higher IP address can be assigned statically without any risc of being reassigned dynamically by DHCP.
I have the same problem. I have a temperature/PM sensor which reboot from time to times and after each reboot its IP address change. I have run "save dhcp" several time but it doesn't assign a fix IP to my sensor.
Any news on this?
I solved this by making sure my esp32s don't connect through a wifi repeater... for some reason the repeater was changing the Mac address and the offense wouldn't recognize it...
On August 26, 2020 10:55:16 a.m. MagTun [email protected] wrote:
I have the same problem. I have a temperature/PM sensor which reboot from time to times and after each reboot its IP address change. I have run "save dhcp" several time but it doesn't assign a fix IP to my sensor. Any news on this? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
Thanks @danieloSD for your answer but unfortunately, I need to use a wifi repeater as I need to extended my wifi (my device is outside). Also I have keep track of the MAC address of my esp8266 and it doesn't change (based on show dhcp and show stats).
I have the same problem than MagTun: I'm using the esp_wifi_repeater to extend the wifi to a sensor. Each time the sensor bugs (which happens quite often) it get disconnected from the esp_wifi_repeater. And when the sensor comes back the esp_wifi_repeater don't recognize it anymore so it gives it another IP.
Try to use "save dhcp" once the sensor is connected, this should save the MAC-IP binding.
Thanks for your reply Martin. I already tried but it doesn't save it. It seems that if I disconnect it for too long (≈2-3h?) it doesn't save it (the user above has the same problem: https://github.com/martin-ger/esp_wifi_repeater/issues/236#issuecomment-680931678)
EDIT: I did not had the last update. I installed it. Then I tried again to stop the sensor during 3h. This time it works. I will let you know if it doesn't work in the future.
@WiliTest, is it working for you?
On my side, it still doesn't work but (I guess, only*) for one of the 2 NodeMCU/sensors that are connected to the NodeMCU wifi repeater.
Just to be clear I have 2 devices (A and B). These "clients" are NodeMCU with temperature/PM sensors. Devices A and B have the same hardware/software. but one device (A) is indoor and the devices (B) is outdoor.
The NodeMCU wifi repeater is indoor, close to devices A. Device B is connected to the NodeMCU wifi repeater because it's too far to get the main wifi router (I also connected device A to the NodeMCU wifi repeater because my router regularly gave it a new IP). After a power cut, device B (usually, but not systematically) gets a new IP. This happens despite using the last version of the NodeMCU wifi repeater and doing the "save dhcp" several times.
(*) I don't remember having to redo the portmap for device A. I'm just sure I did it several times during the last 6 months only for device B. Why? Maybe because device B is more often disconnected (I plug it out). Sometime the power cut only affects only device A (when I plug it out) and sometime both, and sometime it affects also the router and the repeater (during total power cut). It might also/instead be related to duration of the power cut.
@MagTun Apologies, I forgot to update. No, finally it did not work. I still have the same problem you describe.