Add cypher language

Here is a more or less hacky first version of the cypher language as requested in #1606

Too bad Ivan is no longer online on Github since August 2017.

It is why I downloaded your file.

Hi @languitar !
I am going to back up your highlighter, and you can delete it now.

@marcoscaceres Looks like we have a maintainer for this language. Can you please make a repo and maybe give some initial instructions for @gusbemacbe?

@gusbemacbe sorry for the delay - I've made a repo for you. You should have gotten an invite over email. I'd suggest copying the structure of https://github.com/highlightjs/highlightjs-cshtml-razor

@marcoscaceres !
I have accepted the invite and I have just forked highlightjs-cshtml-razor. Did I do the right thing?

Almost, but don’t fork: just look at the file structure, and copy the README, tests, etc. and modify them for Cypher. The final files should be all unique for Cypher.

Yes, @marcoscaceres !
I have just upgraded it. I am going to enable that repository for Travis CI.

@marcoscaceres , I did not find the repository in the list of repositories at Travis CI.

I’ll take a look, but TravisCI integration should probably be the last thing we do.

@gusbemacbe You all good?  I see your repo in the organization now and you're listed in the list of languages in the readme so I'm going to go ahead and close this PR.
If you have any other questions or issues we're still happy to help!  Just trying to finally process some of these long-lived language PRs.

You all good? I see your repo in the organization now and you're listed in the list of languages in the readme so I'm going to go ahead and close this PR.

@yyyc514, I am sorry for my long absence, I have been very busy for months. An Italian guy broke his two repositories and I had to repair his repositories for 6 months. I forbade him of messing the files. This month I got a new job and made part of a team, and am overcharged with a lot of things.
But today I will check your issues.

@yyyc514, I am sorry for my long absence, I have been very busy for months.

No problem, life and work is busy.  That's how it goes sometimes. :-)

Hi @yyyc514, hi @gusbemacbe,
can I help you somehow with this issue? I am working on a project with some Cypher query examples and having code highlighting for Cypher would be really great.

Hi @obfischer
You can make a PR and we review.

@obfischer If you want cypher support for HLJS the best thing to do is use the 3rd party language grammar that @gusbemacbe linked you to.  It's pretty trivial to do so.

Ok, I wil try it tomorrow. It will be my Sunday excercise.
Am 15.02.20 um 09:03 schrieb Josh Goebel:

@obfischer https://github.com/obfischer If you want |cypher| support
for HLJS the best thing to do is use the 3rd party language grammar
that @gusbemacbe https://github.com/gusbemacbe linked you to. It's
pretty trivial to do so.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/highlightjs/highlight.js/pull/1684?email_source=notifications&email_token=AAFTOLQW4FCYIUGQSLEHFELRC6OV7A5CNFSM4EONLQTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL3ETLI#issuecomment-586566061,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAFTOLVL7JGPEKKNK7XRZ6TRC6OV7ANCNFSM4EONLQTA.

--
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49<PHONE_NUMBER>
E<EMAIL_ADDRESS>S oliver.b.fischer
J<EMAIL_ADDRESS>X http://xing.to/obf

Hi @yyyc514, @gusbemacbe,
would be nice if you could review and  comment on GH-2426.


mail_settings cannot be empty hash

Passing mail_settings: {} causes a crash when sending emails.
The error is caused by the usage of json_parse to parse mail settings. The regex used in json_parse  is confused by blank strings, which is what you get calling mail['mail_settings'].value when mail_settings is empty.
The code I had when discovering this:
  def welcome_email
    user = params[:user]
    mail(
      to: user.email,
      template_id: WELCOME_TEMPLATE_ID,
      dynamic_template_data: { name: user.first_name },
      mail_settings: mail_settings
    )
  end

  private

  def mail_settings
    if Rails.env.production?
      {}
    else
      {
        sandbox_mode: {
          enable: true
        }
      }
    end
  end

I'm changing my code to this workaround for now:
  def mail_settings
    {
      sandbox_mode: {
        enable: !Rails.env.production?
      }
    }
  end

I'm not sure what the intention of the regex in the json_parse method is, so unfortunately I can't attempt a PR at this time.

Hey @thomassnielsen,  Given the gem passes options through Mail, and Mail treats those attributes as strings, json encoding was required.  The json_parse method was intended to enable ruby hash syntax for mail options, in addition to json.  The 'parse_object' context spec tests this functionality with ruby 1.8, 1.9 and json hashes.
Digging in though, it looks like this is actually an issue with Mail and not the regex in 'json_parse'.    It appears that Mail will not accept an empty hash as an attribute and translates it to nil.
 > Mail.new(mail_settings:{})
 => #<Mail::Message:70275845826100, Multipart: false, Headers: <mail-settings: >>

As a result, JSON.parse(nil) fails.
PR #42 modifies json_parse to be able to handle nil options.   Does that address the issue?


2nd quitting clears ram

With this program
"For(I,1,5):Input "F",C:End"
you can clear ram.
Steps:

Add that code to a basic program
Archive that program
Run from cesium
2nd + Quit on the input

Inputs in loops and it being archived seem to be the problem.

Man all the bugs are related to this one :(

I can't reproduce this.

Oh nope I got it hm.

Fixed with 972bdd7e2442ddcf0b10547fa60fb3e525959360 hopefully


GPOS Type 7, format 2: "PosClassRuleSet" would be better name

In the spec for type 7, format 2, there's a table structure currently named "PosClassSet". This contains an array of offsets to "PosClassRule" tables. This is parallel in structure to type 7, format 1, in which the "PosRuleSet" table contains an array of offsets to "PosRule" tables. So, to be consistent in naming and to reflect what the table contains, "PosClassSet" would be better named as "PosClassRuleSet".
If changed as proposed, then the fields "posClassSetCount" and "posClassSetOffsets" in the ContextPosFormat2 table should also be renamed "posClassRuleSetCount" and "posClassRuleSetOffsets".

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 3f748ff4-44a6-6395-e0ce-d249b8c9541b
Version Independent ID: b80d0359-5657-632b-29e8-142c06902001
Content: GPOS — Glyph Positioning Table - Typography
Content Source: typographydocs/opentype/spec/gpos.md
Product: typography
GitHub Login: @PeterCon
Microsoft Alias: PeterCon

Need to take #519 into consideration as well.

Superseded by changes for #519. (Would need to revisit if those changes were not kept.)


printing infix types

@ val f: Int -> String = 5 -> ""
f: psp.std.->[psp.std.Int,psp.std.String] = 5 ->
@

Scala choose a pathologically awful way to print the type Int -> String. That issue goes back forever. You could print them sensibly, with the operator infix.

This will actually be a whole bunch of work. Up till now we're just calling .toString on the type and printing whatever it gives us. There's quite a lot of space to improve if we do things manually (color, multi-line prettyprinting) but of course we'd actually need to write code to do it =/

Yes, it's some work. The real home run would be pluggable type pretty-printing, just like the value printing and for the same reason. I want that type printed as Int -> String, not psp.std.Int -> psp.std.String, but there's no general way to know when and whether to dealias types or omit packages.

Would something like "pick the shortest path from the things in scope to reach the desired type" work? That way if you import things like collection.mutable, then you'd get mutable.Buffer and such.
It could be expensive, but pretty-printing may not be that performance critical...

There are a lot of heuristics one could apply, just like scala does, but it will never be satisfying if there's no way to control it. It's the same reason you have a PPrint trait for values: it matters how things print, but the same thing should print differently in different situations. You have to have more visibility into what's being printed than string concatenation offers if you want to do anything sensible under composition, a part of the type might need to be rendered in red because a configuration says so, they might need to be truncated or abbreviated to fit in a diagram, etc etc etc.

This has been fixed in the latest merge. You can now define an implicit TPrint[T] in order to control how a type is pretty-printed. Naturally, it works recursively like values and will apply to any type being printed, even in a larger compount type, and it can make use of the TPrint[V] for any components of the type T by taking them as implicits.


[Box] No MuiBox property defined in ThemeOptions.overrides (typescript)

can not override MuiBox theme from createMuiTheme in typescrpt, because ThemeOptions.overrides doesn't provide MuiBox

[x] The issue is present in the latest release.
[x] I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯
when we try to add MuiBox property in overrides object for creating new theme, it says :
Object literal may only specify known properties, and 'MuiBox' does not exist in type 'Overrides'
Expected Behavior 🤔
ThemeOptions.overrides type should contain MuiBox property
Steps to Reproduce 🕹

https://www.typescriptlang.org/play?#code/JYWwDg9gTgLgBAbzgYygUwIYzQWQK7AAqAFmiGnAL5wBmUEIcARAAIhZpTAYA2AtAQD0yaGkEBnGAE8eacUwDcAKCVoAHpFgoIAO0lwYpcnAC8KdB3xEjaABQIlcOIMGcocAFxwA8gCMAVmjI8DzA2FC8cOxScLo8MeJgQcA0MQDWOhAA7jpwYPRJsMByADRwGDoAJnAA5FYAQhBqNXCVEHJwmfDqwPrAudJJtd4Abm7AlXKOcA1NnogqTpRKlACUSkA
Steps:

create a theme with createMuiTheme
add overrides property to it
try adding MuiBox to overrides

`npx @material-ui/envinfo`

System:
OS: Linux 5.4 Linux Mint 20.1 (Ulyssa)
Binaries:
Node: 15.14.0 - ~/.nvm/versions/node/v15.14.0/bin/node
Yarn: Not Found
npm: 7.7.6 - ~/.nvm/versions/node/v15.14.0/bin/npm
Browsers:
Chrome: 89.0.4389.114
Firefox: 87.0
npmPackages:
@material-ui/core: ^4.11.0 => 4.11.0
@material-ui/icons: ^4.9.1 => 4.9.1
@material-ui/lab: 4.0.0-alpha.56 => 4.0.0-alpha.56
@material-ui/pickers: ^3.2.10 => 3.2.10
@material-ui/styles: ^4.10.0 => 4.10.0
@material-ui/system:  4.9.14
@material-ui/types:  5.1.0
@material-ui/utils:  4.10.2
@types/react: ^16.9.0 => 16.9.46
react: ^16.13.1 => 16.13.1
react-dom: ^16.13.1 => 16.13.1
styled-components:  5.2.0
typescript: ^3.9.7 => 3.9.7

tsconfig
{
  "compilerOptions": {
    "target": "es5",
    "lib": ["dom", "dom.iterable", "esnext"],
    "allowJs": true,
    "skipLibCheck": true,
    "esModuleInterop": true,
    "allowSyntheticDefaultImports": true,
    "strict": true,
    "noImplicitAny": false,
    "strictFunctionTypes": false,
    "forceConsistentCasingInFileNames": true,
    "module": "esnext",
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "noEmit": true,
    "baseUrl": "src",
    "jsx": "preserve",
    "experimentalDecorators": true
  },
  "include": ["src"],
  "exclude": ["node_modules"]
}

@MohammadArasteh This seems to be on purpose. What's your use case?

there are some components the project which are implemented using Box component, I want add a feature to let the user change the theme of the application, for some reasons I need to change the background color of Box components too

@mnajdova do you know if it's possible with TypeScript to communicate that a key can't be used? I mean so far, it could feel, from a developer's point of view that Box missing is an unintended omission.

@mnajdova do you know if it's possible with TypeScript to communicate that a key can't be used? I mean so far it could feel, from a developer's point of view, that Box missing is an unintended omission.

I don't understand this. With types, we are defining which options are available. I think that is is expected that using something that is not supported by types won't work. Not sure if TypeScript has a special syntax for highlighting that something doesn't exist in types, it seems unintuitive.

Alternatively, do you think that it should be supported?

The main reason why we do not support this, is because of perf. Also, I don't see a valid use-case for it, as ut should replace a simple div supporting system props. Using the experimentalStyled for creating components, automatically allows developers to define styleOverrides for the new component inside the theme. I'd recommend creating a custom Box component and using that one as base for different components, so that it will be intentional that it should support style overrides. I wouldn't like to add this overhead to be the default of the Box component.

The main reason why we do not support this, is because of perf.

I was not aware of the performance opportunity. My main motivation was because it's a foot-gun. It would be like adding padding-top: 2px to all the elements on the page.

Should we close then?

I'd say yes, developers can do it with a custom component.

@mnajdova , how should i migrate my huge app from mui v4 to v5, if i already have overriden CSS (webkit scrollbar) for MuiBox by theme? There is no any way to migrate to the latest version and do not break styles in app.
I believe MuiBox should be available in theme still.
Why was it removed?

@dknadratsenka my bad for not adding the MuiBox-root class on the Box component, we should definitely add it. Would that help your migration. I'd say you could easily move the overrides from the MuiBox to the MuiCssBaseline style overrides inside the theme for example, by using the MuiBox-root class:
https://codesandbox.io/s/nervous-dust-fmbl6?file=/src/App.js

@mnajdova thanks. It would help my migration if you would add this class back.

@dknadratsenka my bad for not adding the MuiBox-root class on the Box component, we should definitely add it. Would that help your migration? I'd say you could easily move the overrides from the MuiBox to the MuiCssBaseline style overrides inside the theme for example, by using the MuiBox-root class:
https://codesandbox.io/s/nervous-dust-fmbl6?file=/src/App.js

This would be GREATLY appreciated, because I am trying to modify the scrollbar and it works for some sections of my Theme on other components, but the box's exclusion has left me not knowing how to apply it.


ESP32: Wifi/Network stack broken after beacon timeout (IDFGH-10357)

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.
v4.3.1
Operating System used.
macOS
How did you build your project?
Command line with idf.py
If you are using Windows, please specify command line type.
None
Development Kit.
Custom Board with ESP32DOWDQ6
Power Supply used.
External 3.3V
What is the expected behavior?
The ESP32 connects to wifi and stays connected normally until it is powered off or a call to esp_wifi_disconnect() is made.
What is the actual behavior?
Randomly our ESP32 lose Wifi connection, it happens in the filed regularly. The ESP32 operates correctly then suddenly two error messages appears :
wifi:m f null
wifi:bcn_timout,ap_probe_send_start

The first message is quite not comprehensible but the second suggests a timeout happened and that the AP did not send a beacon in the correct interval. Normally, the would actively probe the AP five times to "re-enable" the connection. However in this, it is not done and the ESP stays in this state until a reboot is performed.
All network services stop working, no more web server, mdns, udp sockets and aws connection. The network is completely done. At first I thought it could be because of a memory leak but when it happens memory is high (60K left).
The problem is that the issue is rather random and not reproducible. It seems that using the "WIFI_PS_MIN_MODEM" power saving mode and connecting to Ubiquiti appliances trigger the problem more often.
Steps to reproduce.
That's the problem, we cannot reproduce it. We see it happening a lot and it happened yersterday on an ESP32 we were monitoring and we just got the two messages above. It seems to be related to power saving mode and to ubiquiti appliances.
Debug Logs.
No response
More Information.
No response

Same here on an ESP32-S3-MINI-! based board and IDF 5.0.2. Connecting to AWS.
Minor differences: i am using WIFI_PS_MAX_MODEM and auto light sleep enabled.
On my side it occurs ca 10 times during 24 hours irregularly, at least i can not recognize any pattern.

hi, could you please provide a description of the application scenarios? Are there any uses of Bluetooth or other applications besides WiFi connectivity? Insufficient memory can sometimes result in this issue.

In my case Bluetooth is not used, the application does not write to the flash a lot (I read somewhere that this maybe a problem because the chip needs to constantly read the flash to operate).
At the application level the ESP32 is used for multiple things: he has an HTTPD web server, makes broadcast requests on UDP, reads sensors from I2C, controls LEDs, communicates to another appliance through UART, communicates its data to AWS for the main points.
All other functions continue to work properly (except the one based on the network obviously).
As for the memory, I'm tracking free heap. Both with esp_get_free_heap_size() to get the total free heap and with heap_caps_get_per_task_info() to get indication per tasks.
However, memory does not seem to be an issue since it is above 50-60K free in all scenarios.
I'm available to provide more information as needed.

In my case i integrated iot reference repo into my project. That means WiFi provisioning is done via Bluetooth, but i opted to turn Bluetooth off once provisioning is done. Beyond that the board sends MQTT messages, listens to OTA (over MQTT) to AWS, and periodically sends files over FTP to another server. All WiFi relevant task is pinned to core 0 in my case and i can confirm that all tasks/function that are not relevant to networking continue to run.
My ESP32S3 logs sensor data over SPI and I2C into ringbuffers and stores data to SD over SPI.
I am also monitoring memory: the issue occurs even when i have more than 100K free heap. Regarding task stack sizes, all my tasks have more than 1300 bytes free when the issue occurs, so at first glance available memory should be enough.
On top of that i also set stack smashing protection level to strong inside menuconfig, but that does not log anything.
(However when setting that to overall level, then the code does not even compile just like the original iot reference repo i integrated into my code). Not sure however if this might be relevant to the issue.

hi @FnxQT, The current version is a bit outdated. We have made many fixes on a more recent version. Please try updating to version 4.3.3 or higher version.
hi @idea--list,  you have used the BLE, which seems to be another issue. Please open a new issue for that

Hi @Xiehanxin,
I can try a lucky punch by updating to a newer version but since it seems to still be a problem in 5.0.2, I'm not sure about it.
However, I have news. We were able to monitor an ESP again when the problem happened. It seems the problem is not related to the beacon timeout since this time we only received the error log:
wifi: m f null
Could you please inform us on what this message is about ? Since the wifi lib is precompiled it is a bit difficult to debug.
Another is that the ESP32 still thinks it is connected to the access point. esp_wifi_sta_get_ap_info(&ap_info) still returns all the information about the connection. However when checking on the Ubiquiti/Unifi web GUI, the AP thinks the ESP is disconnected.

hi, @FnxQT,  could you please begin a periodic task to print  wifi_statis_dump(0xffff) and upload your log? without being too frequent, just print every minutes

Hello @Xiehanxin,
Sorry for the late reply. I started the system with wifi_statis_dump as you said. Will provide you with logs once the issue is triggered again.

Hello @Xiehanxin,
Do you have any news about the issues ? Were the logs helpful, do you need more ?

hi @FnxQT We are analyzing, and if there is any progress, we will inform you as soon as possible.

Hello @Espressif-liuuuu, thank you for analysing the problem. Here are my responses:

Yes the m f null happened on v4.4.4
There was no log shown such as beacon timeout or wifi disconnect, no indication whatsoever that the wifi is malfunctioning.

I let the system under surveillance run since the 14th of June. I monitored what happened and noticed the following. The issue repeats itself but not in a periodical manner. Since the 14th of June it happened:

14-06 at 4:40pm
15-06 at 11:25am
15-06 at 1:07pm
15-06 at 2:02pm
15-06 at 2:57pm
16-06 at 9:19am
16-06 at 12am
17-06 at 6:01am
19-06 at 9:21am
19-06 at 5:34pm

I found a way to "detect" and restart the wifi stack entirely when the problem happens. I simply open a UDP socket and send broadcast packets on the network. If I cannot send a packet for more than 15min I stop and restart the wifi interface :
int result = sendto(sock, message, strlen(message), 0, (struct sockaddr*)&broadcast_addr, sizeof(broadcast_addr));
            if (result < 0) {
                int error = 0;
                socklen_t len = sizeof (error);
                int retval = getsockopt (sock, SOL_SOCKET, SO_ERROR, &error, &len);

                if (retval != 0) {
                    // there was a problem getting the error code
                    ESP_LOGE(TAG, "error getting socket error code: %s", strerror(retval));
                }

                if (error != 0) {
                    // socket has a non-zero error status
                    ESP_LOGE(TAG, "socket error: %s", strerror(error));
                }

                ESP_LOGE(TAG, "Failed to send message. Error: %d", errno);
                ESP_LOGE(TAG, "Error message: %s", strerror(errno));
                udp_error_cnt++;
if(udp_error_cnt >= 90){
                  ESP_LOGE(TAG, "UDP socket failed for more than 15 minutes, resetting wifi");
                  wl_on_disconnect(WL_EVENT_STA_DISCONN);
                  esp_wifi_disconnect();
                  esp_wifi_stop();
                  esp_wifi_start();
                  vTaskDelay(20000 / portTICK_PERIOD_MS);
                  esp_wifi_connect();
                  udp_error_cnt = 0;
              }

Interestingly, the behaviour after the wifi:m f null error is always the same. For 3 to 4 attempts, UDP packets are sent correctly but then they all fail with :
Errno 12 : Not enough space
Until the wifi interface is completely stopped and restarted. It seems the TX buffer is completely full because the packets cannot be sent due to the wifi interface being in a bad condition.
As for the other question:

I'll try to use a sniffer to give what you want. However, what are you calling open mode ? Do you want that I remove the security of my network or that I monitor it all?
We tried this workaround already with a few clients, we're still waiting for feedback but it seems to improve the situation. However, we need the power-saving option to reduce the heat of the ESP32 at it is needed by our product.
Unfortunately the issue is really not easy to reproduce. We currently have one device in the office that we monitor and that produces the issue more or less frequently. Since we are making a commercial product I unfortunately cannot pass along all the codebase. However, I'll try to create a reduced version with just the wifi stack we use and try to reproduce the problem. This I could give to you.

Let me know if you need anything else in the interval. Thanks.

hi @FnxQT  ,  as for open mode, yes, it means you set the router open, without any password, so that we can analyze the Wi-Fi packet more easily.

Hi @Espressif-liuuuu, @Xiehanxin
I ran Wireshark to check on the monitored system. Unfortunately, there is basically nothing to show as when the error "wifi:m f null" happens then the ESP32 sends nothing more on the network and remains quiet until the entire wifi stack is restarted. After that, the network operations are normal again.
I'm trying to trim down our production code base so that you have an example to try. However since our code is pretty large it takes me a bit of time. In the mean time I can already send you our wifi stack code.
Let me know if I can do anything else to help you. It seems to be related to wifi power saving since it's the only significant change we made in our wifi stack.
wl.zip

Hi @Espressif-liuuuu,
I attached a packet capture to this message. The Wifi stopped working on the 21th of June at 09:05am until 09:21am. After 15 minutes of not being able to send UDP packets, wifi interface was reset. I also join the corresponding log from the ESP directly. The IP of the system under surveillance is <IP_ADDRESS>. The ESP log begins a bit earlier with the previous wifi:m f null error so that you see the evolution.
No we do not use AP + STA mode simultaneously. We use AP mode only during provisioning. However, in the case of the system under surveillance, AP mode is never enabled. It's only in STA mode.
wifi_cap_and_logs.zip
I updated the system under surveillance with your libs thanks. However, I do not seem to notice a different output from wifi_statis_dump, is it normal ? I will send the associated logs and packet capture once the problem has been triggered again.
wifi_cap_and_logs.zip

Hi @Espressif-liuuuu, @Xiehanxin,
The issue was triggered using the debug libs you provided and new debug information was out.
The wifi:m f null happened two times, first on 22-06 at 12:03PM and second at 2:17PM.
Thank you for your help.
Archive.zip

hi @FnxQT , there was a festival days before so sorry for the late reply
I saw captured packet and it seems to be an ethernet one, and the wireless one would be helpful  :)
And I think I have found the reason for this issue, which is a mistake for Wi-Fi power-save state machine when handling the failure of allocating nulldata. I have attacthed another lib below and this one shall be able to workaround this issue.
The m f null may still happen, which was beacause of the shortage of memory at that moment, while the blocked packets shall be relieved later since the memory would be recoverd later. If you still find that there is no traffic after m f null for a long time, please feel free to provide us with the packet and log. Thanks!
esp32_76263271.zip

Hello @Espressif-liuuuu, no problem thank you for analysing the issue.
It's strange, I ran Wireshark on my Mac on the wireless interface, not on the ethernet one. I will check if I can do something different.
Ok. I will update the running system with your library tomorrow and check for errors. However there is something strange. The system have about 50K of ram left before the m f null error and about the same amount after. Why is it like that ? Why does the wifi stack sometimes need to allocate a lot more memory ?
Thank you.

Hello @Espressif-liuuuu, no problem thank you for analysing the issue.
It's strange, I ran Wireshark on my Mac on the wireless interface, not on the ethernet one. I will check if I can do something different.
Ok. I will update the running system with your library tomorrow and check for errors. However there is something strange. The system have about 50K of ram left before the m f null error and about the same amount after. Why is it like that ? Why does the wifi stack sometimes need to allocate a lot more memory ?
Thank you.

I guess thats because of the shortage of internal memory. Memory with DMA capability is needed for Wi-Fi TX/RX, you could try esp_get_free_internal_heap_size instead to query left internal RAM.

Hello @Espressif-liuuuu,
Since Monday, the wifi:m f null appeared only once and it has not caused any problem ! 💯 Wifi was still working after and our web interface too. However, I logged the internal DMA capable RAM as you said, and both the amount before and after the wifi:m f null were above 35K free.
Is there something else that could cause the error ?
I will continue monitoring the system and keep you updated. I'm out of office for a week though.

Hello @Espressif-liuuuu,
Since Monday, the wifi:m f null appeared only once and it has not caused any problem ! 100 Wifi was still working after and our web interface too. However, I logged the internal DMA capable RAM as you said, and both the amount before and after the wifi:m f null were above 35K free.
Is there something else that could cause the error ?
I will continue monitoring the system and keep you updated. I'm out of office for a week though.

Yes thats do weird. Could please add a check at the line below when the heap_caps_malloc return null, and log the internal memory by esp_get_free_internal_heap_size? Lets make sure if the memory is sufficient at the moment.
https://github.com/espressif/esp-idf/blob/8b94183c9cb47ede8f02df5598d8b9d68c754860/components/esp_wifi/esp32/esp_adapter.c#L544C4-L544C4

Hey @Espressif-liuuuu, I just returned from days off. Before going, I added the esp_get_free_internal_heap_size print where you told me to.
However, during the previous week, the problem did not trigger again. I will keep you updated.

Hi @Espressif-liuuuu,
The wifi:m f null error triggered again but as expected it did not cause the wifi stack to crash, so it's all okay. I saw in the log that at the moment the wifi tries to allocate internal memory the heap is nearly full, about 564 bytes left. Here is the log :
13-07 06:18:47 E (222535226) WIFI_MD: internal DMA capable free heap: 564
13-07 06:18:47 W (222535226) wifi:m f null
13-07 06:18:47
13-07 06:18:47 time:<PHONE_NUMBER>, pm: 0, cca; 51db4, qblock: 0, txst1: 0, txst2: 0
13-07 06:18:47 [ac 0: sw:0, hw: 16f6d44]
13-07 06:18:47 [ac 1: sw:0, hw: 0]
13-07 06:18:47 [ac 2: sw:0, hw: 22e602c]
13-07 06:18:47 [ac 3: sw:0, hw: 0]
13-07 06:18:47 [ac 4: sw:0, hw: 0]
13-07 06:18:47 === tx st info ===
13-07 06:18:47 ac: 0
13-07 06:18:47 [i: 3, t:<PHONE_NUMBER>, e: 0, s: 2667, b: 3] [i: 4, t:<PHONE_NUMBER>, e: 0, s: 2668, b: 1]
13-07 06:18:47 [i: 5, t:<PHONE_NUMBER>, e: 0, s: 2668, b: 7] [i: 6, t:<PHONE_NUMBER>, e: 0, s: 2527, b: 3] [i: 7, t:<PHONE_NUMBER>, e: 0, s: 2527, b: 3] [i: 8, t:<PHONE_NUMBER>, e: 0, s: 2669, b: 2] [i: 9, t:<PHONE_NUMBER>, e: 0, s: 2670, b: 1]
13-07 06:18:47 [i: 10, t:<PHONE_NUMBER>, e: 0, s: 2528, b: 1] [i: 11, t:<PHONE_NUMBER>, e: 0, s: 2671, b: 3] [i: 12, t:<PHONE_NUMBER>, e: 0, s: 2672, b: 3] [i: 13, t:<PHONE_NUMBER>, e: 0, s: 2529, b: 1] [i: 14, t:<PHONE_NUMBER>, e: 0, s: 2673, b: 0]
13-07 06:18:47 [i: 15, t:<PHONE_NUMBER>, e: 0, s: 2674, b: 2] [i: 16, t:<PHONE_NUMBER>, e: 0, s: 2530, b: 0] [i: 17, t:<PHONE_NUMBER>, e: 0, s: 2675, b: 2] [i: 18, t:<PHONE_NUMBER>, e: 0, s: 2676, b: 0] [i: 19, t:<PHONE_NUMBER>, e: 0, s: 2531, b: 2]
13-07 06:18:47 [i: 20, t:<PHONE_NUMBER>, e: 0, s: 2677, b: 3] [i: 21, t:<PHONE_NUMBER>, e: 0, s: 2678, b: 2] [i: 22, t:<PHONE_NUMBER>, e: 0, s: 2532, b: 0] [i: 23, t:<PHONE_NUMBER>, e: 0, s: 2532, b: 7] [i: 24, t:<PHONE_NUMBER>, e: 0, s: 2532, b: 7]
13-07 06:18:47 [i: 25, t:<PHONE_NUMBER>, e: 0, s: 2532, b: 6] [i: 26, t:<PHONE_NUMBER>, e: 0, s: 2532, b: 4] [i: 27, t:<PHONE_NUMBER>, e: 0, s: 2532, b: 0] [i: 28, t:<PHONE_NUMBER>, e: 0, s: 2532, b: 4] [i: 29, t:<PHONE_NUMBER>, e: 0, s: 2532, b: 4]
13-07 06:18:47 [i: 30, t:<PHONE_NUMBER>, e: 0, s: 2532, b: 3] [i: 31, t:<PHONE_NUMBER>, e: 0, s: 2533, b: 0] [i: 32, t:<PHONE_NUMBER>, e: 0, s: 2679, b: 3] [i: 33, t:<PHONE_NUMBER>, e: 0, s: 2680, b: 0] [i: 34, t:<PHONE_NUMBER>, e: 0, s: 2534, b: 2]
13-07 06:18:47 [i: 35, t:<PHONE_NUMBER>, e: 0, s: 2535, b: 1] [i: 36, t:<PHONE_NUMBER>, e: 0, s: 2681, b: 2] [i: 37, t:<PHONE_NUMBER>, e: 0, s: 2682, b: 2] [i: 38, t:<PHONE_NUMBER>, e: 0, s: 2536, b: 1] [i: 39, t:<PHONE_NUMBER>, e: 0, s: 2537, b: 1]
13-07 06:18:47 [i: 40, t:<PHONE_NUMBER>, e: 0, s: 2683, b: 3] [i: 41, t:<PHONE_NUMBER>, e: 0, s: 2684, b: 1] [i: 42, t:<PHONE_NUMBER>, e: 0, s: 2538, b: 0] [i: 43, t:<PHONE_NUMBER>, e: 0, s: 2538, b: 0] [i: 44, t:<PHONE_NUMBER>, e: 0, s: 2538, b: 5]
13-07 06:18:47 [i: 45, t:<PHONE_NUMBER>, e: 0, s: 2538, b: 5] [i: 46, t:<PHONE_NUMBER>, e: 0, s: 2538, b: 0] [i: 47, t:<PHONE_NUMBER>, e: 0, s: 2539, b: 0] [i: 48, t:<PHONE_NUMBER>, e: 0, s: 2685, b: 2] [i: 49, t:<PHONE_NUMBER>, e: 0, s: 2686, b: 3]
13-07 06:18:47
13-07 06:18:47 [i: 0, t:<PHONE_NUMBER>, e: 0, s: 2540, b: 1] [i: 1, t:<PHONE_NUMBER>, e: 0, s: 2687, b: 2] [i: 2, t:<PHONE_NUMBER>, e: 0, s: 2687, b: 0]
13-07 06:18:47 ac: 1
13-07 06:18:47
13-07 06:18:47
13-07 06:18:47 ac: 2
13-07 06:18:47 [i: 7, t:<PHONE_NUMBER>, e: 0, s: 513, b: 8] [i: 8, t:<PHONE_NUMBER>, e: 0, s: 0, b: 20] [i: 9, t:<PHONE_NUMBER>, e: 0, s: 0, b: 24]
13-07 06:18:47 [i: 10, t:<PHONE_NUMBER>, e: 0, s: 513, b: 14] [i: 11, t:<PHONE_NUMBER>, e: 0, s: 0, b: 15] [i: 12, t:<PHONE_NUMBER>, e: 0, s: 514, b: 11] [i: 13, t: 46409463, e: 0, s: 515, b: 0] [i: 14, t: 46510074, e: 0, s: 516, b: 11]
13-07 06:18:47 [i: 15, t: 46510556, e: 0, s: 0, b: 10] [i: 16, t: 51521867, e: 0, s: 517, b: 5] [i: 17, t: 51522275, e: 0, s: 0, b: 15] [i: 18, t: 51522984, e: 0, s: 0, b: 27] [i: 19, t: 51523804, e: 0, s: 0, b: 54]
13-07 06:18:47 [i: 20, t: 51525475, e: 0, s: 517, b: 7] [i: 21, t: 51525827, e: 0, s: 0, b: 15] [i: 22, t: 51526964, e: 0, s: 517, b: 12] [i: 23, t: 564431845, e: 0, s: 518, b: 12] [i: 24, t: 564432422, e: 0, s: 518, b: 0]
13-07 06:18:47 [i: 25, t: 564435526, e: 0, s: 519, b: 1] [i: 26, t: 564435975, e: 0, s: 0, b: 13] [i: 27, t: 577567321, e: 0, s: 520, b: 6] [i: 28, t: 577606773, e: 0, s: 521, b: 14] [i: 29, t: 577619009, e: 0, s: 522, b: 9]
13-07 06:18:47 [i: 30, t: 577622885, e: 0, s: 523, b: 7] [i: 31, t: 577623443, e: 0, s: 0, b: 27] [i: 32, t: 577624739, e: 0, s: 523, b: 13] [i: 33, t: 646482827, e: 0, s: 524, b: 2] [i: 34, t: 646540708, e: 0, s: 525, b: 13]
13-07 06:18:47 [i: 35, t: 646541274, e: 0, s: 0, b: 12] [i: 36, t: 651596540, e: 0, s: 526, b: 9] [i: 37, t: 651597110, e: 0, s: 0, b: 24] [i: 38, t: 651598509, e: 0, s: 526, b: 10] [i: 39, t:<PHONE_NUMBER>, e: 0, s: 527, b: 9]
13-07 06:18:47 [i: 40, t:<PHONE_NUMBER>, e: 0, s: 528, b: 8] [i: 41, t:<PHONE_NUMBER>, e: 0, s: 0, b: 14] [i: 42, t:<PHONE_NUMBER>, e: 0, s: 529, b: 0] [i: 43, t:<PHONE_NUMBER>, e: 0, s: 530, b: 4] [i: 44, t:<PHONE_NUMBER>, e: 0, s: 0, b: 5]
13-07 06:18:47 [i: 45, t:<PHONE_NUMBER>, e: 0, s: 531, b: 9] [i: 46, t:<PHONE_NUMBER>, e: 0, s: 532, b: 3] [i: 47, t:<PHONE_NUMBER>, e: 0, s: 533, b: 5] [i: 48, t:<PHONE_NUMBER>, e: 0, s: 0, b: 6] [i: 49, t:<PHONE_NUMBER>, e: 0, s: 534, b: 13]
13-07 06:18:47
13-07 06:18:47 [i: 0, t:<PHONE_NUMBER>, e: 0, s: 535, b: 4] [i: 1, t:<PHONE_NUMBER>, e: 0, s: 536, b: 15] [i: 2, t:<PHONE_NUMBER>, e: 0, s: 0, b: 15] [i: 3, t:<PHONE_NUMBER>, e: 0, s: 537, b: 7] [i: 4, t:<PHONE_NUMBER>, e: 0, s: 538, b: 5]
13-07 06:18:47 [i: 5, t:<PHONE_NUMBER>, e: 0, s: 0, b: 3] [i: 6, t:<PHONE_NUMBER>, e: 0, s: 539, b: 13]
13-07 06:18:47 ac: 3
13-07 06:18:47
13-07 06:18:47
13-07 06:18:47 ac: 4
13-07 06:18:47
13-07 06:18:47
13-07 06:18:47 === tx end info ===
13-07 06:18:47 ac: 0
13-07 06:18:47 [i: 3, t:<PHONE_NUMBER>, e: 0, s: 2667, p: 1210000, c: 388440] [i: 4, t:<PHONE_NUMBER>, e: 0, s: 2668, p: 7f5300, c: 388440]
13-07 06:18:47 [i: 5, t:<PHONE_NUMBER>, e: 0, s: 2668, p: 1200000, c: 388440] [i: 6, t:<PHONE_NUMBER>, e: 0, s: 2527, p: 7f5300, c: 388440] [i: 7, t:<PHONE_NUMBER>, e: 0, s: 2527, p: 1200000, c: 388440] [i: 8, t:<PHONE_NUMBER>, e: 0, s: 2669, p: 1200000, c: 388440] [i: 9, t:<PHONE_NUMBER>, e: 0, s: 2670, p: 1210000, c: 390340]
13-07 06:18:47 [i: 10, t:<PHONE_NUMBER>, e: 0, s: 2528, p: 1200000, c: 390340] [i: 11, t:<PHONE_NUMBER>, e: 0, s: 2671, p: 1210000, c: 390340] [i: 12, t:<PHONE_NUMBER>, e: 0, s: 2672, p: 1210000, c: 498034] [i: 13, t:<PHONE_NUMBER>, e: 0, s: 2529, p: 1200000, c: 498034] [i: 14, t:<PHONE_NUMBER>, e: 0, s: 2673, p: 1200000, c: 498034]
13-07 06:18:47 [i: 15, t:<PHONE_NUMBER>, e: 0, s: 2674, p: 1210000, c: 498034] [i: 16, t:<PHONE_NUMBER>, e: 0, s: 2530, p: 1200000, c: 498034] [i: 17, t:<PHONE_NUMBER>, e: 0, s: 2675, p: 1200000, c: 486014] [i: 18, t:<PHONE_NUMBER>, e: 0, s: 2676, p: 1210000, c: 486014] [i: 19, t:<PHONE_NUMBER>, e: 0, s: 2531, p: 1200000, c: 486014]
13-07 06:18:47 [i: 20, t:<PHONE_NUMBER>, e: 0, s: 2677, p: 1200000, c: 455356] [i: 21, t:<PHONE_NUMBER>, e: 0, s: 2678, p: 1210000, c: 455356] [i: 22, t:<PHONE_NUMBER>, e: 0, s: 2532, p: 7f5300, c: 455356] [i: 23, t:<PHONE_NUMBER>, e: 0, s: 2532, p: 7f2300, c: 455356] [i: 24, t:<PHONE_NUMBER>, e: 0, s: 2532, p: 7f2300, c: 455356]
13-07 06:18:47 [i: 25, t:<PHONE_NUMBER>, e: 0, s: 2532, p: 7f2300, c: 455356] [i: 26, t:<PHONE_NUMBER>, e: 0, s: 2532, p: 7f2300, c: 455356] [i: 27, t:<PHONE_NUMBER>, e: 0, s: 2532, p: 7f2300, c: 455356] [i: 28, t:<PHONE_NUMBER>, e: 0, s: 2532, p: 7f2300, c: 455356] [i: 29, t:<PHONE_NUMBER>, e: 0, s: 2532, p: 7f2300, c: 455356]
13-07 06:18:47 [i: 30, t:<PHONE_NUMBER>, e: 0, s: 2532, p: 1240000, c: 455356] [i: 31, t:<PHONE_NUMBER>, e: 0, s: 2533, p: 1200000, c: 455356] [i: 32, t:<PHONE_NUMBER>, e: 0, s: 2679, p: 1210000, c: 455356] [i: 33, t:<PHONE_NUMBER>, e: 0, s: 2680, p: 1210000, c: 335284] [i: 34, t:<PHONE_NUMBER>, e: 0, s: 2534, p: 1200000, c: 335284]
13-07 06:18:47 [i: 35, t:<PHONE_NUMBER>, e: 0, s: 2535, p: 1200000, c: 335284] [i: 36, t:<PHONE_NUMBER>, e: 0, s: 2681, p: 1200000, c: 335284] [i: 37, t:<PHONE_NUMBER>, e: 0, s: 2682, p: 1210000, c: 335284] [i: 38, t:<PHONE_NUMBER>, e: 0, s: 2536, p: 1200000, c: 335284] [i: 39, t:<PHONE_NUMBER>, e: 0, s: 2537, p: 1200000, c: 335284]
13-07 06:18:47 [i: 40, t:<PHONE_NUMBER>, e: 0, s: 2683, p: 1210000, c: 335284] [i: 41, t:<PHONE_NUMBER>, e: 0, s: 2684, p: 1210000, c: 335284] [i: 42, t:<PHONE_NUMBER>, e: 0, s: 2538, p: 7f5300, c: 335284] [i: 43, t:<PHONE_NUMBER>, e: 0, s: 2538, p: 7f2300, c: 335284] [i: 44, t:<PHONE_NUMBER>, e: 0, s: 2538, p: 7f2300, c: 335284]
13-07 06:18:47 [i: 45, t:<PHONE_NUMBER>, e: 0, s: 2538, p: 7f2300, c: 335284] [i: 46, t:<PHONE_NUMBER>, e: 0, s: 2538, p: 1200000, c: 335284] [i: 47, t:<PHONE_NUMBER>, e: 0, s: 2539, p: 1200000, c: 335284] [i: 48, t:<PHONE_NUMBER>, e: 0, s: 2685, p: 1200000, c: 335284] [i: 49, t:<PHONE_NUMBER>, e: 0, s: 2686, p: 1200000, c: 335284]
13-07 06:18:47
13-07 06:18:47 [i: 0, t:<PHONE_NUMBER>, e: 0, s: 2540, p: 1200000, c: 335284] [i: 1, t:<PHONE_NUMBER>, e: 0, s: 2687, p: 7f5300, c: 335284] [i: 2, t:<PHONE_NUMBER>, e: 0, s: 2687, p: 1200000, c: 335284]
13-07 06:18:47 ac: 1
13-07 06:18:47
13-07 06:18:47
13-07 06:18:47 ac: 2
13-07 06:18:47 [i: 7, t:<PHONE_NUMBER>, e: 0, s: 513, p: 7f5300, c: 700764] [i: 8, t:<PHONE_NUMBER>, e: 0, s: 0, p: 7f5300, c: 700764] [i: 9, t:<PHONE_NUMBER>, e: 0, s: 0, p: 1250000, c: 700764]
13-07 06:18:47 [i: 10, t:<PHONE_NUMBER>, e: 0, s: 513, p: 1200000, c: 700764] [i: 11, t:<PHONE_NUMBER>, e: 0, s: 0, p: 1250000, c: 700764] [i: 12, t:<PHONE_NUMBER>, e: 0, s: 514, p: 1200000, c: 373857] [i: 13, t: 46409781, e: 0, s: 515, p: 1200000, c: 176861] [i: 14, t: 46510345, e: 0, s: 516, p: 1200000, c: 176861]
13-07 06:18:47 [i: 15, t: 46511564, e: 0, s: 0, p: 1260000, c: 176861] [i: 16, t: 51522114, e: 0, s: 517, p: 7f5300, c: 858913] [i: 17, t: 51522934, e: 0, s: 0, p: 7f5300, c: 858913] [i: 18, t: 51523732, e: 0, s: 0, p: 7f5300, c: 858913] [i: 19, t: 51525204, e: 0, s: 0, p: 1260000, c: 858913]
13-07 06:18:47 [i: 20, t: 51525723, e: 0, s: 517, p: 7f5300, c: 858913] [i: 21, t: 51526871, e: 0, s: 0, p: 1250000, c: 858913] [i: 22, t: 51527335, e: 0, s: 517, p: 1200000, c: 858913] [i: 23, t: 564432232, e: 0, s: 518, p: 7f5051, c: 426412] [i: 24, t: 564432747, e: 0, s: 518, p: 1200000, c: 426412]
13-07 06:18:47 [i: 25, t: 564435751, e: 0, s: 519, p: 1200000, c: 426412] [i: 26, t: 564437012, e: 0, s: 0, p: 1260000, c: 426412] [i: 27, t: 577567731, e: 0, s: 520, p: 1200000, c: 715698] [i: 28, t: 577608602, e: 0, s: 521, p: 1200000, c: 715698] [i: 29, t: 577619293, e: 0, s: 522, p: 1200000, c: 715698]
13-07 06:18:47 [i: 30, t: 577623144, e: 0, s: 523, p: 7f5300, c: 715698] [i: 31, t: 577624594, e: 0, s: 0, p: 1260000, c: 715698] [i: 32, t: 577625101, e: 0, s: 523, p: 1200000, c: 715698] [i: 33, t: 646483112, e: 0, s: 524, p: 1200000, c: 433770] [i: 34, t: 646541025, e: 0, s: 525, p: 1200000, c: 356457]
13-07 06:18:47 [i: 35, t: 646542294, e: 0, s: 0, p: 1260000, c: 356457] [i: 36, t: 651596828, e: 0, s: 526, p: 7f5300, c: 356457] [i: 37, t: 651598326, e: 0, s: 0, p: 1260000, c: 356457] [i: 38, t: 651598767, e: 0, s: 526, p: 1200000, c: 356457] [i: 39, t:<PHONE_NUMBER>, e: 0, s: 527, p: 1200000, c: 475494]
13-07 06:18:47 [i: 40, t:<PHONE_NUMBER>, e: 0, s: 528, p: 1200000, c: 475494] [i: 41, t:<PHONE_NUMBER>, e: 0, s: 0, p: 1260000, c: 475494] [i: 42, t:<PHONE_NUMBER>, e: 0, s: 529, p: 1200000, c: 418892] [i: 43, t:<PHONE_NUMBER>, e: 0, s: 530, p: 1200000, c: 418892] [i: 44, t:<PHONE_NUMBER>, e: 0, s: 0, p: 1270000, c: 418892]
13-07 06:18:47 [i: 45, t:<PHONE_NUMBER>, e: 0, s: 531, p: 1200000, c: 418892] [i: 46, t:<PHONE_NUMBER>, e: 0, s: 532, p: 1200000, c: 932667] [i: 47, t:<PHONE_NUMBER>, e: 0, s: 533, p: 1200000, c: 932667] [i: 48, t:<PHONE_NUMBER>, e: 0, s: 0, p: 1260000, c: 932667] [i: 49, t:<PHONE_NUMBER>, e: 0, s: 534, p: 1200000, c: 932667]
13-07 06:18:47
13-07 06:18:47 [i: 0, t:<PHONE_NUMBER>, e: 0, s: 535, p: 1200000, c: 788208] [i: 1, t:<PHONE_NUMBER>, e: 0, s: 536, p: 1200000, c: 788208] [i: 2, t:<PHONE_NUMBER>, e: 0, s: 0, p: 1260000, c: 788208] [i: 3, t:<PHONE_NUMBER>, e: 0, s: 537, p: 1200000, c: 392003] [i: 4, t:<PHONE_NUMBER>, e: 0, s: 538, p: 1200000, c: 392003]
13-07 06:18:47 [i: 5, t:<PHONE_NUMBER>, e: 0, s: 0, p: 1270000, c: 392003] [i: 6, t:<PHONE_NUMBER>, e: 0, s: 539, p: 1200000, c: 392003]
13-07 06:18:47 ac: 3
13-07 06:18:47
13-07 06:18:47
13-07 06:18:47 ac: 4
13-07 06:18:47
13-07 06:18:47
13-07 06:18:47 I (222535341) wifi: BUFFER:
13-07 06:18:47 I (222535342) wifi: t  max alloc total_alloc total_free fail_fc  fail_oom
13-07 06:18:47 I (222535342) wifi: 1  32  1     89136       89097      19       0
13-07 06:18:47 I (222535343) wifi: 2  32  0     14          14         0        0
13-07 06:18:47 I (222535344) wifi: 3  32  0     139924      139922     1        0
13-07 06:18:47 I (222535345) wifi: 4  32  0     0           0          0        0
13-07 06:18:47 I (222535346) wifi: 5  0   0     4           4          0        0
13-07 06:18:47 I (222535346) wifi: 6  0   0     0           0          0        0
13-07 06:18:47 I (222535347) wifi: 7  32  9     2347156     2347103    22       0
13-07 06:18:47 I (222535348) wifi: 8  32  0     2172233     2172233    0        0
13-07 06:18:47 I (222535349) wifi: 9  0   0     0           0          0        0
13-07 06:18:47 I (222535350) wifi:
13-07 06:18:47 I (222535350) wifi: LMAC TX:
13-07 06:18:47 I (222535350) wifi: tx_all   lrc src age to
13-07 06:18:47 I (222535351) wifi: 224398   0   2   0   0
13-07 06:18:47 I (222535351) wifi: 0        0   0   0   0
13-07 06:18:47 I (222535352) wifi: 4636     0   0   0   0
13-07 06:18:47 I (222535352) wifi: 0        0   0   0   0
13-07 06:18:47 I (222535353) wifi: 0        0   0   0   0
13-07 06:18:47 I (222535353) wifi:
13-07 06:18:47 I (222535353) wifi: LMAC RX:
13-07 06:18:47 I (222535354) wifi: ampdu    mdpu     mgmt     ctrl     frag
13-07 06:18:47 I (222535354) wifi:<PHONE_NUMBER>  2222943  0        0
13-07 06:18:47 I (222535355) wifi:
13-07 06:18:47 I (222535355) wifi: HW RX:
13-07 06:18:47 I (222535356) wifi: rx_suc   rx_end   full#1   full#2
13-07 06:18:47 I (222535356) wifi: 45ba1f   165a589  2        0
13-07 06:18:47 I (222535357) wifi:
13-07 06:18:47 I (222535357) wifi: Hardware:
13-07 06:18:47 I (222535357) wifi: rxbufbk  rxcckerr ofdmerr  rx_agc   rxsf     rx_abort rx_fcs   fifofull
13-07 06:18:47 I (222535359) wifi: 1        7a7228   7a7293   0        3170     564725   6014     0
13-07 06:18:47 I (222535360) wifi: afull    rx_oth   tkiperr  samebm   ack_int  rts_int  cts_int  rifs_int
13-07 06:18:47 I (222535361) wifi: 0        411e2a   0        58       36f4c    32b      411a     0
13-07 06:18:47 I (222535362) wifi: blockerr hoperr   txrts    txcts    track    trcts    trigger  txhung   panic
13-07 06:18:47 I (222535363) wifi: 0        0        c166     0        14ea     32b      6d9      0        0
13-07 06:18:47 I (222535364) wifi:
13-07 06:18:47 I (222535364) wifi: DIAG:
13-07 06:18:47 I (222535364) wifi: diag0    diag1    diag2    diag3    diag4    diag5    diag6
13-07 06:18:47 I (222535365) wifi: d00000   0        fa00a07  0        747e8001 830      10
13-07 06:18:47 I (222535366) wifi: diag7    diag8    diag9    diag10   diag12   diagsel
13-07 06:18:47 I (222535367) wifi: 810      0        8ac000   40       0        0
13-07 06:18:47 I (222535368) wifi:
13-07 06:18:47 I (222535368) wifi: Power save:
13-07 06:18:47 I (222535368) wifi: tbtt     beacon   timset   dtimset  tbttdrm  actto    txwake   null1    null0    bcndly   sleep    wake     sleept   waket    totalt   percent
13-07 06:18:47 I (222535370) wifi: 2174589  2171129  1540     1081735  2108523  69717    37779    69601    69694<PHONE_NUMBER>  2168038<PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER> 87.34 %
13-07 06:18:47 I (222535372) wifi:
13-07 06:18:47 I (222535372) wifi: HMAC RX:
13-07 06:18:47 I (222535372) wifi: ifx all      data     ctl    mgmt   bcn/probe
13-07 06:18:47 I (222535373) wifi: sta 4519703  2347112  0      9536   8472
13-07 06:18:47 I (222535374) wifi: ap  0        0        0      0      0
13-07 06:18:47 I (222535375) wifi:
13-07 06:18:47 I (222535375) wifi: ifx auth     assoc    deauth action amsdu
13-07 06:18:47 I (222535375) wifi: sta 1        1        0      38     0
13-07 06:18:47 I (222535376) wifi: ap  0        0        0      0      0
13-07 06:18:47 I (222535377) wifi:
13-07 06:18:47 I (222535377) wifi: HMAC TX:
13-07 06:18:47 I (222535377) wifi: sta_tx   ap_tx    psq_tx psq_mc psq_uc ps_uc1 reorder oos   amsdu
13-07 06:18:47 I (222535378) wifi: 89117    0        0      0      0      0       1
13-07 06:18:48 I (222536134) AP_INFO: Wifi connected
13-07 06:18:48 I (222536139) WIFI_MONITOR: Message sent
13-07 06:18:48 D (222536619) MDS: Query success
13-07 06:18:58 I (222546141) AP_INFO: Wifi connected
13-07 06:18:58 I (222546144) WIFI_MONITOR: Message sent
13-07 06:19:08 I (222556145) AP_INFO: Wifi connected
13-07 06:19:08 I (222556148) WIFI_MONITOR: Message sent
13-07 06:19:12 E (222559793) HEAP_DEBUG:  rtos free heap: 42244
13-07 06:19:12 E (222559793) HEAP_DEBUG: internal DMA capable free heap: 34692
13-07 06:19:12 E (222559793) HEAP_DEBUG: largest free heap block: 12784
13-07 06:19:12 E (222559796) MAIN: number of tasks: 23
13-07 06:19:12 E (222559799) MAIN: Task: Pre-Scheduler allocs -> CAP_8BIT: 6684 CAP_32BIT: 0
13-07 06:19:12 E (222559799) MAIN: Task: esp_timer -> CAP_8BIT: 9436 CAP_32BIT: 0
13-07 06:19:12 E (222559799) MAIN: Task: main -> CAP_8BIT: 122712 CAP_32BIT: 0
13-07 06:19:12 E (222559800) MAIN: Task: tiT -> CAP_8BIT: 4000 CAP_32BIT: 0
13-07 06:19:12 E (222559801) MAIN: Task: bcmd -> CAP_8BIT: 664 CAP_32BIT: 0
13-07 06:19:12 E (222559802) MAIN: Task: wifi -> CAP_8BIT: 22440 CAP_32BIT: 0
13-07 06:19:12 E (222559803) MAIN: Task: uev -> CAP_8BIT: 504 CAP_32BIT: 0
13-07 06:19:12 E (222559803) MAIN: Task: wl -> CAP_8BIT: 12160 CAP_32BIT: 0
13-07 06:19:12 E (222559804) MAIN: Task: sys_evt -> CAP_8BIT: 156 CAP_32BIT: 0
13-07 06:19:12 E (222559805) MAIN: Task: mqc -> CAP_8BIT: 144 CAP_32BIT: 0
13-07 06:19:12 E (222559806) MAIN: Task: wifi_mon -> CAP_8BIT: 768 CAP_32BIT: 0
13-07 06:19:12 E (222559807) MAIN: Task: aws -> CAP_8BIT: 47600 CAP_32BIT: 0
13-07 06:19:12 E (222559807) MAIN: Task: ns -> CAP_8BIT: 1288 CAP_32BIT: 0
13-07 06:19:12 E (222559808) MAIN: Task: httpd -> CAP_8BIT: 4424 CAP_32BIT: 0
13-07 06:19:12 E (222559809) MAIN: Task: mdns -> CAP_8BIT: 176 CAP_32BIT: 0
13-07 06:19:12 E (222559810) MAIN: Task: unknown -> CAP_8BIT: 0 CAP_32BIT: 0
13-07 06:19:12 E (222559811) MAIN: Task: unknown -> CAP_8BIT: 0 CAP_32BIT: 0
13-07 06:19:12 E (222559811) MAIN: Task: out -> CAP_8BIT: 272 CAP_32BIT: 0
13-07 06:19:12 E (222559812) MAIN: Task: unknown -> CAP_8BIT: 0 CAP_32BIT: 0
13-07 06:19:12 E (222559813) MAIN: Task: unknown -> CAP_8BIT: 0 CAP_32BIT: 0
13-07 06:19:12 E (222559814) MAIN: Task: unknown -> CAP_8BIT: 0 CAP_32BIT: 0
13-07 06:19:12 E (222559815) MAIN: Task: unknown -> CAP_8BIT: 0 CAP_32BIT: 0
13-07 06:19:12 E (222559815) MAIN: Task: unknown -> CAP_8BIT: 0 CAP_32BIT: 0
13-07 06:19:12 I (222559816) wifi: BUFFER:
13-07 06:19:12 I (222559817) wifi: t  max alloc total_alloc total_free fail_fc  fail_oom
13-07 06:19:12 I (222559817) wifi: 1  32  0     89148       89110      19       0
13-07 06:19:12 I (222559818) wifi: 2  32  0     14          14         0        0
13-07 06:19:12 I (222559819) wifi: 3  32  0     139946      139944     1        0
13-07 06:19:12 I (222559820) wifi: 4  32  0     0           0          0        0
13-07 06:19:12 I (222559821) wifi: 5  0   0     4           4          0        0
13-07 06:19:12 I (222559821) wifi: 6  0   0     0           0          0        0
13-07 06:19:12 I (222559822) wifi: 7  32  0     2347386     2347330    28       0
13-07 06:19:12 I (222559823) wifi: 8  32  0     2172473     2172473    0        0
13-07 06:19:12 I (222559824) wifi: 9  0   0     0           0          0        0
13-07 06:19:12 I (222559825) wifi:
13-07 06:19:12 I (222559825) wifi: LMAC TX:
13-07 06:19:12 I (222559825) wifi: tx_all   lrc src age to
13-07 06:19:12 I (222559826) wifi: 224432   0   2   0   0
13-07 06:19:12 I (222559826) wifi: 0        0   0   0   0
13-07 06:19:12 I (222559827) wifi: 4636     0   0   0   0
13-07 06:19:12 I (222559827) wifi: 0        0   0   0   0
13-07 06:19:12 I (222559828) wifi: 0        0   0   0   0
13-07 06:19:12 I (222559828) wifi:
13-07 06:19:12 I (222559828) wifi: LMAC RX:
13-07 06:19:12 I (222559829) wifi: ampdu    mdpu     mgmt     ctrl     frag
13-07 06:19:12 I (222559829) wifi:<PHONE_NUMBER>  2223188  0        0
13-07 06:19:12 I (222559830) wifi:
13-07 06:19:12 I (222559830) wifi: HW RX:
13-07 06:19:12 I (222559831) wifi: rx_suc   rx_end   full#1   full#2
13-07 06:19:12 I (222559831) wifi: 45bbea   165acd0  4        0
13-07 06:19:12 I (222559832) wifi:
13-07 06:19:12 I (222559832) wifi: Hardware:
13-07 06:19:12 I (222559832) wifi: rxbufbk  rxcckerr ofdmerr  rx_agc   rxsf     rx_abort rx_fcs   fifofull
13-07 06:19:12 I (222559833) wifi: 1        7a74a0   7a74a9   0        3170     564909   6017     0
13-07 06:19:12 I (222559834) wifi: afull    rx_oth   tkiperr  samebm   ack_int  rts_int  cts_int  rifs_int
13-07 06:19:12 I (222559835) wifi: 0        411f72   0        58       36f6f    32b      411a     0
13-07 06:19:12 I (222559836) wifi: blockerr hoperr   txrts    txcts    track    trcts    trigger  txhung   panic
13-07 06:19:12 I (222559838) wifi: 0        0        c166     0        14ea     32b      6d9      0        0
13-07 06:19:12 I (222559839) wifi:
13-07 06:19:12 I (222559839) wifi: DIAG:
13-07 06:19:12 I (222559839) wifi: diag0    diag1    diag2    diag3    diag4    diag5    diag6
13-07 06:19:12 I (222559840) wifi: d00001   0        fa00000<PHONE_NUMBER>1 3000081b 0
13-07 06:19:12 I (222559841) wifi: diag7    diag8    diag9    diag10   diag12   diagsel
13-07 06:19:12 I (222559842) wifi: 8010     0        8ac000   40       0        0
13-07 06:19:12 I (222559843) wifi:
13-07 06:19:12 I (222559843) wifi: Power save:
13-07 06:19:12 I (222559843) wifi: tbtt     beacon   timset   dtimset  tbttdrm  actto    txwake   null1    null0    bcndly   sleep    wake     sleept   waket    totalt   percent
13-07 06:19:12 I (222559845) wifi: 2174827  2171369  1540     1081840  2108748  69728    37782    69612    69705<PHONE_NUMBER>  2168268<PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER> 87.34 %
13-07 06:19:12 I (222559847) wifi:
13-07 06:19:12 I (222559847) wifi: HMAC RX:
13-07 06:19:12 I (222559847) wifi: ifx all      data     ctl    mgmt   bcn/probe
13-07 06:19:12 I (222559848) wifi: sta 4520161  2347330  0      9776   8712
13-07 06:19:12 I (222559849) wifi: ap  0        0        0      0      0
13-07 06:19:12 I (222559849) wifi:
13-07 06:19:12 I (222559850) wifi: ifx auth     assoc    deauth action amsdu
13-07 06:19:12 I (222559850) wifi: sta 1        1        0      38     0
13-07 06:19:12 I (222559851) wifi: ap  0        0        0      0      0
13-07 06:19:12 I (222559852) wifi:
13-07 06:19:12 I (222559852) wifi: HMAC TX:
13-07 06:19:12 I (222559852) wifi: sta_tx   ap_tx    psq_tx psq_mc psq_uc ps_uc1 reorder oos   amsdu
13-07 06:19:12 I (222559853) wifi: 89129    0        0      0      0      0       1
13-07 06:19:18 I (222566150) AP_INFO: Wifi connected
13-07 06:19:18 I (222566154) WIFI_MONITOR: Message sent
13-07 06:19:28 I (222576155) AP_INFO: Wifi connected
13-07 06:19:28 I (222576159) WIFI_MONITOR: Message sent
13-07 06:19:37 D (222585579) wifi:obss scan is disabled
13-07 06:19:37 D (222585579) wifi:start obss scan: obss scan is stopped
13-07 06:19:38 I (222586160) AP_INFO: Wifi connected
13-07 06:19:38 I (222586163) WIFI_MONITOR: Message sent
13-07 06:19:48 I (222596164) AP_INFO: Wifi connected
13-07 06:19:48 I (222596167) WIFI_MONITOR: Message sent
13-07 06:19:54 D (222601981) MDS: Query for _hue._tcp...
13-07 06:19:58 I (222606168) AP_INFO: Wifi connected
13-07 06:19:58 I (222606173) WIFI_MONITOR: Message sent
13-07 06:19:59 D (222607019) MDS: Query success
13-07 06:20:08 I (222616173) AP_INFO: Wifi connected
13-07 06:20:08 I (222616178) WIFI_MONITOR: Message sent
13-07 06:20:12 E (222620044) HEAP_DEBUG:  rtos free heap: 42404
13-07 06:20:12 E (222620045) HEAP_DEBUG: internal DMA capable free heap: 34852
13-07 06:20:12 E (222620045) HEAP_DEBUG: largest free heap block: 12784
13-07 06:20:12 E (222620047) MAIN: number of tasks: 23
13-07 06:20:12 E (222620051) MAIN: Task: Pre-Scheduler allocs -> CAP_8BIT: 6684 CAP_32BIT: 0
13-07 06:20:12 E (222620052) MAIN: Task: esp_timer -> CAP_8BIT: 9436 CAP_32BIT: 0
13-07 06:20:12 E (222620052) MAIN: Task: main -> CAP_8BIT: 122712 CAP_32BIT: 0
13-07 06:20:12 E (222620054) MAIN: Task: tiT -> CAP_8BIT: 4000 CAP_32BIT: 0
13-07 06:20:12 E (222620056) MAIN: Task: bcmd -> CAP_8BIT: 664 CAP_32BIT: 0
13-07 06:20:12 E (222620056) MAIN: Task: wifi -> CAP_8BIT: 22432 CAP_32BIT: 0
13-07 06:20:12 E (222620057) MAIN: Task: uev -> CAP_8BIT: 504 CAP_32BIT: 0
13-07 06:20:12 E (222620057) MAIN: Task: wl -> CAP_8BIT: 12160 CAP_32BIT: 0
13-07 06:20:12 E (222620058) MAIN: Task: sys_evt -> CAP_8BIT: 156 CAP_32BIT: 0
13-07 06:20:12 E (222620059) MAIN: Task: mqc -> CAP_8BIT: 144 CAP_32BIT: 0
13-07 06:20:12 E (222620060) MAIN: Task: wifi_mon -> CAP_8BIT: 768 CAP_32BIT: 0
13-07 06:20:12 E (222620061) MAIN: Task: aws -> CAP_8BIT: 47460 CAP_32BIT: 0
13-07 06:20:12 E (222620061) MAIN: Task: ns -> CAP_8BIT: 1284 CAP_32BIT: 0
13-07 06:20:12 E (222620062) MAIN: Task: httpd -> CAP_8BIT: 4424 CAP_32BIT: 0
13-07 06:20:12 E (222620063) MAIN: Task: mdns -> CAP_8BIT: 176 CAP_32BIT: 0
13-07 06:20:12 E (222620064) MAIN: Task: unknown -> CAP_8BIT: 0 CAP_32BIT: 0
13-07 06:20:12 E (222620065) MAIN: Task: unknown -> CAP_8BIT: 0 CAP_32BIT: 0
13-07 06:20:12 E (222620065) MAIN: Task: out -> CAP_8BIT: 272 CAP_32BIT: 0
13-07 06:20:12 E (222620066) MAIN: Task: unknown -> CAP_8BIT: 0 CAP_32BIT: 0
13-07 06:20:12 E (222620067) MAIN: Task: unknown -> CAP_8BIT: 0 CAP_32BIT: 0
13-07 06:20:12 E (222620068) MAIN: Task: unknown -> CAP_8BIT: 0 CAP_32BIT: 0
13-07 06:20:12 E (222620069) MAIN: Task: unknown -> CAP_8BIT: 0 CAP_32BIT: 0
13-07 06:20:12 E (222620069) MAIN: Task: unknown -> CAP_8BIT: 0 CAP_32BIT: 0
13-07 06:20:12 I (222620070) wifi: BUFFER:
13-07 06:20:12 I (222620071) wifi: t  max alloc total_alloc total_free fail_fc  fail_oom
13-07 06:20:12 I (222620071) wifi: 1  32  0     89177       89139      19       0
13-07 06:20:12 I (222620072) wifi: 2  32  0     14          14         0        0
13-07 06:20:12 I (222620073) wifi: 3  32  0     139994      139992     1        0
13-07 06:20:12 I (222620074) wifi: 4  32  0     0           0          0        0
13-07 06:20:12 I (222620075) wifi: 5  0   0     4           4          0        0
13-07 06:20:12 I (222620075) wifi: 6  0   0     0           0          0        0
13-07 06:20:12 I (222620076) wifi: 7  32  0     2347989     2347933    28       0
13-07 06:20:12 I (222620077) wifi: 8  32  0     2173062     2173062    0        0
13-07 06:20:12 I (222620078) wifi: 9  0   0     0           0          0        0
13-07 06:20:12 I (222620079) wifi:
13-07 06:20:12 I (222620079) wifi: LMAC TX:
13-07 06:20:12 I (222620079) wifi: tx_all   lrc src age to
13-07 06:20:12 I (222620080) wifi: 224509   0   2   0   0
13-07 06:20:12 I (222620080) wifi: 0        0   0   0   0
13-07 06:20:12 I (222620081) wifi: 4636     0   0   0   0
13-07 06:20:12 I (222620081) wifi: 0        0   0   0   0
13-07 06:20:12 I (222620082) wifi: 0        0   0   0   0
13-07 06:20:12 I (222620082) wifi:
13-07 06:20:12 I (222620082) wifi: LMAC RX:
13-07 06:20:12 I (222620083) wifi: ampdu    mdpu     mgmt     ctrl     frag
13-07 06:20:12 I (222620083) wifi:<PHONE_NUMBER>  2223804  0        0
13-07 06:20:12 I (222620084) wifi:
13-07 06:20:12 I (222620084) wifi: HW RX:
13-07 06:20:12 I (222620085) wifi: rx_suc   rx_end   full#1   full#2
13-07 06:20:12 I (222620085) wifi: 45c0ad   165c432  4        0
13-07 06:20:12 I (222620086) wifi:
13-07 06:20:12 I (222620086) wifi: Hardware:
13-07 06:20:12 I (222620086) wifi: rxbufbk  rxcckerr ofdmerr  rx_agc   rxsf     rx_abort rx_fcs   fifofull
13-07 06:20:12 I (222620087) wifi: 1        7a7aad   7a7ac2   0        3172     564d68   6029     0
13-07 06:20:12 I (222620088) wifi: afull    rx_oth   tkiperr  samebm   ack_int  rts_int  cts_int  rifs_int
13-07 06:20:12 I (222620089) wifi: 0        412208   0        58       36fbc    32b      411f     0
13-07 06:20:12 I (222620090) wifi: blockerr hoperr   txrts    txcts    track    trcts    trigger  txhung   panic
13-07 06:20:12 I (222620092) wifi: 0        0        c17c     0        14eb     32b      6d9      0        0
13-07 06:20:12 I (222620093) wifi:
13-07 06:20:12 I (222620093) wifi: DIAG:
13-07 06:20:12 I (222620093) wifi: diag0    diag1    diag2    diag3    diag4    diag5    diag6
13-07 06:20:12 I (222620094) wifi: d00002   0        fa00000  210      848001   20d00803 0
13-07 06:20:12 I (222620095) wifi: diag7    diag8    diag9    diag10   diag12   diagsel
13-07 06:20:12 I (222620096) wifi: 10       0        8ac000   40       0        0
13-07 06:20:12 I (222620097) wifi:
13-07 06:20:12 I (222620097) wifi: Power save:
13-07 06:20:12 I (222620097) wifi: tbtt     beacon   timset   dtimset  tbttdrm  actto    txwake   null1    null0    bcndly   sleep    wake     sleept   waket    totalt   percent
13-07 06:20:12 I (222620099) wifi: 2175416  2171958  1541     1082132  2109318  69752    37796    69636    69729<PHONE_NUMBER>  2168858<PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER> 87.34 %
13-07 06:20:12 I (222620101) wifi:
13-07 06:20:12 I (222620101) wifi: HMAC RX:
13-07 06:20:12 I (222620101) wifi: ifx all      data     ctl    mgmt   bcn/probe
13-07 06:20:12 I (222620102) wifi: sta 4521353  2347933  0      10365  9301
13-07 06:20:12 I (222620103) wifi: ap  0        0        0      0      0
13-07 06:20:12 I (222620103) wifi:
13-07 06:20:12 I (222620104) wifi: ifx auth     assoc    deauth action amsdu
13-07 06:20:12 I (222620104) wifi: sta 1        1        0      38     0
13-07 06:20:12 I (222620105) wifi: ap  0        0        0      0      0
13-07 06:20:12 I (222620106) wifi:
13-07 06:20:12 I (222620106) wifi: HMAC TX:
13-07 06:20:12 I (222620106) wifi: sta_tx   ap_tx    psq_tx psq_mc psq_uc ps_uc1 reorder oos   amsdu
13-07 06:20:12 I (222620107) wifi: 89158    0        0      0      0      0       1
13-07 06:20:18 I (222626179) AP_INFO: Wifi connected
13-07 06:20:18 I (222626182) WIFI_MONITOR: Message sent
13-07 06:20:28 I (222636185) AP_INFO: Wifi connected
13-07 06:20:28 I (222636188) WIFI_MONITOR: Message sent
13-07 06:20:38 I (222646189) AP_INFO: Wifi connected
13-07 06:20:38 I (222646192) WIFI_MONITOR: Message sent
13-07 06:20:48 I (222656192) AP_INFO: Wifi connected
13-07 06:20:48 I (222656196) WIFI_MONITOR: Message sent
13-07 06:20:58 I (222666197) AP_INFO: Wifi connected
13-07 06:20:58 I (222666202) WIFI_MONITOR: Message sent
13-07 06:21:05 D (222673283) MDS: Query for _sonos._tcp...
13-07 06:21:08 I (222676203) AP_INFO: Wifi connected
13-07 06:21:08 I (222676206) WIFI_MONITOR: Message sent
13-07 06:21:10 D (222678319) MDS: Query success
13-07 06:21:12 E (222680302) HEAP_DEBUG:  rtos free heap: 42252
13-07 06:21:12 E (222680303) HEAP_DEBUG: internal DMA capable free heap: 34700
13-07 06:21:12 E (222680303) HEAP_DEBUG: largest free heap block: 12784
13-07 06:21:12 E (222680305) MAIN: number of tasks: 23
13-07 06:21:12 E (222680308) MAIN: Task: Pre-Scheduler allocs -> CAP_8BIT: 6684 CAP_32BIT: 0
13-07 06:21:12 E (222680309) MAIN: Task: esp_timer -> CAP_8BIT: 9436 CAP_32BIT: 0
13-07 06:21:12 E (222680309) MAIN: Task: main -> CAP_8BIT: 122712 CAP_32BIT: 0
13-07 06:21:12 E (222680310) MAIN: Task: tiT -> CAP_8BIT: 4000 CAP_32BIT: 0
13-07 06:21:12 E (222680311) MAIN: Task: bcmd -> CAP_8BIT: 664 CAP_32BIT: 0
13-07 06:21:12 E (222680312) MAIN: Task: wifi -> CAP_8BIT: 22432 CAP_32BIT: 0
13-07 06:21:12 E (222680312) MAIN: Task: uev -> CAP_8BIT: 504 CAP_32BIT: 0
13-07 06:21:12 E (222680313) MAIN: Task: wl -> CAP_8BIT: 12160 CAP_32BIT: 0
13-07 06:21:12 E (222680314) MAIN: Task: sys_evt -> CAP_8BIT: 156 CAP_32BIT: 0
13-07 06:21:12 E (222680315) MAIN: Task: mqc -> CAP_8BIT: 144 CAP_32BIT: 0
13-07 06:21:12 E (222680315) MAIN: Task: wifi_mon -> CAP_8BIT: 768 CAP_32BIT: 0
13-07 06:21:12 E (222680316) MAIN: Task: aws -> CAP_8BIT: 47600 CAP_32BIT: 0
13-07 06:21:12 E (222680318) MAIN: Task: ns -> CAP_8BIT: 1288 CAP_32BIT: 0
13-07 06:21:12 E (222680318) MAIN: Task: httpd -> CAP_8BIT: 4424 CAP_32BIT: 0
13-07 06:21:12 E (222680319) MAIN: Task: mdns -> CAP_8BIT: 176 CAP_32BIT: 0
13-07 06:21:12 E (222680320) MAIN: Task: unknown -> CAP_8BIT: 0 CAP_32BIT: 0
13-07 06:21:12 E (222680320) MAIN: Task: unknown -> CAP_8BIT: 0 CAP_32BIT: 0
13-07 06:21:12 E (222680321) MAIN: Task: out -> CAP_8BIT: 272 CAP_32BIT: 0
13-07 06:21:12 E (222680322) MAIN: Task: unknown -> CAP_8BIT: 0 CAP_32BIT: 0
13-07 06:21:12 E (222680324) MAIN: Task: unknown -> CAP_8BIT: 0 CAP_32BIT: 0
13-07 06:21:12 E (222680324) MAIN: Task: unknown -> CAP_8BIT: 0 CAP_32BIT: 0
13-07 06:21:12 E (222680325) MAIN: Task: unknown -> CAP_8BIT: 0 CAP_32BIT: 0
13-07 06:21:12 E (222680325) MAIN: Task: unknown -> CAP_8BIT: 0 CAP_32BIT: 0
13-07 06:21:12 I (222680326) wifi: BUFFER:
13-07 06:21:12 I (222680327) wifi: t  max alloc total_alloc total_free fail_fc  fail_oom
13-07 06:21:12 I (222680327) wifi: 1  32  0     89198       89160      19       0
13-07 06:21:12 I (222680328) wifi: 2  32  0     14          14         0        0
13-07 06:21:12 I (222680329) wifi: 3  32  0     140024      140022     1        0
13-07 06:21:12 I (222680330) wifi: 4  32  0     0           0          0        0
13-07 06:21:12 I (222680331) wifi: 5  0   0     4           4          0        0
13-07 06:21:12 I (222680331) wifi: 6  0   0     0           0          0        0
13-07 06:21:12 I (222680332) wifi: 7  32  0     2348456     2348400    28       0
13-07 06:21:12 I (222680333) wifi: 8  32  0     2173651     2173651    0        0
13-07 06:21:12 I (222680334) wifi: 9  0   0     0           0          0        0
13-07 06:21:12 I (222680335) wifi:
13-07 06:21:12 I (222680335) wifi: LMAC TX:
13-07 06:21:12 I (222680335) wifi: tx_all   lrc src age to
13-07 06:21:12 I (222680336) wifi: 224560   0   2   0   0
13-07 06:21:12 I (222680336) wifi: 0        0   0   0   0
13-07 06:21:12 I (222680337) wifi: 4636     0   0   0   0
13-07 06:21:12 I (222680337) wifi: 0        0   0   0   0
13-07 06:21:12 I (222680338) wifi: 0        0   0   0   0
13-07 06:21:12 I (222680338) wifi:
13-07 06:21:12 I (222680338) wifi: LMAC RX:
13-07 06:21:12 I (222680339) wifi: ampdu    mdpu     mgmt     ctrl     frag
13-07 06:21:12 I (222680339) wifi:<PHONE_NUMBER>  2224398  0        0
13-07 06:21:12 I (222680340) wifi:
13-07 06:21:12 I (222680340) wifi: HW RX:
13-07 06:21:12 I (222680341) wifi: rx_suc   rx_end   full#1   full#2
13-07 06:21:12 I (222680341) wifi: 45c4d2   165d2cf  4        0
13-07 06:21:12 I (222680342) wifi:
13-07 06:21:12 I (222680342) wifi: Hardware:
13-07 06:21:12 I (222680343) wifi: rxbufbk  rxcckerr ofdmerr  rx_agc   rxsf     rx_abort rx_fcs   fifofull
13-07 06:21:12 I (222680343) wifi: 1        7a7fa5   7a7fba   0        3172     565002   6031     0
13-07 06:21:12 I (222680344) wifi: afull    rx_oth   tkiperr  samebm   ack_int  rts_int  cts_int  rifs_int
13-07 06:21:12 I (222680345) wifi: 0        412365   0        58       36fef    32b      4121     0
13-07 06:21:12 I (222680346) wifi: blockerr hoperr   txrts    txcts    track    trcts    trigger  txhung   panic
13-07 06:21:12 I (222680348) wifi: 0        0        c17e     0        14eb     32b      6d9      0        0
13-07 06:21:12 I (222680349) wifi:
13-07 06:21:12 I (222680349) wifi: DIAG:
13-07 06:21:12 I (222680349) wifi: diag0    diag1    diag2    diag3    diag4    diag5    diag6
13-07 06:21:12 I (222680350) wifi: d00003   0        fa00000  210      878001   20d00800 0
13-07 06:21:12 I (222680351) wifi: diag7    diag8    diag9    diag10   diag12   diagsel
13-07 06:21:12 I (222680352) wifi: 10       0        8ac000   40       0        0
13-07 06:21:12 I (222680353) wifi:
13-07 06:21:12 I (222680353) wifi: Power save:
13-07 06:21:12 I (222680353) wifi: tbtt     beacon   timset   dtimset  tbttdrm  actto    txwake   null1    null0    bcndly   sleep    wake     sleept   waket    totalt   percent
13-07 06:21:12 I (222680355) wifi: 2176005  2172547  1541     1082381  2109894  69767    37805    69651    69744<PHONE_NUMBER>  2169448<PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER> 87.34 %
13-07 06:21:12 I (222680357) wifi:
13-07 06:21:12 I (222680357) wifi: HMAC RX:
13-07 06:21:12 I (222680357) wifi: ifx all      data     ctl    mgmt   bcn/probe
13-07 06:21:12 I (222680358) wifi: sta 4522409  2348400  0      10954  9890
13-07 06:21:12 I (222680359) wifi: ap  0        0        0      0      0
13-07 06:21:12 I (222680359) wifi:
13-07 06:21:12 I (222680360) wifi: ifx auth     assoc    deauth action amsdu
13-07 06:21:12 I (222680360) wifi: sta 1        1        0      38     0
13-07 06:21:12 I (222680361) wifi: ap  0        0        0      0      0
13-07 06:21:12 I (222680362) wifi:
13-07 06:21:12 I (222680363) wifi: HMAC TX:
13-07 06:21:12 I (222680363) wifi: sta_tx   ap_tx    psq_tx psq_mc psq_uc ps_uc1 reorder oos   amsdu
13-07 06:21:12 I (222680363) wifi: 89179    0        0      0      0      0       1
13-07 06:21:18 I (222686208) AP_INFO: Wifi connected
13-07 06:21:18 I (222686211) WIFI_MONITOR: Message sent
13-07 06:21:28 I (222696212) AP_INFO: Wifi connected
13-07 06:21:28 I (222696215) WIFI_MONITOR: Message sent
13-07 06:21:38 I (222706215) AP_INFO: Wifi connected
13-07 06:21:38 I (222706219) WIFI_MONITOR: Message sent
13-07 06:21:48 I (222716220) AP_INFO: Wifi connected
13-07 06:21:48 I (222716224) WIFI_MONITOR: Message sent
13-07 06:21:58 I (222726225) AP_INFO: Wifi connected
13-07 06:21:58 I (222726228) WIFI_MONITOR: Message sent
13-07 06:22:08 I (222736229) AP_INFO: Wifi connected
13-07 06:22:08 I (222736232) WIFI_MONITOR: Message sent
13-07 06:22:12 E (222740515) HEAP_DEBUG:  rtos free heap: 38932
13-07 06:22:12 D (222740516) MDS: Query for _http._tcp...
13-07 06:22:12 E (222740516) HEAP_DEBUG: internal DMA capable free heap: 31088
13-07 06:22:12 E (222740516) HEAP_DEBUG: largest free heap block: 12784
13-07 06:22:12 E (222740522) MAIN: number of tasks: 23
13-07 06:22:12 E (222740529) MAIN: Task: Pre-Scheduler allocs -> CAP_8BIT: 6684 CAP_32BIT: 0
13-07 06:22:12 E (222740529) MAIN: Task: esp_timer -> CAP_8BIT: 9436 CAP_32BIT: 0
13-07 06:22:12 E (222740530) MAIN: Task: main -> CAP_8BIT: 126172 CAP_32BIT: 0
13-07 06:22:12 E (222740531) MAIN: Task: tiT -> CAP_8BIT: 4000 CAP_32BIT: 0
13-07 06:22:12 E (222740531) MAIN: Task: bcmd -> CAP_8BIT: 664 CAP_32BIT: 0
13-07 06:22:12 E (222740532) MAIN: Task: wifi -> CAP_8BIT: 22432 CAP_32BIT: 0
13-07 06:22:12 E (222740533) MAIN: Task: uev -> CAP_8BIT: 504 CAP_32BIT: 0
13-07 06:22:12 E (222740534) MAIN: Task: wl -> CAP_8BIT: 12160 CAP_32BIT: 0
13-07 06:22:12 E (222740535) MAIN: Task: sys_evt -> CAP_8BIT: 156 CAP_32BIT: 0
13-07 06:22:12 E (222740535) MAIN: Task: mqc -> CAP_8BIT: 144 CAP_32BIT: 0
13-07 06:22:12 E (222740536) MAIN: Task: wifi_mon -> CAP_8BIT: 768 CAP_32BIT: 0
13-07 06:22:12 E (222740537) MAIN: Task: aws -> CAP_8BIT: 47460 CAP_32BIT: 0
13-07 06:22:12 E (222740538) MAIN: Task: ns -> CAP_8BIT: 1288 CAP_32BIT: 0
13-07 06:22:12 E (222740539) MAIN: Task: httpd -> CAP_8BIT: 4424 CAP_32BIT: 0
13-07 06:22:12 E (222740539) MAIN: Task: mdns -> CAP_8BIT: 176 CAP_32BIT: 0
13-07 06:22:12 E (222740540) MAIN: Task: unknown -> CAP_8BIT: 0 CAP_32BIT: 0
13-07 06:22:12 E (222740541) MAIN: Task: unknown -> CAP_8BIT: 0 CAP_32BIT: 0
13-07 06:22:12 E (222740542) MAIN: Task: out -> CAP_8BIT: 272 CAP_32BIT: 0
13-07 06:22:12 E (222740543) MAIN: Task: unknown -> CAP_8BIT: 0 CAP_32BIT: 0
13-07 06:22:12 E (222740543) MAIN: Task: unknown -> CAP_8BIT: 0 CAP_32BIT: 0
13-07 06:22:12 E (222740544) MAIN: Task: unknown -> CAP_8BIT: 0 CAP_32BIT: 0
13-07 06:22:12 E (222740545) MAIN: Task: unknown -> CAP_8BIT: 0 CAP_32BIT: 0
13-07 06:22:12 E (222740546) MAIN: Task: mds -> CAP_8BIT: 236 CAP_32BIT: 0
13-07 06:22:12 I (222740547) wifi: BUFFER:
13-07 06:22:12 I (222740547) wifi: t  max alloc total_alloc total_free fail_fc  fail_oom
13-07 06:22:12 I (222740548) wifi: 1  32  0     89212       89174      19       0
13-07 06:22:12 I (222740548) wifi: 2  32  0     14          14         0        0
13-07 06:22:12 I (222740549) wifi: 3  32  0     140048      140046     1        0
13-07 06:22:12 I (222740550) wifi: 4  32  0     0           0          0        0
13-07 06:22:12 I (222740551) wifi: 5  0   0     4           4          0        0
13-07 06:22:12 I (222740552) wifi: 6  0   0     0           0          0        0
13-07 06:22:12 I (222740553) wifi: 7  32  0     2348970     2348914    28       0
13-07 06:22:12 I (222740553) wifi: 8  32  0     2174240     2174240    0        0
13-07 06:22:12 I (222740554) wifi: 9  0   0     0           0          0        0
13-07 06:22:12 I (222740555) wifi:
13-07 06:22:12 I (222740555) wifi: LMAC TX:
13-07 06:22:12 I (222740556) wifi: tx_all   lrc src age to
13-07 06:22:12 I (222740556) wifi: 224596   0   2   0   0
13-07 06:22:12 I (222740557) wifi: 0        0   0   0   0
13-07 06:22:12 I (222740557) wifi: 4638     0   0   0   0
13-07 06:22:12 I (222740558) wifi: 0        0   0   0   0
13-07 06:22:12 I (222740558) wifi: 0        0   0   0   0
13-07 06:22:12 I (222740559) wifi:
13-07 06:22:12 I (222740559) wifi: LMAC RX:
13-07 06:22:12 I (222740559) wifi: ampdu    mdpu     mgmt     ctrl     frag
13-07 06:22:12 I (222740560) wifi:<PHONE_NUMBER>  2224998  0        0
13-07 06:22:12 I (222740560) wifi:
13-07 06:22:12 I (222740561) wifi: HW RX:
13-07 06:22:12 I (222740561) wifi: rx_suc   rx_end   full#1   full#2
13-07 06:22:12 I (222740562) wifi: 45c92c   165e0a3  4        0
13-07 06:22:12 I (222740562) wifi:
13-07 06:22:12 I (222740562) wifi: Hardware:
13-07 06:22:12 I (222740563) wifi: rxbufbk  rxcckerr ofdmerr  rx_agc   rxsf     rx_abort rx_fcs   fifofull
13-07 06:22:12 I (222740564) wifi: 1        7a8374   7a837a   0        3176     5652b4   6034     0
13-07 06:22:12 I (222740565) wifi: afull    rx_oth   tkiperr  samebm   ack_int  rts_int  cts_int  rifs_int
13-07 06:22:12 I (222740566) wifi: 0        4124d4   0        58       37014    32b      4122     0
13-07 06:22:12 I (222740567) wifi: blockerr hoperr   txrts    txcts    track    trcts    trigger  txhung   panic
13-07 06:22:12 I (222740568) wifi: 0        0        c17f     0        14ef     32b      6d9      0        0
13-07 06:22:12 I (222740569) wifi:
13-07 06:22:12 I (222740569) wifi: DIAG:
13-07 06:22:12 I (222740570) wifi: diag0    diag1    diag2    diag3    diag4    diag5    diag6
13-07 06:22:12 I (222740570) wifi: f00002   0        fa00a04  0        1        a2088b   0
13-07 06:22:12 I (222740571) wifi: diag7    diag8    diag9    diag10   diag12   diagsel
13-07 06:22:12 I (222740572) wifi: 2810     0        8ac000   40       0        0
13-07 06:22:12 I (222740573) wifi:
13-07 06:22:12 I (222740573) wifi: Power save:
13-07 06:22:12 I (222740574) wifi: tbtt     beacon   timset   dtimset  tbttdrm  actto    txwake   null1    null0    bcndly   sleep    wake     sleept   waket    totalt   percent
13-07 06:22:12 I (222740576) wifi: 2176593  2173134  1542     1082651  2110473  69779    37810    69663    69756<PHONE_NUMBER>  2170038<PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER> 87.34 %
13-07 06:22:12 I (222740578) wifi:
13-07 06:22:12 I (222740578) wifi: HMAC RX:
13-07 06:22:12 I (222740578) wifi: ifx all      data     ctl    mgmt   bcn/probe
13-07 06:22:12 I (222740579) wifi: sta 4523512  2348914  0      11543  10477
13-07 06:22:12 I (222740579) wifi: ap  0        0        0      0      0
13-07 06:22:12 I (222740580) wifi:
13-07 06:22:12 I (222740581) wifi: ifx auth     assoc    deauth action amsdu
13-07 06:22:12 I (222740581) wifi: sta 1        1        0      40     0
13-07 06:22:12 I (222740582) wifi: ap  0        0        0      0      0
13-07 06:22:12 I (222740582) wifi:
13-07 06:22:12 I (222740583) wifi: HMAC TX:
13-07 06:22:12 I (222740583) wifi: sta_tx   ap_tx    psq_tx psq_mc psq_uc ps_uc1 reorder oos   amsdu
13-07 06:22:12 I (222740584) wifi: 89193    0        0      0      0      0       1
13-07 06:22:17 D (222745519) MDS: Query success

Hi @Espressif-liuuuu,
In the past few days the issue triggered like 3 times (less than before) and the wifi lib stayed stable. The problem seems to be fixed.
It's only strange to me that the heap goes from 55K free to ~500 bytes free but one assumption, as you explained, is that it is the amount of memory mbedtls needs to create SSL/TLS connections.
Do you need something more ?

Hi @FnxQT , thanks for your information
yes from your log it seems that the memory was little at m f null while it came back quickly later, we would discuss today and keep you updated if there is anything else needed
13-07 06:18:47 E (222535226) WIFI_MD: internal DMA capable free heap: 564
13-07 06:19:12 E (222559793) HEAP_DEBUG: internal DMA capable free heap: 34692

Any updates on a fix?

Any updates on a fix?

hi, do you mean you also face with the same issue? A patch could be provided to fix that issue, please provide us with your sdk version and we could provide you the patch.

Any updates on a fix?

hi, do you mean you also face with the same issue? A patch could be provided to fix that issue, please provide us with your sdk version and we could provide you the patch.

I don't get it.
If you already have a fix, why not fix it in github and close the issue?

@Espressif-liuuuu
Maybe you want to take a look at this "beacon timeout" issue as well: https://github.com/espressif/esp-idf/issues/11124#issuecomment-1720411364

Any updates on a fix?

hi, do you mean you also face with the same issue? A patch could be provided to fix that issue, please provide us with your sdk version and we could provide you the patch.

Yes. Also with an Ubiquity AP. Both with SDK version 4.4 and 5.0, with an ESP32S3

Any updates on a fix?

hi, do you mean you also face with the same issue? A patch could be provided to fix that issue, please provide us with your sdk version and we could provide you the patch.

Yes. Also with an Ubiquity AP. Both with SDK version 4.4 and 5.0, with an ESP32S3

this issue happened with output m f null, just make sure that there is same situation on your side.
And pls provide with the exact commit number or tag, e.g v5.0.2

Any updates on a fix?

hi, do you mean you also face with the same issue? A patch could be provided to fix that issue, please provide us with your sdk version and we could provide you the patch.

I don't get it. If you already have a fix, why not fix it in github and close the issue?

this issue resulted from nulldata, which we want to make big change later, and it happened not that frequently, so we`d like to provide a patch instead of workaround to fix it now:)

Any updates on a fix?

hi, do you mean you also face with the same issue? A patch could be provided to fix that issue, please provide us with your sdk version and we could provide you the patch.

I don't get it. If you already have a fix, why not fix it in github and close the issue?

this issue resulted from nulldata, which we want to make big change later, and it happened not that frequently, so we`d like to provide a patch instead of workaround to fix it now:)

@Espressif-liuuuu

"it happened not that frequently" is a big problem if you have thousands of devices on the market.
Because some devices just stop working randomly.
If you don't fix it in esp-idf and provide fix privately instead, you are asking people stick on a certain version with your fix.
Then there is no way to get other bug fix by sdk update.
People want to get fix for current issue, not really care about the big change later.
Don't mix bugfix with your refactor in the future.
You need to fix it first before further refactor.

yes ur right, we will think about it, thanks for ur suggestion:)

Hi @Espressif-liuuuu
Is c8a6ac54c577b479ab10f69341f98a3ac1d345a3  related to this issue?

Hi @Espressif-liuuuu
Is c8a6ac54c577b479ab10f69341f98a3ac1d345a3 related to this issue?

Hi, it didnt. It fixes another issue introduced recently on master, beacon timeout happend immedieatly after connection established.

Hi @Espressif-liuuuu
Is c8a6ac54c577b479ab10f69341f98a3ac1d345a3 related to this issue?

Hi, it didnt. It fixes another issue introduced recently on master, beacon timeout happend immedieatly after connection established.

Can you give an ETA on a fix for this issue?

Hi @Espressif-liuuuu
Is c8a6ac54c577b479ab10f69341f98a3ac1d345a3 related to this issue?

Hi, it didnt. It fixes another issue introduced recently on master, beacon timeout happend immedieatly after connection established.

Can you give an ETA on a fix for this issue?

Its under review and would be merged recently. Maybe on v5.2 or the next master sync.
I have to clarify that the title of this ticket maybe misunderstanding. The issue we resolved is the station could not reply and receive data from AP after log shown as m f null.
The original issue of beacon timeout has gone after upgrading to v4.4.4. Please consider to open another ticket if you still have some trouble related with beaocn timeout.

This issue, the no response of station after m f null happened, has been fixed on lastest master and release/v5.1.
cc @FnxQT

@Espressif-liuuuu
Could you share the commit for the fix? (It's strange the espressif-bot does not push the fix to this issue.)
Since this issue is still OPEN, so which branches still need fix?

@Espressif-liuuuu Could you share the commit for the fix? (It's strange the espressif-bot does not push the fix to this issue.) Since this issue is still OPEN, so which branches still need fix?

Maybe I missed the link of this ticket in MR.
The fixed version of v5.1: 21360b9ef3a2c5747b2effdb3213182db47dd2a7
And correct for master: it would be in the next sync

Thanks for tracking, the fix on master branch is available at https://github.com/espressif/esp-idf/commit/db4598e305aa0eb2f140c7cef6df922ea80b4235.
And we plan to back port to release/4.3 and release/4.4, will update once fixes on release/4.3 and release/4.4 are available. Thanks.

Hi @Espressif-liuuuu,
thank you for the followup. However as suggested by @Alvin1Zhang, it would be great to see the fix back ported to v4.4 and v4.3 since they are still under maintenance. Our products are currently using 4.4.4 and we can't easily make a jump to v5.1...
What do you think about that ?

Hi @Espressif-liuuuu,
Maybe this information is still important for you. I was playing with the updated library you gave me on the 25th of June in the file : esp32_76263271.zip
And today out of nowhere my esp32 crashed after the wifi:m f null error happened in infinite loop. Here is the log if it's of some importance to you. Unfortunately I did not have the "esp_wifi_statis_dump(0xffff);" method in my code.
output_logs.txt

Thanks for tracking, the fix on master branch is available at db4598e.
And we plan to back port to release/4.3, release/4.4 and release/5.0, will update once fixes on those branches are available. Thanks.

@Alvin1Zhang
How is the status of the backport? I still cannot find the fix in 4.3, 4.4, and 5.0.

backport information for old branches, anyway I suggest to update to lastest version to avoid the bug in middle version
4.3: 365b867
4.4: d665b47
5.0: e9ee047
And thanks for your report @FnxQT , I saw the log and thought that in your scenary the memory is indeed to the limit. The consecutive debug print in high priority task (Wi-Fi task) may leave no time for your application to free memory, which resulting in more m f null and more debug print. I suggest that:

update the branch to lastest v4.3 at your convenience

backport information for old branches, anyway I suggest to update to lastest version to avoid the bug in middle version 4.3: 5.0: e9ee047

@Espressif-liuuuu Are you sure above commit is the fix fo this issue in 5.0 branch? (The commit looks different from other branches).

backport information for old branches, anyway I suggest to update to lastest version to avoid the bug in middle version 4.3: 5.0: e9ee047

@Espressif-liuuuu Are you sure above commit is the fix fo this issue in 5.0 branch? (The commit looks different from other branches).

yes it is. Its brought in the MR.

I check the v5.0 branch of esp32-wifi-lib, but I still cannot find the fix.
Could you please point out which commit fix this issue?

backport information for old branches, anyway I suggest to update to lastest version to avoid the bug in middle version 4.3: 5.0: e9ee047

@Espressif-liuuuu Are you sure above commit is the fix fo this issue in 5.0 branch? (The commit looks different from other branches).

yes it is. Its brought in the MR.

I check the v5.0 branch of esp32-wifi-lib, but I still cannot find the fix. Could you please point out which commit fix this issue?

Hi, it did in the C3 eco7 MR https://github.com/espressif/esp-idf/commit/e9ee0479086a63fda0cc7f28b17b069a7ec5503a while its not named in the commit information, you may see it in the changelog of the release/v5.0 later, which shall be v5.0.5

Hi, it did in the C3 eco7 MR e9ee047 while its not named in the commit information, you may see it in the changelog of the release/v5.0 later, which shall be v5.0.5

The bug report was against ESP32DOWDQ6, but you said the fix is in the C3 eco7 MR? confused.

The series of chips share most of the Wi-Fi code, so the issue is common. Sorry for the ambiguity.

Not sure if this helps, but for me I had a memory leak. Make sure any heap allocated memory gets freed

Thanks for reporting, feel free to reopen.


⚠ Bofrost.hr has degraded performance

In bec95f8, Bofrost.hr (https://www.bofrost.hr) experienced degraded performance:

HTTP code: 200
Response time: 3063 ms

Resolved: Bofrost.hr performance has improved in e0713b7 after 10 minutes.


[Feature request] Respect TPs

Is it even possible for bots to "see" if there are enemies TPing to a place, when a human player can absolutely see the TP and decide to retreat to avoid death.

I don't see any API from valve to achieve this, do you have any suggestion on what should we use to get the tp-ing number of heroes?

Yeah, so I have a workaround thinking - Check if there's any enemy that we can see that have TP modifiers on them and facing the target tower location, which means they are likely TPing to defend.

{ { playerid, location, time_remaining }, ... } GetIncomingTeleports()
Gets a table of all the teleports that are visibly happening.


tsdb: Remove duplicate variables.

Small fix.
The variables k and removed are duplicated, and removed is more precise so keep removed

Why not get rid of the named return then? We're not using a defer that'd need it.


update simulation makefiles

…rilator/ makefiles; rebuild a.out when running make sim VCD=1

Ok, you see, less is more!
less lines to maintain in the future


Support for 'Modern Terminal' editors

Description of the new feature/enhancement
'Modern Terminal' editors do not work (editors like Micro). If you try to select something wih the cursor, it doesn't select it in the terminal properly. Also, when I click somewhere, it doesn't change the cursors position. This is not a problem with the editor, it works fine in Command Prompt.
Windows Terminal (text isn't really selected, cursor does not move):

Command Prompt (properly working):

Proposed technical implementation details (optional)
Add an option to disable selecting and somehow make it more Command Propmt like.

Thanks for the report! From trying to read between the lines here, this sounds like this is actually caused by the terminal not supporting win32 mouse input quite yet. I'd follow #376 for more details.
/dup #376


python3Packages.qiskit: 0.19.6 -> 0.20.0 & update components

Motivation for this change
Updates python3Packages.qiskit to v0.20.0, as well as updates all components.
Some components require new packages, which were added (muparserx, pythonPackages.yfinance (which requires pythonPackages.multitasking)).
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[x] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

do you mind looking at https://github.com/NixOS/nixpkgs/issues/95527 as well?

Addressed all comments. Building locally now. Only outstanding item IMHO is maybe running self-test on muparserx (WIP).
🤦 on changing retworkx = toPythonModule ..., did it in my nur-packages but forgot here... Fixed.

OK. Worked out last few bugs.

pythonPackages.retworkx now properly works as python37Packages.retworkx, and is disabled for python27Packages.
muparserx is self-tested
all review comments addressed.
nix-review pr 95713 runs locally

the failure:
=================================== FAILURES ===================================
__________________________ TestOptimizers.test_p_bfgs __________________________

self = <test.aqua.test_optimizers.TestOptimizers testMethod=test_p_bfgs>

    def test_p_bfgs(self):
        """ parallel l_bfgs_b test """
        optimizer = P_BFGS(maxfun=1000)
        res = self._optimize(optimizer)
>       self.assertLessEqual(res[2], 10000)
E       AssertionError: 44250 not less than or equal to 10000

test/aqua/test_optimizers.py:69: AssertionError

@jonringer this is probably another massively-parallel CPU issue... the test runs an optimizer that distributes across the cores (https://github.com/Qiskit/qiskit-aqua/blob/72a6fb3b40accfe18b77bfb8c811aa94a7afa443/qiskit/aqua/components/optimizers/p_bfgs.py#L90), which each run an optimization and the number of function evalutions are summed across the processes and assumed to be < 10000 in the test.
I'll open an upstream issue, but in the meantime I feel comfortable disabling this test to get this PR to pass since I've not had this issue locally or on the GitHub Actions build of my NUR repo.

Steps to reproduce the problem

    Get a Threadripper 3990X (or equivalent many-core CPU), running Linux

lol, yes, $4k cpu :)

Steps to reproduce the problem

    Get a Threadripper 3990X (or equivalent many-core CPU), running Linux

lol, yes, $4k cpu :)

That is the CPU you tested it against, right?
And this package is distributed by IBM, I'm sure they have a few high-core-count systems like Summit that they could test this on if they really wanted :D

right, or the 7742 also has 64/128 https://www.newegg.com/amd-epyc-7742-socket-sp3/p/N82E16819113581

@jonringer pushed the patch upstream made. Hoping python3Packages.qiskit-aqua will build cleanly for you now.

@jonringer pushed the patch upstream made. Hoping python3Packages.qiskit-aqua will build cleanly for you now.

I think i mentioned it somewhere else, but i had to drop the NIX_BUILD_CORES to 32 due to other packages having timing issues (bashCompeletion would fail in tests, some meson builds would try to link against objects that don't exist, etc)

cc @FRidh does the rust -> python retworkx changes look good to you?

I based it on the @FRidh approved https://github.com/NixOS/nixpkgs/pull/91342 python3Packages.tokenizers.


msbot clone does not provide a way to deploy code

Tool
Name: Msbot
Version: all versions
OS: all supported OS's
Describe the bug
Using the msbot tools or the Azure CLI, nothing is actually deployed. Resources are "cloned", but code is not pushed.
Additional context
If developers manage to make their way through scattered deployment documentation, they will then discover that the deployment process is actually not working. Using the msbot tools or the Azure CLI, nothing is actually deployed. Resources are "cloned", but code is not pushed. Instead a C# echobot is configured (even when deploying a Node project).
[bug]

Any work in msbot clone is this is dependent on #756 which covers the work on az cli side.
Moving this to 4.3. For 4.2, we will fix #799 which should document the commands the user needs to run to push code up.
@carlosscastro; @sgellock FYI

Adding Tom to this as well; @tomlm it sounds like most of the work here was fixed via #816, can we close this?

This is fixed in 4.2 via #816 and related work.


Merged pull request...

It is time-consuming to maintain all changes in separate pull requests.
So i merged all changes from #9 #10 #11 and #13

Anything else that needs to be changed to merged?

Sorry, but this PR is too big. My time for this project is quite limited and reviewing all these unrelated changes in a single PR needs bigger "timeslot" than I have available for a while for this.
The start_date/end_date thing started to look ready for merging before you combined it here, so maybe just revive it in the separate PR?

That's a dilemma. My time is also limited. That's why I merged the changes.
And there's also another new thing coming up: I need a role "request publishing" and "accept/reject publish request" with short message exchange.
All this is too time-consuming to implement completely separately. Maybe i should made my fork independent and publish a new package to PyPi?!?

@jedie I think there is value in focusing development into one repo. So if you want, we can still try to help you out in ironing the features. Just that, the smaller and more concise the PR, the easier it is to review and iterate on.

I think there is value in focusing development into one repo.

I agree with you. But the reactions times are very long or there is no response. e.g.:
#11 -> a simple bugfix + editorconfig, 8 days old -> No reaction
#10 8 days old, has some questions -> No reaction
Or the hint at #5 ... no reaction...
I think the interest in this project is very low.

@jedie You are right, this is not actively maintained project, rather a occasionally maintained fork from an abandoned project.
So indeed, it might make sense to have your own fork to keep things going forward in your projects.

I have made a fork, merge all my changes and release this on PyPi as django-ya-model-publisher:
github: https://github.com/wearehoods/django-ya-model-publisher/
PyPi: https://pypi.org/project/django-ya-model-publisher/


rust-script: 0.32.0 -> 0.34.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/fornwall/rust-script/releases.
meta.description for rust-script is: Run Rust files and expressions as scripts without any setup or compilation step
meta.homepage for rust-script is: https://rust-script.org
meta.changelog for rust-script is: https://github.com/fornwall/rust-script/releases/tag/0.34.0
Updates performed

Rust version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.34.0 with grep in /nix/store/i2xsckiqdk29gblhv2d07kzkd5wmrpsa-rust-script-0.34.0
found 0.34.0 in filename of file in /nix/store/i2xsckiqdk29gblhv2d07kzkd5wmrpsa-rust-script-0.34.0

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
rust-script

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/i2xsckiqdk29gblhv2d07kzkd5wmrpsa-rust-script-0.34.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A rust-script https://github.com/r-ryantm/nixpkgs/archive/efbc9890a213807f7288791fe48b86914f3ccf2c.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/efbc9890a213807f7288791fe48b86914f3ccf2c#rust-script

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/i2xsckiqdk29gblhv2d07kzkd5wmrpsa-rust-script-0.34.0
ls -la /nix/store/i2xsckiqdk29gblhv2d07kzkd5wmrpsa-rust-script-0.34.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

rust-script

Maintainer pings
cc @figsoda for testing.

Result of nixpkgs-review pr 259117 run on x86_64-linux 1

1 package built:

rust-script