<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/include/net/if_inet6.h, branch linux-3.17.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-3.17.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-3.17.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2014-07-11T22:05:45Z</updated>
<entry>
<title>ipv6: addrconf: implement address generation modes</title>
<updated>2014-07-11T22:05:45Z</updated>
<author>
<name>Jiri Pirko</name>
<email>jiri@resnulli.us</email>
</author>
<published>2014-07-11T19:10:18Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=bc91b0f07ada5535427373a4e2050877bcc12218'/>
<id>urn:sha1:bc91b0f07ada5535427373a4e2050877bcc12218</id>
<content type='text'>
This patch introduces a possibility for userspace to set various (so far
two) modes of generating addresses. This is useful for example for
NetworkManager because it can set the mode to NONE and take care of link
local addresses itself. That allow it to have the interface up,
monitoring carrier but still don't have any addresses on it.

One more use-case by Dan Williams:
&lt;quote&gt;
WWAN devices often have their LL address provided by the firmware of the
device, which sometimes refuses to respond to incorrect LL addresses
when doing DHCPv6 or IPv6 ND.  The kernel cannot generate the correct LL
address for two reasons:

1) WWAN pseudo-ethernet interfaces often construct a fake MAC address,
or read a meaningless MAC address from the firmware.  Thus the EUI64 and
the IPv6LL address the kernel assigns will be wrong.  The real LL
address is often retrieved from the firmware with AT or proprietary
commands.

2) WWAN PPP interfaces receive their LL address from IPV6CP, not from
kernel assignments.  Only after IPV6CP has completed do we know the LL
address of the PPP interface and its peer.  But the kernel has already
assigned an incorrect LL address to the interface.

So being able to suppress the kernel LL address generation and assign
the one retrieved from the firmware is less complicated and more robust.
&lt;/quote&gt;

Signed-off-by: Jiri Pirko &lt;jiri@resnulli.us&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>ipv6: move DAD and addrconf_verify processing to workqueue</title>
<updated>2014-03-28T20:54:50Z</updated>
<author>
<name>Hannes Frederic Sowa</name>
<email>hannes@stressinduktion.org</email>
</author>
<published>2014-03-27T17:28:07Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=c15b1ccadb323ea50023e8f1cca2954129a62b51'/>
<id>urn:sha1:c15b1ccadb323ea50023e8f1cca2954129a62b51</id>
<content type='text'>
addrconf_join_solict and addrconf_join_anycast may cause actions which
need rtnl locked, especially on first address creation.

A new DAD state is introduced which defers processing of the initial
DAD processing into a workqueue.

To get rtnl lock we need to push the code paths which depend on those
calls up to workqueues, specifically addrconf_verify and the DAD
processing.

(v2)
addrconf_dad_failure needs to be queued up to the workqueue, too. This
patch introduces a new DAD state and stop the DAD processing in the
workqueue (this is because of the possible ipv6_del_addr processing
which removes the solicited multicast address from the device).

addrconf_verify_lock is removed, too. After the transition it is not
needed any more.

As we are not processing in bottom half anymore we need to be a bit more
careful about disabling bottom half out when we lock spin_locks which are also
used in bh.

