-
Notifications
You must be signed in to change notification settings - Fork 3k
Ublox odin - Wi-Fi interface fails endurance testing/jams #12497
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Attn: @ARMmbed/team-ublox @MarceloSalazar |
Log example below;
I.e. the notification sending fails - client tries to reconnect, but it just does not help and connection never recovers. Counter was only 283 in this case, so it happened quite quicly that time (I had a total of 4 test runs over the weekend, every one of them failed). For reference: NXP K66F worked flawlessly the whole weekend, even with the Ethernet cable intentionally plugged out for a while. |
Same story with mbed-cloud-client-example, log from that, too.
Counter is at that same 283, so that seems like too much of a co-incidence? |
Internal Jira reference: https://jira.arm.com/browse/MBOTRIAGE-2559 |
I have seen this issue too. Thank you @JanneKiiskila goes into the detail. I actually have seen this issue on mebd-os-5.14.2 and it seems that ARP packet cannot be received after running for a while. By connecting the ublox to the wifi hotspot on my laptop and use Wireshark for packet capture, I traced things back to the Ublox driver. However, since it's closed source, I cannot proceed anymore. The LWIP trace shows that Ublox requires ARP at 270 seconds (30 seconds before ARP table expires) and it usually gets a response to renew the table. However, after a while, the packet capture shows the gateway(my laptop) provided an ARP response but it wasn't received by the LWIP stack although SSDP packet was received without any issue. Hence, no packet can be sent. I temporarily goes around the issue by enabling static ARP but would like to see a much more reliable ublox driver. |
@ARMmbed/team-ublox - please comment / analyse this issue. |
This issue is just seems duplicate of we would resume analysis on it and would see how we may fix in driver. for wifi we have analyzed and turning off DHCP and switching to static IP's avoid a crash. |
Closing as it's a duplicate of #10815 |
This is not a crash, this is a jam. So, I don't see the problem symptom being the same necessarily - there is no Mbed OS crash. |
Reproducing this issue not require any noisy Wi-Fi environment either, just enough time (2-3 hours). |
@JanneKiiskila thanks for clarifying this. |
@JanneKiiskila Are you getting device running into JAM condition without DHCP if practice for 2-3 hours? |
I have not tried with static IP addresses, it's not a realistic scenario for many setups. |
Description of defect
Try running mbed-os-example-pelion with UBLOX_EVK_ODIN_W2 target, leave it running for a longer time. Once tick count on /3200/0/5501 reaches around 1900-2200 - the connection will fail and all DNS queries against that interface will fail. Seems the Wi-Fi stack gets somehow stuck and it never recovers.
With K66F/Ethernet - you can plug out the whole cable for a long time, then plug it back in and everything recovers nicely.
Target(s) affected by this defect ?
UBLOX_EVK_ODIN_W2
Toolchain(s) (name and version) displaying this defect ?
gcc-arm-none-eabi-9-2019-q4-major
What version of Mbed-os are you using (tag or sha) ?
mbed-os.5.15.1
What version(s) of tools are you using. List all that apply (E.g. mbed-cli)
mbed-cli 1.10.1
How is this defect reproduced ?
mbed_app.json
, optinally turn traces on.-> At some point of time you will have network error/lose Wi-Fi connectivity.
The text was updated successfully, but these errors were encountered: