After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 782682 - reduce time of internet disconnect time delay
reduce time of internet disconnect time delay
Status: RESOLVED OBSOLETE
Product: NetworkManager
Classification: Platform
Component: Mobile broadband
unspecified
Other Linux
: Normal critical
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2017-05-16 09:22 UTC by niraj ram
Modified: 2020-11-12 14:28 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
ellisys log snippet for reference (126.13 KB, application/x-rar)
2017-05-16 09:23 UTC, niraj ram
Details

Description niraj ram 2017-05-16 09:22:40 UTC
Hi, 

I already created another ticket and discussed this issue with modem manager.
https://bugs.freedesktop.org/show_bug.cgi?id=101046

Issue Description:
With Intel modem with simultaneous ping and playing youtube video(HD), internet disconnect -> connect do not initiate connection again.

So, we analyzed this issue from device side and found a lot of IP packets are stuck in device side as host stopped USB communication of data channel very early before sending actual MBIM command for network disconnect.

Please find ellisys logs in attachment.
The detailed discussion and conclusion form modem manager is available in bugzilla id 101046.
https://bugs.freedesktop.org/show_bug.cgi?id=101046

The conclusion is the USB communication should not stop very early before sending the network disconnect message.

The time taken by windows after last USB transfer is 3 to 10ms normally and max I observed is 90ms while in case of ubuntu, the time delay is always grearer than 200ms(e.g. 200ms, 470ms, 900ms etc).

So, Alaksander suggested to use option (a) from options below:
a) The WWAN network interface should stop IP traffic before the MBIM disconnect is sent to the device.
b) The WWAN network interface should stop IP traffic just after the MBIM disconnect is sent to the device, before even getting the reply from the device.
c) The WWAN network interface should stop IP traffic after the MBIM disconnect is sent to the device and the reply from the device received.

Can you please check the feasibility and provide the new temporary patch or executable to check it from our side?

Thanks,
Niraj Ram
Comment 1 niraj ram 2017-05-16 09:23:26 UTC
Created attachment 351952 [details]
ellisys log snippet for reference
Comment 2 Aleksander Morgado 2017-05-16 11:33:21 UTC
> So, Alaksander suggested to use option (a) from options below:
> a) The WWAN network interface should stop IP traffic before the MBIM
> disconnect is sent to the device.
> b) The WWAN network interface should stop IP traffic just after the MBIM
> disconnect is sent to the device, before even getting the reply from the
> device.
> c) The WWAN network interface should stop IP traffic after the MBIM
> disconnect is sent to the device and the reply from the device received.
> 

Just to clarify; I didn't suggest to use option (a). I don't know if that option is the right one or even the best one. In the ModemManager bug report I was just trying to clarify which of the options it was the one the reported wanted to have.

From my understanding, the current situation with MM+NM is (c); i.e. the IP settings are removed from the WWAN interface after MM has reported the successful disconnection; but I'm not even sure of this. Is this really the case?
Comment 3 Steve Fosdick 2017-05-16 12:07:44 UTC
Just received notification that this bug has been set as "depends on" 101046.  Are you sure this is correct?  101046 is about issues with mergeant and Oracle and was closed years ago.  I can't see how that is relevant to a current issue with network manager.
Comment 4 niraj ram 2017-05-16 12:12:24 UTC
Hi Steve,

May be I just gave you the number but exact URL is below:
https://bugs.freedesktop.org/show_bug.cgi?id=101046

In this ticket we had a discussion an came to some conclusion but we are not sure which option we can choose.

However, I think "network manager" can judge better what is current scenario and what could be changed.

The description and detailed issue discussion is mentioned in url https://bugs.freedesktop.org/show_bug.cgi?id=101046


Thanks,
Comment 5 Aleksander Morgado 2017-05-18 07:40:30 UTC
> May be I just gave you the number but exact URL is below:
> https://bugs.freedesktop.org/show_bug.cgi?id=101046

Niraj, you cannot add a "depends on" bug number if the bug is in a different bugzilla :) (GNOME bugzilla vs Freedesktop bugzilla)

Steve, sorry for the noise.
Comment 6 niraj ram 2017-05-18 11:37:16 UTC
Hi Aleksander,

Thank you for removing "depends on" number.

@Steve: Please let me know if you need more information for this issue.
Comment 7 niraj ram 2017-05-29 13:15:28 UTC
Hi Steve,

Is there any progress or suggestion you want to provide for this issue?
Currently, we have pressure from our client to finish this task as soon as possible.

Thanks,
Niraj Ram
Comment 8 André Klapper 2020-11-12 14:28:04 UTC
bugzilla.gnome.org is being shut down in favor of a GitLab instance. 
We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time.

If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/

Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).