Relevant backtrace:
[  541.030090] RTNL: assertion failed at net/core/dev.c (4496)
[  541.031143] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G           O 3.10.33-1-amd64-vyatta #1
[  541.031145] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
[  541.031146]  ffffffff8148a9f0 000000000000002f ffffffff813c98c1 ffff88007c4451f8
[  541.031148]  0000000000000000 0000000000000000 ffffffff813d3540 ffff88007fc03d18
[  541.031150]  0000880000000006 ffff88007c445000 ffffffffa0194160 0000000000000000
[  541.031152] Call Trace:
[  541.031153]  &lt;IRQ&gt;  [&lt;ffffffff8148a9f0&gt;] ? dump_stack+0xd/0x17
[  541.031180]  [&lt;ffffffff813c98c1&gt;] ? __dev_set_promiscuity+0x101/0x180
[  541.031183]  [&lt;ffffffff813d3540&gt;] ? __hw_addr_create_ex+0x60/0xc0
[  541.031185]  [&lt;ffffffff813cfe1a&gt;] ? __dev_set_rx_mode+0xaa/0xc0
[  541.031189]  [&lt;ffffffff813d3a81&gt;] ? __dev_mc_add+0x61/0x90
[  541.031198]  [&lt;ffffffffa01dcf9c&gt;] ? igmp6_group_added+0xfc/0x1a0 [ipv6]
[  541.031208]  [&lt;ffffffff8111237b&gt;] ? kmem_cache_alloc+0xcb/0xd0
[  541.031212]  [&lt;ffffffffa01ddcd7&gt;] ? ipv6_dev_mc_inc+0x267/0x300 [ipv6]
[  541.031216]  [&lt;ffffffffa01c2fae&gt;] ? addrconf_join_solict+0x2e/0x40 [ipv6]
[  541.031219]  [&lt;ffffffffa01ba2e9&gt;] ? ipv6_dev_ac_inc+0x159/0x1f0 [ipv6]
[  541.031223]  [&lt;ffffffffa01c0772&gt;] ? addrconf_join_anycast+0x92/0xa0 [ipv6]
[  541.031226]  [&lt;ffffffffa01c311e&gt;] ? __ipv6_ifa_notify+0x11e/0x1e0 [ipv6]
[  541.031229]  [&lt;ffffffffa01c3213&gt;] ? ipv6_ifa_notify+0x33/0x50 [ipv6]
[  541.031233]  [&lt;ffffffffa01c36c8&gt;] ? addrconf_dad_completed+0x28/0x100 [ipv6]
[  541.031241]  [&lt;ffffffff81075c1d&gt;] ? task_cputime+0x2d/0x50
[  541.031244]  [&lt;ffffffffa01c38d6&gt;] ? addrconf_dad_timer+0x136/0x150 [ipv6]
[  541.031247]  [&lt;ffffffffa01c37a0&gt;] ? addrconf_dad_completed+0x100/0x100 [ipv6]
[  541.031255]  [&lt;ffffffff8105313a&gt;] ? call_timer_fn.isra.22+0x2a/0x90
[  541.031258]  [&lt;ffffffffa01c37a0&gt;] ? addrconf_dad_completed+0x100/0x100 [ipv6]

Hunks and backtrace stolen from a patch by Stephen Hemminger.

Reported-by: Stephen Hemminger &lt;stephen@networkplumber.org&gt;
Signed-off-by: Stephen Hemminger &lt;stephen@networkplumber.org&gt;
Signed-off-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net</title>
<updated>2014-01-18T08:55:41Z</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2014-01-18T08:55:41Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=41804420586ab41049a14ab7ef04eaa2280b8647'/>
<id>urn:sha1:41804420586ab41049a14ab7ef04eaa2280b8647</id>
<content type='text'>
Conflicts:
	drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
	net/ipv4/tcp_metrics.c

Overlapping changes between the "don't create two tcp metrics objects
with the same key" race fix in net and the addition of the destination
address in the lookup key in net-next.

