Missing Gateway field on IPv6 |
|||||||
Issue description
The ONC specification states that in an IPConfig object, the Gateway field is required if the IPAddress field is set. However, it is currently empty for IPv6 objects. It appears to be empty because shill returns an empty Gateway field:
# dbus-send --system --dest=org.chromium.flimflam --print-reply /ipconfig/eth0_1_ip org.chromium.flimflam.IPConfig.GetProperties
method return sender=:1.9 -> dest=:1.71 reply_serial=2
array [
dict entry(
string "AcceptedHostname"
variant string ""
)
dict entry(
string "Address"
variant string "2620:0:1000:1305:61fc:cbea:e291:6bbe"
)
dict entry(
string "Broadcast"
variant string ""
)
dict entry(
string "Dhcpv6Addresses"
variant array [
]
)
dict entry(
string "Dhcpv6DelegatedPrefixes"
variant array [
]
)
dict entry(
string "DomainName"
variant string ""
)
dict entry(
string "Gateway"
variant string ""
)
shill's doc/ipconfig-api.txt does not make any claims as to whether the field will be populated.
Possible solutions include:
1) Make shill populate the Gateway field.
2) Change the ONC spec to make Gateway optional.
,
Jul 11 2016
The following revision refers to this bug: https://chromium.googlesource.com/aosp/platform/system/connectivity/shill/+/496f396f9178b2830a60e3f667321f7eae5c482c commit 496f396f9178b2830a60e3f667321f7eae5c482c Author: Kevin Cernekee <cernekee@chromium.org> Date: Sun Jul 03 21:24:48 2016 Handle duplicate IPv6 default routes After shill adjusts a default IPv6 route to use a metric other than 1024, the kernel will re-create a duplicate route with a metric of 1024 the next time it receives a Router Advertisement. Ignore these redundant routes when shill is trying to adjust the metric, by choosing the default route with the lowest (most preferred) metric. BUG= chromium:625229 TEST=run `ip -6 route list` while hot plugging / unplugging a USB ethernet adapter Change-Id: I9a775cc2435ba4cb1b7a235cfc8753b5a171df1d Reviewed-on: https://chromium-review.googlesource.com/358143 Commit-Ready: Kevin Cernekee <cernekee@chromium.org> Tested-by: Kevin Cernekee <cernekee@chromium.org> Reviewed-by: Eric Caruso <ejcaruso@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@google.com> [modify] https://crrev.com/496f396f9178b2830a60e3f667321f7eae5c482c/routing_table.cc [modify] https://crrev.com/496f396f9178b2830a60e3f667321f7eae5c482c/routing_table_unittest.cc
,
Jul 11 2016
The following revision refers to this bug: https://chromium.googlesource.com/aosp/platform/system/connectivity/shill/+/6bbd442d269e108eedf9e762bd5fa2fe18a05a4b commit 6bbd442d269e108eedf9e762bd5fa2fe18a05a4b Author: Kevin Cernekee <cernekee@chromium.org> Date: Sun Jul 03 18:40:01 2016 Track the IPv6 default gateway on each connection shill currently does not look at the default gateway created by the kernel's stateless autoconfiguration mechanism. This leads to several issues: 1) The IPConfig Gateway property is left blank even when a gateway has been configured. 2) Since ONC in Chrome promises that its own gateway field will be populated whenever an IP address is present, this leads to an ONC spec violation that may confuse clients that use ONC APIs. 3) The kernel always seems to assign a metric of IP6_RT_PRIO_USER (1024) to all IPv6 default routes, rather than honoring the technology/service preference order. This can cause IPv6 traffic to be inadvertently routed through a non-default service. 4) When ARC sets up forwarding rules through netfilter, it explicitly whitelists the interface associated with the default service. If the kernel picks a default route on a different interface, all IPv6 traffic from the container will be dropped even though the containerized OS believes it has a usable IPv6 address with global scope. BUG= chromium:625229 TEST=`FEATURES=test emerge-link shill` TEST=`ip -6 route list` with multiple interfaces connected, and verify that the metric on each default route matches with IPv4 Change-Id: Ie900529c3895d5e8f0c4d1b148d9f7401559db85 Reviewed-on: https://chromium-review.googlesource.com/358139 Commit-Ready: Kevin Cernekee <cernekee@chromium.org> Tested-by: Kevin Cernekee <cernekee@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@google.com> [modify] https://crrev.com/6bbd442d269e108eedf9e762bd5fa2fe18a05a4b/routing_table_unittest.cc [modify] https://crrev.com/6bbd442d269e108eedf9e762bd5fa2fe18a05a4b/connection.cc [modify] https://crrev.com/6bbd442d269e108eedf9e762bd5fa2fe18a05a4b/connection.h [modify] https://crrev.com/6bbd442d269e108eedf9e762bd5fa2fe18a05a4b/device.cc [modify] https://crrev.com/6bbd442d269e108eedf9e762bd5fa2fe18a05a4b/device.h [modify] https://crrev.com/6bbd442d269e108eedf9e762bd5fa2fe18a05a4b/routing_table.cc
,
Jul 11 2016
The following revision refers to this bug: https://chromium.googlesource.com/aosp/platform/system/connectivity/shill/+/d9064490e6d3729499bb78aa9f3d1c034c8ef57e commit d9064490e6d3729499bb78aa9f3d1c034c8ef57e Author: Kevin Cernekee <cernekee@chromium.org> Date: Tue Jul 05 02:28:49 2016 Allow duplicate routes with different metrics When a new route shows up, RouteMsgHandler() currently scans the list of known routes for matches. If a matching route with a different metric is found, the old entry is replaced by the new entry. But on IPv6 it is normal for the kernel to add duplicate default routes with different metrics in response to RA messages received off the LAN. So shill needs to track the duplicate routes so that it knows which entries to have the kernel delete when the service sort order changes. BUG= chromium:625229 TEST=`FEATURES=test emerge-link shill` Change-Id: I22cd572d891e800b41d3ff9b7a9e441fd3d5e3cc Reviewed-on: https://chromium-review.googlesource.com/358172 Commit-Ready: Kevin Cernekee <cernekee@chromium.org> Tested-by: Kevin Cernekee <cernekee@chromium.org> Reviewed-by: Eric Caruso <ejcaruso@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@google.com> [modify] https://crrev.com/d9064490e6d3729499bb78aa9f3d1c034c8ef57e/routing_table.cc [modify] https://crrev.com/d9064490e6d3729499bb78aa9f3d1c034c8ef57e/routing_table_unittest.cc
,
Jul 13 2016
,
Jul 13 2016
Your change meets the bar and is auto-approved for M53 (branch: 2785)
,
Jul 14 2016
The following revision refers to this bug: https://chromium.googlesource.com/aosp/platform/system/connectivity/shill/+/a2cde3cdbd9c12ca6ede7fb48c75d7a451ac02e8 commit a2cde3cdbd9c12ca6ede7fb48c75d7a451ac02e8 Author: Kevin Cernekee <cernekee@chromium.org> Date: Sun Jul 03 18:40:01 2016 Track the IPv6 default gateway on each connection shill currently does not look at the default gateway created by the kernel's stateless autoconfiguration mechanism. This leads to several issues: 1) The IPConfig Gateway property is left blank even when a gateway has been configured. 2) Since ONC in Chrome promises that its own gateway field will be populated whenever an IP address is present, this leads to an ONC spec violation that may confuse clients that use ONC APIs. 3) The kernel always seems to assign a metric of IP6_RT_PRIO_USER (1024) to all IPv6 default routes, rather than honoring the technology/service preference order. This can cause IPv6 traffic to be inadvertently routed through a non-default service. 4) When ARC sets up forwarding rules through netfilter, it explicitly whitelists the interface associated with the default service. If the kernel picks a default route on a different interface, all IPv6 traffic from the container will be dropped even though the containerized OS believes it has a usable IPv6 address with global scope. BUG= chromium:625229 TEST=`FEATURES=test emerge-link shill` TEST=`ip -6 route list` with multiple interfaces connected, and verify that the metric on each default route matches with IPv4 Change-Id: Ie900529c3895d5e8f0c4d1b148d9f7401559db85 Previous-Reviewed-on: https://chromium-review.googlesource.com/358139 (cherry picked from commit 4f08cef232578bcd9ff332f428d9389b943a2807) [modify] https://crrev.com/a2cde3cdbd9c12ca6ede7fb48c75d7a451ac02e8/routing_table_unittest.cc [modify] https://crrev.com/a2cde3cdbd9c12ca6ede7fb48c75d7a451ac02e8/connection.cc [modify] https://crrev.com/a2cde3cdbd9c12ca6ede7fb48c75d7a451ac02e8/connection.h [modify] https://crrev.com/a2cde3cdbd9c12ca6ede7fb48c75d7a451ac02e8/device.cc [modify] https://crrev.com/a2cde3cdbd9c12ca6ede7fb48c75d7a451ac02e8/device.h [modify] https://crrev.com/a2cde3cdbd9c12ca6ede7fb48c75d7a451ac02e8/routing_table.cc
,
Jul 14 2016
The following revision refers to this bug: https://chromium.googlesource.com/aosp/platform/system/connectivity/shill/+/7d0fd1db8ad32a0956971da25393f359a0b1752c commit 7d0fd1db8ad32a0956971da25393f359a0b1752c Author: Kevin Cernekee <cernekee@chromium.org> Date: Tue Jul 05 02:28:49 2016 Allow duplicate routes with different metrics When a new route shows up, RouteMsgHandler() currently scans the list of known routes for matches. If a matching route with a different metric is found, the old entry is replaced by the new entry. But on IPv6 it is normal for the kernel to add duplicate default routes with different metrics in response to RA messages received off the LAN. So shill needs to track the duplicate routes so that it knows which entries to have the kernel delete when the service sort order changes. BUG= chromium:625229 TEST=`FEATURES=test emerge-link shill` Change-Id: I22cd572d891e800b41d3ff9b7a9e441fd3d5e3cc Previous-Reviewed-on: https://chromium-review.googlesource.com/358172 (cherry picked from commit 8607bebf6c445ecd1dd0e6e447dee94334d1417f) [modify] https://crrev.com/7d0fd1db8ad32a0956971da25393f359a0b1752c/routing_table.cc [modify] https://crrev.com/7d0fd1db8ad32a0956971da25393f359a0b1752c/routing_table_unittest.cc
,
Jul 14 2016
The following revision refers to this bug: https://chromium.googlesource.com/aosp/platform/system/connectivity/shill/+/ffc6e8657330c28a742cfbf3b904f1b33fa04cbf commit ffc6e8657330c28a742cfbf3b904f1b33fa04cbf Author: Kevin Cernekee <cernekee@chromium.org> Date: Sun Jul 03 21:24:48 2016 Handle duplicate IPv6 default routes After shill adjusts a default IPv6 route to use a metric other than 1024, the kernel will re-create a duplicate route with a metric of 1024 the next time it receives a Router Advertisement. Ignore these redundant routes when shill is trying to adjust the metric, by choosing the default route with the lowest (most preferred) metric. BUG= chromium:625229 TEST=run `ip -6 route list` while hot plugging / unplugging a USB ethernet adapter Change-Id: I9a775cc2435ba4cb1b7a235cfc8753b5a171df1d Previous-Reviewed-on: https://chromium-review.googlesource.com/358143 (cherry picked from commit f568d8ba08c2679ec8196ca724f80ecf861f0206) [modify] https://crrev.com/ffc6e8657330c28a742cfbf3b904f1b33fa04cbf/routing_table.cc [modify] https://crrev.com/ffc6e8657330c28a742cfbf3b904f1b33fa04cbf/routing_table_unittest.cc
,
Jul 14 2016
,
Jul 17 2016
This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible! If all merges have been completed, please remove any remaining Merge-Approved labels from this issue. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 17 2016
,
Aug 8 2016
I was able to see link local address in default gateway entry after running the following command
dbus-send --system --dest=org.chromium.flimflam --print-reply /ipconfig/eth0_1_ip org.chromium.flimflam.IPConfig.GetProperties
dict entry(
string "Gateway"
variant string "fe80::21c:b0ff:feb6:9140"
)
ip -6 route list
2620:0:1000:1305::/64 dev eth0 proto kernel metric 256 expires 2591957sec
fe80::/64 dev eth0 proto kernel metric 256
default via fe80::21c:b0ff:feb6:9140 dev eth0 metric 1
default via fe80::21c:b0ff:feb6:9140 dev eth0 proto ra metric 1024 expires 1757sec
ELM 8685.0.0
,
Aug 8 2016
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by cernekee@chromium.org
, Jul 3 2016Status: Started (was: Untriaged)