Netdev List
 help / color / mirror / Atom feed
* ping6: echo reply ok in tcpdump, but not captured in ping (Depending on address type)
From: Jakub Muszynski @ 2011-08-07 14:13 UTC (permalink / raw)
  To: netdev

Hello, 

I have a problem:
I'm writing my own IPv6 stack, and I faced interesting issue (probably
my mistake).
I do receive ping6 output, depending on address I probe (ff02:x or
fe80:x). The echo reply is the same in both cases.

I do ping:
$ ping6 -I eth0 fe80::21e:33ff:fe0b:872e 
PING fe80::21e:33ff:fe0b:872e(fe80::21e:33ff:fe0b:872e) from
fe80::21e:33ff:fe0b:872f eth0: 56 data bytes
^C
--- fe80::21e:33ff:fe0b:872e ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 999ms

On my device, the ping is replied, and send back.
I can capture it via tcpdump, but can't register in ping6:

tcpdump:
00:1e:33:0b:87:2f > 00:1e:33:0b:87:2e, ethertype IPv6 (0x86dd), length
118: (hlim 64, next-header ICMPv6 (58) payload length: 64)
fe80::21e:33ff:fe0b:872f > fe80::21e:33ff:fe0b:872e: [icmp6 sum ok]
ICMP6, echo request, length 64, seq 2
	0x0000:  6000 0000 0040 3a40 fe80 0000 0000 0000
	0x0010:  021e 33ff fe0b 872f fe80 0000 0000 0000
	0x0020:  021e 33ff fe0b 872e 8000 b3da 0c69 0002
	0x0030:  365b 3e4e e4e0 0700 0809 0a0b 0c0d 0e0f
	0x0040:  1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
	0x0050:  2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
	0x0060:  3031 3233 3435 3637
00:1e:33:0b:87:2f > 00:1e:33:0b:87:2e, ethertype IPv6 (0x86dd), length
118: (hlim 255, next-header ICMPv6 (58) payload length: 64)
fe80::21e:33ff:fe0b:872e > fe80::21e:33ff:fe0b:872f: [icmp6 sum ok]
ICMP6, echo reply, length 64, seq 2
	0x0000:  6000 0000 0040 3aff fe80 0000 0000 0000
	0x0010:  021e 33ff fe0b 872e fe80 0000 0000 0000
	0x0020:  021e 33ff fe0b 872f 8100 b2da 0c69 0002
	0x0030:  365b 3e4e e4e0 0700 0809 0a0b 0c0d 0e0f
	0x0040:  1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
	0x0050:  2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
	0x0060:  3031 3233 3435 3637


>>> Curious case: 
If I do ping and ff02:xxxx address, it works:

ping6 -I eth0 ff02::21e:33ff:fe0b:872e 
PING ff02::21e:33ff:fe0b:872e(ff02::21e:33ff:fe0b:872e) from
fe80::21e:33ff:fe0b:872f eth0: 56 data bytes
64 bytes from ff02::21e:33ff:fe0b:872e: icmp_seq=1 ttl=255 time=125 ms
64 bytes from ff02::21e:33ff:fe0b:872e: icmp_seq=2 ttl=255 time=125 ms
^C
--- ff02::21e:33ff:fe0b:872e ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 125.374/125.423/125.473/0.357 ms


tcpdump:
00:1e:33:0b:87:2f > 33:33:fe:0b:87:2e, ethertype IPv6 (0x86dd), length
118: (hlim 1, next-header ICMPv6 (58) payload length: 64)
fe80::21e:33ff:fe0b:872f > ff02::21e:33ff:fe0b:872e: [icmp6 sum ok]
ICMP6, echo request, length 64, seq 2
	0x0000:  6000 0000 0040 3a01 fe80 0000 0000 0000
	0x0010:  021e 33ff fe0b 872f ff02 0000 0000 0000
	0x0020:  021e 33ff fe0b 872e 8000 b262 0cb4 0002
	0x0030:  bb5c 3e4e 608a 0700 0809 0a0b 0c0d 0e0f
	0x0040:  1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
	0x0050:  2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
	0x0060:  3031 3233 3435 3637
00:1e:33:0b:87:2f > 33:33:fe:0b:87:2e, ethertype IPv6 (0x86dd), length
118: (hlim 255, next-header ICMPv6 (58) payload length: 64)
ff02::21e:33ff:fe0b:872e > fe80::21e:33ff:fe0b:872f: [icmp6 sum ok]
ICMP6, echo reply, length 64, seq 2
	0x0000:  6000 0000 0040 3aff ff02 0000 0000 0000
	0x0010:  021e 33ff fe0b 872e fe80 0000 0000 0000
	0x0020:  021e 33ff fe0b 872f 8100 b162 0cb4 0002
	0x0030:  bb5c 3e4e 608a 0700 0809 0a0b 0c0d 0e0f
	0x0040:  1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
	0x0050:  2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
	0x0060:  3031 3233 3435 3637


Well - all seems quite similar.
I did try to understand strace ping6, it says:
recvmsg(3, 0xbfc64358, 0) = -1 EAGAIN (Resource temporarily unavailable)
But why?
Some specification (RFC) issues?
Do you have any idea, why local-multicast address works, and other not?

Greetings
Kuba

-------------------------------
the tcpdump command:
tcpdump -t -n -i eth0 -e -x -vv

Interface settings:
ip -6 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 fe80::21e:33ff:fe0b:872f/64 scope link 
       valid_lft forever preferred_lft forever

---------------------------

strace :

NOT WORKING: (fe80:xx)

