by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    gadget-man
    @gadget-man
    Could this have any thing to do with CONFIG_LWIP_DHCP_DOES_ARP_CHECK that I see on various forums (though mostly Ardiunio-related)?
    Deomid Ryabkov
    @rojer
    ok, interesting
    no, it shouldn't be related to dhcp, auth expire occurs before we authenticate to the AP
    gadget-man
    @gadget-man
    There is a reason: 8 before the auth expire, but I’d presumed that was caused by my manual disconnect
    Deomid Ryabkov
    @rojer
    well, then... i think it's time to head on over to esp-idf and file an issue there
    reason 8 should be manual disconnect, yes
    WIFI_REASON_ASSOC_LEAVE
    can you verify that your disconnect / reconnect code is working in other cases?
    Deomid Ryabkov
    @rojer
    still, this is so weird - if we stay connected, UDP logging is working but DNS no longer does
    gadget-man
    @gadget-man
    Yes, I tested it on my local board here, tethered to a 4G connection. I then disabled the 4G momentarily to force a disconnect, then turned it back on and watched it reconnect fine.
    Yep, can’t get my head around it.
    Deomid Ryabkov
    @rojer
    one more thing to try is to stub out DNS resolution of the AWS host and see if it's just rhe DNS that stops working
    i.e. if we move on to TCP connect, does it work?
    gadget-man
    @gadget-man
    Not sure I can do that with an AWS IoT endpoint? Could I perhaps force an SNTP refresh or ping a remote server (mdash?) instead to check the DNS?
    Deomid Ryabkov
    @rojer
    we can do it for aws endpoint, yes. we'll hard-code on of the addresses it resolves to, it should be fine as a quick experiment
    we can patch mg_parse_address in mongoose.c to return a fixed IP address for the AWS endpoint instead of going through the DNS resolution
    so just strcmp() and punch in the address into sa
    gadget-man
    @gadget-man
    OK. Interestingly, since yesterday the frequency of disconnects has reduced to 2-3 per day, rather than every 10 mins or so.
    Sorry, not sure what you mean. Only started learning c about 6 weeks ago!
    Deomid Ryabkov
    @rojer
    or, in fact, let mongoose do it for you: if (strcmp(str, "a24buxh69lukw9-ats.iot.eu-west-1.amazonaws.com:8883") == 0) str = "52.211.66.183:8883";
    https://github.com/cesanta/mongoose/blob/80d74e9e341d541f71c0fa587d22cec89be32dd5/mongoose.c#L2653
    if (strcmp(str, "a24buxh69lukw9-ats.iot.eu-west-1.amazonaws.com:8883") == 0) {
      LOG(LL_INFO, ("STUB!"));
      str = "52.211.66.183:8883";
    }
    something like that
    gadget-man
    @gadget-man
    Got it thanks. Will try it now on a local device.
    gadget-man
    @gadget-man
    What is MQTT0 TCP connect error (-13)? Seeing it on my local device on an old firmware when connecting over my 4G tether. Fine when on WiFi. Not sure it’s relevant but interested nonetheless
    gadget-man
    @gadget-man
    @rojer, some pretty interesting results when I tether the ESP32 to an iPad Pro - WiFi connection is fine but MQTT fails (using the new code). See attached L3 logs.
    Changing the Wifi to my normal wifi connects straight away.
    gadget-man
    @gadget-man
    And now I just get ‘Invliad SSL Cert’ when connecting. Which we’ve seen quite often across the UDP after disconnects, so perhaps this is linked?
    gadget-man
    @gadget-man
    The only way to resolve the tethered connection was an iPad reboot
    gadget-man
    @gadget-man
    @rojer this sounds somewhat similar espressif/esp-idf#5351
    Deomid Ryabkov
    @rojer
    it might be. feel free to provide the info we were able to find
    @DrBomb i recall that you were having UART issues with ESP32, can you remind me what those are?
    gadget-man
    @gadget-man
    OK I’ve added some notes to the issue and a couple of the logs.
    DrBomb
    @DrBomb
    Sure, @rojer I was having issues running PPPoS over UART on latest. When doing the SSL handshake the board would core dump with interrupt wdt on the guru meditation
    Here's the pastebin with the backtrace symbolized https://pastebin.com/DiJbVB80
    It isn't able to do a complete core dump
    For now I just pinned my production firmwares to 2.17.0 because pppos is the core of our product
    Deomid Ryabkov
    @rojer
    right. i'd like to understand what the problem is
    i remember you were checking out which caommit caused it, were you able to pinpoint one?
    was it this one? cesanta/mongoose-os@726446d
    DrBomb
    @DrBomb
    I'm pretty sure that's the one. Let me check my old messages
    67e7d9f0b3ed1bea0e09e07faca03f3b4fd95e04 does not crash
    Jumped to 726446d016e9316f128fa066e9f1d146c733914d and crashes
    That's what I tested back then
    There is one or two commits in between those two though, I skipped them because they seemed to address the same as the 726446d
    Deomid Ryabkov
    @rojer
    i think it's 72644, but just want to be sure
    and in case it is, can you revert this part of it and see if the crash goes away?