-
Notifications
You must be signed in to change notification settings - Fork 3k
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
ODIN_EVK_W2_UBLOX fails to reconnect when Nanostack is used #11500
Comments
Internal Jira reference: https://jira.arm.com/browse/MBOCUSTRIA-1767 |
@michalpasztamobica internal jira: https://jira.u-blox.net/browse/TE_OM2-310 It's not a problem with ODIWIFIInterfcae rather with nanostack, a quick analysis by team mate reveals, its connect_semaphore lock is expiring rather than wifi_connect().
|
Hi @aqib-ublox . Thanks a lot for a quick analysis. |
If I run with Ethernet connection:
I can reconnect without a problem. Only WiFi is failing... |
Have u anything investigated? |
@aqib-ublox , I have not, sorry, I will try to get down to this next week. |
I am sharing our findings so far with you. The program is showing different results for us. As you stated, it only fails to connect second time. But we are not able to make it connect for the first time either over the both WiFi and Ethernet. Upon debugging, we found out that the reason for failure is unsuccessful DHCP bringup. It fails because of not able to acquire the On the other hand, on the router (AP) end, it shows device as connected because AP advertised the address and it was received and processed by device. We ran the same example on a different target Attached is the screenshot of Call Stack for this debugging session for your reference. I believe we are not on the same line here, may be we have different configurations set up. Can you please check if the following configurations are correct or share yours? <project_dir>/mbed_app.json:
<project_dir>/mbed-os/features/netsocket/mbed_lib.json:
|
Hi @hamza-ubx . Thanks a lot for this insightfult comment!
On my end I managed to reconnect multiple times if I enabled a debug message in |
It seems with the debug print in place (which delays the handler execution) on reconnection I am getting the following status callbacks: But if I remove the printf the following statuses are reported: |
@michalpasztamobica I think you are right about the delayed execution of handler due to debug statement. There needs to be some transitioning state to accommodate race condition between disconnect and connect. We however, haven't received Looking at the name of the states and functioning of the algorithm, it also seems to me that
But again functioning of algorithm shows that |
I amended my previous comment, as I figured out that I mixed up the names of events slightly...
What worries me is that after a failed bootstrap there is a reversed order of I couldn't find any proper documentation on the state machine operation. This is the best I could find. @mikter , can you point us to any document explaining which state should come after which? |
@mikter , @SeppoTakalo , @AnttiKauppila , if you could confirm, that our understanding of expected order of events is correct, or point me to a relevant documentation, that would be great. |
@hamza-ubx Do you have IPv6 network available? What you reported, sounds like there is no IPv6 router and therefore the semaphore will never be released, as the Nanostack will never get IPv6 address. Please note that Nanostack is only IPv6 capable, as it is meant for mesh networks. However Ethernet is used as a backbone network in border routers. |
@SeppoTakalo , I can reproduce the issue on our RAAS configuration. What is more the first connect passes fine. I can also see that all other tests (including tcp/udp/tls) pass fine with Nanostack. We need to clarify whether this is acceptable and we need to amend the mesh interface or not acceptable and the driver's behavior needs adjustment. |
@SeppoTakalo Yes we have already figured that IPv6 was disabled on our local network for some reason. We are setting up the network with IPv6 support and will continue the testing. @michalpasztamobica Hopefully once we test with IPv6 enabled network, we will be able to reproduce the sequence of events you are receiving. We will further investigate the drivers behavior and keep you posted. |
Can you kindly test with this private branch and see if you are still getting the states in reversed order: ublox_odin_driver_os_5_v3.7.1_rc3 We have fixed some issues with the driver state machine but we are not certain if this issue may also have been fixed. While we wait for IPv6 network to be setup, kindly let us know about your test results. |
Hi @hamza-ubx , I checked out the branch which you posted and ran my sample application, but unfortunately on reconnection I got the same result as before - |
@0xc0170 , @MarceloSalazar , do you think this task can be closed as irrelevant, now that Ublox has been dropped from mbed-os-6? |
Description
When compiled with Nanostack set up in mbed_app.json:
(and all other configs set up for correct WiFi operation)
this minimal example does not work as expected:
The output is:
The other connect should work and return 0 (
NSAPI_ERROR_OK
), while it returns -3004 (NSAPI_ERROR_NO_CONNECTION
) instead.It works just fine if I compile with
LWIP
, no matter if it'sipv6
oripv4
enabled.I checked that it doesn't matter if the network is secured or not - the next connect always fails, unless the whole new
NetworkInterface
is created (for example in a test suite teardown).I debugged the Interface all the way down to OdinWiFiInterface::wlan_connect and it seems that parameters are set up correctly. I cannot get any deeper than that because the code is provided as a library.
@ARMmbed/team-ublox , could you please take a look at this issue?
Issue request type
The text was updated successfully, but these errors were encountered: