<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Hi Antti,<br><br>> Date: Thu, 17 Sep 2015 10:15:21 +0300<br><div>> Subject: Re: [OpenWrt-Devel] [PATCH v2] uqmi: Add proper IPv6 support<br>> From: a.seppala@gmail.com<br>> To: malaakso@elisanet.fi<br>> CC: openwrt-devel@lists.openwrt.org<br>> <br>> On 10 September 2015 at 22:03, Matti Laakso <malaakso@elisanet.fi> wrote:<br>> > Use the new --ip-family option to start both IPv4 and IPv6 sessions<br>> > by default. Autoconnect can't be used when starting two sessions,<br>> > so revert back to using the client IDs and packet data handles for<br>> > handling the network connection.<br>> ><br>> > Some modem firmwares do not implement a RA server, therefore by<br>> > default use outband IP configuration and static addressing. Some<br>> > other firmwares report bogus IP configuration with the WDS get<br>> > current settings command. In this case inband configuration with<br>> > DHCP/RA can be optionally enabled by setting option dhcp to 1.<br>> ><br>> > Per 3GPP standard a /64 prefix is served to all clients, which is<br>> > extended to LAN as specified in RFC 7278.<br>> ><br>> > v2: Restrict the IPv6 gateway route source address<br>> > Signed-off-by: Matti Laakso <malaakso@elisanet.fi><br>> <br>> Hi Matti.<br>> <br>> I built openwrt with uqmi built into the squashfs with your patch<br>> applied and for some reason the qmi.sh does not get execute bit when<br>> installed:<br>> <br>> root@OpenWrt:~# ls -l /lib/netifd/proto/<br>> -rwxr-xr-x 1 root root 2430 Sep 16 20:30 3g.sh<br>> -rwxr-xr-x 1 root root 2165 Sep 16 20:30 dhcp.sh<br>> -rwxr-xr-x 1 root root 3508 Sep 16 20:30 dhcpv6.sh<br>> -rwxr-xr-x 1 root root 3393 Sep 16 20:30 openconnect.sh<br>> -rwxr-xr-x 1 root root 6945 Sep 16 20:30 ppp.sh<br>> -rw-r--r-- 1 root root 6557 Sep 16 20:30 qmi.sh<br>> -rwxr-xr-x 1 root root 3325 Sep 16 20:30 wwan.sh<br>> <br>> Apparently the protocol won't then load properly. Any idea why this<br>> is? Applying chmod +x to the file makes the protocol work.<br>> <br><br>Good catch, my patch accidentally contained an unintended mode change from 755 to 644.<br><br>> The other thing I was wondering is the tests for the new boolean<br>> variables with -z. E.g if there now is an explicit config directive to<br>> set dhcp off ("option dhcp 0") then dhcp would still be enabled.<br>> <br>> I think the recommended design is to use something along the lines of:<br>> if [ "${boolean_variable:-0}" -gt 0 ]; then whatever; fi<br>> It looks like this should maybe apply to both dhcp and ipv6 variables?<br>> <br><br>That's true with the dhcp option, but ipv6 should work correctly since it is explicitely set to "" if ipv6=0.<br><br>I'll fix both the execute bit and the dhcp option handling later today. Thanks for reporting!<br><br>Matti<br></div> </div></body>
</html>