Minor overlapping changes in bnx2x driver.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>ipv6: simplify detection of first operational link-local address on interface</title>
<updated>2014-01-18T02:10:01Z</updated>
<author>
<name>Hannes Frederic Sowa</name>
<email>hannes@stressinduktion.org</email>
</author>
<published>2014-01-16T19:13:04Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=11ffff752c6a5adc86f7dd397b2f75af8f917c51'/>
<id>urn:sha1:11ffff752c6a5adc86f7dd397b2f75af8f917c51</id>
<content type='text'>
In commit 1ec047eb4751e3 ("ipv6: introduce per-interface counter for
dad-completed ipv6 addresses") I build the detection of the first
operational link-local address much to complex. Additionally this code
now has a race condition.

Replace it with a much simpler variant, which just scans the address
list when duplicate address detection completes, to check if this is
the first valid link local address and send RS and MLD reports then.

Fixes: 1ec047eb4751e3 ("ipv6: introduce per-interface counter for dad-completed ipv6 addresses")
Reported-by: Jiri Pirko &lt;jiri@resnulli.us&gt;
Cc: Flavio Leitner &lt;fbl@redhat.com&gt;
Signed-off-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Acked-by: Flavio Leitner &lt;fbl@redhat.com&gt;
Acked-by: Jiri Pirko &lt;jiri@resnulli.us&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>ipv6 addrconf: extend ifa_flags to u32</title>
<updated>2013-12-06T21:34:43Z</updated>
<author>
<name>Jiri Pirko</name>
<email>jiri@resnulli.us</email>
</author>
<published>2013-12-06T08:45:21Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=479840ffdbe4242e8a25349218c8e0859223aa35'/>
<id>urn:sha1:479840ffdbe4242e8a25349218c8e0859223aa35</id>
<content type='text'>
There is no more space in u8 ifa_flags. So do what davem suffested and
add another netlink attr called IFA_FLAGS for carry more flags.

Signed-off-by: Jiri Pirko &lt;jiri@resnulli.us&gt;
Signed-off-by: Thomas Haller &lt;thaller@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>ipv6: Remove privacy config option.</title>
<updated>2013-10-29T00:07:50Z</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2013-10-29T00:07:50Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=5d9efa7ee99eed58388f186c13cf2e2a87e9ceb4'/>
<id>urn:sha1:5d9efa7ee99eed58388f186c13cf2e2a87e9ceb4</id>
<content type='text'>
The code for privacy extentions is very mature, and making it
configurable only gives marginal memory/code savings in exchange
for obfuscation and hard to read code via CPP ifdef'ery.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: ipv6: mld: fix v1/v2 switchback timeout to rfc3810, 9.12.</title>
<updated>2013-09-04T18:53:20Z</updated>
<author>
<name>Daniel Borkmann</name>
<email>dborkman@redhat.com</email>
</author>
<published>2013-09-03T22:19:37Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=89225d1ce6af3916bf32aecbe9d83f571a098588'/>
<id>urn:sha1:89225d1ce6af3916bf32aecbe9d83f571a098588</id>
<content type='text'>
i) RFC3810, 9.2. Query Interval [QI] says:

   The Query Interval variable denotes the interval between General
   Queries sent by the Querier. Default value: 125 seconds. [...]

ii) RFC3810, 9.3. Query Response Interval [QRI] says:

  The Maximum Response Delay used to calculate the Maximum Response
  Code inserted into the periodic General Queries. Default value:
  10000 (10 seconds) [...] The number of seconds represented by the
  [Query Response Interval] must be less than the [Query Interval].

iii) RFC3810, 9.12. Older Version Querier Present Timeout [OVQPT] says:

  The Older Version Querier Present Timeout is the time-out for
  transitioning a host back to MLDv2 Host Compatibility Mode. When an
  MLDv1 query is received, MLDv2 hosts set their Older Version Querier
  Present Timer to [Older Version Querier Present Timeout].

  This value MUST be ([Robustness Variable] times (the [Query Interval]
  in the last Query received)) plus ([Query Response Interval]).

Hence, on *default* the timeout results in:

  [RV] = 2, [QI] = 125sec, [QRI] = 10sec
  [OVQPT] = [RV] * [QI] + [QRI] = 260sec

Having that said, we currently calculate [OVQPT] (here given as 'switchback'
variable) as ...

  switchback = (idev-&gt;mc_qrv + 1) * max_delay

RFC3810, 9.12. says "the [Query Interval] in the last Query received". In
section "9.14. Configuring timers", it is said:

  This section is meant to provide advice to network administrators on
  how to tune these settings to their network. Ambitious router
  implementations might tune these settings dynamically based upon
  changing characteristics of the network. [...]

iv) RFC38010, 9.14.2. Query Interval:

  The overall level of periodic MLD traffic is inversely proportional
  to the Query Interval. A longer Query Interval results in a lower
  overall level of MLD traffic. The value of the Query Interval MUST
  be equal to or greater than the Maximum Response Delay used to
  calculate the Maximum Response Code inserted in General Query
  messages.

I assume that was why switchback is calculated as is (3 * max_delay), although
this setting seems to be meant for routers only to configure their [QI]
interval for non-default intervals. So usage here like this is clearly wrong.

Concluding, the current behaviour in IPv6's multicast code is not conform
to the RFC as switch back is calculated wrongly. That is, it has a too small
value, so MLDv2 hosts switch back again to MLDv2 way too early, i.e. ~30secs
instead of ~260secs on default.

Hence, introduce necessary helper functions and fix this up properly as it
should be.

Introduced in 06da92283 ("[IPV6]: Add MLDv2 support."). Credits to Hannes
Frederic Sowa who also had a hand in this as well. Also thanks to Hangbin Liu
who did initial testing.

Signed-off-by: Daniel Borkmann &lt;dborkman@redhat.com&gt;
Cc: David Stevens &lt;dlstevens@us.ibm.com&gt;
Cc: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Acked-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>ipv6: resend MLD report if a link-local address completes DAD</title>
<updated>2013-06-29T04:19:17Z</updated>
<author>
<name>Hannes Frederic Sowa</name>
<email>hannes@stressinduktion.org</email>
</author>
<published>2013-06-26T22:07:01Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=b173ee488dcc545e77ed482158a2f0d06d7a5860'/>
<id>urn:sha1:b173ee488dcc545e77ed482158a2f0d06d7a5860</id>
<content type='text'>
RFC3590/RFC3810 specifies we should resend MLD reports as soon as a
valid link-local address is available.

We now use the valid_ll_addr_cnt to check if it is necessary to resend
a new report.

Changes since Flavio Leitner's version:
a) adapt for valid_ll_addr_cnt
b) resend first reports directly in the path and just arm the timer for
   mc_qrv-1 resends.

Reported-by: Flavio Leitner &lt;fleitner@redhat.com&gt;
Cc: Hideaki YOSHIFUJI &lt;yoshfuji@linux-ipv6.org&gt;
Cc: David Stevens &lt;dlstevens@us.ibm.com&gt;
Signed-off-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: Flavio Leitner &lt;fbl@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>ipv6: introduce per-interface counter for dad-completed ipv6 addresses</title>
<updated>2013-06-29T04:19:17Z</updated>
<author>
<name>Hannes Frederic Sowa</name>
<email>hannes@stressinduktion.org</email>
</author>
<published>2013-06-26T22:06:56Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=1ec047eb4751e331bc61cff0e98f0db67db8b8dc'/>
<id>urn:sha1:1ec047eb4751e331bc61cff0e98f0db67db8b8dc</id>
<content type='text'>
To reduce the number of unnecessary router solicitations, MLDv2 and IGMPv3
messages we need to track the number of valid (as in non-optimistic,
no-dad-failed and non-tentative) link-local addresses. Therefore, this
patch implements a valid_ll_addr_cnt in struct inet6_dev.

We now only emit router solicitations if the first link-local address
finishes duplicate address detection.

The changes for MLDv2 and IGMPv3 are in a follow-up patch.

While there, also simplify one if statement(one minor nit I made in one
of my previous patches):

if (!...)
	do();
else
	return;

&lt;&lt;into&gt;&gt;

if (...)
	return;
do();

Cc: Flavio Leitner &lt;fbl@redhat.com&gt;
Cc: YOSHIFUJI Hideaki &lt;yoshfuji@linux-ipv6.org&gt;
Cc: David Stevens &lt;dlstevens@us.ibm.com&gt;
Suggested-by: David Stevens &lt;dlstevens@us.ibm.com&gt;
Signed-off-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Acked-by: Flavio Leitner &lt;fbl@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>ipv6: split duplicate address detection and router solicitation timer</title>
<updated>2013-06-25T23:23:03Z</updated>
<author>
<name>Hannes Frederic Sowa</name>
<email>hannes@stressinduktion.org</email>
</author>
<published>2013-06-23T16:39:01Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=b7b1bfce0bb68bd8f6e62a28295922785cc63781'/>
<id>urn:sha1:b7b1bfce0bb68bd8f6e62a28295922785cc63781</id>
<content type='text'>
This patch splits the timers for duplicate address detection and router
solicitations apart. The router solicitations timer goes into inet6_dev
and the dad timer stays in inet6_ifaddr.

The reason behind this patch is to reduce the number of unneeded router
solicitations send out by the host if additional link-local addresses
are created. Currently we send out RS for every link-local address on
an interface.

If the RS timer fires we pick a source address with ipv6_get_lladdr. This
change could hurt people adding additional link-local addresses and
specifying these addresses in the radvd clients section because we
no longer guarantee that we use every ll address as source address in
router solicitations.

Cc: Flavio Leitner &lt;fleitner@redhat.com&gt;
Cc: Hideaki YOSHIFUJI &lt;yoshfuji@linux-ipv6.org&gt;
Cc: David Stevens &lt;dlstevens@us.ibm.com&gt;
Signed-off-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Reviewed-by: Flavio Leitner &lt;fbl@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
