[spark] Tethering / internet sharing does not work with IPv6-only APNs

VERIFIED FIXED in Firefox OS master

Status

Firefox OS
RIL
P1
normal
VERIFIED FIXED
3 years ago
3 years ago

People

(Reporter: callahad, Assigned: jessica)

Tracking

({dogfood})

unspecified
2.2 S14 (12june)
ARM
Gonk (Firefox OS)
dogfood
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:2.5+, b2g-master verified)

Details

(Whiteboard: [bzlite][spark])

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

3 years ago
User-Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0

I'm unable to get a working connection to the Internet through the Wi-Fi hotspot on my Aries device.

Devices can successfully connect to my hotspot and communicate with other devices in 192.168.x.y, but are unable to connect to the outside world. DNS doesn't resolve, and ping 8.8.8.8 reports "destination net unreachable."

I can ping and communicate with the host phone at 192.168.1.1, and the host phone itself continues to have a working internet connection; sites load normally.
(Reporter)

Comment 1

3 years ago
(FWIW, I tried connecting a Flame running FxOS, a Nexus 5 running Android, and a MacBook Pro running OS X. All three failed, so I'm pretty sure it's an issue with FxOS on my host Aries)
Vincent, Henry, could you take a look at this please? I've experienced this as well.
Blocks: 1162197
blocking-b2g: --- → spark+
Flags: needinfo?(vchang)
Flags: needinfo?(hchang)
Priority: -- → P1
Whiteboard: [bzlite] → [bzlite][spark]
(In reply to Doug Sherk (:drs) (use needinfo?) from comment #2)
> Vincent, Henry, could you take a look at this please? I've experienced this
> as well.

Hi,

Does the wifi tethering fail occasionally or permanently?

Could you help run the following commands for me to debug? Thanks!

$ netcfg
$ iptables -t nat -L
$ ip route

Thanks!
Flags: needinfo?(hchang)
Could it be a dupe of bug 1154291 ? WiFi Tethering works, I'm using it daily.
Flags: needinfo?(drs)
Flags: needinfo?(dan.callahan)
(Reporter)

Comment 5

3 years ago
It's failed 5/5 attempts, so I'd call it permanent. It may be a dupe of 1154291, since I'm also in the US and on T-Mobile. Now that I'm home, I can confirm that the same SIM tethers perfectly in a Nexus 5 running Android, but also fails on a Flame running Firefox OS.

When tethering is enabled, each device reports the following:

IP ROUTE

> shell@aries:/ # ip route
192.168.1.0/24 dev wlan0  proto kernel  scope link  src 192.168.1.1

> shell@hammerhead:/ $ ip route
10.168.187.116 via 21.219.115.169 dev rmnet1  src 21.219.115.168
10.177.0.34 via 21.219.115.169 dev rmnet1  src 21.219.115.168
21.219.115.160/28 dev rmnet1  proto kernel  scope link  src 21.219.115.168
192.168.43.0/24 dev wlan0  proto kernel  scope link  src 192.168.43.1

NETCFG

> shell@aries:/ # netcfg
rev_rmnet0 DOWN                                   0.0.0.0/0   0x00001002 06:9e:65:ca:7a:03
rev_rmnet1 DOWN                                   0.0.0.0/0   0x00001002 d2:57:bf:60:3e:b2
rev_rmnet2 DOWN                                   0.0.0.0/0   0x00001002 8a:3a:e6:09:5f:fd
rev_rmnet3 DOWN                                   0.0.0.0/0   0x00001002 86:d2:ac:39:a8:29
rev_rmnet4 DOWN                                   0.0.0.0/0   0x00001002 0e:f9:54:28:59:0d
rev_rmnet5 DOWN                                   0.0.0.0/0   0x00001002 36:f4:7f:09:a3:95
rev_rmnet6 DOWN                                   0.0.0.0/0   0x00001002 ae:e2:c7:5e:9f:34
rev_rmnet7 DOWN                                   0.0.0.0/0   0x00001002 ea:18:5e:93:86:3c
rev_rmnet8 DOWN                                   0.0.0.0/0   0x00001002 be:94:cd:6d:1b:0d
rmnet0   UP                                     0.0.0.0/0   0x00000041 00:00:00:00:00:00
rmnet1   DOWN                                   0.0.0.0/0   0x00000000 00:00:00:00:00:00
rmnet2   DOWN                                   0.0.0.0/0   0x00000000 00:00:00:00:00:00
rmnet3   DOWN                                   0.0.0.0/0   0x00000000 00:00:00:00:00:00
rmnet4   DOWN                                   0.0.0.0/0   0x00000000 00:00:00:00:00:00
rmnet5   DOWN                                   0.0.0.0/0   0x00000000 00:00:00:00:00:00
rmnet6   DOWN                                   0.0.0.0/0   0x00000000 00:00:00:00:00:00
rmnet7   DOWN                                   0.0.0.0/0   0x00000000 00:00:00:00:00:00
dummy0   DOWN                                   0.0.0.0/0   0x00000082 0a:7e:36:98:15:d3
rmnet_usb0 DOWN                                   0.0.0.0/0   0x00001002 7a:c6:ea:56:1a:ff
p2p0     DOWN                                   0.0.0.0/0   0x00001002 be:6e:64:e9:14:5a
sit0     DOWN                                   0.0.0.0/0   0x00000080 00:00:00:00:00:00
lo       UP                                   127.0.0.1/8   0x00000049 00:00:00:00:00:00
wlan0    UP                                 192.168.1.1/24  0x00001043 bc:6e:64:e9:14:5a

> shell@hammerhead:/ $ netcfg
rev_rmnet3 DOWN                                   0.0.0.0/0   0x00001002 e6:66:6e:4b:66:2a
rev_rmnet2 DOWN                                   0.0.0.0/0   0x00001002 72:9f:8b:1f:ec:d9
rev_rmnet4 DOWN                                   0.0.0.0/0   0x00001002 7a:7f:c8:b7:98:e0
rev_rmnet6 DOWN                                   0.0.0.0/0   0x00001002 6e:30:0f:c5:b0:83
rev_rmnet5 DOWN                                   0.0.0.0/0   0x00001002 16:d9:08:bc:ff:3a
rev_rmnet7 DOWN                                   0.0.0.0/0   0x00001002 9a:89:e1:0b:16:69
rev_rmnet8 DOWN                                   0.0.0.0/0   0x00001002 6a:39:1a:bc:a5:25
rev_rmnet0 DOWN                                   0.0.0.0/0   0x00001002 22:3a:0c:b0:a7:0b
rev_rmnet1 DOWN                                   0.0.0.0/0   0x00001002 d2:6c:d0:0f:d8:8b
rmnet3   DOWN                                   0.0.0.0/0   0x00000000 00:00:00:00:00:00
rmnet2   DOWN                                   0.0.0.0/0   0x00000000 00:00:00:00:00:00
rmnet4   DOWN                                   0.0.0.0/0   0x00000000 00:00:00:00:00:00
rmnet6   DOWN                                   0.0.0.0/0   0x00000000 00:00:00:00:00:00
rmnet5   DOWN                                   0.0.0.0/0   0x00000000 00:00:00:00:00:00
rmnet7   DOWN                                   0.0.0.0/0   0x00000000 00:00:00:00:00:00
rmnet0   UP                                     0.0.0.0/0   0x00000041 00:00:00:00:00:00
rmnet1   UP                              21.219.115.168/28  0x00000041 00:00:00:00:00:00
v4-rmnet0 UP                                   192.0.0.4/32  0x000010d1 00:00:00:00:00:00
lo       UP                                   127.0.0.1/8   0x00000049 00:00:00:00:00:00
p2p0     DOWN                                   0.0.0.0/0   0x00001002 36:4d:f7:53:6a:9f
sit0     DOWN                                   0.0.0.0/0   0x00000080 00:00:00:00:00:00
wlan0    UP                                192.168.43.1/24  0x00001043 02:1a:11:ff:f5:13

IPTABLES -T NAT -L

> shell@flame:/ # iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
oem_nat_pre  all  --  anywhere             anywhere

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
natctrl_nat_POSTROUTING  all  --  anywhere             anywhere
st_nat_POSTROUTING  all  --  anywhere             anywhere

Chain natctrl_nat_POSTROUTING (1 references)
target     prot opt source               destination
MASQUERADE  all  --  anywhere             anywhere

Chain oem_nat_pre (1 references)
target     prot opt source               destination

Chain st_nat_POSTROUTING (1 references)
target     prot opt source               destination

> shell@hammerhead:/ $
(The nexus 5 isn't rooted, so I can't list the nat table)
Flags: needinfo?(dan.callahan)
(Reporter)

Comment 6

3 years ago
Whoops, accidentally copied the flame's nat table there. The table on my aries is identical.

If having the nat table on a working Android device is crucial, I can re-flash my old, rooted Nexus 4 and see what that gives us.
Duplicate of this bug: 1154291
Summary: [spark] Tethering / internet sharing does not work → [spark] Tethering / internet sharing does not work with T-Mobile in the USA
Can we reverify if it's not related to this "dun" APN thing ? Like bug 1134644 ?
(Reporter)

Comment 9

3 years ago
Pretty certain it's not the dun thing, as I don't have a dun APN defined in settings. Things still fail if I add one manually.

I'm noticing a few things in adb logcat:

> D/TetherController(  292): Starting tethering services
> D/radish  ( 2193): radish_init_bridge: brctl addbr bridge0
> D/TetherController(  292): Sending update msg to dnsmasq [update_ifaces:wlan0]
> D/TetherController(  292): Tethering services running
> D/CommandListener(  292): TetherCmd::runCommand. argc: 5. argv[0]: tether
> D/TetherController(  292): setDnsForwarders(0 = '8.8.8.8')
> D/TetherController(  292): setDnsForwarders(1 = '8.8.4.4')
> D/TetherController(  292): Sending update msg to dnsmasq [update_dns:8.8.8.8:8.8.4.4]
> V/NatController(  292): enableNat(intIface=<wlan0>, extIface=<rmnet0>)
> E/radish  ( 2193): Cannot create the bridge interface
> D/radish  ( 2193): radish_init_bridge: ifconfig bridge0 up
> V/NatController(  292): runCmd(/system/bin/iptables -t nat -A natctrl_nat_POSTROUTING -o rmnet0 -j MASQUERADE) res=0
> I/dnsmasq ( 2198): started, version 2.51 cachesize 150
> I/dnsmasq ( 2198): compile time options: no-IPv6 GNU-getopt no-DBus no-I18N DHCP no-scripts no-TFTP
> W/dnsmasq ( 2198): warning: no upstream servers configured
> I/dnsmasq ( 2198): DHCP, IP range 192.168.0.10 -- 192.168.0.30, lease time 1h
> I/dnsmasq ( 2198): DHCP, IP range 192.168.1.10 -- 192.168.1.30, lease time 1h

One is that the bridge0 interface isn't getting created.

The other is that dnsmasq was compiled without IPv6 support. Since T-Mobile is fully IPv6 in the US, might that cause issue
with DNS forwarding?
(In reply to Dan Callahan [:callahad] from comment #9)
> Pretty certain it's not the dun thing, as I don't have a dun APN defined in
> settings. Things still fail if I add one manually.
> 
> I'm noticing a few things in adb logcat:
> 
> > D/TetherController(  292): Starting tethering services
> > D/radish  ( 2193): radish_init_bridge: brctl addbr bridge0
> > D/TetherController(  292): Sending update msg to dnsmasq [update_ifaces:wlan0]
> > D/TetherController(  292): Tethering services running
> > D/CommandListener(  292): TetherCmd::runCommand. argc: 5. argv[0]: tether
> > D/TetherController(  292): setDnsForwarders(0 = '8.8.8.8')
> > D/TetherController(  292): setDnsForwarders(1 = '8.8.4.4')
> > D/TetherController(  292): Sending update msg to dnsmasq [update_dns:8.8.8.8:8.8.4.4]
> > V/NatController(  292): enableNat(intIface=<wlan0>, extIface=<rmnet0>)
> > E/radish  ( 2193): Cannot create the bridge interface
> > D/radish  ( 2193): radish_init_bridge: ifconfig bridge0 up
> > V/NatController(  292): runCmd(/system/bin/iptables -t nat -A natctrl_nat_POSTROUTING -o rmnet0 -j MASQUERADE) res=0
> > I/dnsmasq ( 2198): started, version 2.51 cachesize 150
> > I/dnsmasq ( 2198): compile time options: no-IPv6 GNU-getopt no-DBus no-I18N DHCP no-scripts no-TFTP
> > W/dnsmasq ( 2198): warning: no upstream servers configured
> > I/dnsmasq ( 2198): DHCP, IP range 192.168.0.10 -- 192.168.0.30, lease time 1h
> > I/dnsmasq ( 2198): DHCP, IP range 192.168.1.10 -- 192.168.1.30, lease time 1h
> 
> One is that the bridge0 interface isn't getting created.

I don't think it's a problem

> 
> The other is that dnsmasq was compiled without IPv6 support. Since T-Mobile
> is fully IPv6 in the US, might that cause issue
> with DNS forwarding?

That might on the other hand be a very good lead. Sadly, we don't have IPv6-enabled mobile carrier here in France, so you're on your own.

Is it only IPv6 ? Do you get working IPv6 stuff ?
(Reporter)

Comment 11

3 years ago
> we don't have IPv6-enabled mobile carrier here in France, so you're on your own.

Pfft, I could totally set up a VNC server or something and let you attempt to remote-control my device. ;)

T-Mobile defaults to IPv6-only on newish phones, and has for about a year and a half: http://www.dslreports.com/shownews/TMobile-Goes-IPv6-Only-on-Android-44-Devices-126506

It works, too! I can see the dancing kame when I hit http://www.kame.net/ :)

I'll try setting the APNs to IPv4 and seeing what happens.
(In reply to Dan Callahan [:callahad] from comment #11)
> > we don't have IPv6-enabled mobile carrier here in France, so you're on your own.
> 
> Pfft, I could totally set up a VNC server or something and let you attempt
> to remote-control my device. ;)

Yes, but I'm somehow on PTO those days and with very reduced connectivity because of a fiber cut since yesterday, no more DSL maybe until next monday. So not the best conditions.

> 
> T-Mobile defaults to IPv6-only on newish phones, and has for about a year
> and a half:
> http://www.dslreports.com/shownews/TMobile-Goes-IPv6-Only-on-Android-44-
> Devices-126506
> 
> It works, too! I can see the dancing kame when I hit http://www.kame.net/ :)
> 
> I'll try setting the APNs to IPv4 and seeing what happens.

Sure. If it's only IPv6 enabling, we should be able to fix it soon.
(Reporter)

Comment 13

3 years ago
Hah! It's totally IPv6! Setting the "T-Mobile GPRS" APNs to IPv4 results in working tethering.
Flags: needinfo?(drs)
Flags: needinfo?(changyihsin)
Summary: [spark] Tethering / internet sharing does not work with T-Mobile in the USA → [spark] Tethering / internet sharing does not work with IPv6-only APNs
Created attachment 8615335 [details]
Removing NO_IPV6 build flag
Created attachment 8615338 [details]
/system/bin/dnsmasq with NO_IPV6

adb root && adb wait-for-device && adb remount && adb push dnsmasq /system/bin/dnsmasq && adb reboot
Flags: needinfo?(dan.callahan)
Attachment #8615338 - Attachment description: /system/bin/dnsmasq without NO_IPV6 → /system/bin/dnsmasq with NO_IPV6
Created attachment 8615341 [details]
/system/bin/dnsmasq without NO_IPV6

This one should be the good one.
Attachment #8615338 - Attachment is obsolete: true
(Reporter)

Comment 17

3 years ago
I also had to chmod 755 dnsmasq since the default is evidently 666, which the OS refuses to execute.

Things look more promising in that I see a ton of radish tcp6 lines in my logcat now. However, I can't seem to maintain a connection to the hotspot, and I also see:

> adb logcat | grep dnsmasq
> D/TetherController(  292): Sending update msg to dnsmasq [update_ifaces:wlan0]
> D/TetherController(  292): Sending update msg to dnsmasq [update_dns:8.8.8.8:8.8.4.4]
> I/dnsmasq ( 1841): started, version 2.51 cachesize 150
> I/dnsmasq ( 1841): compile time options: IPv6 GNU-getopt no-DBus no-I18N DHCP no-scripts no-TFTP
> W/dnsmasq ( 1841): warning: no upstream servers configured
> I/dnsmasq ( 1841): DHCP, IP range 192.168.0.10 -- 192.168.0.30, lease time 1h
> I/dnsmasq ( 1841): DHCP, IP range 192.168.1.10 -- 192.168.1.30, lease time 1h
> I/dnsmasq ( 1841): read /etc/hosts - 1 addresses
> E/dnsmasq ( 1841): failed to bind listening socket for fe80::be6e:64ff:fee9:145a: Address already in use
> E/dnsmasq ( 1841): FAILED to start up
Flags: needinfo?(dan.callahan)
(Reporter)

Comment 19

3 years ago
Looks like IPv6 tethering isn't supported in upstream AOSP (see comment 21 in Bug 1057091).

Setting the T-Mobile APN to "IPv6/IPv4" seems to give me the best possible compromise: my Aries device still talks to the outside world over IPv6, while connected clients work and talk to the outside world over IPv4.
Henry, can you take this?
Flags: needinfo?(hchang)
(Assignee)

Comment 21

3 years ago
Thanks for reporting this. In Aries/Shinano, we have enabled ipv6 [1], so some carriers will have ipv6 data connection by default, in contrast to Flame, we have ipv6 disabled.

In bug 1057091, we have added support for ipv6 tethering, but it doesn't work on pure AOSP, it only runs on proprietary builds, so ipv6 tethering is disabled by default.

After discussing internally, we are considering disabling ipv6 on Aries/Shinano, to make sure all of the functions behave properly, just like Flame. We can enable ipv6 back once we fully support ipv6, including functions like tethering, mms, etc.


[1] https://github.com/mozilla-b2g/device-shinano-common/blob/master/device.mk#L25
(In reply to Jessica Jong [:jjong] [:jessica] from comment #21)
> Thanks for reporting this. In Aries/Shinano, we have enabled ipv6 [1], so
> some carriers will have ipv6 data connection by default, in contrast to
> Flame, we have ipv6 disabled.
> 
> In bug 1057091, we have added support for ipv6 tethering, but it doesn't
> work on pure AOSP, it only runs on proprietary builds, so ipv6 tethering is
> disabled by default.
> 
> After discussing internally, we are considering disabling ipv6 on
> Aries/Shinano, to make sure all of the functions behave properly, just like
> Flame. We can enable ipv6 back once we fully support ipv6, including
> functions like tethering, mms, etc.
> 
> 
> [1]
> https://github.com/mozilla-b2g/device-shinano-common/blob/master/device.
> mk#L25

Sorry, blame on me. It's my bad to enable ipv6 for shinano/aries simply based on the hw capability. I'd agree and support Jessica's suggestion that we disable ipv6 on shinao/aries considering the whole ipv6 feature support on FxOS, and also to make all the functions behave correctly.
(In reply to Hsin-Yi Tsai [:hsinyi] from comment #22)
> Sorry, blame on me. It's my bad to enable ipv6 for shinano/aries simply
> based on the hw capability. I'd agree and support Jessica's suggestion that
> we disable ipv6 on shinao/aries considering the whole ipv6 feature support
> on FxOS, and also to make all the functions behave correctly.

My understanding is that IPv6 may be breaking many other things such as WiFi. If so, I would support this. Any thoughts, Alex?
Flags: needinfo?(lissyx+mozillians)
See Also: → bug 1171283
Flags: needinfo?(lissyx+mozillians)
(Assignee)

Comment 24

3 years ago
Created attachment 8617240 [details] [review]
PR to disable ipv6 on shinano-device-common
(Assignee)

Comment 25

3 years ago
(In reply to Jessica Jong [:jjong] [:jessica] from comment #24)
> Created attachment 8617240 [details] [review]
> PR to disable ipv6 on shinano-device-common

Dan, could you build an image with this PR to see if tethering works as expected? Thanks.
Flags: needinfo?(dan.callahan)
(Reporter)

Comment 26

3 years ago
Unfortunately, I don't currently have a B2G build environment set up. Maybe :kgrandon from Bug 1154291 could test this, if he's back from PTO?
Flags: needinfo?(dan.callahan) → needinfo?(kgrandon)
Naoki, could you provide build with this patch applied? Dan and I can test it.
Flags: needinfo?(nhirata.bugzilla)
commit 694df9d431897ba4bec67d8e5c62fa1d05badd60
Merge: 9934000 1d285cf
Author: nhirata <nhirata.bugzilla@gmail.com>
Date:   Tue Jun 9 18:57:26 2015 -0700

    Merge branch 'bug-1171185' of https://github.com/jessi3py/device-shinano-com

commit 9934000e6d842b4c4d76fb56f52584e1a3819c9c
Merge: dfcb155 ff18a03
Author: lissyx <lissyx+github@lissyx.dyndns.org>
Date:   Tue Jun 9 19:55:26 2015 +0200

    Merge pull request #20 from sotaroikeda/bug1169505
    
    Bug 1169505 - Remove libExtendedExtractor.so


Build being made.
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #29)
> Build made and shared: 
> https://drive.google.com/a/mozilla.com/file/d/0B_0LdM1CVycIYUJwdUJqM2xJMFU/
> view?usp=sharing

Test this.
Flags: needinfo?(drs)

Updated

3 years ago
Flags: needinfo?(hchang)
My tethering was working before this build, but it's still working after. Thus my results are inconclusive. Let's go ahead and land this and we can revisit it if it doesn't fix the issue for others.
Flags: needinfo?(drs) → needinfo?(jjong)
QAWanted: please test with both at&T sims and T-mobile sims with the build in Comment 29.  bug also affected is bug 1171283.  T-Mobile should be able to send MMS after this patch, and we should also be able to tether the device as well as use wifi hotspot.  Other things to test is making sure that we can still retrieve data (web browse) with only the SIM data.
Keywords: qaurgent, qawanted
(Assignee)

Comment 33

3 years ago
Comment on attachment 8617240 [details] [review]
PR to disable ipv6 on shinano-device-common

Alexandre, we are disabling ipv6 on shinano for now, may I have your review on this? Thanks.
Flags: needinfo?(jjong)
Attachment #8617240 - Flags: review?(lissyx+mozillians)
Comment on attachment 8617240 [details] [review]
PR to disable ipv6 on shinano-device-common

Sure, I'm trusting you since we have no IPv6 mobile network here :)
Attachment #8617240 - Flags: review?(lissyx+mozillians) → review+
QA Contact: pcheng
Tested on Aries with AT&T SIM with custom build from comment 29, the result is a pass. I was able to browse websites using Data connection, and other devices are able to connect to Aries as a wifi hotspot. (Note: I wasn't able to repro the bug before patch on AT & T SIM).

Tested on Aries with T-Mobile SIM with custom build from comment 29, the result is a fail. I was able to browse website using Data connection, BUT other devices are NOT able to connect to Aries as a wifi hotspot. Also, bug 1171283 is NOT fixed in this patch either.

Conclusion: The patch does not fix this bug, nor does it fix bug 1171283.
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-master: --- → affected
Flags: needinfo?(ktucker)
Keywords: qaurgent, qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Looks like the patch doesn't fix the t-mobile issue.  I think we should still disable it for the time being and look at other causes for this bug to occur.
Flags: needinfo?(jjong)
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #36)
> Looks like the patch doesn't fix the t-mobile issue.  I think we should
> still disable it for the time being and look at other causes for this bug to
> occur.

I agree.
(Assignee)

Comment 38

3 years ago
Thanks Pi Wei for your help.

Could you grab logs with ril log and network log enabled to see whether ipv4 or ipv6 connection was used? You can enable both logs from Settings -> Developer and check 'RIL Output in ADB' and 'Network Output in ADB', and then reboot after that.
Flags: needinfo?(pcheng)
(Assignee)

Comment 39

3 years ago
Thanks Alexandre for the review.

As comment 36 and comment 37, requesting checkin-needed.
Keywords: checkin-needed
(Assignee)

Comment 40

3 years ago
(In reply to Jessica Jong [:jjong] [:jessica] from comment #38)
> Thanks Pi Wei for your help.
> 
> Could you grab logs with ril log and network log enabled to see whether ipv4
> or ipv6 connection was used? You can enable both logs from Settings ->
> Developer and check 'RIL Output in ADB' and 'Network Output in ADB', and
> then reboot after that.

Could you also run the following command:

# adb shell getprop ro.moz.ril.ipv6

and see what you get? Thanks a lot!
(In reply to Jessica Jong [:jjong] [:jessica] from comment #40)
> (In reply to Jessica Jong [:jjong] [:jessica] from comment #38)
> > Thanks Pi Wei for your help.
> > 
> > Could you grab logs with ril log and network log enabled to see whether ipv4
> > or ipv6 connection was used? You can enable both logs from Settings ->
> > Developer and check 'RIL Output in ADB' and 'Network Output in ADB', and
> > then reboot after that.
> 
> Could you also run the following command:
> 
> # adb shell getprop ro.moz.ril.ipv6
> 
> and see what you get? Thanks a lot!

Looks like Naoki missed something, since I have downloaded the build and mounted system partition, and in build.prop there is still the ro.moz.ril.ipv6 defined :(

> $ grep ro.moz system/build.prop 
> ro.moz.nfc.enabled=true
> ro.moz.bluetooth.backend=bluetoothd
> ro.moz.ril.ipv6=true
> ro.moz.ril.signal_extra_int=true
> ro.moz.has_home_button=0

So the test in comment 35 is useless. Please, just:
> adb pull /system/build.prop

Remove the line for the property ro.moz.ril.ipv6, then:
> adb push build.prop /system/build.prop && adb shell chmod 644 /system/build.prop && adb reboot

That should be enough to assert.
Flags: needinfo?(dan.callahan)
https://github.com/mozilla-b2g/device-shinano-common/commit/ac45522bb3a14aff9facd74e2cd03430e1e0793f
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Spoke to Alexandre, turns out that I most likely need to clobber.  Making a new build with the clobber for retesting.  I asked for the patch to be pushed.
Flags: needinfo?(nhirata.bugzilla)
Keywords: verifyme
Flags: needinfo?(pcheng)
Tested with T Mobile SIM on Aries with build from comment 44, the result is a pass. I was able to browse the web via Data connection, and other devices are able to browse websites via Aries as a wifi hotspot.

I have also verified that bug 1171283 is fixed with this change. I can now send MMS without issue. I'll be marking that bug as fixed as well.

----

I cleared NI without message on previous comment. Jessica, I believe the logs are no longer needed since I was testing on a build without fix on comment 35.

----

Leaving verifyme keyword for an actual verification on the next nightly build.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
status-b2g-master: affected → fixed
Flags: needinfo?(ktucker)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
(In reply to Dan Callahan [:callahad] from comment #26)
> Maybe :kgrandon from Bug 1154291 could test this, if he's back from PTO?

Looks like qa has been testing this in comment 35 and comment 45. Thanks for addressing this one, and for figuring out the cause.
Flags: needinfo?(kgrandon)
(Assignee)

Comment 47

3 years ago
Thanks for providing the new build and testing it. :)
Assignee: nobody → jjong
Component: Gaia::Feedback → RIL
Flags: needinfo?(jjong)
OS: All → Gonk (Firefox OS)
Hardware: All → ARM
Target Milestone: --- → 2.2 S14 (12june)
(Assignee)

Updated

3 years ago
No longer depends on: 1174004
This issue is verified fixed on Aries. Devices are able to connect to Aries acting as a Wifi hotspot and browse the web. T-mobile SIM was used on the Aries.

Device: Aries
BuildID: 20150617002346
Gaia: 6271f932e1e918a35ee89f54288bd13385143a71
Gecko: d7c148c84594
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 41.0a1 (3.0) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
status-b2g-master: fixed → verified
Flags: needinfo?(ktucker)
Keywords: verifyme
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
blocking-b2g: spark+ → 2.5+
status-b2g-v2.5: --- → verified
status-b2g-v2.5: verified → ---
See Also: → bug 1181397

Updated

3 years ago
Blocks: 1183002
(Reporter)

Comment 49

3 years ago
Clearing old needinfo; this is working great for me.
Flags: needinfo?(dan.callahan)
You need to log in before you can comment on or make changes to this bug.