Tasmota Device does not respond to ARP #7098

marrold · 2019-12-03T13:40:25Z

PROBLEM DESCRIPTION

Periodically my Tasmota Devices stop responding to ARP requests. This looks to have been a historical problem that was recently fixed here but I still have the same behaviour on Tasmota 7.1.1. I don't experience this issue on another device running ESPHome - I'm wondering if a change needs to be made to Tasmota to accommodate this fix?

REQUESTED INFORMATION

Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!

  13:38:42 MQT: tasmota_92E5D5/stat/RESULT = {"NAME":"Teckin SP23","GPIO":[0,255,56,255,0,134,0,0,131,17,132,21,0],"FLAG":0,"BASE":45}
13:38:42 MQT: tasmota_92E5D5/stat/RESULT = {"Module":{"0":"Teckin SP23"}}
13:38:42 MQT: tasmota_92E5D5/stat/RESULT = {"GPIO1":{"0":"None"},"GPIO3":{"0":"None"}}

If using rules, provide the output of this command: Backlog Rule1; Rule2; Rule3:

  Rules output here:

Provide the output of this command: Status 0:

  13:39:08 MQT: tasmota_92E5D5/stat/STATUS = {"Status":{"Module":0,"FriendlyName":["Tasmota Outdoor Xmas Lights"],"Topic":"tasmota_92E5D5","ButtonTopic":"0","Power":0,"PowerOnState":3,"LedState":1,"LedMask":"FFFF","SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":0}}
13:39:08 MQT: tasmota_92E5D5/stat/STATUS1 = {"StatusPRM":{"Baudrate":115200,"GroupTopic":"sonoffs","OtaUrl":"http://thehackbox.org/tasmota/release/tasmota.bin","RestartReason":"Software/System restart","Uptime":"0T00:46:23","StartupUTC":"2019-12-03T12:52:45","Sleep":1,"CfgHolder":4617,"BootCount":25,"SaveCount":135,"SaveAddress":"F9000"}}
13:39:08 MQT: tasmota_92E5D5/stat/STATUS2 = {"StatusFWR":{"Version":"7.1.1(tasmota)","BuildDateTime":"2019-12-01T13:00:09","Boot":4,"Core":"2_6_1","SDK":"2.2.2-dev(38a443e)","Hardware":"ESP8266EX"}}
13:39:08 MQT: tasmota_92E5D5/stat/STATUS3 = {"StatusLOG":{"SerialLog":2,"WebLog":2,"MqttLog":0,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["BETA-2.4Ghz",""],"TelePeriod":300,"Resolution":"558180C0","SetOption":["000A8009","2805C8000100060000005A00000000000000","00000200","00000000"]}}
13:39:08 MQT: tasmota_92E5D5/stat/STATUS4 = {"StatusMEM":{"ProgramSize":562,"Free":440,"Heap":23,"ProgramFlashSize":1024,"FlashSize":1024,"FlashChipId":"144068","FlashMode":3,"Features":["00000809","8FDAE397","043683A0","22B617CD","01001BC0","00007881"],"Drivers":"1,2,3,4,5,6,7,8,9,10,12,16,18,19,20,21,22,24,26,29","Sensors":"1,2,3,4,5,6,7,8,9,10,14,15,17,18,20,22,26,34"}}
13:39:08 MQT: tasmota_92E5D5/stat/STATUS5 = {"StatusNET":{"Hostname":"tasmota_92E5D5-1493","IPAddress":"10.0.130.117","Gateway":"10.0.130.1","Subnetmask":"255.255.255.0","DNSServer":"10.0.130.1","Mac":"BC:DD:C2:92:E5:D5","Webserver":2,"WifiConfig":4}}
13:39:08 MQT: tasmota_92E5D5/stat/STATUS6 = {"StatusMQT":{"MqttHost":"mqtt.lan.marrold.co.uk","MqttPort":1883,"MqttClientMask":"tasmota_%06X","MqttClient":"tasmota_92E5D5","MqttUser":"tasmota","MqttCount":2,"MAX_PACKET_SIZE":1000,"KEEPALIVE":30}}
13:39:08 MQT: tasmota_92E5D5/stat/STATUS7 = {"StatusTIM":{"UTC":"Tue Dec 03 13:39:08 2019","Local":"Tue Dec 03 13:39:08 2019","StartDST":"Sun Mar 31 02:00:00 2019","EndDST":"Sun Oct 27 03:00:00 2019","Timezone":"+00:00","Sunrise":"07:24","Sunset":"15:55"}}
13:39:08 MQT: tasmota_92E5D5/stat/STATUS9 = {"StatusPTH":{"PowerDelta":0,"PowerLow":0,"PowerHigh":0,"VoltageLow":0,"VoltageHigh":0,"CurrentLow":0,"CurrentHigh":0}}
13:39:08 MQT: tasmota_92E5D5/stat/STATUS10 = {"StatusSNS":{"Time":"2019-12-03T13:39:08","ENERGY":{"TotalStartTime":"2019-10-30T21:55:42","Total":0.179,"Yesterday":0.068,"Today":0.034,"Power":0,"ApparentPower":0,"ReactivePower":0,"Factor":0.00,"Voltage":0,"Current":0.000}}}
13:39:08 MQT: tasmota_92E5D5/stat/STATUS11 = {"StatusSTS":{"Time":"2019-12-03T13:39:08","Uptime":"0T00:46:23","UptimeSec":2783,"Heap":23,"SleepMode":"Dynamic","Sleep":1,"LoadAvg":999,"MqttCount":2,"POWER":"OFF","Wifi":{"AP":1,"SSId":"BETA-2.4Ghz","BSSId":"6E:3B:6B:27:B2:F1","Channel":6,"RSSI":74,"LinkCount":2,"Downtime":"0T00:00:11"}}}

Provide the output of the Console log output when you experience your issue; if applicable:
(Please use weblog 4 for more debug information)

  Console output here:

TO REPRODUCE

Connect to Wifi and wait a period of time - the device will stop responding to ARP requests

EXPECTED BEHAVIOUR

The device should always respond to ARP requests

SCREENSHOTS

If applicable, add screenshots to help explain your problem.

ADDITIONAL CONTEXT

Add any other context about the problem here.

(Please, remember to close the issue when the problem has been addressed)

The text was updated successfully, but these errors were encountered:

ascillato · 2019-12-03T14:32:13Z

Please, in the console type sleep 0 and try again for testing.

(Just for reference, original issue comes from esp8266/Arduino#6873)

marrold · 2019-12-03T15:12:01Z

Done, will report back shortly. Thanks

s-hadinger · 2019-12-03T15:28:35Z

@ascillato I'm afraid Sleep 0 will have the opposite effect, leaving little time to the Wifi stack to respond to ARP requests.

@marrold can you also try Sleep 50?

ascillato · 2019-12-03T15:58:01Z

@s-hadinger He is using "SleepMode":"Dynamic","Sleep":1 according to his status 0.

Sleep 0 test was about turning down the adaptive sleep. To see if that improves it. The main loop leaves time for the SDK and it is called sooner on sleep=0.

Anyway, you are totally right about also testing the Tasmota Default: sleep 50

@marrold Please, perform both tests:

Sleep 0

and

Sleep 50

marrold · 2019-12-03T16:28:33Z

Sleep 0 is currently looking good, I get a response to an ARP request every time - but I will need to leave it over night to be sure.

I had the ARP issue with default settings ( Sleep 50 ) so I don't think this will help, but I will try it once the current configuration has been running for 24 hours

Thanks

ascillato · 2019-12-03T16:37:00Z

As this issue is not common, can you describe a bit more your setup? router brand, how many wifi devices are connected to it, etc etc.?

marrold · 2019-12-03T17:05:58Z

Sure. It's a Mikrotik hAP AC and I replicated with a Mikrotik wAP Access Point too. Unfortunately I don't have another vendor to do detailed testing but I had a similar experience at work with Tasmota and Aruba access points.

There's around 8 devices connected to the 2.4Ghz network, and its bridged to my LAN. The device doing the ARP and the Tasmota device are in the same subnet. The configuration is fairly average.

Although the device stops responding to ARP requests, the interaction with Home Assistant continues to function as expected, presumably because it still has an ARP entry.

ascillato · 2019-12-03T17:07:55Z

Looking at ESPHome's code, seems that it is using sleep 0 by default. So, that correlates with your observation of sleep 0 of Tasmota and your other device with ESPHome.

https://github.com/esphome/esphome/blob/0f406c38ebe0c5c2e00bba412082c8a589101265/esphome/components/wifi/wifi_component_esp8266.cpp#L61-L76 :

bool WiFiComponent::wifi_apply_power_save_() {
  sleep_type_t power_save;
  switch (this->power_save_) {
    case WIFI_POWER_SAVE_LIGHT:
      power_save = LIGHT_SLEEP_T;
      break;
    case WIFI_POWER_SAVE_HIGH:
      power_save = MODEM_SLEEP_T;
      break;
    case WIFI_POWER_SAVE_NONE:
    default:
      power_save = NONE_SLEEP_T;
      break;
  }
  return wifi_set_sleep_type(power_save);
}

In that case, this ARP issue is an Arduino Core issue that it is shown only when using WIFI SLEEP. The actual default of DTIM is 3 in most routers' default, and that should allow the ESP8266 to be on sleep without having this issue.

So,

Seems that the SDK is not serving the ARP requests when waking up from WIFI SLEEP?
Or, that the router is not respecting the DTIM time for making the request and it is requesting the ARP while the device is sleeping?

Please, can you check your wifi parameters of your router? DTIM, lease time, etc etc.?

There must be something extra there that produces this issue. I have a similar setup as yours and never had an ARP issue with any value of sleep. That is why I suspect of DTIM or other parameter.

From Arduino Core, there is an explanation of DTIM and Sleep at: https://github.com/esp8266/Arduino/blob/2309a1c9cbbcfd1a29a1395ca06ad2af8a0d23d0/libraries/ESP8266WiFi/src/ESP8266WiFiGeneric.cpp#L266-L292

ascillato · 2019-12-03T17:30:05Z

In your STATUS 0 it is shown "LinkCount":2,"Downtime":"0T00:00:11", so your device had wifi disconnections but your RSSI is ok.

Do you have fixed wifi channel at 6?
Do you have too many strong wifi signals nearby?
DTIM value and other wifi parameters?
Lease time ?

marrold · 2019-12-03T18:35:39Z

Unfortunately DTIM is not configurable on my Access Point. Some posts suggests its set to 1.

Do you have fixed wifi channel at 6?
Yes, it's fixed to Channel 6
Do you have too many strong wifi signals nearby?
It is a little congested. 6 is the clearest channel but I am in a block of flats with lots of SSIDs
DTIM value and other wifi parameters?

Export from router:

set [ find default-name=wlan1 ] adaptive-noise-immunity=ap-and-client-mode antenna-gain=3 band=2ghz-g/n bridge-mode=disabled country="united kingdom" disabled=no distance=indoors frequency=2437 \
    frequency-mode=regulatory-domain hw-retries=5 l2mtu=1530 mode=ap-bridge mtu=1530 multicast-helper=disabled name=BETA-2.4Ghz security-profile=BETA-2.4Ghz ssid=BETA-2.4Ghz vlan-id=130 vlan-mode=\
    use-tag wireless-protocol=802.11

Lease time ?
DHCP Lease time is 1 hour

Thanks

ascillato · 2019-12-03T19:26:52Z

Thanks for sharing all that info 👍

After your test with sleep 0, if that goes fine, let's try the following test in order to reduce why it is causing that:

In Tasmota console, please type:

setoption60 1
sleep 50

Thanks.

Setoption60 changes the type of sleep:

Tasmota/tasmota/support_wifi.ino

Lines 153 to 157 in e8a135f

    
           if (sleep && Settings.flag3.sleep_normal) {  // SetOption60 - Enable normal sleep instead of dynamic sleep 
        
             WiFi.setSleepMode(WIFI_LIGHT_SLEEP);       // Allow light sleep during idle times 
        
           } else { 
        
             WiFi.setSleepMode(WIFI_MODEM_SLEEP);       // Disable sleep (Esp8288/Arduino core and sdk default) 
        
           }

marrold · 2019-12-04T07:32:46Z

The devices continued to reply to ARP requests this morning so I can confirm sleep 0 is working.

I've now applied:

setoption60 1
sleep 50

I will report back this evening with the results.

Thanks for your assistance!

marrold · 2019-12-04T19:06:30Z

I'd say its better than before (Dynamic / 1) but still poor. I performed these tests within a few seconds each other and the results were significantly different:

sudo nping --arp-type ARP 10.0.130.117 -c 20
...
Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
Raw packets sent: 20 (840B) | Rcvd: 19 (532B) | Lost: 1 (5.00%)

sudo nping --arp-type ARP 10.0.130.117 -c 20
...
Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
Raw packets sent: 20 (840B) | Rcvd: 9 (252B) | Lost: 11 (55.00%)

Thanks

ascillato · 2019-12-04T19:11:57Z

Ok, So, it is performing good only with sleep 0, any other option have some packets lost right?

marrold · 2019-12-04T19:19:37Z

I have bad performance with:

setoption60 0
sleep > 0

and:

setoption60 1
sleep 50

I have not tried Normal Sleep with 0, should I ?

setoption60 1
sleep 0

ascillato · 2019-12-04T19:20:53Z

yes please, because the type of sleep the ESP8266 do, is controlled by setoption60

Thanks for all these tests 👍

This is the output in my case:

$ sudo nping --arp-type ARP 192.168.1.22 -c 20

Starting Nping 0.6.47 ( http://nmap.org/nping ) at 2019-12-04 16:24 -03
SENT (0.1706s) ARP who has 192.168.1.22? Tell 192.168.1.101
RCVD (0.3497s) ARP reply 192.168.1.22 is at DC:4F:22:76:FA:98
SENT (1.1733s) ARP who has 192.168.1.22? Tell 192.168.1.101
RCVD (1.3997s) ARP reply 192.168.1.22 is at DC:4F:22:76:FA:98
SENT (2.1735s) ARP who has 192.168.1.22? Tell 192.168.1.101
RCVD (2.4497s) ARP reply 192.168.1.22 is at DC:4F:22:76:FA:98
...
...
Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
Raw packets sent: 20 (840B) | Rcvd: 20 (920B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 19.46 seconds

using the defaults: SETOPTION60 0 (Dynamic) and SLEEP 50 on Tasmota 7.1.1 of the precompiled bin.

ascillato · 2019-12-04T19:42:45Z

@andrethomas @arendst @s-hadinger @Jason2866 @mike2nl

I can't reproduce this issue. Any idea why @marrold has this ARP issue if sleep is different than 0 ?

andrethomas · 2019-12-04T19:53:16Z

I can reproduce

Starting Nping 0.7.01 ( https://nmap.org/nping ) at 2019-12-04 21:47
SENT (0.8867s) ARP who has 192.168.42.7? Tell 192.168.44.1
SENT (1.8871s) ARP who has 192.168.42.7? Tell 192.168.44.1
SENT (2.8884s) ARP who has 192.168.42.7? Tell 192.168.44.1
SENT (3.8897s) ARP who has 192.168.42.7? Tell 192.168.44.1
SENT (4.8908s) ARP who has 192.168.42.7? Tell 192.168.44.1
SENT (5.8921s) ARP who has 192.168.42.7? Tell 192.168.44.1
SENT (6.8934s) ARP who has 192.168.42.7? Tell 192.168.44.1
SENT (7.8947s) ARP who has 192.168.42.7? Tell 192.168.44.1
SENT (8.8960s) ARP who has 192.168.42.7? Tell 192.168.44.1
SENT (9.8973s) ARP who has 192.168.42.7? Tell 192.168.44.1
SENT (10.8986s) ARP who has 192.168.42.7? Tell 192.168.44.1
RCVD (11.0690s) ARP reply 192.168.42.7 is at 60:01:94:B2:A1:04
SENT (11.9001s) ARP who has 192.168.42.7? Tell 192.168.44.1

Using Mikrotik AP's with Capsman - This is something I have observed very long ago already but always assumed it was the way Mikrotik is bridging the interfaces to form the Capsman (similar to Unify.)

Either way, it does eventually respond and I've not observed any other side effects such
as wifi or mqtt disconnects from the device side which is why I remained with the theory on ARP propagation with Mikrotik Capsman and not explored it any further.

This theory is further supported by the fact that my development/test wireless network (Using a stand-alone Trendnet wifi AP) does not exhibit this behaviour.

marrold · 2019-12-04T20:30:25Z

Initial tests of setoption60 1 / sleep 0 indicate it's reliably responding to ARP requests.

The response from @andrethomas suggests this could be related to Mikrotik access points. I have tested on 3 different Mikrotik models / chipsets with the same result. I've enabled debug logging but it doesn't appear to reveal any low level information.

My earlier assumption that I had the same issue on Aruba access points was incorrect.

kugelkopf123 · 2019-12-04T20:36:55Z

If the problem with the arp expressed in such a way that it is not possible to open the webgui, then I have this problem for quite a long time. I had the feeling that it improved somewhat with Core 2.6.1. If I cant open the webgui, It helps by pinging the Esp. After a few pings it’s possible to connect to the webgui. I use a fritzbox 7490 and the current dev Build Core 2.6.1.

_{Sent with GitHawk}

andrethomas · 2019-12-04T21:10:41Z

@kugelkopf123 Yes, I also experience that after some time the webui becomes inaccessible but that it recovers from this by pinging the device which eventually responds (usually after 10-20 seconds). I cannot, however, reproduce this on my Trendnet AP - I only experience this on my Mikrotik AP's.

I had this since when we were still running on 2.4.2 - It may also have been there on 2.3.0 but at that time I was still having a few devices so I did maybe just not notice it.

It is not uncommon for different behaviour from the different core versions - This has indeed been seen as other unrelated issues between different core versions working differently with different wireless equipment.

Interesting topic nevertheless.

ascillato2 · 2019-12-04T22:00:53Z

Ok, so, as this ARP issue is related to mikrotik and the source of it is not the Arduino Core neither Tasmota, and as there is a workaround using SLEEP 0 to fast response to ARP requests, we can close this issue.

If someone finds any way in which Tasmota can help on this issue, please, do not hesitate on asking to reopen this issue.

Thanks everyone for helping on this issue and for testing. Very appreciated.

marrold · 2019-12-04T22:05:45Z

the source of it is not the Arduino Core

I don't think we've proven for definite that its not related to Arduino Core - this issue doesn't affect any other WiFi device connected to a Mikrotik AP and appears to be an interoperability issue between the two.

kugelkopf123 · 2019-12-13T13:30:58Z

I guess the mystery is solved, but it would be good to get the Gratuitous ARP change tested as perhaps not everyone will be able to change this setting or have access to the Access Point Config.

Yes,I have a Apple AirportExtreme and a Fritzbox7490 both arent able to set those settings.

TD-er · 2019-12-13T13:46:59Z

I guess the mystery is solved, but it would be good to get the Gratuitous ARP change tested as perhaps not everyone will be able to change this setting or have access to the Access Point Config.

But this does not solve the issue of not able to route any (layer 3?) traffic for a while when you change to another AP.
To me that sounds also a bit as an ARP problem, but it may be unrelated to esp8266/Arduino. (not sure yet)

Jason2866 · 2019-12-13T15:11:39Z

@kugelkopf123 Do you have any Multicast settings?

andrethomas · 2019-12-13T15:30:17Z

@marrold Good stuff getting that from Mikrotik - Made the setting on mine and it works as expected now, Thanks :)

marrold · 2019-12-13T17:22:57Z

@TD-er I think the issue you're referring to when WiFi roaming is a fundamental networking challenge with client / vendor specific work arounds rather than anything Arduino / Mikrotik specific.

@andrethomas Glad it's working. I guess we should document it somewhere?

andrethomas · 2019-12-13T17:44:23Z

@TD-er

But this does not solve the issue of not able to route any (layer 3?) traffic for a while when you change to another AP.

In my case, I changed the settings on the capsman interface and I've tested roaming as well as turning AP's off to force all devices over the one of the AP's and back to another and it seems to handle it just fine.

I am still a bit perplexed on the naming convention Mikrotik used for this since I know I read over that flag originally when trying to find some ARP related setting that could explain the behaviour and dismissed the multicast-helper setting flag on the Mikrotik wireless configuration to perhaps be related to multicast as in the traditional sense of the term and I do not use multicast for anything.

Having said this, I am still not clear how the router/AP is doing anything different because from the perspective of wireshark it looks exactly the same as I found on my Trendnet test AP which shows that the response is not coming from the router at all but is coming from the actual device as intended.

So yes, although this solves it for Mikrotik based systems I am not sure that the naming convention is correct and leads me to another question... what is the naming convention for this on the other AP's we're see'ing reports of this such as fritzbox for example.

Either way, I do not think it relates to proxy-arp.

TD-er · 2019-12-13T18:46:10Z

MikroTik's multicast-helper is converting multicast into unicast.
So what it does is not just broadcast multicast packets once, but addressing them to separate hosts on the wifi network (assuming it is set on the wifi interface in the mikrotik)
So it does cause some overhead, which does take more bandwidth, but it does make sure the packets are received by wireless nodes.

An ARP request is multicast traffic, (N.B. its answer is unicast) so enabling this does help ARP issues.

proxy-arp is something different and it was just something I was wondering about, but as far as I know now, it will cause more harm than good, as we do not route the traffic to another subnet, nor run on separate VLANs.

@marrold

@TD-er I think the issue you're referring to when WiFi roaming is a fundamental networking challenge with client / vendor specific work arounds rather than anything Arduino / Mikrotik specific.

Just to be sure you know.
I am not using Tasmota, but am the developer of ESPEasy, so the way how I do things differ from how it is done in Tasmota.
In ESPEasy the network layer does try a few networks, when some appear to be unstable.
This means it will actively disconnect and reconnect to a different AP. This is not roaming, but just like when you switch AP's on your mobile.
I use event based wifi, so the response to changes is rather quick.
I assume Tasmota does it differently, so a change to another AP may take quite a bit more time meaning the ARP cache in the switches may already have purged the entry of the node that's reconnecting. (typical ARP TTL is 30 seconds)
That's also just about the same time I see that a node may not be able to send or receive traffic. (sometimes even more, but then there may be more switches in between the APs)

andrethomas · 2019-12-13T19:49:22Z

Understand now what you mean by roaming... for me, roaming does not require the client to reconnect to another AP - the handing over of the client device from one AP to another is done by the access point management system on the main Mikrotik router... so in theory, this is completely transparent from a client device's perspective.

Tasmota can behave in a similar way to what you explain and this will still surely cause the same issues stemming from the ARP TTL perspective.

Edit: I do not observe any additional overhead after enabling multicast-helper

TD-er · 2019-12-13T20:05:22Z

Edit: I do not observe any additional overhead after enabling multicast-helper

If you would experience overhead, then it would be noticeable with multiple nodes connected to the same AP (and all interested in this multicast traffic)
The general idea of multicast is to send out the data once and it will be received by many.
When the AP does convert it to unicast, the same (small) packet has to be sent again for any host that wants to receive it and maybe the packet has to be re-sent a number of times if the client does not receive it.
But the number of ARP requests are not really a lot and also the packets are not big.
So the overhead is merely theoretical in a domestic setting.

It may be different if you stream multicast data other than ARP packets. Such traffic will also be affected by this setting.

Jason2866 · 2019-12-13T20:10:22Z

A big use case for mulitcast trafffic is IP-TV. Without it wouldnt work and flood network (s).

andrethomas · 2019-12-13T20:12:59Z

I do not have the Multicast package installed on the Mikrotik - Hence I don't think its related to conventional multicast... which is why I question the naming convention.

Jason2866 · 2019-12-13T20:14:26Z

If mikrotik is really converting all multicast to unicast traffic it is a MESS!
Anyway the naming is bad.

TD-er · 2019-12-13T20:53:34Z

If mikrotik is really converting all multicast to unicast traffic it is a MESS!
Anyway the naming is bad.

It is supposed to change it only on the interface for which you set it.
For example on the WLAN interface, should only translate it to unicast.
And as far as I know, you have to "subscribe" (not the correct term, but cannot remember the correct one) or else it would be broadcast to any port on any switch on your network and that's also not what you want.

Not sure if it is also a limitation on this multicast setting, but I've seen that some options in MikroTik firmware are only available on license level N and up (e.g. level 4 for local-proxy-arp)

marrold · 2019-12-13T21:13:56Z

If mikrotik is really converting all multicast to unicast traffic it is a MESS!

Check the thread linked above. I thought the same but seems the other major vendors are doing it one way or another, TP-Link, Aruba, Ubiquiti to name a few.

Anyway the naming is bad.

Welcome to Mikrotik.

Jason2866 · 2019-12-13T21:23:58Z

Was curious if there is a setting in my Lancom Accesspoints. I think i have no problems
because there is a option called Arp treatment and this option is set default to on.
After a search i found this explanation from Lancom for this option
If a station in the LAN wants to establish a connection to a station in the WLAN that is in energy-saving mode, this often either does not work at all or only with great delays. The reason is that broadcast delivery, e.g. ARP requests to stations located in Powersave cannot be guaranteed by the base station. If you switch on the ARP treatment, the base station answers ARP queries for the stations it has registered with itself and thus more reliably in such cases. Note: As of LCOS version 8.00, this switch activates an analog treatment for IPv6 neighbor solicitations.

marrold · 2019-12-13T21:26:05Z

the base station answers ARP queries for the stations it has registered

That would be nice!

Whilst you're active @Jason2866, I couldn't see any Gratuitous ARPs being sent from your bin with fix applied?

Jason2866 · 2019-12-13T21:28:30Z

@marrold you are right, tbh i dont know why. I must overlook a simple thing.

kugelkopf123 · 2019-12-14T15:00:03Z

@kugelkopf123 Do you have any Multicast settings?

No Nothing. In the Fritbox interface i have the option "optimize for WebTV". I tried that, but it makes no difference.

TD-er · 2019-12-14T15:21:22Z

optimize for WebTV

That sounds like IGMP snooping

andrethomas · 2019-12-14T15:57:31Z

And then, of course, there's always this idea:

https://gist.github.com/SupraJames/779475fefb6dfe7af315a68f03fe63dd

Jason2866 · 2019-12-14T20:26:02Z

@kugelkopf123 Sorry, there is no solution from Tasmota side. That is the reason why this issue is
closed. It is a general problem in a wifi environment where devices are used which are using powersave functions. To solve this the wifi equipment has to take care.
If there is no option (for this) in your Fritzbox the only way to get it solved is to open a ticket at AVM

marrold · 2019-12-24T15:50:26Z

@andrethomas Have you had any problems since enabling multicast-helper ? When it's enabled I seem to have stability issues with all connected clients

andrethomas · 2019-12-24T16:01:11Z

@marrold No issues which I have noticed except on one nodemcu v3 board (https://www.banggood.com/NodeMCU-V3-340G-Lua-WIFI-Module-Integration-Of-ESP8266-Extra-Memory-32M-Flash-p-1175347.html) but that is most likely because of the specific board rather than the wifi setting... this particular device does not like 2.6.1 but runs fine on core 2.4.2 - it has thermal design issues I believe.

And then there's the funny aspect of this particular board - It is powered from the OTG port on an RB2011UiAS-2HnD-IN and resides right next to it on the wall in the corner of the dining room so it is officially the closest to any wifi AP that any of the devices are.

Something I still have not checked is how the wifi setting impacts on the power consumption of the ESP8266 - I suspect it is running a bit hotter than usual but just a guess - still need to find the time to perform further analysis.

marrold changed the title ~~Tasmota Device does not respond to ARP (7.7.1)~~ Tasmota Device does not respond to ARP (7.1.1) Dec 3, 2019

ascillato2 changed the title ~~Tasmota Device does not respond to ARP (7.1.1)~~ Tasmota Device does not respond to ARP Dec 3, 2019

ascillato2 added awaiting feedback Action - Waiting for response or more information help needed Action - Asking for help from the community troubleshooting Type - Troubleshooting workaround Result - The work on the issue has ended with an alternative solution labels Dec 4, 2019

ascillato2 closed this as completed Dec 4, 2019

andrethomas2 added Add to Docs Add info to Docs and removed awaiting feedback Action - Waiting for response or more information help needed Action - Asking for help from the community labels Dec 14, 2019

andrethomas2 closed this as completed Dec 14, 2019

Jason2866 mentioned this issue Feb 26, 2020

Tasmota devices fail to reconnect to network after they are power cycled #7770

Closed

15 tasks

Jason2866 mentioned this issue May 15, 2020

Connection lost after a Time #8439

Closed

13 tasks

ascillato mentioned this issue Nov 20, 2020

Device lag when unable to contact MQTT server #9886

Closed

15 tasks

Tasmota Device does not respond to ARP #7098

Tasmota Device does not respond to ARP #7098

Comments

marrold commented Dec 3, 2019 • edited Loading

PROBLEM DESCRIPTION

REQUESTED INFORMATION

TO REPRODUCE

EXPECTED BEHAVIOUR

SCREENSHOTS

ADDITIONAL CONTEXT

ascillato commented Dec 3, 2019 • edited Loading

marrold commented Dec 3, 2019

s-hadinger commented Dec 3, 2019

ascillato commented Dec 3, 2019 • edited Loading

marrold commented Dec 3, 2019

ascillato commented Dec 3, 2019 • edited Loading

marrold commented Dec 3, 2019

ascillato commented Dec 3, 2019 • edited Loading

ascillato commented Dec 3, 2019 • edited Loading

marrold commented Dec 3, 2019

ascillato commented Dec 3, 2019 • edited Loading

marrold commented Dec 4, 2019

marrold commented Dec 4, 2019

ascillato commented Dec 4, 2019 • edited Loading

marrold commented Dec 4, 2019

ascillato commented Dec 4, 2019 • edited Loading

ascillato commented Dec 4, 2019

andrethomas commented Dec 4, 2019

marrold commented Dec 4, 2019

kugelkopf123 commented Dec 4, 2019

andrethomas commented Dec 4, 2019

ascillato2 commented Dec 4, 2019 • edited Loading

marrold commented Dec 4, 2019

kugelkopf123 commented Dec 13, 2019

TD-er commented Dec 13, 2019

Jason2866 commented Dec 13, 2019

andrethomas commented Dec 13, 2019

marrold commented Dec 13, 2019

andrethomas commented Dec 13, 2019

TD-er commented Dec 13, 2019

andrethomas commented Dec 13, 2019 • edited Loading

TD-er commented Dec 13, 2019

Jason2866 commented Dec 13, 2019

andrethomas commented Dec 13, 2019

Jason2866 commented Dec 13, 2019 • edited Loading

TD-er commented Dec 13, 2019

marrold commented Dec 13, 2019 • edited Loading

Jason2866 commented Dec 13, 2019

marrold commented Dec 13, 2019 • edited Loading

Jason2866 commented Dec 13, 2019

kugelkopf123 commented Dec 14, 2019

TD-er commented Dec 14, 2019

andrethomas commented Dec 14, 2019

Jason2866 commented Dec 14, 2019

marrold commented Dec 24, 2019

andrethomas commented Dec 24, 2019

marrold commented Dec 3, 2019 •

edited

Loading

ascillato commented Dec 3, 2019 •

edited

Loading

ascillato commented Dec 3, 2019 •

edited

Loading

ascillato commented Dec 3, 2019 •

edited

Loading

ascillato commented Dec 3, 2019 •

edited

Loading

ascillato commented Dec 3, 2019 •

edited

Loading

ascillato commented Dec 3, 2019 •

edited

Loading

ascillato commented Dec 4, 2019 •

edited

Loading

ascillato commented Dec 4, 2019 •

edited

Loading

ascillato2 commented Dec 4, 2019 •

edited

Loading

andrethomas commented Dec 13, 2019 •

edited

Loading

Jason2866 commented Dec 13, 2019 •

edited

Loading

marrold commented Dec 13, 2019 •

edited

Loading

marrold commented Dec 13, 2019 •

edited

Loading