Ipv6 delegate option is not respected by proto ncm
this add support for it.
Signed-off-by: Chen Minqiang <ptpt52@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/15508
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This patch solves the problem of receiving "error" responses when
initially calling gcom. This avoids unnecessary NO_DEVICE failures.
A retry loop retries the call after an "error" response within the
specified delay. A successful response will continue with the connection
immediately without waiting for max specified delay, bringing the
interface up sooner.
Signed-off-by: Mike Wilson <mikewse@hotmail.com>
Some modems expose ttyACM as their control ports, which have the
"device" symlink pointing one level down in sysfs tree. Try to find
network interfaces for them as well, this is commonly used for modems
exposing ACM + RNDIS or ACM + ECM interface combinations.
Co-developed-by: Cezary Jackiewicz <cezary@eko.one.pl>
Signed-off-by: Cezary Jackiewicz <cezary@eko.one.pl>
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
Some modems expose multiple network interfaces on the same USB device,
causing the connection setup script to fail, because glob matching in
the detection phase causes 'ls' to output more than one interface name
plus their base directories in sysfs. Avoid that by listing the
directories explicitly and then selecting first available interface.
This is the case for some variants of ZTE MF286R built-in modem, which
exposes both RNDIS and CDC-ECM network interfaces, causing the
connection setup to fail.
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
Add ifname property to UCI, which can be used to override the
autodetected interface name in case the detection fails due to having
none or more than one interface exposed by the modem, which is not
explicitly linked to TTY port. This is needed on certain variants of ZTE
MF286R built-in modem, which exposes both RNDIS and CDC-ECM interfaces
on the modem, on which the automatic detection may select the wrong
network interface.
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
After a hardware reconnect, the control device might be unavailable and
attempting to interact with it will lead to hanging gcom calls, leaving
the protocol setup in an unrecoverable state.
Change the protocol handler to bail out early and notify netifd if the
control device is not defined or if the underlying device node does not
exist.
Also ensure that the "disconnect", "connect" and "setmode" commands are
actually defined before trying to invoke them.
Finally attempt to re-query the device manufacturer if it is unset in
the interface state in order to prevent UNUPPORTED_MODEM errors after
a modem hardware reconnect.
Signed-off-by: Rozhuk Ivan <rozhuk.im@gmail.com>
[reword subject and commit message]
Ref: https://github.com/openwrt/openwrt/pull/2352
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Fix an issue where subinterfaces were not added to the same
firewall zone as their parent.
Fixes: FS#2122
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
This PR allow the 3G modem embedded in the DWR-512 to be managed
by the wwan-ncm scripts. The modem will use the usb-option and
usb-cdc-ether drivers.
The DWR-512 DT is updated accordingly.
Signed-off-by: Giuseppe Lippolis <giu.lippolis@gmail.com>
It's useful when using multiple usb devices that should be bound to
certain usb ports. Symlinks are created by hotplug handlers.
Signed-off-by: Nickolay Ledovskikh <nledovskikh@gmail.com>
Add support for specifying a call profile index instead of APN. A
specific index different from 1 must be used for some service
provider and modem combinations.
In addition, change the manufacturer detection to use the standard
AT+CGMI command, which produces more predictable output than ATI,
remove the redundant ipv6 option, since it is less ambiguous to
directly specify the PDP context type with mobile connections, and
fix missing device during teardown when using ncm through the wwan
proto.
Signed-off-by: Matti Laakso <malaakso@elisanet.fi>
For Huawei devices like E3372 proper command for set lte mode is:
AT^SYSCFGEX="03",3fffffff,2,4,7fffffffffffffff,,
Eval is required for proper quotation.
Without this fix:
Fri Nov 4 19:07:49 2016 daemon.notice netifd: Interface 'wan' is setting up now
Fri Nov 4 19:07:52 2016 daemon.notice netifd: wan (2060): sending -> AT
Fri Nov 4 19:07:52 2016 daemon.notice netifd: wan (2060): sending -> ATZ
Fri Nov 4 19:07:53 2016 daemon.notice netifd: wan (2060): sending -> ATQ0
Fri Nov 4 19:07:53 2016 daemon.notice netifd: wan (2060): sending -> ATV1
Fri Nov 4 19:07:54 2016 daemon.notice netifd: wan (2060): sending -> ATE1
Fri Nov 4 19:07:55 2016 daemon.notice netifd: wan (2060): sending -> ATS0=0
Fri Nov 4 19:07:55 2016 daemon.notice netifd: wan (2060): sending -> AT+CGDCONT=1,"IP","internet"
Fri Nov 4 19:07:57 2016 daemon.notice netifd: wan (2060): sending -> AT^SYSCFGEX=\"03\",3fffffff,2,4,7fffffffffffffff,,
Fri Nov 4 19:07:58 2016 daemon.notice netifd: wan (2060): Error running AT-command
Fri Nov 4 19:07:58 2016 daemon.notice netifd: wan (2060): Failed to set operating mode
Fri Nov 4 19:07:58 2016 daemon.notice netifd: wan (2092): Stopping network
...
With this fix:
Fri Nov 4 19:10:59 2016 daemon.notice netifd: Interface 'wan' is setting up now
Fri Nov 4 19:11:01 2016 daemon.notice netifd: wan (2539): sending -> AT
Fri Nov 4 19:11:01 2016 daemon.notice netifd: wan (2539): sending -> ATZ
Fri Nov 4 19:11:02 2016 daemon.notice netifd: wan (2539): sending -> ATQ0
Fri Nov 4 19:11:03 2016 daemon.notice netifd: wan (2539): sending -> ATV1
Fri Nov 4 19:11:03 2016 daemon.notice netifd: wan (2539): sending -> ATE1
Fri Nov 4 19:11:04 2016 daemon.notice netifd: wan (2539): sending -> ATS0=0
Fri Nov 4 19:11:05 2016 daemon.notice netifd: wan (2539): sending -> AT+CGDCONT=1,"IP","internet"
Fri Nov 4 19:11:06 2016 daemon.notice netifd: wan (2539): sending -> AT^SYSCFGEX="03",3fffffff,2,4,7fffffffffffffff,,
Fri Nov 4 19:11:07 2016 daemon.notice netifd: wan (2539): sending -> AT^NDISDUP=1,1,"internet"
Fri Nov 4 19:11:08 2016 daemon.notice netifd: wan (2539): Connected, starting DHCP on wwan0
Fri Nov 4 19:11:08 2016 daemon.notice netifd: Interface 'wan' is now up
Fri Nov 4 19:11:08 2016 daemon.notice netifd: Network device 'wwan0' link is up
Fri Nov 4 19:11:08 2016 daemon.notice netifd: Network alias 'wwan0' link is up
Fri Nov 4 19:11:08 2016 daemon.notice netifd: Interface 'wan_4' is enabled
Fri Nov 4 19:11:08 2016 daemon.notice netifd: Interface 'wan_4' has link connectivity
Fri Nov 4 19:11:08 2016 daemon.notice netifd: Interface 'wan_4' is setting up now
...
Signed-off-by: Cezary Jackiewicz <cezary@eko.one.pl>
By setting the option pdptype to IP, IPV6 or IPV4V6 the user can
choose the context type between IPv4, IPv6 and dual stack,
respectively. The default setting is dual stack, except if option
ipv6=0 is specified, in which case IPv4 context is the default.
This allows for an out-of-the-box IPv6 support with modems
utilizing NCM-like protocols.
While we are at it, also add commands for Sierra DirectIP modems
(currently untested), which will allow us to drop the separate
comgt-directip package (once tested and verified working).
Signed-off-by: Matti Laakso <malaakso@elisanet.fi>
SVN-Revision: 46844
Interface should not be set unavailable in all error cases,
returning 1 is enough.
Signed-off-by: Matti Laakso <malaakso@elisanet.fi>
SVN-Revision: 44630
This patch fixes the NCM protocol by adding the missing ifname
to the netifd script and changing one unintended "send" statement to
"print" in runcommand.gcom. It also cleans up logging and makes the
manufacturer names case-insensitive. Furthermore, comgt-ncm should
not depend on the USB-serial-related kernel modules, as the cdc-wdm
control device works without them. There is also no need to depend on
kmod-huawei-cdc-ncm, since other manufacturers (like Sony-Ericsson
and Samsung) which use other kernel modules should also be supported.
I'd appreciate if someone with Samsung or Sony-Ericsson modems could
test this, I was only able to test it with Huawei E3276, E3372 and
E353.
Signed-off-by: Matti Laakso <malaakso@elisanet.fi>
SVN-Revision: 44182