recvmsg(3, 0xbfc64358, 0)               = -1 EAGAIN (Resource
temporarily unavailable)
gettimeofday({1312710414, 968503}, NULL) = 0
poll([{fd=3, events=POLLIN|POLLERR}], 1, 10) = 0 (Timeout)
gettimeofday({1312710414, 978868}, NULL) = 0
gettimeofday({1312710414, 978996}, NULL) = 0
sendmsg(3, {msg_name(28)={sa_family=AF_INET6, sin6_port=htons(58),
inet_pton(AF_INET6, "fe80::2aa:ff:fe28:9c5a", &sin6_addr),
sin6_flowinfo=0, sin6_scope_id=0}, msg_iov(1)=[{"\200\0\0\0\f\365\0\7
\16_>N4\360\16\0\10\t\n\v\f\r\16\17\20\21\22\23\24\25\26\27"..., 64}],
msg_controllen=32, {cmsg_len=32, cmsg_level=SOL_IPV6, cmsg_type=, ...},
msg_flags=MSG_OOB}, 0) = 64
recvmsg(3, 0xbfc64358, 0)               = -1 EAGAIN (Resource
temporarily unavailable)
gettimeofday({1312710415, 976589}, NULL) = 0
poll([{fd=3, events=POLLIN|POLLERR}], 1, 10) = 0 (Timeout)



WOTKING: (ff02:xx)

poll([{fd=3, events=POLLIN|POLLERR}], 1, 870) = 0 (Timeout)
gettimeofday({1312710444, 919737}, NULL) = 0
gettimeofday({1312710444, 919854}, NULL) = 0
sendmsg(3, {msg_name(28)={sa_family=AF_INET6, sin6_port=htons(58),
inet_pton(AF_INET6, "ff02::2aa:ff:fe28:9c5a", &sin6_addr),
sin6_flowinfo=0, sin6_scope_id=0}, msg_iov(1)=[{"\200\0\0\0\f\376\0
\2,_>N.\t\16\0\10\t\n\v\f\r\16\17\20\21\22\23\24\25\26\27"..., 64}],
msg_controllen=32, {cmsg_len=32, cmsg_level=SOL_IPV6, cmsg_type=, ...},
msg_flags=MSG_OOB}, MSG_CONFIRM) = 64
recvmsg(3, {msg_name(28)={sa_family=AF_INET6, sin6_port=htons(0),
inet_pton(AF_INET6, "ff02::2aa:ff:fe28:9c5a", &sin6_addr),
sin6_flowinfo=0, sin6_scope_id=if_nametoindex("eth0")},
msg_iov(1)=[{"\201\0\210\302\f\376\0\2,_>N.\t\16\0\10\t\n\v\f\r\16\17\20
\21\22\23\24\25\26\27"..., 4208}], msg_controllen=36, {cmsg_len=20,
cmsg_level=SOL_SOCKET, cmsg_type=0x1d /* SCM_??? */, ...}, msg_flags=0},
0) = 64
write(1, "64 bytes from ff02::2aa:ff:fe28:"..., 6964 bytes from
ff02::2aa:ff:fe28:9c5a: icmp_seq=2 ttl=255 time=125 ms
) = 69
gettimeofday({1312710445, 46448}, NULL) = 0
poll([{fd=3, events=POLLIN|POLLERR}], 1, 873) = 0 (Timeout)




^ permalink raw reply

* ping6: echo reply ok in tcpdump, but not captured in ping (Depending on address type)
From: Jakub Muszynski @ 2011-08-07  9:56 UTC (permalink / raw)
  To: netdev

Hello, 

I have a problem:
I'm writing my own IPv6 stack, and I faced interesting issue (probably
my mistake).
I do receive ping6 output, depending on address I probe (ff02:x or
fe80:x). The echo reply is the same in both cases.

I do ping:
$ ping6 -I eth0 fe80::21e:33ff:fe0b:872e 
PING fe80::21e:33ff:fe0b:872e(fe80::21e:33ff:fe0b:872e) from
fe80::21e:33ff:fe0b:872f eth0: 56 data bytes
^C
--- fe80::21e:33ff:fe0b:872e ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 999ms

On my device, the ping is replied, and send back.
I can capture it via tcpdump, but can't register in ping6:

tcpdump:
00:1e:33:0b:87:2f > 00:1e:33:0b:87:2e, ethertype IPv6 (0x86dd), length
118: (hlim 64, next-header ICMPv6 (58) payload length: 64)
fe80::21e:33ff:fe0b:872f > fe80::21e:33ff:fe0b:872e: [icmp6 sum ok]
ICMP6, echo request, length 64, seq 2
	0x0000:  6000 0000 0040 3a40 fe80 0000 0000 0000
	0x0010:  021e 33ff fe0b 872f fe80 0000 0000 0000
	0x0020:  021e 33ff fe0b 872e 8000 b3da 0c69 0002
	0x0030:  365b 3e4e e4e0 0700 0809 0a0b 0c0d 0e0f
	0x0040:  1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
	0x0050:  2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
	0x0060:  3031 3233 3435 3637
00:1e:33:0b:87:2f > 00:1e:33:0b:87:2e, ethertype IPv6 (0x86dd), length
118: (hlim 255, next-header ICMPv6 (58) payload length: 64)
fe80::21e:33ff:fe0b:872e > fe80::21e:33ff:fe0b:872f: [icmp6 sum ok]
ICMP6, echo reply, length 64, seq 2
	0x0000:  6000 0000 0040 3aff fe80 0000 0000 0000
	0x0010:  021e 33ff fe0b 872e fe80 0000 0000 0000
	0x0020:  021e 33ff fe0b 872f 8100 b2da 0c69 0002
	0x0030:  365b 3e4e e4e0 0700 0809 0a0b 0c0d 0e0f
	0x0040:  1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
	0x0050:  2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
	0x0060:  3031 3233 3435 3637


>>> Curious case: 
If I do ping and ff02:xxxx address, it works:

ping6 -I eth0 ff02::21e:33ff:fe0b:872e 
PING ff02::21e:33ff:fe0b:872e(ff02::21e:33ff:fe0b:872e) from
fe80::21e:33ff:fe0b:872f eth0: 56 data bytes
64 bytes from ff02::21e:33ff:fe0b:872e: icmp_seq=1 ttl=255 time=125 ms
64 bytes from ff02::21e:33ff:fe0b:872e: icmp_seq=2 ttl=255 time=125 ms
^C
--- ff02::21e:33ff:fe0b:872e ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 125.374/125.423/125.473/0.357 ms


tcpdump:
00:1e:33:0b:87:2f > 33:33:fe:0b:87:2e, ethertype IPv6 (0x86dd), length
118: (hlim 1, next-header ICMPv6 (58) payload length: 64)
fe80::21e:33ff:fe0b:872f > ff02::21e:33ff:fe0b:872e: [icmp6 sum ok]
ICMP6, echo request, length 64, seq 2
	0x0000:  6000 0000 0040 3a01 fe80 0000 0000 0000
	0x0010:  021e 33ff fe0b 872f ff02 0000 0000 0000
	0x0020:  021e 33ff fe0b 872e 8000 b262 0cb4 0002
	0x0030:  bb5c 3e4e 608a 0700 0809 0a0b 0c0d 0e0f
	0x0040:  1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
	0x0050:  2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
	0x0060:  3031 3233 3435 3637
00:1e:33:0b:87:2f > 33:33:fe:0b:87:2e, ethertype IPv6 (0x86dd), length
118: (hlim 255, next-header ICMPv6 (58) payload length: 64)
ff02::21e:33ff:fe0b:872e > fe80::21e:33ff:fe0b:872f: [icmp6 sum ok]
ICMP6, echo reply, length 64, seq 2
	0x0000:  6000 0000 0040 3aff ff02 0000 0000 0000
	0x0010:  021e 33ff fe0b 872e fe80 0000 0000 0000
	0x0020:  021e 33ff fe0b 872f 8100 b162 0cb4 0002
	0x0030:  bb5c 3e4e 608a 0700 0809 0a0b 0c0d 0e0f
	0x0040:  1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
	0x0050:  2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
	0x0060:  3031 3233 3435 3637


Well - all seems quite similar.
I did try to understand strace ping6, it says:
recvmsg(3, 0xbfc64358, 0) = -1 EAGAIN (Resource temporarily unavailable)
But why?
Some specification (RFC) issues?
Do you have any idea, why local-multicast address works, and other not?

Greetings
Kuba

-------------------------------
the tcpdump command:
tcpdump -t -n -i eth0 -e -x -vv

Interface settings:
ip -6 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 fe80::21e:33ff:fe0b:872f/64 scope link 
       valid_lft forever preferred_lft forever

---------------------------

strace :

NOT WORKING: (fe80:xx)

recvmsg(3, 0xbfc64358, 0)               = -1 EAGAIN (Resource
temporarily unavailable)
gettimeofday({1312710414, 968503}, NULL) = 0
poll([{fd=3, events=POLLIN|POLLERR}], 1, 10) = 0 (Timeout)
gettimeofday({1312710414, 978868}, NULL) = 0
gettimeofday({1312710414, 978996}, NULL) = 0
sendmsg(3, {msg_name(28)={sa_family=AF_INET6, sin6_port=htons(58),
inet_pton(AF_INET6, "fe80::2aa:ff:fe28:9c5a", &sin6_addr),
sin6_flowinfo=0, sin6_scope_id=0}, msg_iov(1)=[{"\200\0\0\0\f\365\0\7
\16_>N4\360\16\0\10\t\n\v\f\r\16\17\20\21\22\23\24\25\26\27"..., 64}],
msg_controllen=32, {cmsg_len=32, cmsg_level=SOL_IPV6, cmsg_type=, ...},
msg_flags=MSG_OOB}, 0) = 64
recvmsg(3, 0xbfc64358, 0)               = -1 EAGAIN (Resource
temporarily unavailable)
gettimeofday({1312710415, 976589}, NULL) = 0
poll([{fd=3, events=POLLIN|POLLERR}], 1, 10) = 0 (Timeout)



WOTKING: (ff02:xx)

poll([{fd=3, events=POLLIN|POLLERR}], 1, 870) = 0 (Timeout)
gettimeofday({1312710444, 919737}, NULL) = 0
gettimeofday({1312710444, 919854}, NULL) = 0
sendmsg(3, {msg_name(28)={sa_family=AF_INET6, sin6_port=htons(58),
inet_pton(AF_INET6, "ff02::2aa:ff:fe28:9c5a", &sin6_addr),
sin6_flowinfo=0, sin6_scope_id=0}, msg_iov(1)=[{"\200\0\0\0\f\376\0
\2,_>N.\t\16\0\10\t\n\v\f\r\16\17\20\21\22\23\24\25\26\27"..., 64}],
msg_controllen=32, {cmsg_len=32, cmsg_level=SOL_IPV6, cmsg_type=, ...},
msg_flags=MSG_OOB}, MSG_CONFIRM) = 64
recvmsg(3, {msg_name(28)={sa_family=AF_INET6, sin6_port=htons(0),
inet_pton(AF_INET6, "ff02::2aa:ff:fe28:9c5a", &sin6_addr),
sin6_flowinfo=0, sin6_scope_id=if_nametoindex("eth0")},
msg_iov(1)=[{"\201\0\210\302\f\376\0\2,_>N.\t\16\0\10\t\n\v\f\r\16\17\20
\21\22\23\24\25\26\27"..., 4208}], msg_controllen=36, {cmsg_len=20,
cmsg_level=SOL_SOCKET, cmsg_type=0x1d /* SCM_??? */, ...}, msg_flags=0},
0) = 64
write(1, "64 bytes from ff02::2aa:ff:fe28:"..., 6964 bytes from
ff02::2aa:ff:fe28:9c5a: icmp_seq=2 ttl=255 time=125 ms
) = 69
gettimeofday({1312710445, 46448}, NULL) = 0
poll([{fd=3, events=POLLIN|POLLERR}], 1, 873) = 0 (Timeout)



^ permalink raw reply

* rtl8150: rtl8150_disconnect(...) does not need tasklet_disable(...)
From: Huajun Li @ 2011-08-07 13:03 UTC (permalink / raw)
  To: David Miller, petkan-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f
  Cc: netdev, lud, Huajun Li

Executing cmd 'rmmod rtl8150' does not return(if your device connects
to host), the root cause is tasklet_disable() causes tasklet_kill()
block, remove it from rtl8150_disconnect().

Signed-off-by: Huajun Li <huajun.li.lee-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 drivers/net/usb/rtl8150.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/net/usb/rtl8150.c b/drivers/net/usb/rtl8150.c
index 041fb7d..ef3b236 100644
--- a/drivers/net/usb/rtl8150.c
+++ b/drivers/net/usb/rtl8150.c
@@ -977,7 +977,6 @@ static void rtl8150_disconnect(struct usb_interface *intf)
 	usb_set_intfdata(intf, NULL);
 	if (dev) {
 		set_bit(RTL8150_UNPLUG, &dev->flags);
-		tasklet_disable(&dev->tl);
 		tasklet_kill(&dev->tl);
 		unregister_netdev(dev->netdev);
 		unlink_all_urbs(dev);
-- 
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related

* Bonding problem
From: Eduard Sinelnikov @ 2011-08-07 12:00 UTC (permalink / raw)
  To: majordomo, netdev, Jay Vosburgh, Andy Gospodarek

Hi,

In the kernel 2.6.39.3 ( /drivers/net/bond/bond_main.c).
In the function  ‘bond_xmit_roundrobin’
The code check if the bond is active via
‘bond_is_active_slave(slave)’ Function call.
Which actually checks if the slave is backup or active
What is the meaning of slave being  backup in round robin mode?
Correct me if I wrong but in round robin every slave should send a
packet, regardless of being active or backup.

Thank you,
           Eduard

^ permalink raw reply

* Pick Up
From: WESTERN UNION OFFICE @ 2011-08-07 11:26 UTC (permalink / raw)


How are you today?


I write to inform you that we have already sent you $5,000.00USD
through Western union as we have been given the mandate to transfer
your full compensation payment of  $1.800,000.00USD via western union
by this government.

I called to give you the information through phone as internet hackers
were many but i cannot reach you yesterday even this morning,So I
decided to email you the (MTCN) and sender name so that you can pick
up this $5,000.00USD to enable us send another $5,000.00USD by
tomorrow as you knows we will be sending you only $5,000.00USD per
day.Please pick up this information and run to any western union
(OUTLET) in your country and pick up this $5,000.00USD and send us an
email back,so that we can send another $5,000.00USD by tomorrow.

Manager: Mr Frank Amos
email me on:western-money71@xnmsn.com
call us on: +234-7031908911
once you picked up this $5000.00USD today.

Here is the western union information to pick up the $5000.00USD,

MTCN :___________  MTCN 9500834460
first name: ________Appoline
Second Name: ____Ouedraoge
Text Question: ____When
Answer: ____________2Hours ago
Amount:__________ $5,000.00 United State Dollars

I am waiting for your E-mail once you pick up $5000.00USD,

Thanks
Mr Frank Amos.

^ permalink raw reply

* [PATCH 1/2] gianfar: fix fiper alignment after resetting the time
From: Richard Cochran @ 2011-08-07  7:03 UTC (permalink / raw)
  To: netdev; +Cc: linux-kernel, David Miller, stable
In-Reply-To: <cover.1312699693.git.richard.cochran@omicron.at>

After resetting the time, the PPS signals on the FIPER output channels
are incorrectly offset from the clock time, as can be readily verified
by a looping back the FIPER to the external time stamp input.

Despite its name, setting the "Fiper Realignment Disable" bit seems to
fix the problem, at least on the P2020.

Also, following the example code from the Freescale BSP, it is not really
necessary to disable and re-enable the timer in order to reprogram the
FIPER. (The documentation is rather unclear on this point. It seems that
writing to the alarm register also disables the FIPER.)

Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
Cc: <stable@kernel.org>
---
 drivers/net/gianfar_ptp.c |    9 ++-------
 1 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/net/gianfar_ptp.c b/drivers/net/gianfar_ptp.c
index 1c97861..f67b8ae 100644
--- a/drivers/net/gianfar_ptp.c
+++ b/drivers/net/gianfar_ptp.c
@@ -193,14 +193,9 @@ static void set_alarm(struct etsects *etsects)
 /* Caller must hold etsects->lock. */
 static void set_fipers(struct etsects *etsects)
 {
-	u32 tmr_ctrl = gfar_read(&etsects->regs->tmr_ctrl);
-
-	gfar_write(&etsects->regs->tmr_ctrl,   tmr_ctrl & (~TE));
-	gfar_write(&etsects->regs->tmr_prsc,   etsects->tmr_prsc);
+	set_alarm(etsects);
 	gfar_write(&etsects->regs->tmr_fiper1, etsects->tmr_fiper1);
 	gfar_write(&etsects->regs->tmr_fiper2, etsects->tmr_fiper2);
-	set_alarm(etsects);
-	gfar_write(&etsects->regs->tmr_ctrl,   tmr_ctrl|TE);
 }
 
 /*
@@ -511,7 +506,7 @@ static int gianfar_ptp_probe(struct platform_device *dev)
 	gfar_write(&etsects->regs->tmr_fiper1, etsects->tmr_fiper1);
 	gfar_write(&etsects->regs->tmr_fiper2, etsects->tmr_fiper2);
 	set_alarm(etsects);
-	gfar_write(&etsects->regs->tmr_ctrl,   tmr_ctrl|FS|RTPE|TE);
+	gfar_write(&etsects->regs->tmr_ctrl,   tmr_ctrl|FS|RTPE|TE|FRD);
 
 	spin_unlock_irqrestore(&etsects->lock, flags);
 
-- 
1.7.0.4


^ permalink raw reply related

* [PATCH 2/2] dp83640: increase receive time stamp buffer size
From: Richard Cochran @ 2011-08-07  7:03 UTC (permalink / raw)
  To: netdev; +Cc: linux-kernel, David Miller, stable
In-Reply-To: <cover.1312699693.git.richard.cochran@omicron.at>

The dp83640 buffers receive time stamps from special PHY status frames,
matching them to received PTP packets in a work queue. Because the timeout
for orphaned time stamps is so long and the buffer is so small, the driver
can drop time stamps under moderate PTP traffic.

This commit fixes the issue by decreasing the timeout to (at least) one
timer tick and increasing the buffer size.

Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
Cc: <stable@kernel.org>
---
 drivers/net/phy/dp83640.c |    5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/net/phy/dp83640.c b/drivers/net/phy/dp83640.c
index 2cd8dc5..cb6e0b4 100644
--- a/drivers/net/phy/dp83640.c
+++ b/drivers/net/phy/dp83640.c
@@ -34,8 +34,7 @@
 #define PAGESEL		0x13
 #define LAYER4		0x02
 #define LAYER2		0x01
-#define MAX_RXTS	4
-#define MAX_TXTS	4
+#define MAX_RXTS	64
 #define N_EXT_TS	1
 #define PSF_PTPVER	2
 #define PSF_EVNT	0x4000
@@ -218,7 +217,7 @@ static void phy2rxts(struct phy_rxts *p, struct rxts *rxts)
 	rxts->seqid = p->seqid;
 	rxts->msgtype = (p->msgtype >> 12) & 0xf;
 	rxts->hash = p->msgtype & 0x0fff;
-	rxts->tmo = jiffies + HZ;
+	rxts->tmo = jiffies + 2;
 }
 
 static u64 phy2txts(struct phy_txts *p)
-- 
1.7.0.4

^ permalink raw reply related

* [PATCH 0/2] ptp: bug fixes for 3.1 and 3.0
From: Richard Cochran @ 2011-08-07  7:03 UTC (permalink / raw)
  To: netdev; +Cc: linux-kernel, David Miller

These two patches fix two bugs in the PTP Hardware Clock drivers. The
drivers were first introduced in Linux version 3.0.

Please apply them.

Thanks,
Richard


Richard Cochran (2):
  gianfar: fix fiper alignment after resetting the time
  dp83640: increase receive time stamp buffer size

 drivers/net/gianfar_ptp.c |    9 ++-------
 drivers/net/phy/dp83640.c |    5 ++---
 2 files changed, 4 insertions(+), 10 deletions(-)


^ permalink raw reply

* [PATCHv3 NEXT 1/1] netxen: add vlan LRO support
From: amit.salecha @ 2011-08-07  2:46 UTC (permalink / raw)
  To: davem; +Cc: netdev, ameen.rahman, Rajesh Borundia, Amit Kumar Salecha

From: Rajesh Borundia <rajesh.borundia@qlogic.com>

o To support vlan lro, driver need to program ip address in device.
o Same ip addresses need to be program after fw recovery, so sotre them
  in list.
o In case of vlan packet, include vlan header length while
calculating ip and tcp headers.

Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
 drivers/net/netxen/netxen_nic.h      |    6 ++
 drivers/net/netxen/netxen_nic_init.c |    8 ++-
 drivers/net/netxen/netxen_nic_main.c |  103 +++++++++++++++++++++++++++++++---
 3 files changed, 107 insertions(+), 10 deletions(-)

diff --git a/drivers/net/netxen/netxen_nic.h b/drivers/net/netxen/netxen_nic.h
index f744d29..196b660 100644
--- a/drivers/net/netxen/netxen_nic.h
+++ b/drivers/net/netxen/netxen_nic.h
@@ -940,6 +940,11 @@ typedef struct nx_mac_list_s {
 	uint8_t mac_addr[ETH_ALEN+2];
 } nx_mac_list_t;
 
+struct nx_vlan_ip_list {
+	struct list_head list;
+	u32 ip_addr;
+};
+
 /*
  * Interrupt coalescing defaults. The defaults are for 1500 MTU. It is
  * adjusted based on configured MTU.
@@ -1165,6 +1170,7 @@ struct netxen_adapter {
 	struct net_device *netdev;
 	struct pci_dev *pdev;
 	struct list_head mac_list;
+	struct list_head vlan_ip_list;
 
 	spinlock_t tx_clean_lock;
 
diff --git a/drivers/net/netxen/netxen_nic_init.c b/drivers/net/netxen/netxen_nic_init.c
index e8993a7..d6c6357 100644
--- a/drivers/net/netxen/netxen_nic_init.c
+++ b/drivers/net/netxen/netxen_nic_init.c
@@ -26,6 +26,7 @@
 #include <linux/netdevice.h>
 #include <linux/delay.h>
 #include <linux/slab.h>
+#include <linux/if_vlan.h>
 #include "netxen_nic.h"
 #include "netxen_nic_hw.h"
 
@@ -1619,6 +1620,7 @@ netxen_process_lro(struct netxen_adapter *adapter,
 	int index;
 	u16 lro_length, length, data_offset;
 	u32 seq_number;
+	u8 vhdr_len;
 
 	if (unlikely(ring > adapter->max_rds_rings))
 		return NULL;
@@ -1652,8 +1654,10 @@ netxen_process_lro(struct netxen_adapter *adapter,
 	skb_pull(skb, l2_hdr_offset);
 	skb->protocol = eth_type_trans(skb, netdev);
 
-	iph = (struct iphdr *)skb->data;
-	th = (struct tcphdr *)(skb->data + (iph->ihl << 2));
+	if (skb->protocol == htons(ETH_P_8021Q))
+		vhdr_len = VLAN_HLEN;
+	iph = (struct iphdr *)(skb->data + vhdr_len);
+	th = (struct tcphdr *)((skb->data + vhdr_len) + (iph->ihl << 2));
 
 	length = (iph->ihl << 2) + (th->doff << 2) + lro_length;
 	iph->tot_len = htons(length);
diff --git a/drivers/net/netxen/netxen_nic_main.c b/drivers/net/netxen/netxen_nic_main.c
index f574edf..8c7fc32 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -91,7 +91,8 @@ static irqreturn_t netxen_intr(int irq, void *data);
 static irqreturn_t netxen_msi_intr(int irq, void *data);
 static irqreturn_t netxen_msix_intr(int irq, void *data);
 
-static void netxen_config_indev_addr(struct net_device *dev, unsigned long);
+static void netxen_free_vlan_ip_list(struct netxen_adapter *);
+static void netxen_restore_indev_addr(struct net_device *dev, unsigned long);
 static struct rtnl_link_stats64 *netxen_nic_get_stats(struct net_device *dev,
 						      struct rtnl_link_stats64 *stats);
 static int netxen_nic_set_mac(struct net_device *netdev, void *p);
@@ -1359,6 +1360,7 @@ netxen_nic_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
 
 	spin_lock_init(&adapter->tx_clean_lock);
 	INIT_LIST_HEAD(&adapter->mac_list);
+	INIT_LIST_HEAD(&adapter->vlan_ip_list);
 
 	err = netxen_setup_pci_map(adapter);
 	if (err)
@@ -1481,6 +1483,7 @@ static void __devexit netxen_nic_remove(struct pci_dev *pdev)
 
 	cancel_work_sync(&adapter->tx_timeout_task);
 
+	netxen_free_vlan_ip_list(adapter);
 	netxen_nic_detach(adapter);
 
 	nx_decr_dev_ref_cnt(adapter);
@@ -1563,7 +1566,7 @@ static int netxen_nic_attach_func(struct pci_dev *pdev)
 		if (err)
 			goto err_out_detach;
 
-		netxen_config_indev_addr(netdev, NETDEV_UP);
+		netxen_restore_indev_addr(netdev, NETDEV_UP);
 	}
 
 	netif_device_attach(netdev);
@@ -2374,7 +2377,7 @@ netxen_attach_work(struct work_struct *work)
 			goto done;
 		}
 
-		netxen_config_indev_addr(netdev, NETDEV_UP);
+		netxen_restore_indev_addr(netdev, NETDEV_UP);
 	}
 
 	netif_device_attach(netdev);
@@ -2848,10 +2851,70 @@ netxen_destip_supported(struct netxen_adapter *adapter)
 }
 
 static void
-netxen_config_indev_addr(struct net_device *dev, unsigned long event)
+netxen_free_vlan_ip_list(struct netxen_adapter *adapter)
+{
+	struct nx_vlan_ip_list  *cur;
+	struct list_head *head = &adapter->vlan_ip_list;
+
+	while (!list_empty(head)) {
+		cur = list_entry(head->next, struct nx_vlan_ip_list, list);
+		netxen_config_ipaddr(adapter, cur->ip_addr, NX_IP_DOWN);
+		list_del(&cur->list);
+		kfree(cur);
+	}
+
+}
+static void
+netxen_list_config_vlan_ip(struct netxen_adapter *adapter,
+		struct in_ifaddr *ifa, unsigned long event)
+{
+	struct net_device *dev;
+	struct nx_vlan_ip_list *cur, *tmp_cur;
+	struct list_head *head;
+
+	dev = ifa->ifa_dev ? ifa->ifa_dev->dev : NULL;
+
+	if (dev == NULL)
+		return;
+
+	if (!is_vlan_dev(dev))
+		return;
+
+	switch (event) {
+	case NX_IP_UP:
+		list_for_each(head, &adapter->vlan_ip_list) {
+			cur = list_entry(head, struct nx_vlan_ip_list, list);
+
+			if (cur->ip_addr == ifa->ifa_address)
+				return;
+		}
+
+		cur = kzalloc(sizeof(struct nx_vlan_ip_list), GFP_ATOMIC);
+		if (cur == NULL) {
+			printk(KERN_ERR "%s: failed to add vlan ip to list\n",
+					adapter->netdev->name);
+			return;
+		}
+
+		cur->ip_addr = ifa->ifa_address;
+		list_add_tail(&cur->list, &adapter->vlan_ip_list);
+		break;
+	case NX_IP_DOWN:
+		list_for_each_entry_safe(cur, tmp_cur,
+					&adapter->vlan_ip_list, list) {
+			if (cur->ip_addr == ifa->ifa_address) {
+				list_del(&cur->list);
+				kfree(cur);
+				break;
+			}
+		}
+	}
+}
+static void
+netxen_config_indev_addr(struct netxen_adapter *adapter,
+		struct net_device *dev, unsigned long event)
 {
 	struct in_device *indev;
-	struct netxen_adapter *adapter = netdev_priv(dev);
 
 	if (!netxen_destip_supported(adapter))
 		return;
@@ -2865,10 +2928,12 @@ netxen_config_indev_addr(struct net_device *dev, unsigned long event)
 		case NETDEV_UP:
 			netxen_config_ipaddr(adapter,
 					ifa->ifa_address, NX_IP_UP);
+			netxen_list_config_vlan_ip(adapter, ifa, NX_IP_UP);
 			break;
 		case NETDEV_DOWN:
 			netxen_config_ipaddr(adapter,
 					ifa->ifa_address, NX_IP_DOWN);
+			netxen_list_config_vlan_ip(adapter, ifa, NX_IP_DOWN);
 			break;
 		default:
 			break;
@@ -2878,11 +2943,28 @@ netxen_config_indev_addr(struct net_device *dev, unsigned long event)
 	in_dev_put(indev);
 }
 
+static void
+netxen_restore_indev_addr(struct net_device *netdev, unsigned long event)
+
+{
+	struct netxen_adapter *adapter = netdev_priv(netdev);
+	struct nx_vlan_ip_list *pos, *tmp_pos;
+	unsigned long ip_event;
+
+	ip_event = (event == NETDEV_UP) ? NX_IP_UP : NX_IP_DOWN;
+	netxen_config_indev_addr(adapter, netdev, event);
+
+	list_for_each_entry_safe(pos, tmp_pos, &adapter->vlan_ip_list, list) {
+		netxen_config_ipaddr(adapter, pos->ip_addr, ip_event);
+	}
+}
+
 static int netxen_netdev_event(struct notifier_block *this,
 				 unsigned long event, void *ptr)
 {
 	struct netxen_adapter *adapter;
 	struct net_device *dev = (struct net_device *)ptr;
+	struct net_device *orig_dev = dev;
 
 recheck:
 	if (dev == NULL)
@@ -2904,7 +2986,7 @@ recheck:
 	if (adapter->is_up != NETXEN_ADAPTER_UP_MAGIC)
 		goto done;
 
-	netxen_config_indev_addr(dev, event);
+	netxen_config_indev_addr(adapter, orig_dev, event);
 done:
 	return NOTIFY_DONE;
 }
@@ -2921,7 +3003,7 @@ netxen_inetaddr_event(struct notifier_block *this,
 	dev = ifa->ifa_dev ? ifa->ifa_dev->dev : NULL;
 
 recheck:
-	if (dev == NULL || !netif_running(dev))
+	if (dev == NULL)
 		goto done;
 
 	if (dev->priv_flags & IFF_802_1Q_VLAN) {
@@ -2943,9 +3025,11 @@ recheck:
 	switch (event) {
 	case NETDEV_UP:
 		netxen_config_ipaddr(adapter, ifa->ifa_address, NX_IP_UP);
+		netxen_list_config_vlan_ip(adapter, ifa, NX_IP_UP);
 		break;
 	case NETDEV_DOWN:
 		netxen_config_ipaddr(adapter, ifa->ifa_address, NX_IP_DOWN);
+		netxen_list_config_vlan_ip(adapter, ifa, NX_IP_DOWN);
 		break;
 	default:
 		break;
@@ -2964,7 +3048,10 @@ static struct notifier_block netxen_inetaddr_cb = {
 };
 #else
 static void
-netxen_config_indev_addr(struct net_device *dev, unsigned long event)
+netxen_restore_indev_addr(struct net_device *dev, unsigned long event)
+{ }
+static void
+netxen_free_vlan_ip_list(struct netxen_adapter *adapter)
 { }
 #endif
 
-- 
1.6.3.3



^ permalink raw reply related

* [PATCH 2/2] net: Compute protocol sequence numbers and fragment IDs using MD5.
From: David Miller @ 2011-08-07  1:50 UTC (permalink / raw)
  To: netdev; +Cc: dan, w, torvalds, linux-kernel, dccp, mpm, herbert, gerrit


Computers have become a lot faster since we compromised on the
partial MD4 hash which we use currently for performance reasons.

MD5 is a much safer choice, and is inline with both RFC1948 and
other ISS generators (OpenBSD, Solaris, etc.)

Furthermore, only having 24-bits of the sequence number be truly
unpredictable is a very serious limitation.  So the periodic
regeneration and 8-bit counter have been removed.  We compute and
use a full 32-bit sequence number.

For ipv6, DCCP was found to use a 32-bit truncated initial sequence
number (it needs 43-bits) and that is fixed here as well.

Reported-by: Dan Kaminsky <dan@doxpara.com>
Tested-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/char/random.c                    |  349 +-----------------------------
 include/linux/random.h                   |   12 -
 include/net/secure_seq.h                 |   20 ++
 net/core/Makefile                        |    2 +-
 net/core/secure_seq.c                    |  184 ++++++++++++++++
 net/dccp/ipv4.c                          |    1 +
 net/dccp/ipv6.c                          |    9 +-
 net/ipv4/inet_hashtables.c               |    1 +
 net/ipv4/inetpeer.c                      |    1 +
 net/ipv4/netfilter/nf_nat_proto_common.c |    1 +
 net/ipv4/route.c                         |    1 +
 net/ipv4/tcp_ipv4.c                      |    1 +
 net/ipv6/inet6_hashtables.c              |    1 +
 net/ipv6/tcp_ipv6.c                      |    1 +
 14 files changed, 223 insertions(+), 361 deletions(-)
 create mode 100644 include/net/secure_seq.h
 create mode 100644 net/core/secure_seq.c

diff --git a/drivers/char/random.c b/drivers/char/random.c
index 7292819..c35a785 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1300,345 +1300,14 @@ ctl_table random_table[] = {
 };
 #endif 	/* CONFIG_SYSCTL */
 
-/********************************************************************
- *
- * Random functions for networking
- *
- ********************************************************************/
-
-/*
- * TCP initial sequence number picking.  This uses the random number
- * generator to pick an initial secret value.  This value is hashed
- * along with the TCP endpoint information to provide a unique
- * starting point for each pair of TCP endpoints.  This defeats
- * attacks which rely on guessing the initial TCP sequence number.
- * This algorithm was suggested by Steve Bellovin.
- *
- * Using a very strong hash was taking an appreciable amount of the total
- * TCP connection establishment time, so this is a weaker hash,
- * compensated for by changing the secret periodically.
- */
-
-/* F, G and H are basic MD4 functions: selection, majority, parity */
-#define F(x, y, z) ((z) ^ ((x) & ((y) ^ (z))))
-#define G(x, y, z) (((x) & (y)) + (((x) ^ (y)) & (z)))
-#define H(x, y, z) ((x) ^ (y) ^ (z))
-
-/*
- * The generic round function.  The application is so specific that
- * we don't bother protecting all the arguments with parens, as is generally
- * good macro practice, in favor of extra legibility.
- * Rotation is separate from addition to prevent recomputation
- */
-#define ROUND(f, a, b, c, d, x, s)	\
-	(a += f(b, c, d) + x, a = (a << s) | (a >> (32 - s)))
-#define K1 0
-#define K2 013240474631UL
-#define K3 015666365641UL
-
-#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
-
-static __u32 twothirdsMD4Transform(__u32 const buf[4], __u32 const in[12])
-{
-	__u32 a = buf[0], b = buf[1], c = buf[2], d = buf[3];
-
-	/* Round 1 */
-	ROUND(F, a, b, c, d, in[ 0] + K1,  3);
-	ROUND(F, d, a, b, c, in[ 1] + K1,  7);
-	ROUND(F, c, d, a, b, in[ 2] + K1, 11);
-	ROUND(F, b, c, d, a, in[ 3] + K1, 19);
-	ROUND(F, a, b, c, d, in[ 4] + K1,  3);
-	ROUND(F, d, a, b, c, in[ 5] + K1,  7);
-	ROUND(F, c, d, a, b, in[ 6] + K1, 11);
-	ROUND(F, b, c, d, a, in[ 7] + K1, 19);
-	ROUND(F, a, b, c, d, in[ 8] + K1,  3);
-	ROUND(F, d, a, b, c, in[ 9] + K1,  7);
-	ROUND(F, c, d, a, b, in[10] + K1, 11);
-	ROUND(F, b, c, d, a, in[11] + K1, 19);
-
-	/* Round 2 */
-	ROUND(G, a, b, c, d, in[ 1] + K2,  3);
-	ROUND(G, d, a, b, c, in[ 3] + K2,  5);
-	ROUND(G, c, d, a, b, in[ 5] + K2,  9);
-	ROUND(G, b, c, d, a, in[ 7] + K2, 13);
-	ROUND(G, a, b, c, d, in[ 9] + K2,  3);
-	ROUND(G, d, a, b, c, in[11] + K2,  5);
-	ROUND(G, c, d, a, b, in[ 0] + K2,  9);
-	ROUND(G, b, c, d, a, in[ 2] + K2, 13);
-	ROUND(G, a, b, c, d, in[ 4] + K2,  3);
-	ROUND(G, d, a, b, c, in[ 6] + K2,  5);
-	ROUND(G, c, d, a, b, in[ 8] + K2,  9);
-	ROUND(G, b, c, d, a, in[10] + K2, 13);
-
-	/* Round 3 */
-	ROUND(H, a, b, c, d, in[ 3] + K3,  3);
-	ROUND(H, d, a, b, c, in[ 7] + K3,  9);
-	ROUND(H, c, d, a, b, in[11] + K3, 11);
-	ROUND(H, b, c, d, a, in[ 2] + K3, 15);
-	ROUND(H, a, b, c, d, in[ 6] + K3,  3);
-	ROUND(H, d, a, b, c, in[10] + K3,  9);
-	ROUND(H, c, d, a, b, in[ 1] + K3, 11);
-	ROUND(H, b, c, d, a, in[ 5] + K3, 15);
-	ROUND(H, a, b, c, d, in[ 9] + K3,  3);
-	ROUND(H, d, a, b, c, in[ 0] + K3,  9);
-	ROUND(H, c, d, a, b, in[ 4] + K3, 11);
-	ROUND(H, b, c, d, a, in[ 8] + K3, 15);
-
-	return buf[1] + b; /* "most hashed" word */
-	/* Alternative: return sum of all words? */
-}
-#endif
-
-#undef ROUND
-#undef F
-#undef G
-#undef H
-#undef K1
-#undef K2
-#undef K3
-
-/* This should not be decreased so low that ISNs wrap too fast. */
-#define REKEY_INTERVAL (300 * HZ)
-/*
- * Bit layout of the tcp sequence numbers (before adding current time):
- * bit 24-31: increased after every key exchange
- * bit 0-23: hash(source,dest)
- *
- * The implementation is similar to the algorithm described
- * in the Appendix of RFC 1185, except that
- * - it uses a 1 MHz clock instead of a 250 kHz clock
- * - it performs a rekey every 5 minutes, which is equivalent
- * 	to a (source,dest) tulple dependent forward jump of the
- * 	clock by 0..2^(HASH_BITS+1)
- *
- * Thus the average ISN wraparound time is 68 minutes instead of
- * 4.55 hours.
- *
- * SMP cleanup and lock avoidance with poor man's RCU.
- * 			Manfred Spraul <manfred@colorfullife.com>
- *
- */
-#define COUNT_BITS 8
-#define COUNT_MASK ((1 << COUNT_BITS) - 1)
-#define HASH_BITS 24
-#define HASH_MASK ((1 << HASH_BITS) - 1)
+static u32 random_int_secret[MD5_MESSAGE_BYTES / 4] ____cacheline_aligned;
 
-static struct keydata {
-	__u32 count; /* already shifted to the final position */
-	__u32 secret[12];
-} ____cacheline_aligned ip_keydata[2];
-
-static unsigned int ip_cnt;
-
-static void rekey_seq_generator(struct work_struct *work);
-
-static DECLARE_DELAYED_WORK(rekey_work, rekey_seq_generator);
-
-/*
- * Lock avoidance:
- * The ISN generation runs lockless - it's just a hash over random data.
- * State changes happen every 5 minutes when the random key is replaced.
- * Synchronization is performed by having two copies of the hash function
- * state and rekey_seq_generator always updates the inactive copy.
- * The copy is then activated by updating ip_cnt.
- * The implementation breaks down if someone blocks the thread
- * that processes SYN requests for more than 5 minutes. Should never
- * happen, and even if that happens only a not perfectly compliant
- * ISN is generated, nothing fatal.
- */
-static void rekey_seq_generator(struct work_struct *work)
+static int __init random_int_secret_init(void)
 {
-	struct keydata *keyptr = &ip_keydata[1 ^ (ip_cnt & 1)];
-
-	get_random_bytes(keyptr->secret, sizeof(keyptr->secret));
-	keyptr->count = (ip_cnt & COUNT_MASK) << HASH_BITS;
-	smp_wmb();
-	ip_cnt++;
-	schedule_delayed_work(&rekey_work,
-			      round_jiffies_relative(REKEY_INTERVAL));
-}
-
-static inline struct keydata *get_keyptr(void)
-{
-	struct keydata *keyptr = &ip_keydata[ip_cnt & 1];
-
-	smp_rmb();
-
-	return keyptr;
-}
-
-static __init int seqgen_init(void)
-{
-	rekey_seq_generator(NULL);
+	get_random_bytes(random_int_secret, sizeof(random_int_secret));
 	return 0;
 }
-late_initcall(seqgen_init);
-
-#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
-__u32 secure_tcpv6_sequence_number(__be32 *saddr, __be32 *daddr,
-				   __be16 sport, __be16 dport)
-{
-	__u32 seq;
-	__u32 hash[12];
-	struct keydata *keyptr = get_keyptr();
-
-	/* The procedure is the same as for IPv4, but addresses are longer.
-	 * Thus we must use twothirdsMD4Transform.
-	 */
-
-	memcpy(hash, saddr, 16);
-	hash[4] = ((__force u16)sport << 16) + (__force u16)dport;
-	memcpy(&hash[5], keyptr->secret, sizeof(__u32) * 7);
-
-	seq = twothirdsMD4Transform((const __u32 *)daddr, hash) & HASH_MASK;
-	seq += keyptr->count;
-
-	seq += ktime_to_ns(ktime_get_real());
-
-	return seq;
-}
-EXPORT_SYMBOL(secure_tcpv6_sequence_number);
-#endif
-
-/*  The code below is shamelessly stolen from secure_tcp_sequence_number().
- *  All blames to Andrey V. Savochkin <saw@msu.ru>.
- */
-__u32 secure_ip_id(__be32 daddr)
-{
-	struct keydata *keyptr;
-	__u32 hash[4];
-
-	keyptr = get_keyptr();
-
-	/*
-	 *  Pick a unique starting offset for each IP destination.
-	 *  The dest ip address is placed in the starting vector,
-	 *  which is then hashed with random data.
-	 */
-	hash[0] = (__force __u32)daddr;
-	hash[1] = keyptr->secret[9];
-	hash[2] = keyptr->secret[10];
-	hash[3] = keyptr->secret[11];
-
-	return half_md4_transform(hash, keyptr->secret);
-}
-
-__u32 secure_ipv6_id(const __be32 daddr[4])
-{
-	const struct keydata *keyptr;
-	__u32 hash[4];
-
-	keyptr = get_keyptr();
-
-	hash[0] = (__force __u32)daddr[0];
-	hash[1] = (__force __u32)daddr[1];
-	hash[2] = (__force __u32)daddr[2];
-	hash[3] = (__force __u32)daddr[3];
-
-	return half_md4_transform(hash, keyptr->secret);
-}
-
-#ifdef CONFIG_INET
-
-__u32 secure_tcp_sequence_number(__be32 saddr, __be32 daddr,
-				 __be16 sport, __be16 dport)
-{
-	__u32 seq;
-	__u32 hash[4];
-	struct keydata *keyptr = get_keyptr();
-
-	/*
-	 *  Pick a unique starting offset for each TCP connection endpoints
-	 *  (saddr, daddr, sport, dport).
-	 *  Note that the words are placed into the starting vector, which is
-	 *  then mixed with a partial MD4 over random data.
-	 */
-	hash[0] = (__force u32)saddr;
-	hash[1] = (__force u32)daddr;
-	hash[2] = ((__force u16)sport << 16) + (__force u16)dport;
-	hash[3] = keyptr->secret[11];
-
-	seq = half_md4_transform(hash, keyptr->secret) & HASH_MASK;
-	seq += keyptr->count;
-	/*
-	 *	As close as possible to RFC 793, which
-	 *	suggests using a 250 kHz clock.
-	 *	Further reading shows this assumes 2 Mb/s networks.
-	 *	For 10 Mb/s Ethernet, a 1 MHz clock is appropriate.
-	 *	For 10 Gb/s Ethernet, a 1 GHz clock should be ok, but
-	 *	we also need to limit the resolution so that the u32 seq
-	 *	overlaps less than one time per MSL (2 minutes).
-	 *	Choosing a clock of 64 ns period is OK. (period of 274 s)
-	 */
-	seq += ktime_to_ns(ktime_get_real()) >> 6;
-
-	return seq;
-}
-
-/* Generate secure starting point for ephemeral IPV4 transport port search */
-u32 secure_ipv4_port_ephemeral(__be32 saddr, __be32 daddr, __be16 dport)
-{
-	struct keydata *keyptr = get_keyptr();
-	u32 hash[4];
-
-	/*
-	 *  Pick a unique starting offset for each ephemeral port search
-	 *  (saddr, daddr, dport) and 48bits of random data.
-	 */
-	hash[0] = (__force u32)saddr;
-	hash[1] = (__force u32)daddr;
-	hash[2] = (__force u32)dport ^ keyptr->secret[10];
-	hash[3] = keyptr->secret[11];
-
-	return half_md4_transform(hash, keyptr->secret);
-}
-EXPORT_SYMBOL_GPL(secure_ipv4_port_ephemeral);
-
-#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
-u32 secure_ipv6_port_ephemeral(const __be32 *saddr, const __be32 *daddr,
-			       __be16 dport)
-{
-	struct keydata *keyptr = get_keyptr();
-	u32 hash[12];
-
-	memcpy(hash, saddr, 16);
-	hash[4] = (__force u32)dport;
-	memcpy(&hash[5], keyptr->secret, sizeof(__u32) * 7);
-
-	return twothirdsMD4Transform((const __u32 *)daddr, hash);
-}
-#endif
-
-#if defined(CONFIG_IP_DCCP) || defined(CONFIG_IP_DCCP_MODULE)
-/* Similar to secure_tcp_sequence_number but generate a 48 bit value
- * bit's 32-47 increase every key exchange
- *       0-31  hash(source, dest)
- */
-u64 secure_dccp_sequence_number(__be32 saddr, __be32 daddr,
-				__be16 sport, __be16 dport)
-{
-	u64 seq;
-	__u32 hash[4];
-	struct keydata *keyptr = get_keyptr();
-
-	hash[0] = (__force u32)saddr;
-	hash[1] = (__force u32)daddr;
-	hash[2] = ((__force u16)sport << 16) + (__force u16)dport;
-	hash[3] = keyptr->secret[11];
-
-	seq = half_md4_transform(hash, keyptr->secret);
-	seq |= ((u64)keyptr->count) << (32 - HASH_BITS);
-
-	seq += ktime_to_ns(ktime_get_real());
-	seq &= (1ull << 48) - 1;
-
-	return seq;
-}
-EXPORT_SYMBOL(secure_dccp_sequence_number);
-#endif
-
-#endif /* CONFIG_INET */
-
+late_initcall(random_int_secret_init);
 
 /*
  * Get a random word for internal kernel use only. Similar to urandom but
@@ -1646,17 +1315,15 @@ EXPORT_SYMBOL(secure_dccp_sequence_number);
  * value is not cryptographically secure but for several uses the cost of
  * depleting entropy is too high
  */
-DEFINE_PER_CPU(__u32 [4], get_random_int_hash);
+DEFINE_PER_CPU(__u32 [MD5_DIGEST_WORDS], get_random_int_hash);
 unsigned int get_random_int(void)
 {
-	struct keydata *keyptr;
 	__u32 *hash = get_cpu_var(get_random_int_hash);
-	int ret;
+	unsigned int ret;
 
-	keyptr = get_keyptr();
 	hash[0] += current->pid + jiffies + get_cycles();
-
-	ret = half_md4_transform(hash, keyptr->secret);
+	md5_transform(hash, random_int_secret);
+	ret = hash[0];
 	put_cpu_var(get_random_int_hash);
 
 	return ret;
diff --git a/include/linux/random.h b/include/linux/random.h
index ce29a04..d13059f 100644
--- a/include/linux/random.h
+++ b/include/linux/random.h
@@ -57,18 +57,6 @@ extern void add_interrupt_randomness(int irq);
 extern void get_random_bytes(void *buf, int nbytes);
 void generate_random_uuid(unsigned char uuid_out[16]);
 
-extern __u32 secure_ip_id(__be32 daddr);
-extern __u32 secure_ipv6_id(const __be32 daddr[4]);
-extern u32 secure_ipv4_port_ephemeral(__be32 saddr, __be32 daddr, __be16 dport);
-extern u32 secure_ipv6_port_ephemeral(const __be32 *saddr, const __be32 *daddr,
-				      __be16 dport);
-extern __u32 secure_tcp_sequence_number(__be32 saddr, __be32 daddr,
-					__be16 sport, __be16 dport);
-extern __u32 secure_tcpv6_sequence_number(__be32 *saddr, __be32 *daddr,
-					  __be16 sport, __be16 dport);
-extern u64 secure_dccp_sequence_number(__be32 saddr, __be32 daddr,
-				       __be16 sport, __be16 dport);
-
 #ifndef MODULE
 extern const struct file_operations random_fops, urandom_fops;
 #endif
diff --git a/include/net/secure_seq.h b/include/net/secure_seq.h
new file mode 100644
index 0000000..d97f689
--- /dev/null
+++ b/include/net/secure_seq.h
@@ -0,0 +1,20 @@
+#ifndef _NET_SECURE_SEQ
+#define _NET_SECURE_SEQ
+
+#include <linux/types.h>
+
+extern __u32 secure_ip_id(__be32 daddr);
+extern __u32 secure_ipv6_id(const __be32 daddr[4]);
+extern u32 secure_ipv4_port_ephemeral(__be32 saddr, __be32 daddr, __be16 dport);
+extern u32 secure_ipv6_port_ephemeral(const __be32 *saddr, const __be32 *daddr,
+				      __be16 dport);
+extern __u32 secure_tcp_sequence_number(__be32 saddr, __be32 daddr,
+					__be16 sport, __be16 dport);
+extern __u32 secure_tcpv6_sequence_number(__be32 *saddr, __be32 *daddr,
+					  __be16 sport, __be16 dport);
+extern u64 secure_dccp_sequence_number(__be32 saddr, __be32 daddr,
+				       __be16 sport, __be16 dport);
+extern u64 secure_dccpv6_sequence_number(__be32 *saddr, __be32 *daddr,
+					 __be16 sport, __be16 dport);
+
+#endif /* _NET_SECURE_SEQ */
diff --git a/net/core/Makefile b/net/core/Makefile
index 8a04dd2..0d357b1 100644
--- a/net/core/Makefile
+++ b/net/core/Makefile
@@ -3,7 +3,7 @@
 #
 
 obj-y := sock.o request_sock.o skbuff.o iovec.o datagram.o stream.o scm.o \
-	 gen_stats.o gen_estimator.o net_namespace.o
+	 gen_stats.o gen_estimator.o net_namespace.o secure_seq.o
 
 obj-$(CONFIG_SYSCTL) += sysctl_net_core.o
 
diff --git a/net/core/secure_seq.c b/net/core/secure_seq.c
new file mode 100644
index 0000000..45329d7
--- /dev/null
+++ b/net/core/secure_seq.c
@@ -0,0 +1,184 @@
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/cryptohash.h>
+#include <linux/module.h>
+#include <linux/cache.h>
+#include <linux/random.h>
+#include <linux/hrtimer.h>
+#include <linux/ktime.h>
+#include <linux/string.h>
+
+#include <net/secure_seq.h>
+
+static u32 net_secret[MD5_MESSAGE_BYTES / 4] ____cacheline_aligned;
+
+static int __init net_secret_init(void)
+{
+	get_random_bytes(net_secret, sizeof(net_secret));
+	return 0;
+}
+late_initcall(net_secret_init);
+
+static u32 seq_scale(u32 seq)
+{
+	/*
+	 *	As close as possible to RFC 793, which
+	 *	suggests using a 250 kHz clock.
+	 *	Further reading shows this assumes 2 Mb/s networks.
+	 *	For 10 Mb/s Ethernet, a 1 MHz clock is appropriate.
+	 *	For 10 Gb/s Ethernet, a 1 GHz clock should be ok, but
+	 *	we also need to limit the resolution so that the u32 seq
+	 *	overlaps less than one time per MSL (2 minutes).
+	 *	Choosing a clock of 64 ns period is OK. (period of 274 s)
+	 */
+	return seq + (ktime_to_ns(ktime_get_real()) >> 6);
+}
+
+#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+__u32 secure_tcpv6_sequence_number(__be32 *saddr, __be32 *daddr,
+				   __be16 sport, __be16 dport)
+{
+	u32 secret[MD5_MESSAGE_BYTES / 4];
+	u32 hash[MD5_DIGEST_WORDS];
+	u32 i;
+
+	memcpy(hash, saddr, 16);
+	for (i = 0; i < 4; i++)
+		secret[i] = net_secret[i] + daddr[i];
+	secret[4] = net_secret[4] +
+		(((__force u16)sport << 16) + (__force u16)dport);
+	for (i = 5; i < MD5_MESSAGE_BYTES / 4; i++)
+		secret[i] = net_secret[i];
+
+	md5_transform(hash, secret);
+
+	return seq_scale(hash[0]);
+}
+EXPORT_SYMBOL(secure_tcpv6_sequence_number);
+
+u32 secure_ipv6_port_ephemeral(const __be32 *saddr, const __be32 *daddr,
+			       __be16 dport)
+{
+	u32 secret[MD5_MESSAGE_BYTES / 4];
+	u32 hash[MD5_DIGEST_WORDS];
+	u32 i;
+
+	memcpy(hash, saddr, 16);
+	for (i = 0; i < 4; i++)
+		secret[i] = net_secret[i] + (__force u32) daddr[i];
+	secret[4] = net_secret[4] + (__force u32)dport;
+	for (i = 5; i < MD5_MESSAGE_BYTES / 4; i++)
+		secret[i] = net_secret[i];
+
+	md5_transform(hash, secret);
+
+	return hash[0];
+}
+#endif
+
+#ifdef CONFIG_INET
+__u32 secure_ip_id(__be32 daddr)
+{
+	u32 hash[MD5_DIGEST_WORDS];
+
+	hash[0] = (__force __u32) daddr;
+	hash[1] = net_secret[13];
+	hash[2] = net_secret[14];
+	hash[3] = net_secret[15];
+
+	md5_transform(hash, net_secret);
+
+	return hash[0];
+}
+
+__u32 secure_ipv6_id(const __be32 daddr[4])
+{
+	__u32 hash[4];
+
+	memcpy(hash, daddr, 16);
+	md5_transform(hash, net_secret);
+
+	return hash[0];
+}
+
+__u32 secure_tcp_sequence_number(__be32 saddr, __be32 daddr,
+				 __be16 sport, __be16 dport)
+{
+	u32 hash[MD5_DIGEST_WORDS];
+
+	hash[0] = (__force u32)saddr;
+	hash[1] = (__force u32)daddr;
+	hash[2] = ((__force u16)sport << 16) + (__force u16)dport;
+	hash[3] = net_secret[15];
+
+	md5_transform(hash, net_secret);
+
+	return seq_scale(hash[0]);
+}
+
+u32 secure_ipv4_port_ephemeral(__be32 saddr, __be32 daddr, __be16 dport)
+{
+	u32 hash[MD5_DIGEST_WORDS];
+
+	hash[0] = (__force u32)saddr;
+	hash[1] = (__force u32)daddr;
+	hash[2] = (__force u32)dport ^ net_secret[14];
+	hash[3] = net_secret[15];
+
+	md5_transform(hash, net_secret);
+
+	return hash[0];
+}
+EXPORT_SYMBOL_GPL(secure_ipv4_port_ephemeral);
+#endif
+
+#if defined(CONFIG_IP_DCCP) || defined(CONFIG_IP_DCCP_MODULE)
+u64 secure_dccp_sequence_number(__be32 saddr, __be32 daddr,
+				__be16 sport, __be16 dport)
+{
+	u32 hash[MD5_DIGEST_WORDS];
+	u64 seq;
+
+	hash[0] = (__force u32)saddr;
+	hash[1] = (__force u32)daddr;
+	hash[2] = ((__force u16)sport << 16) + (__force u16)dport;
+	hash[3] = net_secret[15];
+
+	md5_transform(hash, net_secret);
+
+	seq = hash[0] | (((u64)hash[1]) << 32);
+	seq += ktime_to_ns(ktime_get_real());
+	seq &= (1ull << 48) - 1;
+
+	return seq;
+}
+EXPORT_SYMBOL(secure_dccp_sequence_number);
+
+#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+u64 secure_dccpv6_sequence_number(__be32 *saddr, __be32 *daddr,
+				  __be16 sport, __be16 dport)
+{
+	u32 secret[MD5_MESSAGE_BYTES / 4];
+	u32 hash[MD5_DIGEST_WORDS];
+	u64 seq;
+	u32 i;
+
+	memcpy(hash, saddr, 16);
+	for (i = 0; i < 4; i++)
+		secret[i] = net_secret[i] + daddr[i];
+	secret[4] = net_secret[4] +
+		(((__force u16)sport << 16) + (__force u16)dport);
+	for (i = 5; i < MD5_MESSAGE_BYTES / 4; i++)
+		secret[i] = net_secret[i];
+
+	md5_transform(hash, secret);
+
+	seq = hash[0] | (((u64)hash[1]) << 32);
+	seq += ktime_to_ns(ktime_get_real());
+	seq &= (1ull << 48) - 1;
+
+	return seq;
+}
+EXPORT_SYMBOL(secure_dccpv6_sequence_number);
+#endif
+#endif
diff --git a/net/dccp/ipv4.c b/net/dccp/ipv4.c
index 8c36adf..332639b 100644
--- a/net/dccp/ipv4.c
+++ b/net/dccp/ipv4.c
@@ -26,6 +26,7 @@
 #include <net/timewait_sock.h>
 #include <net/tcp_states.h>
 #include <net/xfrm.h>
+#include <net/secure_seq.h>
 
 #include "ackvec.h"
 #include "ccid.h"
diff --git a/net/dccp/ipv6.c b/net/dccp/ipv6.c
index 8dc4348..b74f761 100644
--- a/net/dccp/ipv6.c
+++ b/net/dccp/ipv6.c
@@ -29,6 +29,7 @@
 #include <net/transp_v6.h>
 #include <net/ip6_checksum.h>
 #include <net/xfrm.h>
+#include <net/secure_seq.h>
 
 #include "dccp.h"
 #include "ipv6.h"
@@ -69,13 +70,7 @@ static inline void dccp_v6_send_check(struct sock *sk, struct sk_buff *skb)
 	dh->dccph_checksum = dccp_v6_csum_finish(skb, &np->saddr, &np->daddr);
 }
 
-static inline __u32 secure_dccpv6_sequence_number(__be32 *saddr, __be32 *daddr,
-						  __be16 sport, __be16 dport   )
-{
-	return secure_tcpv6_sequence_number(saddr, daddr, sport, dport);
-}
-
-static inline __u32 dccp_v6_init_sequence(struct sk_buff *skb)
+static inline __u64 dccp_v6_init_sequence(struct sk_buff *skb)
 {
 	return secure_dccpv6_sequence_number(ipv6_hdr(skb)->daddr.s6_addr32,
 					     ipv6_hdr(skb)->saddr.s6_addr32,
diff --git a/net/ipv4/inet_hashtables.c b/net/ipv4/inet_hashtables.c
index 3c0369a..984ec65 100644
--- a/net/ipv4/inet_hashtables.c
+++ b/net/ipv4/inet_hashtables.c
@@ -21,6 +21,7 @@
 
 #include <net/inet_connection_sock.h>
 #include <net/inet_hashtables.h>
+#include <net/secure_seq.h>
 #include <net/ip.h>
 
 /*
diff --git a/net/ipv4/inetpeer.c b/net/ipv4/inetpeer.c
index e382138..86f13c67 100644
--- a/net/ipv4/inetpeer.c
+++ b/net/ipv4/inetpeer.c
@@ -19,6 +19,7 @@
 #include <linux/net.h>
 #include <net/ip.h>
 #include <net/inetpeer.h>
+#include <net/secure_seq.h>
 
 /*
  *  Theory of operations.
diff --git a/net/ipv4/netfilter/nf_nat_proto_common.c b/net/ipv4/netfilter/nf_nat_proto_common.c
index 3e61faf..f52d41e 100644
--- a/net/ipv4/netfilter/nf_nat_proto_common.c
+++ b/net/ipv4/netfilter/nf_nat_proto_common.c
@@ -12,6 +12,7 @@
 #include <linux/ip.h>
 
 #include <linux/netfilter.h>
+#include <net/secure_seq.h>
 #include <net/netfilter/nf_nat.h>
 #include <net/netfilter/nf_nat_core.h>
 #include <net/netfilter/nf_nat_rule.h>
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 6afc4eb..e3dec1c 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -109,6 +109,7 @@
 #include <linux/sysctl.h>
 #endif
 #include <net/atmclip.h>
+#include <net/secure_seq.h>
 
 #define RT_FL_TOS(oldflp4) \
     ((u32)(oldflp4->flowi4_tos & (IPTOS_RT_MASK | RTO_ONLINK)))
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 955b8e6..1c12b8e 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -72,6 +72,7 @@
 #include <net/timewait_sock.h>
 #include <net/xfrm.h>
 #include <net/netdma.h>
+#include <net/secure_seq.h>
 
 #include <linux/inet.h>
 #include <linux/ipv6.h>
diff --git a/net/ipv6/inet6_hashtables.c b/net/ipv6/inet6_hashtables.c
index b531972..73f1a00 100644
--- a/net/ipv6/inet6_hashtables.c
+++ b/net/ipv6/inet6_hashtables.c
@@ -20,6 +20,7 @@
 #include <net/inet_connection_sock.h>
 #include <net/inet_hashtables.h>
 #include <net/inet6_hashtables.h>
+#include <net/secure_seq.h>
 #include <net/ip.h>
 
 int __inet6_hash(struct sock *sk, struct inet_timewait_sock *tw)
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index 78aa534..d1fb63f 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -61,6 +61,7 @@
 #include <net/timewait_sock.h>
 #include <net/netdma.h>
 #include <net/inet_common.h>
+#include <net/secure_seq.h>
 
 #include <asm/uaccess.h>
 
-- 
1.7.6


^ permalink raw reply related

* [PATCH 1/2] crypto: Move md5_transform to lib/md5.c
From: David Miller @ 2011-08-07  1:50 UTC (permalink / raw)
  To: netdev; +Cc: dan, w, torvalds, linux-kernel, dccp, mpm, herbert, gerrit


We are going to use this for TCP/IP sequence number and fragment ID
generation.

Signed-off-by: David S. Miller <davem@davemloft.net>
---
 crypto/md5.c               |   92 +------------------------------------------
 include/linux/cryptohash.h |    5 ++
 lib/Makefile               |    2 +-
 lib/md5.c                  |   95 ++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 102 insertions(+), 92 deletions(-)
 create mode 100644 lib/md5.c

diff --git a/crypto/md5.c b/crypto/md5.c
index 30efc7d..7febeaa 100644
--- a/crypto/md5.c
+++ b/crypto/md5.c
@@ -21,99 +21,9 @@
 #include <linux/module.h>
 #include <linux/string.h>
 #include <linux/types.h>
+#include <linux/cryptohash.h>
 #include <asm/byteorder.h>
 
-#define F1(x, y, z)	(z ^ (x & (y ^ z)))
-#define F2(x, y, z)	F1(z, x, y)
-#define F3(x, y, z)	(x ^ y ^ z)
-#define F4(x, y, z)	(y ^ (x | ~z))
-
-#define MD5STEP(f, w, x, y, z, in, s) \
-	(w += f(x, y, z) + in, w = (w<<s | w>>(32-s)) + x)
-
-static void md5_transform(u32 *hash, u32 const *in)
-{
-	u32 a, b, c, d;
-
-	a = hash[0];
-	b = hash[1];
-	c = hash[2];
-	d = hash[3];
-
-	MD5STEP(F1, a, b, c, d, in[0] + 0xd76aa478, 7);
-	MD5STEP(F1, d, a, b, c, in[1] + 0xe8c7b756, 12);
-	MD5STEP(F1, c, d, a, b, in[2] + 0x242070db, 17);
-	MD5STEP(F1, b, c, d, a, in[3] + 0xc1bdceee, 22);
-	MD5STEP(F1, a, b, c, d, in[4] + 0xf57c0faf, 7);
-	MD5STEP(F1, d, a, b, c, in[5] + 0x4787c62a, 12);
-	MD5STEP(F1, c, d, a, b, in[6] + 0xa8304613, 17);
-	MD5STEP(F1, b, c, d, a, in[7] + 0xfd469501, 22);
-	MD5STEP(F1, a, b, c, d, in[8] + 0x698098d8, 7);
-	MD5STEP(F1, d, a, b, c, in[9] + 0x8b44f7af, 12);
-	MD5STEP(F1, c, d, a, b, in[10] + 0xffff5bb1, 17);
-	MD5STEP(F1, b, c, d, a, in[11] + 0x895cd7be, 22);
-	MD5STEP(F1, a, b, c, d, in[12] + 0x6b901122, 7);
-	MD5STEP(F1, d, a, b, c, in[13] + 0xfd987193, 12);
-	MD5STEP(F1, c, d, a, b, in[14] + 0xa679438e, 17);
-	MD5STEP(F1, b, c, d, a, in[15] + 0x49b40821, 22);
-
-	MD5STEP(F2, a, b, c, d, in[1] + 0xf61e2562, 5);
-	MD5STEP(F2, d, a, b, c, in[6] + 0xc040b340, 9);
-	MD5STEP(F2, c, d, a, b, in[11] + 0x265e5a51, 14);
-	MD5STEP(F2, b, c, d, a, in[0] + 0xe9b6c7aa, 20);
-	MD5STEP(F2, a, b, c, d, in[5] + 0xd62f105d, 5);
-	MD5STEP(F2, d, a, b, c, in[10] + 0x02441453, 9);
-	MD5STEP(F2, c, d, a, b, in[15] + 0xd8a1e681, 14);
-	MD5STEP(F2, b, c, d, a, in[4] + 0xe7d3fbc8, 20);
-	MD5STEP(F2, a, b, c, d, in[9] + 0x21e1cde6, 5);
-	MD5STEP(F2, d, a, b, c, in[14] + 0xc33707d6, 9);
-	MD5STEP(F2, c, d, a, b, in[3] + 0xf4d50d87, 14);
-	MD5STEP(F2, b, c, d, a, in[8] + 0x455a14ed, 20);
-	MD5STEP(F2, a, b, c, d, in[13] + 0xa9e3e905, 5);
-	MD5STEP(F2, d, a, b, c, in[2] + 0xfcefa3f8, 9);
-	MD5STEP(F2, c, d, a, b, in[7] + 0x676f02d9, 14);
-	MD5STEP(F2, b, c, d, a, in[12] + 0x8d2a4c8a, 20);
-
-	MD5STEP(F3, a, b, c, d, in[5] + 0xfffa3942, 4);
-	MD5STEP(F3, d, a, b, c, in[8] + 0x8771f681, 11);
-	MD5STEP(F3, c, d, a, b, in[11] + 0x6d9d6122, 16);
-	MD5STEP(F3, b, c, d, a, in[14] + 0xfde5380c, 23);
-	MD5STEP(F3, a, b, c, d, in[1] + 0xa4beea44, 4);
-	MD5STEP(F3, d, a, b, c, in[4] + 0x4bdecfa9, 11);
-	MD5STEP(F3, c, d, a, b, in[7] + 0xf6bb4b60, 16);
-	MD5STEP(F3, b, c, d, a, in[10] + 0xbebfbc70, 23);
-	MD5STEP(F3, a, b, c, d, in[13] + 0x289b7ec6, 4);
-	MD5STEP(F3, d, a, b, c, in[0] + 0xeaa127fa, 11);
-	MD5STEP(F3, c, d, a, b, in[3] + 0xd4ef3085, 16);
-	MD5STEP(F3, b, c, d, a, in[6] + 0x04881d05, 23);
-	MD5STEP(F3, a, b, c, d, in[9] + 0xd9d4d039, 4);
-	MD5STEP(F3, d, a, b, c, in[12] + 0xe6db99e5, 11);
-	MD5STEP(F3, c, d, a, b, in[15] + 0x1fa27cf8, 16);
-	MD5STEP(F3, b, c, d, a, in[2] + 0xc4ac5665, 23);
-
-	MD5STEP(F4, a, b, c, d, in[0] + 0xf4292244, 6);
-	MD5STEP(F4, d, a, b, c, in[7] + 0x432aff97, 10);
-	MD5STEP(F4, c, d, a, b, in[14] + 0xab9423a7, 15);
-	MD5STEP(F4, b, c, d, a, in[5] + 0xfc93a039, 21);
-	MD5STEP(F4, a, b, c, d, in[12] + 0x655b59c3, 6);
-	MD5STEP(F4, d, a, b, c, in[3] + 0x8f0ccc92, 10);
-	MD5STEP(F4, c, d, a, b, in[10] + 0xffeff47d, 15);
-	MD5STEP(F4, b, c, d, a, in[1] + 0x85845dd1, 21);
-	MD5STEP(F4, a, b, c, d, in[8] + 0x6fa87e4f, 6);
-	MD5STEP(F4, d, a, b, c, in[15] + 0xfe2ce6e0, 10);
-	MD5STEP(F4, c, d, a, b, in[6] + 0xa3014314, 15);
-	MD5STEP(F4, b, c, d, a, in[13] + 0x4e0811a1, 21);
-	MD5STEP(F4, a, b, c, d, in[4] + 0xf7537e82, 6);
-	MD5STEP(F4, d, a, b, c, in[11] + 0xbd3af235, 10);
-	MD5STEP(F4, c, d, a, b, in[2] + 0x2ad7d2bb, 15);
-	MD5STEP(F4, b, c, d, a, in[9] + 0xeb86d391, 21);
-
-	hash[0] += a;
-	hash[1] += b;
-	hash[2] += c;
-	hash[3] += d;
-}
-
 /* XXX: this stuff can be optimized */
 static inline void le32_to_cpu_array(u32 *buf, unsigned int words)
 {
diff --git a/include/linux/cryptohash.h b/include/linux/cryptohash.h
index ec78a4b..d2984fb 100644
--- a/include/linux/cryptohash.h
+++ b/include/linux/cryptohash.h
@@ -8,6 +8,11 @@
 void sha_init(__u32 *buf);
 void sha_transform(__u32 *digest, const char *data, __u32 *W);
 
+#define MD5_DIGEST_WORDS 4
+#define MD5_MESSAGE_BYTES 64
+
+void md5_transform(__u32 *hash, __u32 const *in);
+
 __u32 half_md4_transform(__u32 buf[4], __u32 const in[8]);
 
 #endif
diff --git a/lib/Makefile b/lib/Makefile
index 6457af4..d5d175c 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -10,7 +10,7 @@ endif
 lib-y := ctype.o string.o vsprintf.o cmdline.o \
 	 rbtree.o radix-tree.o dump_stack.o timerqueue.o\
 	 idr.o int_sqrt.o extable.o prio_tree.o \
-	 sha1.o irq_regs.o reciprocal_div.o argv_split.o \
+	 sha1.o md5.o irq_regs.o reciprocal_div.o argv_split.o \
 	 proportions.o prio_heap.o ratelimit.o show_mem.o \
 	 is_single_threaded.o plist.o decompress.o find_next_bit.o
 
diff --git a/lib/md5.c b/lib/md5.c
new file mode 100644
index 0000000..c777180
--- /dev/null
+++ b/lib/md5.c
@@ -0,0 +1,95 @@
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/cryptohash.h>
+
+#define F1(x, y, z)	(z ^ (x & (y ^ z)))
+#define F2(x, y, z)	F1(z, x, y)
+#define F3(x, y, z)	(x ^ y ^ z)
+#define F4(x, y, z)	(y ^ (x | ~z))
+
+#define MD5STEP(f, w, x, y, z, in, s) \
+	(w += f(x, y, z) + in, w = (w<<s | w>>(32-s)) + x)
+
+void md5_transform(__u32 *hash, __u32 const *in)
+{
+	u32 a, b, c, d;
+
+	a = hash[0];
+	b = hash[1];
+	c = hash[2];
+	d = hash[3];
+
+	MD5STEP(F1, a, b, c, d, in[0] + 0xd76aa478, 7);
+	MD5STEP(F1, d, a, b, c, in[1] + 0xe8c7b756, 12);
+	MD5STEP(F1, c, d, a, b, in[2] + 0x242070db, 17);
+	MD5STEP(F1, b, c, d, a, in[3] + 0xc1bdceee, 22);
+	MD5STEP(F1, a, b, c, d, in[4] + 0xf57c0faf, 7);
+	MD5STEP(F1, d, a, b, c, in[5] + 0x4787c62a, 12);
+	MD5STEP(F1, c, d, a, b, in[6] + 0xa8304613, 17);
+	MD5STEP(F1, b, c, d, a, in[7] + 0xfd469501, 22);
+	MD5STEP(F1, a, b, c, d, in[8] + 0x698098d8, 7);
+	MD5STEP(F1, d, a, b, c, in[9] + 0x8b44f7af, 12);
+	MD5STEP(F1, c, d, a, b, in[10] + 0xffff5bb1, 17);
+	MD5STEP(F1, b, c, d, a, in[11] + 0x895cd7be, 22);
+	MD5STEP(F1, a, b, c, d, in[12] + 0x6b901122, 7);
+	MD5STEP(F1, d, a, b, c, in[13] + 0xfd987193, 12);
+	MD5STEP(F1, c, d, a, b, in[14] + 0xa679438e, 17);
+	MD5STEP(F1, b, c, d, a, in[15] + 0x49b40821, 22);
+
+	MD5STEP(F2, a, b, c, d, in[1] + 0xf61e2562, 5);
+	MD5STEP(F2, d, a, b, c, in[6] + 0xc040b340, 9);
+	MD5STEP(F2, c, d, a, b, in[11] + 0x265e5a51, 14);
+	MD5STEP(F2, b, c, d, a, in[0] + 0xe9b6c7aa, 20);
+	MD5STEP(F2, a, b, c, d, in[5] + 0xd62f105d, 5);
+	MD5STEP(F2, d, a, b, c, in[10] + 0x02441453, 9);
+	MD5STEP(F2, c, d, a, b, in[15] + 0xd8a1e681, 14);
+	MD5STEP(F2, b, c, d, a, in[4] + 0xe7d3fbc8, 20);
+	MD5STEP(F2, a, b, c, d, in[9] + 0x21e1cde6, 5);
+	MD5STEP(F2, d, a, b, c, in[14] + 0xc33707d6, 9);
+	MD5STEP(F2, c, d, a, b, in[3] + 0xf4d50d87, 14);
+	MD5STEP(F2, b, c, d, a, in[8] + 0x455a14ed, 20);
+	MD5STEP(F2, a, b, c, d, in[13] + 0xa9e3e905, 5);
+	MD5STEP(F2, d, a, b, c, in[2] + 0xfcefa3f8, 9);
+	MD5STEP(F2, c, d, a, b, in[7] + 0x676f02d9, 14);
+	MD5STEP(F2, b, c, d, a, in[12] + 0x8d2a4c8a, 20);
+
+	MD5STEP(F3, a, b, c, d, in[5] + 0xfffa3942, 4);
+	MD5STEP(F3, d, a, b, c, in[8] + 0x8771f681, 11);
+	MD5STEP(F3, c, d, a, b, in[11] + 0x6d9d6122, 16);
+	MD5STEP(F3, b, c, d, a, in[14] + 0xfde5380c, 23);
+	MD5STEP(F3, a, b, c, d, in[1] + 0xa4beea44, 4);
+	MD5STEP(F3, d, a, b, c, in[4] + 0x4bdecfa9, 11);
+	MD5STEP(F3, c, d, a, b, in[7] + 0xf6bb4b60, 16);
+	MD5STEP(F3, b, c, d, a, in[10] + 0xbebfbc70, 23);
+	MD5STEP(F3, a, b, c, d, in[13] + 0x289b7ec6, 4);
+	MD5STEP(F3, d, a, b, c, in[0] + 0xeaa127fa, 11);
+	MD5STEP(F3, c, d, a, b, in[3] + 0xd4ef3085, 16);
+	MD5STEP(F3, b, c, d, a, in[6] + 0x04881d05, 23);
+	MD5STEP(F3, a, b, c, d, in[9] + 0xd9d4d039, 4);
+	MD5STEP(F3, d, a, b, c, in[12] + 0xe6db99e5, 11);
+	MD5STEP(F3, c, d, a, b, in[15] + 0x1fa27cf8, 16);
+	MD5STEP(F3, b, c, d, a, in[2] + 0xc4ac5665, 23);
+
+	MD5STEP(F4, a, b, c, d, in[0] + 0xf4292244, 6);
+	MD5STEP(F4, d, a, b, c, in[7] + 0x432aff97, 10);
+	MD5STEP(F4, c, d, a, b, in[14] + 0xab9423a7, 15);
+	MD5STEP(F4, b, c, d, a, in[5] + 0xfc93a039, 21);
+	MD5STEP(F4, a, b, c, d, in[12] + 0x655b59c3, 6);
+	MD5STEP(F4, d, a, b, c, in[3] + 0x8f0ccc92, 10);
+	MD5STEP(F4, c, d, a, b, in[10] + 0xffeff47d, 15);
+	MD5STEP(F4, b, c, d, a, in[1] + 0x85845dd1, 21);
+	MD5STEP(F4, a, b, c, d, in[8] + 0x6fa87e4f, 6);
+	MD5STEP(F4, d, a, b, c, in[15] + 0xfe2ce6e0, 10);
+	MD5STEP(F4, c, d, a, b, in[6] + 0xa3014314, 15);
+	MD5STEP(F4, b, c, d, a, in[13] + 0x4e0811a1, 21);
+	MD5STEP(F4, a, b, c, d, in[4] + 0xf7537e82, 6);
+	MD5STEP(F4, d, a, b, c, in[11] + 0xbd3af235, 10);
+	MD5STEP(F4, c, d, a, b, in[2] + 0x2ad7d2bb, 15);
+	MD5STEP(F4, b, c, d, a, in[9] + 0xeb86d391, 21);
+
+	hash[0] += a;
+	hash[1] += b;
+	hash[2] += c;
+	hash[3] += d;
+}
+EXPORT_SYMBOL(md5_transform);
-- 
1.7.6


^ permalink raw reply related

* [PATCH 0/2] Improve sequence number generation.
From: David Miller @ 2011-08-07  1:50 UTC (permalink / raw)
  To: netdev; +Cc: dan, w, torvalds, linux-kernel, dccp, mpm, herbert, gerrit


Dan Kaminsky pointed out that using partial MD4 and using that to
generate a sequence number, of which only 24-bits are truly
unguessable, seriously undermine the goals of random sequence number
generation.

In particular, with only 24-bits being truly unguessable, packet
injection into a session using even something like brute force is a
real potential possibility.

We only use 24-bits because we regenerate the random number every 5
minutes "just in case."  But what does is trade a "we don't know" kind
of theoretical issue for a provably real one (brute force attack).

Therefore I'm moving us more in line with RFC1948 (as well as OpenBSD
and Solaris), to use MD5 and a full 32-bit result in the generated
sequence number.

MD5 was selected as a compromise between performance loss and
theoretical ability to be compromised.  Willy Tarreau did extensive
testing and SHA1 was found to harm performance too much to be
considered seriously at this time.

We may later add a sysctl for various modes (ie. a "super secure" mode
that uses SHA1 if people want that, and an "insecure" mode that doesn't
use cryptographic hashing at all for people in protected environments
where that might be safe to do).

I've also moved the sequence number generators out of random.c (they
never really belonged there, and are only there due to historical
artifacts), and fixed a bug in DCCP sequence number generation
(on ipv6 the 43-bit sequence number was truncated to 32-bits).

This work is already pushed out to the net GIT tree and I'll ask
Linus to pull it in a moment, we've been discussing how to handle
this issue for weeks on security@kernel.org already.

^ permalink raw reply

* [GIT] Networking
From: David Miller @ 2011-08-07  1:51 UTC (permalink / raw)
  To: torvalds; +Cc: akpm, netdev, linux-kernel


Please pull to get the MD5 sequence number changes.

Thanks!

The following changes since commit de96355c111679dd6e2c5c73e25e814c72510c58:

  Merge branch 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6 (2011-08-05 06:44:38 -1000)

are available in the git repository at:

  master.kernel.org:/pub/scm/linux/kernel/git/davem/net.git master

David S. Miller (2):
      crypto: Move md5_transform to lib/md5.c
      net: Compute protocol sequence numbers and fragment IDs using MD5.

 crypto/md5.c                             |   92 +--------
 drivers/char/random.c                    |  349 +-----------------------------
 include/linux/cryptohash.h               |    5 +
 include/linux/random.h                   |   12 -
 include/net/secure_seq.h                 |   20 ++
 lib/Makefile                             |    2 +-
 lib/md5.c                                |   95 ++++++++
 net/core/Makefile                        |    2 +-
 net/core/secure_seq.c                    |  184 ++++++++++++++++
 net/dccp/ipv4.c                          |    1 +
 net/dccp/ipv6.c                          |    9 +-
 net/ipv4/inet_hashtables.c               |    1 +
 net/ipv4/inetpeer.c                      |    1 +
 net/ipv4/netfilter/nf_nat_proto_common.c |    1 +
 net/ipv4/route.c                         |    1 +
 net/ipv4/tcp_ipv4.c                      |    1 +
 net/ipv6/inet6_hashtables.c              |    1 +
 net/ipv6/tcp_ipv6.c                      |    1 +
 18 files changed, 325 insertions(+), 453 deletions(-)
 create mode 100644 include/net/secure_seq.h
 create mode 100644 lib/md5.c
 create mode 100644 net/core/secure_seq.c

^ permalink raw reply

* Re: include/linux/netlink.h: problem when included by an application
From: Ben Hutchings @ 2011-08-07  1:15 UTC (permalink / raw)
  To: Michel Machado; +Cc: netdev
In-Reply-To: <1312580748.2326.15.camel@Thor>

[-- Attachment #1: Type: text/plain, Size: 1534 bytes --]

On Fri, 2011-08-05 at 17:45 -0400, Michel Machado wrote:
> Hi there,
> 
>    When an application includes header <linux/netlink.h> obtained with
> 'make headers_install' or from /usr/include/, it produces the following
> error:
> 
> /usr/include/linux/netlink.h:31:2: error: expected
> specifier-qualifier-list before ‘sa_family_t’

Yeah, I know.

>    The error doesn't come up in the kernel because
> include/linux/netlink.h has the following line:
> 
> #include <linux/socket.h> /* for sa_family_t */
> 
>    However, <linux/socket.h> from /usr/include/ doesn't have sa_family_t
> because it's protected by an $ifdef __KERNEL__ in
> include/linux/socket.h.

Which is correct, as it would otherwise conflict with <sys/socket.h>.

Previous history:
http://thread.gmane.org/gmane.linux.debian.devel.bugs.general/622621
http://thread.gmane.org/gmane.linux.network/143380

>    A workaround for an application is to include <sys/socket.h> before
> <linux/netlink.h>. However, shouldn't include/linux/netlink.h be fixed?
> 
>    The simplest solution that I came up was replacing sa_family_t in
> include/linux/netlink.h to 'unsigned short' as header
> include/linux/socket.h does for struct __kernel_sockaddr_storage
> available to applications.

Maybe we should do something like this in <linux/socket.h>:

typedef unsigned short __kernel_sa_family_t;
#ifdef __KERNEL__
typedef __kernel_sa_family_t sa_family_t;
#endif

and then use __kernel_sa_family_t in <linux/netlink.h>.

Ben.



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

^ permalink raw reply

* (unknown)
From: Bar Yasser @ 2011-08-06 23:38 UTC (permalink / raw)



I am Bar Yasser, I have a very important Business matters i will like to
discuss with you.If this your Email is valid Contact me through my personal
email:rawashdeh.asseral44@w.cn Thank you Mr. Yasser Al




^ permalink raw reply

* [PATCH] ipv4: Fix ip_getsockopt for IP_PKTOPTIONS
From: Daniel Baluta @ 2011-08-06 23:20 UTC (permalink / raw)
  To: davem, kuznet, pekkas, yoshfuji, kaber
  Cc: netdev, Daniel Baluta, Tiberiu Szocs-Mihai

IP_PKTOPTIONS is broken for 32-bit applications running
in COMPAT mode on 64-bit kernels.

This happens because msghdr's msg_flags field is always
set to zero. When running in COMPAT mode this should be
set to MSG_CMSG_COMPAT instead.

Signed-off-by: Tiberiu Szocs-Mihai <tszocs@ixiacom.com>
Signed-off-by: Daniel Baluta <dbaluta@ixiacom.com>
---
 net/ipv4/ip_sockglue.c |    9 +++++----
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index ab0c9ef..c77f5a8 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -1067,7 +1067,7 @@ EXPORT_SYMBOL(compat_ip_setsockopt);
  */
 
 static int do_ip_getsockopt(struct sock *sk, int level, int optname,
-			    char __user *optval, int __user *optlen)
+			    char __user *optval, int __user *optlen, unsigned flags)
 {
 	struct inet_sock *inet = inet_sk(sk);
 	int val;
@@ -1240,7 +1240,7 @@ static int do_ip_getsockopt(struct sock *sk, int level, int optname,
 
 		msg.msg_control = optval;
 		msg.msg_controllen = len;
-		msg.msg_flags = 0;
+		msg.msg_flags = flags;
 
 		if (inet->cmsg_flags & IP_CMSG_PKTINFO) {
 			struct in_pktinfo info;
@@ -1294,7 +1294,7 @@ int ip_getsockopt(struct sock *sk, int level,
 {
 	int err;
 
-	err = do_ip_getsockopt(sk, level, optname, optval, optlen);
+	err = do_ip_getsockopt(sk, level, optname, optval, optlen, 0);
 #ifdef CONFIG_NETFILTER
 	/* we need to exclude all possible ENOPROTOOPTs except default case */
 	if (err == -ENOPROTOOPT && optname != IP_PKTOPTIONS &&
@@ -1327,7 +1327,8 @@ int compat_ip_getsockopt(struct sock *sk, int level, int optname,
 		return compat_mc_getsockopt(sk, level, optname, optval, optlen,
 			ip_getsockopt);
 
-	err = do_ip_getsockopt(sk, level, optname, optval, optlen);
+	err = do_ip_getsockopt(sk, level, optname, optval, optlen, 
+		MSG_CMSG_COMPAT);
 
 #ifdef CONFIG_NETFILTER
 	/* we need to exclude all possible ENOPROTOOPTs except default case */
-- 
1.7.2.5


^ permalink raw reply related

* [PATCH] net/usb: Add IPv6 support to the LG-VL600 LTE USB modem driver
From: Mark Kamichoff @ 2011-08-06 22:28 UTC (permalink / raw)
  To: gregkh; +Cc: linux-usb, netdev, linux-kernel, Mark Kamichoff

The LG-VL600 LTE USB modem supports IPv6, but uses and expects an IPv4
ethertype (0x800) for these packets instead of the standard 0x86dd.
This patch peeks at the IP version in the L3 header and sets the
ethertype appropriately for IPv6 packets.

Signed-off-by: Mark Kamichoff <prox@prolixium.com>
---
 drivers/net/usb/lg-vl600.c |   19 +++++++++++++++++++
 1 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/drivers/net/usb/lg-vl600.c b/drivers/net/usb/lg-vl600.c
index 1d83ccf..1e72219 100644
--- a/drivers/net/usb/lg-vl600.c
+++ b/drivers/net/usb/lg-vl600.c
@@ -89,6 +89,8 @@ static int vl600_bind(struct usbnet *dev, struct usb_interface *intf)
 	 * addresses have no meaning, the destination and the source of every
 	 * packet depend only on whether it is on the IN or OUT endpoint.  */
 	dev->net->flags |= IFF_NOARP;
+	/* IPv6 NDP relies on multicast.  Enable it by default. */
+	dev->net->flags |= IFF_MULTICAST;
 
 	return ret;
 }
@@ -200,6 +202,14 @@ static int vl600_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
 		} else {
 			memset(ethhdr->h_source, 0, ETH_ALEN);
 			memcpy(ethhdr->h_dest, dev->net->dev_addr, ETH_ALEN);
+
+			/* Inbound IPv6 packets have an IPv4 ethertype (0x800)
+			 * for some reason.  Peek at the L3 header to check
+			 * for IPv6 packets, and set the ethertype to IPv6
+			 * (0x86dd) so Linux can understand it.
+			 */
+			if ((buf->data[sizeof(*ethhdr)] & 0xf0) == 0x60)
+				ethhdr->h_proto = __constant_htons(ETH_P_IPV6);
 		}
 
 		if (count) {
@@ -297,6 +307,15 @@ encapsulate:
 	if (skb->len < full_len) /* Pad */
 		skb_put(skb, full_len - skb->len);
 
+	/* The VL600 wants IPv6 packets to have an IPv4 ethertype
+	 * Check if this is an IPv6 packet, and set the ethertype
+	 * to 0x800
+	 */
+	if ((skb->data[sizeof(struct vl600_pkt_hdr *) + 0x22] & 0xf0) == 0x60) {
+		skb->data[sizeof(struct vl600_pkt_hdr *) + 0x20] = 0x08;
+		skb->data[sizeof(struct vl600_pkt_hdr *) + 0x21] = 0;
+	}
+
 	return skb;
 }
 
-- 
1.7.5.4


^ permalink raw reply related

* [PATCH] compat_ioctl: add compat handler for PPPIOCGL2TPSTATS
From: Florian Westphal @ 2011-08-06 22:12 UTC (permalink / raw)
  To: netdev; +Cc: Florian Westphal, James Chapman, Alexander Viro, linux-fsdevel

fixes following error seen on x86_64 kernel:
ioctl32(openl2tpd:7480): Unknown cmd fd(14) cmd(80487436){t:'t';sz:72} arg(ffa7e6c0) on socket:[105094]

The argument (struct pppol2tp_ioc_stats) uses "aligned_u64" and thus doesn't need
fixups.

Cc: James Chapman <jchapman@katalix.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org
Signed-off-by: Florian Westphal <fw@strlen.de>
---
diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
index 8be086e..51352de 100644
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -1003,6 +1003,7 @@ COMPATIBLE_IOCTL(PPPIOCCONNECT)
 COMPATIBLE_IOCTL(PPPIOCDISCONN)
 COMPATIBLE_IOCTL(PPPIOCATTCHAN)
 COMPATIBLE_IOCTL(PPPIOCGCHAN)
+COMPATIBLE_IOCTL(PPPIOCGL2TPSTATS)
 /* PPPOX */
 COMPATIBLE_IOCTL(PPPOEIOCSFWD)
 COMPATIBLE_IOCTL(PPPOEIOCDFWD)
-- 
1.7.3.4


^ permalink raw reply related

* Re: return of ip_rt_bug()
From: Julian Anastasov @ 2011-08-06 22:14 UTC (permalink / raw)
  To: Tom London; +Cc: Dave Jones, netdev
In-Reply-To: <CAFiZG+VJ27939BT-dTbvSotxO6+ACbxWiYwQBUT9pC_Fw22O-w@mail.gmail.com>


	Hello,

	OK, after a bit of digging here is the problem.
It is evident that ip_rt_bug reports skb->dev = NULL which
is impossible to pass ip_route_input. It means, we got this
input route no matter our skb->dev = NULL. Here is how
that happened.

	For the routing cache compare_keys matches
rt_key_dst, rt_key_src, rt_mark, rt_key_tos, rt_oif, rt_iif

	Consider the following two examples:

1. Received traffic from 0.0.0.0 to 255.255.255.255, one example is DHCP

	ip_route_input_slow caches the things as follows:

	rt_key_dst = 255.255.255.255 (iph->daddr)
	rt_key_src = 0.0.0.0 (iph->saddr)
	rt_mark = 0
	rt_key_tos = 0 (RT TOS from iph->tos)
	rt_oif = 0 (always for input route)
	rt_iif = eth0 (input device)

	not compared by compare_keys:
	rt_route_iif = eth0 (input device)

	use hash chain based on some keys and iif

2. Local traffic from ANY LOCAL IP to 255.255.255.255, our example
	is broadcast for EPSON printer where the socket is not
	bound to source address

	__mkroute_output caches the things as follows:

	rt_key_dst = 255.255.255.255 (orig_daddr)
	rt_key_src = 0.0.0.0 (orig_saddr), because not bound
	rt_mark = 0
	rt_key_tos = 0 (RT TOS from iph->tos)
	rt_oif = 0 (orig_oif), because not bound to output device
	rt_iif = eth0 (orig_oif or dev_out->ifindex), dev_out in our case

	not compared by compare_keys:
	rt_route_iif = 0 (always for output route)

	use hash chain based on some keys and orig_oif

	Now when we put rt_intern_hash in the game, it tries to
reuse existing entries in the cache by using compare_keys.
It is hard to hit the problem because input and output
routes use different hashing based on iif/orig_oif.

	The problem: if we have input route in the cache
it can be returned to callers that request output route.
That is why dst_output points to ip_rt_bug.

	As noted above, compare_keys must consider rt_route_iif.
It must be also considered by ip_route_input_common.

	The appended patch fixes the problem for me. I was
able to reproduce ip_rt_bug by using rhash_entries=1 (resulting
in rt_hash_mask=1) and increasing gc_thresh to 8, so that
I can send these 2 packets with custom programs and the
cache entries to live longer in cache.

===============================================================

[PATCH] ipv4: fix the reusing of routing cache entries

	compare_keys and ip_route_input_common rely on
rt_oif for distinguishing of input and output routes
with same keys values. But sometimes the input route has
also same hash chain (keyed by iif != 0) with the output
routes (keyed by orig_oif=0). Problem visible if running
with small number of rhash_entries.

	Fix them to use rt_route_iif instead. By this way
input route can not be returned to users that request
output route.

	The patch fixes the ip_rt_bug errors that were
reported in ip_local_out context, mostly for 255.255.255.255
destinations.

Signed-off-by: Julian Anastasov <ja@ssi.bg>
---

	This is for 3.0, didn't checked net-next yet.

diff -urp v3.0/linux/net/ipv4/route.c linux/net/ipv4/route.c
--- v3.0/linux/net/ipv4/route.c	2011-07-22 09:43:33.000000000 +0300
+++ linux/net/ipv4/route.c	2011-08-06 18:15:17.841066642 +0300
@@ -725,6 +725,7 @@ static inline int compare_keys(struct rt
 		((__force u32)rt1->rt_key_src ^ (__force u32)rt2->rt_key_src) |
 		(rt1->rt_mark ^ rt2->rt_mark) |
 		(rt1->rt_key_tos ^ rt2->rt_key_tos) |
+		(rt1->rt_route_iif ^ rt2->rt_route_iif) |
 		(rt1->rt_oif ^ rt2->rt_oif) |
 		(rt1->rt_iif ^ rt2->rt_iif)) == 0;
 }
@@ -2281,8 +2282,8 @@ int ip_route_input_common(struct sk_buff
 		if ((((__force u32)rth->rt_key_dst ^ (__force u32)daddr) |
 		     ((__force u32)rth->rt_key_src ^ (__force u32)saddr) |
 		     (rth->rt_iif ^ iif) |
-		     rth->rt_oif |
 		     (rth->rt_key_tos ^ tos)) == 0 &&
+		    rt_is_input_route(rth) &&
 		    rth->rt_mark == skb->mark &&
 		    net_eq(dev_net(rth->dst.dev), net) &&
 		    !rt_is_expired(rth)) {

^ permalink raw reply

* Re: [RFC 4/4] [powerpc] Implement a p1010rdb clock source.
From: Kumar Gala @ 2011-08-06 20:59 UTC (permalink / raw)
  To: Robin Holt
  Cc: Netdev, U Bhaskar-B22300, socketcan-core,
	linuxppc-dev@lists.ozlabs.org Development
In-Reply-To: <20110806205010.GQ4926@sgi.com>


On Aug 6, 2011, at 3:50 PM, Robin Holt wrote:

> On Sat, Aug 06, 2011 at 11:52:45AM -0500, Kumar Gala wrote:
>> 
>> On Aug 6, 2011, at 8:58 AM, Marc Kleine-Budde wrote:
>> 
>>> On 08/06/2011 06:05 AM, Robin Holt wrote:
>>>> flexcan driver needs the clk_get, clk_get_rate, etc functions
>>>> to work.  This patch provides the minimum functionality.
>>> 
>>> This patch has to go via the powerpc git tree. Added
>>> linuxppc-dev@lists.ozlabs.org on CC.
>>> 
>>>> Signed-off-by: Robin Holt <holt@sgi.com>
>>>> To: Marc Kleine-Budde <mkl@pengutronix.de>
>>>> To: Wolfgang Grandegger <wg@grandegger.com>
>>>> To: U Bhaskar-B22300 <B22300@freescale.com>
>>>> Cc: socketcan-core@lists.berlios.de
>>>> Cc: netdev@vger.kernel.org
>>>> ---
>>>> arch/powerpc/platforms/85xx/p1010rdb.c |   78 ++++++++++++++++++++++++++++++++
>>>> 1 files changed, 78 insertions(+), 0 deletions(-)
>> 
>> NAK.
>> 
>> This doesn't look right at all.  We should be doing something based on the device tree node that isn't board specific.
>> 
>> I believe Bhaskar has a version of flexcan support that he's been working on cleanup up for upstream.
> 
> That version may be similar to what is in the freescale BSP which puts
> the clock functions inside flexcan.c
> 
> The powerpc arch already provides a means for individual boards to provide
> the clock functions.  I am not posting this patch here for acceptance
> for powerpc and I am sure I will get feedback there when I post to
> their mailing list.  I am posting it here only to show that the flexcan
> developers earlier assertion that this can and should be done in the arch
> tree is correct and will work for the p1010 assuming we can get changes
> into the arch/powerpc directory to implement these clk_* functions.

My point is that I don't think they should live in the arch code.  The clk_* functions you want to implement are tied more the FlexCAN IP than anything arch specific.  As such I believe they should be in the driver.

For example when FSL has a P9999 with FlexCAN on it, we should NOT have to add any arch code to support it.

- k

^ permalink raw reply

* Re: [RFC 4/4] [powerpc] Implement a p1010rdb clock source.
From: Robin Holt @ 2011-08-06 20:50 UTC (permalink / raw)
  To: Kumar Gala
  Cc: Netdev, U Bhaskar-B22300, socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
	Marc Kleine-Budde,
	linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Development,
	Wolfgang Grandegger
In-Reply-To: <39414D86-7822-4B92-B005-351890A2A167-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>

On Sat, Aug 06, 2011 at 11:52:45AM -0500, Kumar Gala wrote:
> 
> On Aug 6, 2011, at 8:58 AM, Marc Kleine-Budde wrote:
> 
> > On 08/06/2011 06:05 AM, Robin Holt wrote:
> >> flexcan driver needs the clk_get, clk_get_rate, etc functions
> >> to work.  This patch provides the minimum functionality.
> > 
> > This patch has to go via the powerpc git tree. Added
> > linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org on CC.
> > 
> >> Signed-off-by: Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>
> >> To: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> >> To: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
> >> To: U Bhaskar-B22300 <B22300-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> >> Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
> >> Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> >> ---
> >> arch/powerpc/platforms/85xx/p1010rdb.c |   78 ++++++++++++++++++++++++++++++++
> >> 1 files changed, 78 insertions(+), 0 deletions(-)
> 
> NAK.
> 
> This doesn't look right at all.  We should be doing something based on the device tree node that isn't board specific.
> 
> I believe Bhaskar has a version of flexcan support that he's been working on cleanup up for upstream.

That version may be similar to what is in the freescale BSP which puts
the clock functions inside flexcan.c

The powerpc arch already provides a means for individual boards to provide
the clock functions.  I am not posting this patch here for acceptance
for powerpc and I am sure I will get feedback there when I post to
their mailing list.  I am posting it here only to show that the flexcan
developers earlier assertion that this can and should be done in the arch
tree is correct and will work for the p1010 assuming we can get changes
into the arch/powerpc directory to implement these clk_* functions.

Thanks,
Robin

^ permalink raw reply

* [PATCH v3] bonding: document two undocumented options.
From: Nicolas de Pesloüan @ 2011-08-06 17:06 UTC (permalink / raw)
  To: fubar, andy; +Cc: netdev, Nicolas de Pesloüan
In-Reply-To: <3571.1312405193@death>

Commit 655f8919d549ad1872e24d826b6ce42530516d2e
    bonding: add min links parameter to 802.3ad

and commit ebd8e4977a87cb81d93c62a9bff0102a9713722f
    bonding: add all_slaves_active parameter

introduced new options to bonding, but didn't provide the documentation
for those options.

V2: add the default value for both options.
V3: document the exact behavior of min_links default value.

Signed-off-by: Nicolas de Pesloüan <nicolas.2p.debian@free.fr>
---
 Documentation/networking/bonding.txt |   29 +++++++++++++++++++++++++++++
 1 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
index 675612f..dc4ea85 100644
--- a/Documentation/networking/bonding.txt
+++ b/Documentation/networking/bonding.txt
@@ -238,6 +238,18 @@ ad_select
 
 	This option was added in bonding version 3.4.0.
 
+all_slaves_active
+
+	Specifies that duplicate frames (received on inactive ports) should be
+	dropped (0) or delivered (1). 
+
+	Normally, bonding will drop duplicate frames (received on inactive
+	ports), which is desirable for most users. But there are some times
+	it is nice to allow duplicate frames to be delivered.
+
+	The default value is 0 (drop duplicate frames received on inactive
+	ports).
+
 arp_interval
 
 	Specifies the ARP link monitoring frequency in milliseconds.
@@ -433,6 +445,23 @@ miimon
 	determined.  See the High Availability section for additional
 	information.  The default value is 0.
 
+min_links
+
+	Specifies the minimum number of links that must be active before
+	asserting carrier. It is similar to the Cisco EtherChannel min-links
+	feature. This allows setting the minimum number of member ports that
+	must be up (link-up state) before marking the bond device as up
+	(carrier on). This is useful for situations where higher level services
+	such as clustering want to ensure a minimum number of low bandwidth
+	links are active before switchover. This option only affect 802.3ad
+	mode. 
+
+	The default value is 0. This will cause carrier to be asserted (for
+	802.3ad mode) whenever there is an active aggregator, regardless of the
+	number of available links in that aggregator. Note that, because an
+	aggregator cannot be active without at least one available link,
+	setting this option to 0 or to 1 has the exact same effect.
+
 mode
 
 	Specifies one of the bonding policies. The default is
-- 
1.7.5.4


^ permalink raw reply related

* Re: [RFC 4/4] [powerpc] Implement a p1010rdb clock source.
From: Kumar Gala @ 2011-08-06 16:52 UTC (permalink / raw)
  To: Marc Kleine-Budde
  Cc: Robin Holt, Wolfgang Grandegger, U Bhaskar-B22300, socketcan-core,
	Netdev, linuxppc-dev@lists.ozlabs.org Development
In-Reply-To: <4E3D4875.30707@pengutronix.de>


On Aug 6, 2011, at 8:58 AM, Marc Kleine-Budde wrote:

> On 08/06/2011 06:05 AM, Robin Holt wrote:
>> flexcan driver needs the clk_get, clk_get_rate, etc functions
>> to work.  This patch provides the minimum functionality.
> 
> This patch has to go via the powerpc git tree. Added
> linuxppc-dev@lists.ozlabs.org on CC.
> 
>> Signed-off-by: Robin Holt <holt@sgi.com>
>> To: Marc Kleine-Budde <mkl@pengutronix.de>
>> To: Wolfgang Grandegger <wg@grandegger.com>
>> To: U Bhaskar-B22300 <B22300@freescale.com>
>> Cc: socketcan-core@lists.berlios.de
>> Cc: netdev@vger.kernel.org
>> ---
>> arch/powerpc/platforms/85xx/p1010rdb.c |   78 ++++++++++++++++++++++++++++++++
>> 1 files changed, 78 insertions(+), 0 deletions(-)

NAK.

This doesn't look right at all.  We should be doing something based on the device tree node that isn't board specific.

I believe Bhaskar has a version of flexcan support that he's been working on cleanup up for upstream.

- k

^ permalink raw reply

* Re: accelerated vlan gives pcap tagged packets untagged
From: Pierre Ossman @ 2011-08-06 16:00 UTC (permalink / raw)
  To: Malcolm Scott; +Cc: Patrick McHardy, Pierre Ossman, Francois Romieu, netdev
In-Reply-To: <alpine.DEB.2.00.0907241743180.12037@callisto.malc.org.uk>

[-- Attachment #1: Type: text/plain, Size: 1423 bytes --]

Reviving a really old thread.

On Fri, 24 Jul 2009 17:50:26 +0100 (BST)
Malcolm Scott <linux-netdev@malc.org.uk> wrote:

> At 18:35 yesterday, Patrick McHardy wrote:
> 
> > Malcolm Scott wrote:
> >
> >> In my case, this is manifesting as the DHCP misbehaviour which Pierre
> >> mentioned.  (ISC dhcp3d does not use libpcap, and does not query the
> >> packet socket for the VLAN tag, so it treats every VLAN's packets as for
> >> the default VLAN.)
> >
> > It needs to get the VLAN tag from the auxilliary data.
> 
> Right.  But backwards compatibility with older apps is the issue.  An app 
> which doesn't go looking for a VLAN tag in the auxiliary data -- because it 
> didn't have to do so prior to 2.6.28 -- will start seeing packets from all 
> VLANs rather than just the untagged ones.
> 
> Perhaps what's actually needed is another interface which sees _just_ the 
> untagged packets, e.g. eth0.0 (0 being a reserved VLAN ID meaning 'no VLAN', 
> i.e. equivalent to no 802.1q tag).
> 

Has any progress been made on this front? I'm running kernel 2.6.32 and
dhcpd 4.1.1 and that combination is still getting very upset by these
stray packages.

Rgds
-- 
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by FRA, a
  Swedish intelligence agency. Make sure your server uses
  encryption for SMTP traffic and consider using PGP for
  end-to-end encryption.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

^ permalink raw reply

* SCTP patch reviewer
From: Michio Honda @ 2011-08-06 15:34 UTC (permalink / raw)
  To: netdev; +Cc: Vlad Yasevich, David Miller

Hi, 

I posted these patches 2 months ago; Wei Yongjun initially looked at them
but now i am getting bounces his email address is no longer valid. Can anybody
help me please?

Thanks,
- Michio

Begin forwarded message:

> From: Michio Honda <micchie@sfc.wide.ad.jp>
> Date: June 16, 2011 5:56:29 PM GMT+09:00
> To: David Miller <davem@davemloft.net>, Wei Yongjun <yjwei@cn.fujitsu.com>
> Cc: netdev@vger.kernel.org
> Subject: [PATCH 0/2] sctp: patches for HEARTBEAT bug fix and improvement
> 
> From 111463f295a5ea7ae03c26bf62671895e803bc28 Mon Sep 17 00:00:00 2001
> From: Michio Honda <micchie@sfc.wide.ad.jp>
> Date: Thu, 16 Jun 2011 17:40:04 +0900
> Subject: [PATCH 0/2]  sctp: patches for HEARTBEAT bug fix and improvement
> 
> Series of 2 patches for bug fix and improvement around HEARTBEAT after the 
> ASCONF event
> 
> Michio Honda (2):
>  sctp: HEARTBEAT negotiation after ASCONF
>  sctp: Bundle HEAERTBEAT into ASCONF_ACK
> 
> include/net/sctp/structs.h |    1 +
> net/sctp/associola.c       |    1 +
> net/sctp/outqueue.c        |    4 ++++
> net/sctp/sm_make_chunk.c   |    1 +
> net/sctp/sm_statefuns.c    |    5 +++++
> 5 files changed, 12 insertions(+), 0 deletions(-)
> 
> -- 
> 1.7.3.2
> 
> 
Begin forwarded message:

> From: Michio Honda <micchie@sfc.wide.ad.jp>
> Date: June 16, 2011 5:56:42 PM GMT+09:00
> To: David Miller <davem@davemloft.net>, Wei Yongjun <yjwei@cn.fujitsu.com>
> Cc: netdev@vger.kernel.org
> Subject: [PATCH 1/2] sctp: HEARTBEAT negotiation after ASCONF
> 
> From 6780e27850126dc200a8700a0f8c3105971b8978 Mon Sep 17 00:00:00 2001
> From: Michio Honda <micchie@sfc.wide.ad.jp>
> Date: Thu, 16 Jun 2011 10:54:23 +0900
> Subject: [PATCH 1/2] sctp: HEARTBEAT negotiation after ASCONF
> 
> This patch fixes BUG that the ASCONF receiver transmits DATA chunks
> to the newly added UNCONFIRMED destination.
> 
> Signed-off-by: Michio Honda <micchie@sfc.wide.ad.jp>
> ---
> net/sctp/outqueue.c |    4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
> index edc7532..4adfc1e 100644
> --- a/net/sctp/outqueue.c
> +++ b/net/sctp/outqueue.c
> @@ -917,6 +917,8 @@ static int sctp_outq_flush(struct sctp_outq *q, int rtx_timeout)
> 		 * current cwnd).
> 		 */
> 		if (!list_empty(&q->retransmit)) {
> +			if (asoc->peer.retran_path->state == SCTP_UNCONFIRMED) 
> +				goto sctp_flush_out;
> 			if (transport == asoc->peer.retran_path)
> 				goto retran;
> 
> @@ -989,6 +991,8 @@ static int sctp_outq_flush(struct sctp_outq *q, int rtx_timeout)
> 			    ((new_transport->state == SCTP_INACTIVE) ||
> 			     (new_transport->state == SCTP_UNCONFIRMED)))
> 				new_transport = asoc->peer.active_path;
> +			if (new_transport->state == SCTP_UNCONFIRMED) 
> +				continue;
> 
> 			/* Change packets if necessary.  */
> 			if (new_transport != transport) {
> -- 
> 1.7.3.2
> 
> 
Begin forwarded message:

> From: Michio Honda <micchie@sfc.wide.ad.jp>
> Date: June 16, 2011 5:56:52 PM GMT+09:00
> To: David Miller <davem@davemloft.net>, Wei Yongjun <yjwei@cn.fujitsu.com>
> Cc: netdev@vger.kernel.org
> Subject: [PATCH 2/2] sctp: Bundle HEAERTBEAT into ASCONF_ACK
> 
> From 111463f295a5ea7ae03c26bf62671895e803bc28 Mon Sep 17 00:00:00 2001
> From: Michio Honda <micchie@sfc.wide.ad.jp>
> Date: Thu, 16 Jun 2011 17:14:34 +0900
> Subject: [PATCH 2/2] sctp: Bundle HEAERTBEAT into ASCONF_ACK
> 
> With this patch a HEARTBEAT chunk is bundled into the ASCONF-ACK
> for ADD IP ADDRESS, confirming the new destination as quickly as
> possible.
> 
> Signed-off-by: Michio Honda <micchie@sfc.wide.ad.jp>
> ---
> include/net/sctp/structs.h |    1 +
> net/sctp/associola.c       |    1 +
> net/sctp/sm_make_chunk.c   |    1 +
> net/sctp/sm_statefuns.c    |    5 +++++
> 4 files changed, 8 insertions(+), 0 deletions(-)
> 
> diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
> index 31d7ea2..7154980 100644
> --- a/include/net/sctp/structs.h
> +++ b/include/net/sctp/structs.h
> @@ -1915,6 +1915,7 @@ struct sctp_association {
> 	__u32 addip_serial;
> 	union sctp_addr *asconf_addr_del_pending;
> 	int src_out_of_asoc_ok;
> +	struct sctp_transport *new_transport;
> 
> 	/* SCTP AUTH: list of the endpoint shared keys.  These
> 	 * keys are provided out of band by the user applicaton
> diff --git a/net/sctp/associola.c b/net/sctp/associola.c
> index dc16b90..152b5b3 100644
> --- a/net/sctp/associola.c
> +++ b/net/sctp/associola.c
> @@ -282,6 +282,7 @@ static struct sctp_association *sctp_association_init(struct sctp_association *a
> 		asoc->peer.asconf_capable = 1;
> 	asoc->asconf_addr_del_pending = NULL;
> 	asoc->src_out_of_asoc_ok = 0;
> +	asoc->new_transport = NULL;
> 
> 	/* Create an input queue.  */
> 	sctp_inq_init(&asoc->base.inqueue);
> diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
> index 3363d37..a42d3b0 100644
> --- a/net/sctp/sm_make_chunk.c
> +++ b/net/sctp/sm_make_chunk.c
> @@ -3016,6 +3016,7 @@ static __be16 sctp_process_asconf_param(struct sctp_association *asoc,
> 		/* Start the heartbeat timer. */
> 		if (!mod_timer(&peer->hb_timer, sctp_transport_timeout(peer)))
> 			sctp_transport_hold(peer);
> +		asoc->new_transport = peer;
> 		break;
> 	case SCTP_PARAM_DEL_IP:
> 		/* ADDIP 4.3 D7) If a request is received to delete the
> diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
> index a297283..5cfd6d2 100644
> --- a/net/sctp/sm_statefuns.c
> +++ b/net/sctp/sm_statefuns.c
> @@ -3612,6 +3612,11 @@ sctp_disposition_t sctp_sf_do_asconf(const struct sctp_endpoint *ep,
> 	 */
> 	asconf_ack->dest = chunk->source;
> 	sctp_add_cmd_sf(commands, SCTP_CMD_REPLY, SCTP_CHUNK(asconf_ack));
> +	if (asoc->new_transport) {
> +	        sctp_sf_heartbeat(ep, asoc, type, asoc->new_transport,
> +                    commands);
> +		((struct sctp_association *)asoc)->new_transport = NULL;
> +	}
> 
> 	return SCTP_DISPOSITION_CONSUME;
> }
> -- 
> 1.7.3.2
> 
> 


^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox