Hi Jonas,
Let me clean up a little bit to take your notes and to answer your questions.
On 8/19/19, Jonas Bonn wrote:
> Aug 17 08:51:46 solar kernel: usb 1-1: USB disconnect, device number 3
> Aug 17 08:51:46 solar kernel: option1 ttyUSB0: GSM modem (1-port)
> converter now disconnected from
Hi Michael,
Re-adding JH and mailing lists to conversation...
On 19/08/2019 10:00, Michael Nazzareno Trimarchi wrote:
Hi
On Mon, Aug 19, 2019 at 9:51 AM Jonas Bonn wrote:
On 19/08/2019 09:36, Michael Nazzareno Trimarchi wrote:
Can be chattering and rush current? Even are you sure that
On 19/08/2019 09:50, Jonas Bonn wrote:
On 19/08/2019 09:36, Michael Nazzareno Trimarchi wrote:
Hi
On Mon, Aug 19, 2019 at 7:38 AM Jonas Bonn wrote:
The kernel log has this:
Aug 17 08:51:46 solar kernel: usb 1-1: USB disconnect, device number 3
Aug 17 08:51:46 solar kernel: option1
On 19/08/2019 09:36, Michael Nazzareno Trimarchi wrote:
Hi
On Mon, Aug 19, 2019 at 7:38 AM Jonas Bonn wrote:
The kernel log has this:
Aug 17 08:51:46 solar kernel: usb 1-1: USB disconnect, device number 3
Aug 17 08:51:46 solar kernel: option1 ttyUSB0: GSM modem (1-port)
converter now
Hi JH,
On 19/08/2019 03:51, JH wrote:
Hi Michael,
On 8/18/19, Michael Nazzareno Trimarchi wrote:
Aug 17 11:32:44 solar kernel: usb 1-1: new high-speed USB device
number 5 using ci_hdrc
Aug 17 11:32:45 solar kernel: usb 1-1: New USB device found,
idVendor=05c6, idProduct=90b2, bcdDevice=
Hi Jonas,
On 8/18/19, Jonas Bonn wrote:
>>> OK, all from kernel, what could make the kernel to delete the link?
>
> What does the kernel log show?
...
kernel: qmi_wwan 1-1:1.3: nonzero urb status received: -71
kernel: qmi_wwan 1-1:1.3: wdm_int_callback - 0 bytes
kernel: qmi_wwan 1-1:1.3:
Hi JH,
On 17/08/2019 13:55, JH wrote:
On 8/17/19, JH wrote:
On 8/16/19, Daniel Wagner wrote:
The NTP code is just telling it can't reach the server. This has no
direct connenction to the next entry.
So that from NTP, don't need to worry about it.
This message is from the kernel via RTNL
On 8/16/19, Daniel Wagner wrote:
> The NTP code is just telling it can't reach the server. This has no
> direct connenction to the next entry.
So that from NTP, don't need to worry about it.
> This message is from the kernel via RTNL interface. The kernel tells
> ConnMan the interface state has
On 8/15/19 2:45 PM, JH wrote:
Well, the log _seemed_ to indicate that connman does an NTP request to a
server that isn't available and thereby decides to take the link down...
off the top of my head I can't say whether that's something connman
actually does so hopefully somebody else will jump
Hi Jonas,
On 8/14/19, Jonas Bonn wrote:
>> I logged link status every 10 minutes.
>
> How? Not clear from what you posted earliest how you can tell that the
> link has gone down. The default route is set to go over WiFi so a
> generic ping isn't sufficient. What exactly are you monitoring?
Hi,
On 8/14/19 3:00 PM, Jonas Bonn wrote:
Well, the log _seemed_ to indicate that connman does an NTP request to a
server that isn't available and thereby decides to take the link down...
NTP lookup failures won't trigger a disconnect. As long oFono or the
kernel via RNTL changes the state
Hi JH,
On 14/08/2019 13:11, JH wrote:
Hi Jonas,
On 8/14/19, Jonas Bonn wrote:
So you have no traffic over the LTE link? How do you know that it goes
down after 1-2 hours... maybe it went down after 5 minutes?
I logged link status every 10 minutes.
How? Not clear from what you posted
Hi Jonas,
On 8/14/19, Jonas Bonn wrote:
> So you have no traffic over the LTE link? How do you know that it goes
> down after 1-2 hours... maybe it went down after 5 minutes?
I logged link status every 10 minutes.
> Cloud messages are as good as a ping... a packet's a packet.
> The link is
CC: ofono mailing list.
Please don't drop the mailing list from the conversation.
On 13/08/2019 13:51, JH wrote:
Hi Jonas,
On 8/13/19, Jonas Bonn wrote:
Hi JH,
Aug 01 08:09:39 connmand[181]: wwan0 {add} route 0.0.0.0 gw
10.114.23.146 scope 0
Aug 01 08:09:45 connmand[181]: Online check
Hi Giacinto,
On 8/11/19, Giacinto Cifelli wrote:
> can you check with the ofono script test/list-contexts if the method
> is static or dhcp?
# ofono/test/list-contexts
[ /ubloxqmi_0 ]
[ /ubloxqmi_0/context1 ]
Name = Internet
Type = internet
AuthenticationMethod =
hi,
On Sun, Aug 11, 2019 at 1:57 PM JH wrote:
>
> More observation about the network connection, the device has two
> network interfaces, WiFi mlan0 and LTE wwan0, I think that problem is
> likely in connman, not in ofono as in some stage, the wifi IP address
> lost as well, but it came back.
>
More observation about the network connection, the device has two
network interfaces, WiFi mlan0 and LTE wwan0, I think that problem is
likely in connman, not in ofono as in some stage, the wifi IP address
lost as well, but it came back.
Why connmand contently calling to add and to del both mlan0
Hi Giacinto,
I tried to run openwrt on my embedded system, it got netifd daemon to
manage the LTE modem, and started udhcpc -p /var/run/udhcpc-wwan0.pid
-s /lib/netifd, that problem has gone away.
Now I am really worried, if the problem of lost LTE network IP address
only happened in connman not
Hi,
On Wed, Aug 7, 2019 at 12:27 PM JH wrote:
>
> Hi Giacinto,
>
> Just got response from the hardware contractor.
>
> On 8/3/19, Giacinto Cifelli wrote:
> > Hi jupiter,
>
> > This signal level is output periodically by ofono in a signal.
> > You can try to catch all ofono signals (these are
Hi Giacinto,
Just got response from the hardware contractor.
On 8/3/19, Giacinto Cifelli wrote:
> Hi jupiter,
> This signal level is output periodically by ofono in a signal.
> You can try to catch all ofono signals (these are dbus events, not to
> be confused with signal level and network
Hi jupiter,
On Fri, Aug 2, 2019 at 12:46 PM JH wrote:
>
> Hi Giacinto, thanks for your response.
>
> On 8/2/19, Giacinto Cifelli wrote:
> > Hi jupiter,
> > most likely the network dropped the context without signaling.
> > What kind of modem is it? And would you know also the chipset?
>
> It is
Hi Giacinto, thanks for your response.
On 8/2/19, Giacinto Cifelli wrote:
> Hi jupiter,
> most likely the network dropped the context without signaling.
> What kind of modem is it? And would you know also the chipset?
It is uBlox SARA-R4 chipset, did you mean it could be caused by weak
LTE
Hi jupiter,
On Thu, Aug 1, 2019 at 1:01 PM JH wrote:
>
> Hi,
>
> I have a device connect to 4G LTE, it was in good connection status on
> start up, after a couple of hours, it dropped LTE connection, the
> ofono did not show any errors, but connman had lots of error messages
> at following,
23 matches
Mail list logo
