On 09/05/2017 09:46 AM, Alexander Couzens wrote: > On Thu, 10 Aug 2017 12:47:28 +0200 > Daniel Wagner <wagi(a)monom.org&gt; wrote: > >>> Bus 001 Device 003: ID 1bc7:1201 Telit Wireless Solutions >> >> Here is a compile tested 'fix'. I don't know if this works and\ >> obviously it doesn't follow the coding guide lines for this >> project. If you could test this and report back the outcome >> that would be really helpful. Then I can create a proper >> patch for Denis. > > I can confirm this bug with an quectel ec20 using the firmware > EC20EQAR02A13E2G 1 [Jul 5 2017 10:49:17]. > > To reproduce using ofono w/o connman. linux 4.12.8 > - call ofono "../context1 Active true" > - set the ip by hand. No ping response. > - using dhcpcd. Ping responses. > > The `ip addr show` looks the same, except the interface has now an ipv6 > link local address. Is this is problem of modern LTE cards? > Could be raw-ip or 802.3 encapsulations the problem? > Here's something Reinhard said in a different thread that might be applicable here: "Unfortunately the PLS8 seems to need DHCP to be used as a trigger to pass IPv4 traffic over the network interface even if the parameters could be obtained from AT commands. This restriction also holds for some other Qualcomm firmwares when the QMI network interface is used in Ethernet mode instead of Raw IP mode." If this is true, then falling back to DHCP would seem to be required for many Qualcomm based devices. This seems to be a recently introduced 'bug' as older QMI devices did not need this workaround.

Hi Daniel, >> >> >> If this is true, then falling back to DHCP would seem to be required >> for many Qualcomm based devices. This seems to be a recently >> introduced 'bug' as older QMI devices did not need this workaround. > > > Do you think we should try to figure out which Qualcomm device is > misbehaving or should the feature just be reverted? It would seem that this only affects devices introduced in the last several years. The QMI code is from 2012, and the devices Marcel tested this with worked fine. Perhaps we should have plugins/udevng.c maintain a database of all the 'dhcp-required' devices and set this property accordingly. Running DHCP takes time, so if it can be avoided, you get online a bit faster... > > The other option is to add some fallback mechanism in ConnMan and print > a fat warning into the log. But I don't this idea. > Sounds like a least preferred option to me as well. Regards, -Denis _______________________________________________ connman mailing list connman(a)lists.01.org https://lists.01.org/mailman/listinfo/connman