| Message ID | 1455815546-17544-1-git-send-email-br1@einfach.org |
|---|---|
| State | Rejected |
| Headers | show |
> Huawei HiLink ("h" model names) modems just provide a CDC Ethernet interface > where we have to run DHCP to get an IP address (usually in the 192.168.8.0 > range). While this may be bad design in general it's sometimes necessary to > support these modems. > > This adds autodetection and handling of these to wwan. > > Tested with Huawei E3030h-1. Why do you need an extra protocol for these? They work just fine with the regular DHCP protocol. Matti > > Signed-off-by: Bruno Randolf <br1 at einfach.org > <https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel>> > --- > package/network/utils/wwan/Makefile | 3 +- > package/network/utils/wwan/files/hilink.sh | 56 ++++++++++++++++++++++++++++++ > package/network/utils/wwan/files/wwan.sh | 9 ++++- > 3 files changed, 66 insertions(+), 2 deletions(-) > create mode 100644 package/network/utils/wwan/files/hilink.sh > > diff --git a/package/network/utils/wwan/Makefile b/package/network/utils/wwan/Makefile > index 8d388dc..1917d1c 100644 > --- a/package/network/utils/wwan/Makefile > +++ b/package/network/utils/wwan/Makefile > @@ -2,7 +2,7 @@ include $(TOPDIR)/rules.mk > > PKG_NAME:=wwan > PKG_VERSION:=2014-07-17 > -PKG_RELEASE=1 > +PKG_RELEASE=3 > > PKG_LICENSE:=GPL-2.0 > PKG_LICENSE_FILES:= > @@ -24,6 +24,7 @@ endef > define Package/wwan/install > $(INSTALL_DIR) $(1)/lib/netifd/proto/ > $(CP) ./files/wwan.sh $(1)/lib/netifd/proto/ > + $(CP) ./files/hilink.sh $(1)/lib/netifd/proto/ > $(INSTALL_DIR) $(1)/etc/hotplug.d/usb > $(INSTALL_BIN) ./files/wwan.usb $(1)/etc/hotplug.d/usb/00_wwan.sh > $(INSTALL_DIR) $(1)/etc/hotplug.d/usbmisc > diff --git a/package/network/utils/wwan/files/hilink.sh b/package/network/utils/wwan/files/hilink.sh > new file mode 100644 > index 0000000..229e1a4 > --- /dev/null > +++ b/package/network/utils/wwan/files/hilink.sh > @@ -0,0 +1,56 @@ > +#!/bin/sh > + > +[ -n "$INCLUDE_ONLY" ] || { > + . /lib/functions.sh > + . ../netifd-proto.sh > + init_proto "$@" > +} > + > +proto_hilink_init_config() { > + available=1 > + no_device=1 > + proto_config_add_boolean defaultroute > + proto_config_add_boolean peerdns > + proto_config_add_int metric > +} > + > +proto_hilink_setup() { > + local interface="$1" > + local ifname="$ctl_device" > + local defaultroute peerdns metric > + > + json_get_vars defaultroute peerdns metric > + > + [ -n "$ifname" ] || { > + proto_notify_error "$interface" NO_IFNAME > + proto_set_available "$interface" 0 > + return 1 > + } > + > + logger -p daemon.info -t "hilink[$$]" "Starting DHCP on $ifname" > + proto_init_update "$ifname" 1 > + proto_send_update "$interface" > + > + json_init > + json_add_string name "${interface}_4" > + json_add_string ifname "@$interface" > + json_add_string proto "dhcp" > + [ -n "$defaultroute" ] && json_add_boolean defaultroute "$defaultroute" > + [ -n "$peerdns" ] && json_add_boolean peerdns "$peerdns" > + [ -n "$metric" ] && json_add_int metric "$metric" > + json_close_object > + ubus call network add_dynamic "$(json_dump)" > + > + return 0 > +} > + > +proto_hilink_teardown() { > + local interface="$1" > + > + proto_init_update "*" 0 > + proto_send_update "$interface" > +} > + > +[ -n "$INCLUDE_ONLY" ] || { > + add_protocol hilink > +} > diff --git a/package/network/utils/wwan/files/wwan.sh b/package/network/utils/wwan/files/wwan.sh > index 6b33600..3d80aba 100755 > --- a/package/network/utils/wwan/files/wwan.sh > +++ b/package/network/utils/wwan/files/wwan.sh > @@ -14,12 +14,14 @@ proto_qmi_setup() { echo "wwan[$$] qmi proto is missing"; } > proto_ncm_setup() { echo "wwan[$$] ncm proto is missing"; } > proto_3g_setup() { echo "wwan[$$] 3g proto is missing"; } > proto_directip_setup() { echo "wwan[$$] directip proto is missing"; } > +proto_hilink_setup() { echo "wwan[$$] hilink proto is missing"; } > > [ -f ./mbim.sh ] && . ./mbim.sh > [ -f ./ncm.sh ] && . ./ncm.sh > [ -f ./qmi.sh ] && . ./qmi.sh > [ -f ./3g.sh ] && { . ./ppp.sh; . ./3g.sh; } > [ -f ./directip.sh ] && . ./directip.sh > +[ -f ./hilink.sh ] && . ./hilink.sh > > proto_wwan_init_config() { > available=1 > @@ -66,7 +68,7 @@ proto_wwan_setup() { > } > } > > - [ -z "$ctl_device" ] && for net in $(ls /sys/class/net/ | grep wwan); do > + [ -z "$ctl_device" ] && for net in $(ls /sys/class/net/ | grep -E "wwan|eth"); do > [ -z "$ctl_device" ] || continue > driver=$(grep DRIVER /sys/class/net/$net/device/uevent | cut -d= -f2) > case "$driver" in > @@ -76,6 +78,9 @@ proto_wwan_setup() { > sierra_net|*cdc_ncm) > ctl_device=/dev/$(cd /sys/class/net/$net/; find ../../../ -name ttyUSB* |xargs basename | head -n1) > ;; > + cdc_ether) > + ctl_device=$net > + ;; > *) continue;; > esac > echo "wwan[$$]" "Using proto:$proto device:$ctl_device iface:$net desc:$desc" > @@ -98,6 +103,7 @@ proto_wwan_setup() { > sierra_net) proto_directip_setup $@ ;; > comgt) proto_3g_setup $@ ;; > *cdc_ncm) proto_ncm_setup $@ ;; > + cdc_ether) proto_hilink_setup $@ ;; > esac > } > > @@ -113,6 +119,7 @@ proto_wwan_teardown() { > sierra_net) proto_mbim_teardown $@ ;; > comgt) proto_3g_teardown $@ ;; > *cdc_ncm) proto_ncm_teardown $@ ;; > + cdc_ether) proto_hilink_teardown $@ ;; > esac > } > > -- > 1.9.1
On 2016-02-23 08:11, Matti Laakso wrote: >> Huawei HiLink ("h" model names) modems just provide a CDC Ethernet >> interface >> where we have to run DHCP to get an IP address (usually in the >> 192.168.8.0 >> range). While this may be bad design in general it's sometimes >> necessary to >> support these modems. >> >> This adds autodetection and handling of these to wwan. >> >> Tested with Huawei E3030h-1. > > Why do you need an extra protocol for these? They work just fine with > the regular DHCP protocol. > FYI the hilink modem i have (E3372) only works if you visit one of the pages on the usb sticks built in web server. if you don't visit this page the stick never connects. i have not yet found a good solution to this problem.
On 23/02/2016 08:47, Torbjorn Jansson wrote: > On 2016-02-23 08:11, Matti Laakso wrote: >>> Huawei HiLink ("h" model names) modems just provide a CDC Ethernet >>> interface >>> where we have to run DHCP to get an IP address (usually in the >>> 192.168.8.0 >>> range). While this may be bad design in general it's sometimes >>> necessary to >>> support these modems. >>> >>> This adds autodetection and handling of these to wwan. >>> >>> Tested with Huawei E3030h-1. >> >> Why do you need an extra protocol for these? They work just fine with >> the regular DHCP protocol. >> > > FYI the hilink modem i have (E3372) only works if you visit one of the > pages on the usb sticks built in web server. > if you don't visit this page the stick never connects. > > i have not yet found a good solution to this problem. that is what i thought. i had the idea that we could build a http client to do this but that is a really ugly hack. however reading that 3 people talk to the stick in a different manner makes me wonder if there is more than 1 type of hilink modem ? John > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Dnia 2016-02-23, o godz. 08:54:06 John Crispin <blogic@openwrt.org> napisał(a): > however reading that 3 people talk to the stick in a different manner > makes me wonder if there is more than 1 type of hilink modem ? E3372s-153 (sold in Poland) require only connect to usb and connect automatically.
On 02/23/2016 07:11 AM, Matti Laakso wrote: >> Huawei HiLink ("h" model names) modems just provide a CDC Ethernet >> interface >> where we have to run DHCP to get an IP address (usually in the >> 192.168.8.0 >> range). While this may be bad design in general it's sometimes >> necessary to >> support these modems. >> >> This adds autodetection and handling of these to wwan. >> >> Tested with Huawei E3030h-1. > > Why do you need an extra protocol for these? They work just fine with > the regular DHCP protocol. Hi, sorry I saw this so late... (cc: please). The reason is that I want different types of Modems to work with the same interface configuration, using 'wwan'. E.g. it's configured like this (/etc/config/network): config interface 'umts' option proto wwan option apn internet.eplus.de option metric 4 And it will work with PPP, QMI, MBIM, HiLink or whatever modem supported by "wwan" (which are hopefully more and more)... Doesn't that make sense? It would help the user who doesn't want to guess wether QMI works better than PPP for a specific modem and which serial port to use, etc... bruno
On 02/23/2016 07:54 AM, John Crispin wrote: > On 23/02/2016 08:47, Torbjorn Jansson wrote: >> FYI the hilink modem i have (E3372) only works if you visit one of the >> pages on the usb sticks built in web server. >> if you don't visit this page the stick never connects. >> >> i have not yet found a good solution to this problem. We have only been testing with E303 and we had one of them, which got plugged into a Windows machine. After that it didn't want to autoconnect any more, until we did a "restore factory defaults" or "reset" on it's web server. After that it worked fine again. > that is what i thought. i had the idea that we could build a http client > to do this but that is a really ugly hack. Well, HiLink is a pretty ugly design in any case. E.g. you will run into problems when you want to use 192.168.8.0/24 yourself on another interface. Problem is that some have these sticks and want to use them. If really necessary, this "hilink protocol" could be the place to add these ugly hacks... > however reading that 3 people talk to the stick in a different manner > makes me wonder if there is more than 1 type of hilink modem ? Thats certainly possible, allthough I'd be interested if the "reset" as described above helps. And we all do DHCP or use an IP from the 192.168.8.0/24 range, no? bruno
On 23/02/2016 18:26, Bruno Randolf wrote: > On 02/23/2016 07:11 AM, Matti Laakso wrote: >>> Huawei HiLink ("h" model names) modems just provide a CDC Ethernet >>> interface >>> where we have to run DHCP to get an IP address (usually in the >>> 192.168.8.0 >>> range). While this may be bad design in general it's sometimes >>> necessary to >>> support these modems. >>> >>> This adds autodetection and handling of these to wwan. >>> >>> Tested with Huawei E3030h-1. >> >> Why do you need an extra protocol for these? They work just fine with >> the regular DHCP protocol. > > Hi, sorry I saw this so late... (cc: please). > > The reason is that I want different types of Modems to work with the > same interface configuration, using 'wwan'. E.g. it's configured like > this (/etc/config/network): > > config interface 'umts' > option proto wwan > option apn internet.eplus.de > option metric 4 > > And it will work with PPP, QMI, MBIM, HiLink or whatever modem supported > by "wwan" (which are hopefully more and more)... Doesn't that make > sense? It would help the user who doesn't want to guess wether QMI works > better than PPP for a specific modem and which serial port to use, etc... > > bruno that does indeed make sense and is the core reason why i added the wwan proto/package. i am planning to merge stuff tomorrow during the day and will pick this one up aswell. John
> Subject: Re: [OpenWrt-Devel] [PATCH 1/2] wwan: Add support for CDC (Huawei 'HiLink') Modems > To: malaakso@elisanet.fi; openwrt-devel@lists.openwrt.org > CC: blogic@openwrt.org > From: br1@einfach.org > Date: Tue, 23 Feb 2016 17:26:33 +0000 > > On 02/23/2016 07:11 AM, Matti Laakso wrote: > >> Huawei HiLink ("h" model names) modems just provide a CDC Ethernet > >> interface > >> where we have to run DHCP to get an IP address (usually in the > >> 192.168.8.0 > >> range). While this may be bad design in general it's sometimes > >> necessary to > >> support these modems. > >> > >> This adds autodetection and handling of these to wwan. > >> > >> Tested with Huawei E3030h-1. > > > > Why do you need an extra protocol for these? They work just fine with > > the regular DHCP protocol. > > Hi, sorry I saw this so late... (cc: please). > > The reason is that I want different types of Modems to work with the > same interface configuration, using 'wwan'. E.g. it's configured like > this (/etc/config/network): > > config interface 'umts' > option proto wwan > option apn internet.eplus.de > option metric 4 > > And it will work with PPP, QMI, MBIM, HiLink or whatever modem supported > by "wwan" (which are hopefully more and more)... Doesn't that make > sense? It would help the user who doesn't want to guess wether QMI works > better than PPP for a specific modem and which serial port to use, etc... > That's a good goal, but I think it's confusing for the user when apn and pin options don't work with HiLink modems but do work with all other modems handled by wwan. Matti
On 02/24/2016 06:11 AM, Matti Laakso wrote: >> The reason is that I want different types of Modems to work with the >> same interface configuration, using 'wwan'. E.g. it's configured like >> this (/etc/config/network): >> >> config interface 'umts' >> option proto wwan >> option apn internet.eplus.de >> option metric 4 >> >> And it will work with PPP, QMI, MBIM, HiLink or whatever modem supported >> by "wwan" (which are hopefully more and more)... Doesn't that make >> sense? It would help the user who doesn't want to guess wether QMI works >> better than PPP for a specific modem and which serial port to use, etc... >> > > That's a good goal, but I think it's confusing for the user when apn and > pin options don't work with HiLink modems but do work with all other > modems handled by wwan. Well, you can see it the other way round: they are not needed for HiLink modems and it will "just work"... :) bruno
It is not true. My 3372h may need PIN. It is on me if I disable PIN verification in modem webif. Only problem is that it is not universal - I need send http POST request to webif to unlock SIM, instead AT cmd. So maybe someone implement unlocking hilink modems on every start - so we need PIN. -- S pozdravom Jakub Janco On Wed, Feb 24, 2016 at 7:11 AM, Matti Laakso <malaakso@elisanet.fi> wrote: >> Subject: Re: [OpenWrt-Devel] [PATCH 1/2] wwan: Add support for CDC (Huawei >> 'HiLink') Modems >> To: malaakso@elisanet.fi; openwrt-devel@lists.openwrt.org >> CC: blogic@openwrt.org >> From: br1@einfach.org >> Date: Tue, 23 Feb 2016 17:26:33 +0000 >> >> On 02/23/2016 07:11 AM, Matti Laakso wrote: >> >> Huawei HiLink ("h" model names) modems just provide a CDC Ethernet >> >> interface >> >> where we have to run DHCP to get an IP address (usually in the >> >> 192.168.8.0 >> >> range). While this may be bad design in general it's sometimes >> >> necessary to >> >> support these modems. >> >> >> >> This adds autodetection and handling of these to wwan. >> >> >> >> Tested with Huawei E3030h-1. >> > >> > Why do you need an extra protocol for these? They work just fine with >> > the regular DHCP protocol. >> >> Hi, sorry I saw this so late... (cc: please). >> >> The reason is that I want different types of Modems to work with the >> same interface configuration, using 'wwan'. E.g. it's configured like >> this (/etc/config/network): >> >> config interface 'umts' >> option proto wwan >> option apn internet.eplus.de >> option metric 4 >> >> And it will work with PPP, QMI, MBIM, HiLink or whatever modem supported >> by "wwan" (which are hopefully more and more)... Doesn't that make >> sense? It would help the user who doesn't want to guess wether QMI works >> better than PPP for a specific modem and which serial port to use, etc... >> > > That's a good goal, but I think it's confusing for the user when apn and pin > options don't work with HiLink modems but do work with all other modems > handled by wwan. > > Matti > > > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >
On 24/02/2016 09:08, Bruno Randolf wrote: > On 02/24/2016 06:11 AM, Matti Laakso wrote: >>> The reason is that I want different types of Modems to work with the >>> same interface configuration, using 'wwan'. E.g. it's configured like >>> this (/etc/config/network): >>> >>> config interface 'umts' >>> option proto wwan >>> option apn internet.eplus.de >>> option metric 4 >>> >>> And it will work with PPP, QMI, MBIM, HiLink or whatever modem supported >>> by "wwan" (which are hopefully more and more)... Doesn't that make >>> sense? It would help the user who doesn't want to guess wether QMI works >>> better than PPP for a specific modem and which serial port to use, etc... >>> >> >> That's a good goal, but I think it's confusing for the user when apn and >> pin options don't work with HiLink modems but do work with all other >> modems handled by wwan. > > Well, you can see it the other way round: they are not needed for HiLink > modems and it will "just work"... :) > > bruno > i have to say i agree most with bruno but i need to think about this a bit and i'll test it with the 2 hilinks i have here. i believe that having the wwan proto handle most of the options is desirable as it will not only unify the code path but also the config path which at the end will increase usability. John
On 25/02/2016 08:23, John Crispin wrote: > > > On 24/02/2016 09:08, Bruno Randolf wrote: >> On 02/24/2016 06:11 AM, Matti Laakso wrote: >>>> The reason is that I want different types of Modems to work with the >>>> same interface configuration, using 'wwan'. E.g. it's configured like >>>> this (/etc/config/network): >>>> >>>> config interface 'umts' >>>> option proto wwan >>>> option apn internet.eplus.de >>>> option metric 4 >>>> >>>> And it will work with PPP, QMI, MBIM, HiLink or whatever modem supported >>>> by "wwan" (which are hopefully more and more)... Doesn't that make >>>> sense? It would help the user who doesn't want to guess wether QMI works >>>> better than PPP for a specific modem and which serial port to use, etc... >>>> >>> >>> That's a good goal, but I think it's confusing for the user when apn and >>> pin options don't work with HiLink modems but do work with all other >>> modems handled by wwan. >> >> Well, you can see it the other way round: they are not needed for HiLink >> modems and it will "just work"... :) >> >> bruno >> > > i have to say i agree most with bruno but i need to think about this a > bit and i'll test it with the 2 hilinks i have here. i believe that > having the wwan proto handle most of the options is desirable as it will > not only unify the code path but also the config path which at the end > will increase usability. > > John > Hi, this only works if the sim card has no pin set. correct ? i tried it and without logging into the webui and adding my pin/apn/ ... there it wont go online John
On 26/02/2016 08:50, John Crispin wrote: > > > On 25/02/2016 08:23, John Crispin wrote: >> >> >> On 24/02/2016 09:08, Bruno Randolf wrote: >>> On 02/24/2016 06:11 AM, Matti Laakso wrote: >>>>> The reason is that I want different types of Modems to work with the >>>>> same interface configuration, using 'wwan'. E.g. it's configured like >>>>> this (/etc/config/network): >>>>> >>>>> config interface 'umts' >>>>> option proto wwan >>>>> option apn internet.eplus.de >>>>> option metric 4 >>>>> >>>>> And it will work with PPP, QMI, MBIM, HiLink or whatever modem supported >>>>> by "wwan" (which are hopefully more and more)... Doesn't that make >>>>> sense? It would help the user who doesn't want to guess wether QMI works >>>>> better than PPP for a specific modem and which serial port to use, etc... >>>>> >>>> >>>> That's a good goal, but I think it's confusing for the user when apn and >>>> pin options don't work with HiLink modems but do work with all other >>>> modems handled by wwan. >>> >>> Well, you can see it the other way round: they are not needed for HiLink >>> modems and it will "just work"... :) >>> >>> bruno >>> >> >> i have to say i agree most with bruno but i need to think about this a >> bit and i'll test it with the 2 hilinks i have here. i believe that >> having the wwan proto handle most of the options is desirable as it will >> not only unify the code path but also the config path which at the end >> will increase usability. >> >> John >> > > Hi, > > this only works if the sim card has no pin set. correct ? i tried it and > without logging into the webui and adding my pin/apn/ ... there it wont > go online > > John i have spent ages thinking about this. the main problem is that the unit wont go online unless we previously set the apn/pin, ... in the webui. although having a unified wwan proto is great and we should have hilink support in it, i fear that this will be rather ambiguous to users as they set the pin in uci and then it wont get applied. so i have heavy heartedly decided to NAK this. i wish i had more time so we could hack up a tiny tool to set the webui setting from uci. although that is really would be an ugly hack. sorry but i hope that the explanation makes sense. John > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >
On Tue, Mar 1, 2016 at 9:43 AM, John Crispin <blogic@openwrt.org> wrote: > i have spent ages thinking about this. the main problem is that the unit > wont go online unless we previously set the apn/pin, ... in the webui. > although having a unified wwan proto is great and we should have hilink > support in it, i fear that this will be rather ambiguous to users as > they set the pin in uci and then it wont get applied. so i have heavy > heartedly decided to NAK this. i wish i had more time so we could hack > up a tiny tool to set the webui setting from uci. although that is > really would be an ugly hack. By the way - mikrotik devices has PIN and APN settings for hilink too. Maybe there are some devices which support it - it didnt work for me, I had to set up things over webif. I have done hack with wget to set PIN(huawei 3372h), but it is umaintained for now and I cant test it because we have device on "production" router. Problem can be a lot of APIs. And it needs to be able use cookies and post data.(If I remember I had to download full wget) If someone want play with it: In connect.post the PIN code is not variabled. ----------- config.sh #!/bin/sh gateway_ip="192.168.8.1" base_url="http://${gateway_ip}" cookie_file="/tmp/cookie" connect_data="connect.post" connect_url="${base_url}/api/dialup/mobile-dataswitch" unlocksim_data="unlocksim.post" unlocksim_url="${base_url}/api/pin/operate" token_url="${base_url}/html/home.html" request_token=$(wget -q -t 0 "$token_url" -O - --save-cookies "$cookie_file" --keep-session-cookies | grep csrf_token | head -n1 | cut -d'"' -f4) ---------------------------------------------------------------------------------------------------------------------------------------------------------- ----------- connect.sh #!/bin/sh . config.sh [ -n "$request_token" ] || { echo No request token found exit 1 } wget -q -t 0 --load-cookies "$cookie_file" --header="__RequestVerificationToken: $request_token" \ --post-file="$connect_data" "$connect_url" -O - ---------------------------------------------------------------------------------------------------------------------------------------------------------- ----------- unlocksim.sh #!/bin/sh . config.sh [ -n "$request_token" ] || { echo No request token found exit 1 } wget -q -t 0 --load-cookies "$cookie_file" --header="__RequestVerificationToken: $request_token" \ --post-file="$unlocksim_data" "$unlocksim_url" -O - ---------------------------------------------------------------------------------------------------------------------------------------------------------- ----------- connect.post <?xml version="1.0" encoding="UTF-8"?><request><dataswitch>0</dataswitch></request> ---------------------------------------------------------------------------------------------------------------------------------------------------------- ----------- connect.post <request><OperateType>0</OperateType><CurrentPin>0000</CurrentPin><NewPin></NewPin><PukCode></PukCode></request> ---------------------------------------------------------------------------------------------------------------------------------------------------------- -- S pozdravom Jakub Janco
I corrected filenames.
If someone want play with it:
In unlocksim.post the PIN code is not variabled.
----------- config.sh
#!/bin/sh
gateway_ip="192.168.8.1"
base_url="http://${gateway_ip}"
cookie_file="/tmp/cookie"
connect_data="connect.post"
connect_url="${base_url}/api/dialup/mobile-dataswitch"
unlocksim_data="unlocksim.post"
unlocksim_url="${base_url}/api/pin/operate"
token_url="${base_url}/html/home.html"
request_token=$(wget -q -t 0 "$token_url" -O - --save-cookies
"$cookie_file" --keep-session-cookies | grep csrf_token | head -n1 |
cut -d'"' -f4)
----------------------------------------------------------------------------------------------------------------------------------------------------------
----------- connect.sh
#!/bin/sh
. config.sh
[ -n "$request_token" ] || {
echo No request token found
exit 1
}
wget -q -t 0 --load-cookies "$cookie_file"
--header="__RequestVerificationToken: $request_token" \
--post-file="$connect_data" "$connect_url" -O -
----------------------------------------------------------------------------------------------------------------------------------------------------------
----------- unlocksim.sh
#!/bin/sh
. config.sh
[ -n "$request_token" ] || {
echo No request token found
exit 1
}
wget -q -t 0 --load-cookies "$cookie_file"
--header="__RequestVerificationToken: $request_token" \
--post-file="$unlocksim_data" "$unlocksim_url" -O -
----------------------------------------------------------------------------------------------------------------------------------------------------------
----------- connect.post
<?xml version="1.0"
encoding="UTF-8"?><request><dataswitch>0</dataswitch></request>
----------------------------------------------------------------------------------------------------------------------------------------------------------
----------- unlocksim.post
<request><OperateType>0</OperateType><CurrentPin>0000</CurrentPin><NewPin></NewPin><PukCode></PukCode></request>
----------------------------------------------------------------------------------------------------------------------------------------------------------
--
S pozdravom Jakub Janco
On 01/03/2016 10:34, Jakub Jančo wrote: > On Tue, Mar 1, 2016 at 9:43 AM, John Crispin <blogic@openwrt.org> wrote: >> i have spent ages thinking about this. the main problem is that the unit >> wont go online unless we previously set the apn/pin, ... in the webui. >> although having a unified wwan proto is great and we should have hilink >> support in it, i fear that this will be rather ambiguous to users as >> they set the pin in uci and then it wont get applied. so i have heavy >> heartedly decided to NAK this. i wish i had more time so we could hack >> up a tiny tool to set the webui setting from uci. although that is >> really would be an ugly hack. > > By the way - mikrotik devices has PIN and APN settings for hilink too. > Maybe there are some devices which support it - it didnt work for me, > I had to set up things over webif. > > I have done hack with wget to set PIN(huawei 3372h), but it is > umaintained for now and I cant test it because we have device on > "production" router. > Problem can be a lot of APIs. And it needs to be able use cookies and > post data.(If I remember I had to download full wget) > reallly ugly stuff, but if anyone feels like merging this into the patch that bruno posted then please do so. John > > If someone want play with it: > In connect.post the PIN code is not variabled. > ----------- config.sh > #!/bin/sh > gateway_ip="192.168.8.1" > base_url="http://${gateway_ip}" > cookie_file="/tmp/cookie" > connect_data="connect.post" > connect_url="${base_url}/api/dialup/mobile-dataswitch" > unlocksim_data="unlocksim.post" > unlocksim_url="${base_url}/api/pin/operate" > > token_url="${base_url}/html/home.html" > request_token=$(wget -q -t 0 "$token_url" -O - --save-cookies > "$cookie_file" --keep-session-cookies | grep csrf_token | head -n1 | > cut -d'"' -f4) > ---------------------------------------------------------------------------------------------------------------------------------------------------------- > ----------- connect.sh > #!/bin/sh > > . config.sh > > [ -n "$request_token" ] || { > echo No request token found > exit 1 > } > > wget -q -t 0 --load-cookies "$cookie_file" > --header="__RequestVerificationToken: $request_token" \ > --post-file="$connect_data" "$connect_url" -O - > ---------------------------------------------------------------------------------------------------------------------------------------------------------- > ----------- unlocksim.sh > #!/bin/sh > > . config.sh > > [ -n "$request_token" ] || { > echo No request token found > exit 1 > } > > wget -q -t 0 --load-cookies "$cookie_file" > --header="__RequestVerificationToken: $request_token" \ > --post-file="$unlocksim_data" "$unlocksim_url" -O - > ---------------------------------------------------------------------------------------------------------------------------------------------------------- > ----------- connect.post > <?xml version="1.0" > encoding="UTF-8"?><request><dataswitch>0</dataswitch></request> > ---------------------------------------------------------------------------------------------------------------------------------------------------------- > ----------- connect.post > <request><OperateType>0</OperateType><CurrentPin>0000</CurrentPin><NewPin></NewPin><PukCode></PukCode></request> > ---------------------------------------------------------------------------------------------------------------------------------------------------------- > > > > > > > > > > > -- > S pozdravom Jakub Janco >
On 03/01/2016 08:43 AM, John Crispin wrote: > > > On 26/02/2016 08:50, John Crispin wrote: >> >> >> On 25/02/2016 08:23, John Crispin wrote: >>> >>> >>> On 24/02/2016 09:08, Bruno Randolf wrote: >>>> On 02/24/2016 06:11 AM, Matti Laakso wrote: >>>>>> The reason is that I want different types of Modems to work with the >>>>>> same interface configuration, using 'wwan'. E.g. it's configured like >>>>>> this (/etc/config/network): >>>>>> >>>>>> config interface 'umts' >>>>>> option proto wwan >>>>>> option apn internet.eplus.de >>>>>> option metric 4 >>>>>> >>>>>> And it will work with PPP, QMI, MBIM, HiLink or whatever modem supported >>>>>> by "wwan" (which are hopefully more and more)... Doesn't that make >>>>>> sense? It would help the user who doesn't want to guess wether QMI works >>>>>> better than PPP for a specific modem and which serial port to use, etc... >>>>>> >>>>> >>>>> That's a good goal, but I think it's confusing for the user when apn and >>>>> pin options don't work with HiLink modems but do work with all other >>>>> modems handled by wwan. >>>> >>>> Well, you can see it the other way round: they are not needed for HiLink >>>> modems and it will "just work"... :) >>>> >>>> bruno >>>> >>> >>> i have to say i agree most with bruno but i need to think about this a >>> bit and i'll test it with the 2 hilinks i have here. i believe that >>> having the wwan proto handle most of the options is desirable as it will >>> not only unify the code path but also the config path which at the end >>> will increase usability. >>> >>> John >>> >> >> Hi, >> >> this only works if the sim card has no pin set. correct ? i tried it and >> without logging into the webui and adding my pin/apn/ ... there it wont >> go online >> >> John > > i have spent ages thinking about this. the main problem is that the unit > wont go online unless we previously set the apn/pin, ... in the webui. > although having a unified wwan proto is great and we should have hilink > support in it, i fear that this will be rather ambiguous to users as > they set the pin in uci and then it wont get applied. so i have heavy > heartedly decided to NAK this. i wish i had more time so we could hack > up a tiny tool to set the webui setting from uci. although that is > really would be an ugly hack. > > sorry but i hope that the explanation makes sense. Well, it makes sense only when you need to set APN and PIN. But this seems to depend on the Provider and SIM card settings. I know two cases where this is not necessary: "eplus.de" and "vodafone.es" (PIN lock was disabled manually before in the vodafone.es case). Anyhow, this is maybe not a generic enough situation to merit adding this to OpenWRT... bruno
On 01/03/2016 12:14, Bruno Randolf wrote: > On 03/01/2016 08:43 AM, John Crispin wrote: >> >> >> On 26/02/2016 08:50, John Crispin wrote: >>> >>> >>> On 25/02/2016 08:23, John Crispin wrote: >>>> >>>> >>>> On 24/02/2016 09:08, Bruno Randolf wrote: >>>>> On 02/24/2016 06:11 AM, Matti Laakso wrote: >>>>>>> The reason is that I want different types of Modems to work with the >>>>>>> same interface configuration, using 'wwan'. E.g. it's configured like >>>>>>> this (/etc/config/network): >>>>>>> >>>>>>> config interface 'umts' >>>>>>> option proto wwan >>>>>>> option apn internet.eplus.de >>>>>>> option metric 4 >>>>>>> >>>>>>> And it will work with PPP, QMI, MBIM, HiLink or whatever modem supported >>>>>>> by "wwan" (which are hopefully more and more)... Doesn't that make >>>>>>> sense? It would help the user who doesn't want to guess wether QMI works >>>>>>> better than PPP for a specific modem and which serial port to use, etc... >>>>>>> >>>>>> >>>>>> That's a good goal, but I think it's confusing for the user when apn and >>>>>> pin options don't work with HiLink modems but do work with all other >>>>>> modems handled by wwan. >>>>> >>>>> Well, you can see it the other way round: they are not needed for HiLink >>>>> modems and it will "just work"... :) >>>>> >>>>> bruno >>>>> >>>> >>>> i have to say i agree most with bruno but i need to think about this a >>>> bit and i'll test it with the 2 hilinks i have here. i believe that >>>> having the wwan proto handle most of the options is desirable as it will >>>> not only unify the code path but also the config path which at the end >>>> will increase usability. >>>> >>>> John >>>> >>> >>> Hi, >>> >>> this only works if the sim card has no pin set. correct ? i tried it and >>> without logging into the webui and adding my pin/apn/ ... there it wont >>> go online >>> >>> John >> >> i have spent ages thinking about this. the main problem is that the unit >> wont go online unless we previously set the apn/pin, ... in the webui. >> although having a unified wwan proto is great and we should have hilink >> support in it, i fear that this will be rather ambiguous to users as >> they set the pin in uci and then it wont get applied. so i have heavy >> heartedly decided to NAK this. i wish i had more time so we could hack >> up a tiny tool to set the webui setting from uci. although that is >> really would be an ugly hack. >> >> sorry but i hope that the explanation makes sense. > > Well, it makes sense only when you need to set APN and PIN. But this > seems to depend on the Provider and SIM card settings. > > I know two cases where this is not necessary: "eplus.de" and > "vodafone.es" (PIN lock was disabled manually before in the vodafone.es > case). > > Anyhow, this is maybe not a generic enough situation to merit adding > this to OpenWRT... > > bruno that is a SIM card feature. if you disable the pin none of the protos need a PIN. i tested it on a eplus card and it did require an APN. however there was a patch on the mailing list just now that posted the mikrotik scripts. they should be easy to integrate. i know its an extra todo but we really want to have a solution that will work for all SIM cards and not just some depending on the provide. hope you agree John > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >
diff --git a/package/network/utils/wwan/Makefile b/package/network/utils/wwan/Makefile index 8d388dc..1917d1c 100644 --- a/package/network/utils/wwan/Makefile +++ b/package/network/utils/wwan/Makefile @@ -2,7 +2,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=wwan PKG_VERSION:=2014-07-17 -PKG_RELEASE=1 +PKG_RELEASE=3 PKG_LICENSE:=GPL-2.0 PKG_LICENSE_FILES:= @@ -24,6 +24,7 @@ endef define Package/wwan/install $(INSTALL_DIR) $(1)/lib/netifd/proto/ $(CP) ./files/wwan.sh $(1)/lib/netifd/proto/ + $(CP) ./files/hilink.sh $(1)/lib/netifd/proto/ $(INSTALL_DIR) $(1)/etc/hotplug.d/usb $(INSTALL_BIN) ./files/wwan.usb $(1)/etc/hotplug.d/usb/00_wwan.sh $(INSTALL_DIR) $(1)/etc/hotplug.d/usbmisc diff --git a/package/network/utils/wwan/files/hilink.sh b/package/network/utils/wwan/files/hilink.sh new file mode 100644 index 0000000..229e1a4 --- /dev/null +++ b/package/network/utils/wwan/files/hilink.sh @@ -0,0 +1,56 @@ +#!/bin/sh + +[ -n "$INCLUDE_ONLY" ] || { + . /lib/functions.sh + . ../netifd-proto.sh + init_proto "$@" +} + +proto_hilink_init_config() { + available=1 + no_device=1 + proto_config_add_boolean defaultroute + proto_config_add_boolean peerdns + proto_config_add_int metric +} + +proto_hilink_setup() { + local interface="$1" + local ifname="$ctl_device" + local defaultroute peerdns metric + + json_get_vars defaultroute peerdns metric + + [ -n "$ifname" ] || { + proto_notify_error "$interface" NO_IFNAME + proto_set_available "$interface" 0 + return 1 + } + + logger -p daemon.info -t "hilink[$$]" "Starting DHCP on $ifname" + proto_init_update "$ifname" 1 + proto_send_update "$interface" + + json_init + json_add_string name "${interface}_4" + json_add_string ifname "@$interface" + json_add_string proto "dhcp" + [ -n "$defaultroute" ] && json_add_boolean defaultroute "$defaultroute" + [ -n "$peerdns" ] && json_add_boolean peerdns "$peerdns" + [ -n "$metric" ] && json_add_int metric "$metric" + json_close_object + ubus call network add_dynamic "$(json_dump)" + + return 0 +} + +proto_hilink_teardown() { + local interface="$1" + + proto_init_update "*" 0 + proto_send_update "$interface" +} + +[ -n "$INCLUDE_ONLY" ] || { + add_protocol hilink +} diff --git a/package/network/utils/wwan/files/wwan.sh b/package/network/utils/wwan/files/wwan.sh index 6b33600..3d80aba 100755 --- a/package/network/utils/wwan/files/wwan.sh +++ b/package/network/utils/wwan/files/wwan.sh @@ -14,12 +14,14 @@ proto_qmi_setup() { echo "wwan[$$] qmi proto is missing"; } proto_ncm_setup() { echo "wwan[$$] ncm proto is missing"; } proto_3g_setup() { echo "wwan[$$] 3g proto is missing"; } proto_directip_setup() { echo "wwan[$$] directip proto is missing"; } +proto_hilink_setup() { echo "wwan[$$] hilink proto is missing"; } [ -f ./mbim.sh ] && . ./mbim.sh [ -f ./ncm.sh ] && . ./ncm.sh [ -f ./qmi.sh ] && . ./qmi.sh [ -f ./3g.sh ] && { . ./ppp.sh; . ./3g.sh; } [ -f ./directip.sh ] && . ./directip.sh +[ -f ./hilink.sh ] && . ./hilink.sh proto_wwan_init_config() { available=1 @@ -66,7 +68,7 @@ proto_wwan_setup() { } } - [ -z "$ctl_device" ] && for net in $(ls /sys/class/net/ | grep wwan); do + [ -z "$ctl_device" ] && for net in $(ls /sys/class/net/ | grep -E "wwan|eth"); do [ -z "$ctl_device" ] || continue driver=$(grep DRIVER /sys/class/net/$net/device/uevent | cut -d= -f2) case "$driver" in @@ -76,6 +78,9 @@ proto_wwan_setup() { sierra_net|*cdc_ncm) ctl_device=/dev/$(cd /sys/class/net/$net/; find ../../../ -name ttyUSB* |xargs basename | head -n1) ;; + cdc_ether) + ctl_device=$net + ;; *) continue;; esac echo "wwan[$$]" "Using proto:$proto device:$ctl_device iface:$net desc:$desc" @@ -98,6 +103,7 @@ proto_wwan_setup() { sierra_net) proto_directip_setup $@ ;; comgt) proto_3g_setup $@ ;; *cdc_ncm) proto_ncm_setup $@ ;; + cdc_ether) proto_hilink_setup $@ ;; esac } @@ -113,6 +119,7 @@ proto_wwan_teardown() { sierra_net) proto_mbim_teardown $@ ;; comgt) proto_3g_teardown $@ ;; *cdc_ncm) proto_ncm_teardown $@ ;; + cdc_ether) proto_hilink_teardown $@ ;; esac }
Huawei HiLink ("h" model names) modems just provide a CDC Ethernet interface where we have to run DHCP to get an IP address (usually in the 192.168.8.0 range). While this may be bad design in general it's sometimes necessary to support these modems. This adds autodetection and handling of these to wwan. Tested with Huawei E3030h-1. Signed-off-by: Bruno Randolf <br1@einfach.org> --- package/network/utils/wwan/Makefile | 3 +- package/network/utils/wwan/files/hilink.sh | 56 ++++++++++++++++++++++++++++++ package/network/utils/wwan/files/wwan.sh | 9 ++++- 3 files changed, 66 insertions(+), 2 deletions(-) create mode 100644 package/network/utils/wwan/files/hilink.sh