Daniel Lee [Mon, 6 Apr 2015 21:37:27 +0000 (14:37 -0700)]
tcp: RFC7413 option support for Fast Open client
Fast Open has been using an experimental option with a magic number
(RFC6994). This patch makes the client by default use the RFC7413
option (34) to get and send Fast Open cookies. This patch makes
the client solicit cookies from a given server first with the
RFC7413 option. If that fails to elicit a cookie, then it tries
the RFC6994 experimental option. If that also fails, it uses the
RFC7413 option on all subsequent connect attempts. If the server
returns a Fast Open cookie then the client caches the form of the
option that successfully elicited a cookie, and uses that form on
later connects when it presents that cookie.
The idea is to gradually obsolete the use of experimental options as
the servers and clients upgrade, while keeping the interoperability
meanwhile.
Daniel Lee [Mon, 6 Apr 2015 21:37:26 +0000 (14:37 -0700)]
tcp: RFC7413 option support for Fast Open server
Fast Open has been using the experimental option with a magic number
(RFC6994) to request and grant Fast Open cookies. This patch enables
the server to support the official IANA option 34 in RFC7413 in
addition.
The change has passed all existing Fast Open tests with both
old and new options at Google.
Johan Hedberg [Tue, 7 Apr 2015 18:52:22 +0000 (21:52 +0300)]
Bluetooth: Add local SSP OOB data to OOB ext data mgmt command
The Read Local Out Of Band Extended Data mgmt command is specified to
return the SSP values when given a BR/EDR address type as input
parameter. The returned values may include either the 192-bit variants
of C and R, or their 256-bit variants, or both, depending on the status
of Secure Connections and Secure Connections Only modes. If SSP is not
enabled the command will only return the Class of Device value (like it
has done so far).
Nicolas Dichtel [Tue, 7 Apr 2015 10:10:16 +0000 (12:10 +0200)]
netdevice.h: remove iflink description
Also move 'group' description to match the order of the net_device structure.
Fixes: 7a66bbc96ce9 ("net: remove iflink field from struct net_device") Reported-by: Fengguang Wu <[email protected]> Signed-off-by: Nicolas Dichtel <[email protected]> Signed-off-by: David S. Miller <[email protected]>
David S. Miller [Tue, 7 Apr 2015 21:29:47 +0000 (17:29 -0400)]
Merge branch 'netns-next'
Nicolas Dichtel says:
====================
netns: enhance netlink interface for nsid
The first patch is a small cleanup. The second patch implements notifications
for netns id events. And the last one allows to dump existing netns id from
userland.
iproute2 patches are available, I can send them on demand.
v2: drop the first patch (the fix is now in net-next)
====================
Johan Hedberg [Tue, 7 Apr 2015 18:52:21 +0000 (21:52 +0300)]
Bluetooth: Update SSP OOB data EIR definitions
Since Bluetooth 4.1 there are two additional values for SSP OOB data,
namely C-256 and R-256. This patch updates the EIR definitions to take
into account both the 192 and 256 bit variants of C and R.
David S. Miller [Tue, 7 Apr 2015 19:29:30 +0000 (15:29 -0400)]
Merge branch 'udp_tunnel_sk'
Prevent UDP tunnels from operating on garbage socket
So this should do the rest of the work such that when we encapsulate
into a UDP tunnel, the output path works on the UDP tunnel's socket
rather than skb->sk.
Part of this work is based upon changes done by Jiri Pirko some time
ago.
Basically the first step is to pass the socket through the nf_hook
okfn(), and then next we do the same for the UDP tunnel xmit routines.
David Miller [Mon, 6 Apr 2015 02:19:04 +0000 (22:19 -0400)]
netfilter: Pass socket pointer down through okfn().
On the output paths in particular, we have to sometimes deal with two
socket contexts. First, and usually skb->sk, is the local socket that
generated the frame.
And second, is potentially the socket used to control a tunneling
socket, such as one the encapsulates using UDP.
We do not want to disassociate skb->sk when encapsulating in order
to fix this, because that would break socket memory accounting.
The most extreme case where this can cause huge problems is an
AF_PACKET socket transmitting over a vxlan device. We hit code
paths doing checks that assume they are dealing with an ipv4
socket, but are actually operating upon the AF_PACKET one.
David Miller [Mon, 6 Apr 2015 02:19:00 +0000 (22:19 -0400)]
netfilter: Add socket pointer to nf_hook_state.
It is currently always set to NULL, but nf_queue is adjusted to be
prepared for it being set to a real socket by taking and releasing a
reference to that socket when necessary.
Miaoqing Pan [Wed, 1 Apr 2015 02:19:57 +0000 (10:19 +0800)]
ath9k: add extra GPIO led support
ar9550 or later chips, the AR_GPIO_IN_OUT register only can
control GPIO[0:3]. For the extra GPIO, use standard GPIO calls
instead of WMAC internal registers.
Taehee Yoo [Fri, 27 Mar 2015 15:22:39 +0000 (00:22 +0900)]
rtlwifi: Add encryption argument in rtl_is_special_data for checking DHCP packet.
rtl8192cu can't connect to AP after physical reconnect.
according to dmesg, that problem's cause was DHCP timeout.
rtl_is_special_data function checks packet type for adjusting rate.
when that function is called from _rtl_rc_get_highest_rix, it can not
calculate offset correctly. so i add argument is_encn in rtl_is_special_data.
is_enc variable mean that iv header is added in skb parameter.
i test only rtl8192cu chipset. because i doesn't have other rtlwifi chipsets.
Bluetooth: hci_uart: Use generic Intel support for address setting
The Bluetooth address setting for Intel devices is provided by a generic
module now. Start using that module instead of relying it being included
in the driver.
Bluetooth: btusb: Use generic Intel support for address support
The Bluetooth address handling for Intel devices is provided by a generic
module now. Start using that module instead of relying it being included
in the driver.
Bluetooth: btintel: Introduce generic Intel Bluetooth support
The majority of Intel Bluetooth vendor commands are shared between USB
and UART transports. This creates a separate module that eventually
will hold all Intel specific commands, but for now just start with the
commands to change the Bluetooth public address and check for the
default address.
Bluetooth: hci_uart: Provide generic H:4 receive framework
Future H:4 based UART drivers require custom packet types and custom
receive functions. To support this, extended the h4_recv_buf function
with a packet definition table.
For the default H:4 packets types of ACL data, SCO data and events,
provide helpers to reduce the amount of code duplication.
Bluetooth: hci_uart: Add protocol support for Broadcom UART devices
This adds the protocol support for Broadcom based UART devices to
enable firmware and patchram download procedure. It is a pretty
straight forward H:4 driver with the exception of actually having
its own setup and address configuration callbacks.
Bluetooth: btusb: Update version number of the module
The version number is cosmetic, but pretty handy for debugging purposes
and since the Broadcom protocol support is now optional, just increase
it to indicate the difference.
Bluetooth: hci_uart: Use generic functionality from Broadcom module
The new Broadcom Bluetooth support module provides generic functionality
for changing and checking the Bluetooth device address. Use these new
features instead of keeping a duplicate in the driver.
Bluetooth: btusb: Use generic functionality by Broadcom module
The new Broadcom Bluetooth support module provides generic functionality
for changing and checking the Bluetooth device address. Use these new
features instead of keeping a duplicate in the driver.
Bluetooth: btbcm: Introduce generic Broadcom Bluetooth support
The majority of Broadcom Bluetooth vendor commands are shared between
USB and UART transports. This creates a separate module that eventually
will hold all Broadcom specific commands, but for now just start with
the commands to change the Bluetooth public address and check for the
default address.
Bluetooth: hci_uart: Remove the manual protocol init message
The init function for each HCI UART protocol prints the same on success
and failure. This information is so generic, remove it and let the main
HCI UART handling print it instead.
Bluetooth: Remove hci_recv_stream_fragment function
The hci_recv_stream_fragment function should have never been introduced
in the first place. The Bluetooth core does not need to know anything
about the HCI transport protocol.
With all transport protocol specific detailed moved back into the
drivers where they belong (mainly generic USB and UART drivers), this
function can now be removed.
This reduces the size of hci_dev structure and also removes an exported
symbol from the Bluetooth core module.
Bluetooth: hci_uart: Introduce h4_recv_buf helper function
The h4_recv_buf helper function can be used for receiving H:4 packets
out of a TTY stream. It is self-contained and allows for reuse by all
HCI UART protocols.
Bluetooth: hci_uart: Use const data pointer for received data
The TTY layer provides its data pointers as const, but the HCI UART
callbacks expect them as general data pointers. This is of course
wrong and instead of casting them, just fix the individual drivers
to actually take a const data pointer.
Bluetooth: Make data pointer of hci_recv_stream_fragment const
The data pointer provided to hci_recv_stream_fragment function should
have been marked const. The function has no business in modifying the
original data. So fix this now.
Bluetooth: hci_uart: Remove unused h4->rx_skb field
The h4->rx_skb is not used anymore and with that just remove it. Seems
this was a leftover and even the kfree_skb call freeing it is rather
pointless since it got never allocated.
Bluetooth: hci_uart: Add support for vendor detection flag
This adds a new HCI_UART_VND_DETECT flag to allow automatic vendor
detection. This allows to enable known vendor commands (for example
for setting the public device address) when using a standard H:4
UART protocol or when running in virtual machines.
When this new flag is configured and no vendor specific setup
routine is provided, then the local version information are read
and the provided manufacturer information can be evaluated to
configure extra vendor callbacks.
Here's what's probably the last bluetooth-next pull request for 4.1:
- Fixes for LE advertising data & advertising parameters
- Fix for race condition with HCI_RESET flag
- New BNEPGETSUPPFEAT ioctl, needed for certification
- New HCI request callback type to get the resulting skb
- Cleanups to use BIT() macro wherever possible
- Consolidate Broadcom device entries in the btusb HCI driver
- Check for valid flags in CMTP, HIDP & BNEP
- Disallow local privacy & OOB data combo to prevent a potential race
- Expose SMP & ECDH selftest results through debugfs
- Expose current Device ID info through debugfs
Please let me know if there are any issues pulling. Thanks.
====================
Johannes Berg [Tue, 31 Mar 2015 14:09:13 +0000 (16:09 +0200)]
cfg80211: send extended capabilities IE in connect
If the connect request from userspace didn't include an extended
capabilities IE, create one using the driver capabilities. This
fixes VHT associations, since those need to set the operating mode
notification capability.
1) In TCP, don't register an FRTO for cumulatively ACK'd data that was
previously SACK'd, from Neal Cardwell.
2) Need to hold RNL mutex in ipv4 multicast code namespace cleanup,
from Cong WANG.
3) Similarly we have to hold RNL mutex for fib_rules_unregister(), also
from Cong WANG.
4) Revert and rework netns nsid allocation fix, from Nicolas Dichtel.
5) When we encapsulate for a tunnel device, skb->sk still points to the
user socket. So this leads to cases where we retraverse the
ipv4/ipv6 output path with skb->sk being of some other address
family (f.e. AF_PACKET). This can cause things to crash since the
ipv4 output path is dereferencing an AF_PACKET socket as if it were
an ipv4 one.
The short term fix for 'net' and -stable is to elide these socket
checks once we've entered an encapsulation sequence by testing
xmit_recursion.
Longer term we have a better solution wherein we pass the tunnel's
socket down through the output paths, but that is way too invasive
for 'net' and -stable.
From Hannes Frederic Sowa.
6) l2tp_init() failure path forgets to unregister per-net ops, from
Cong WANG.
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
net/mlx4_core: Fix error message deprecation for ConnectX-2 cards
net: dsa: fix filling routing table from OF description
l2tp: unregister l2tp_net_ops on failure path
mvneta: dont call mvneta_adjust_link() manually
ipv6: protect skb->sk accesses from recursive dereference inside the stack
netns: don't allocate an id for dead netns
Revert "netns: don't clear nsid too early on removal"
ip6mr: call del_timer_sync() in ip6mr_free_table()
net: move fib_rules_unregister() under rtnl lock
ipv4: take rtnl_lock and mark mrt table as freed on namespace cleanup
tcp: fix FRTO undo on cumulative ACK of SACKed range
xen-netfront: transmit fully GSO-sized packets
net/mlx4_core: Fix error message deprecation for ConnectX-2 cards
Commit 1daa4303b4ca ("net/mlx4_core: Deprecate error message at
ConnectX-2 cards startup to debug") did the deprecation only for port 1
of the card. Need to deprecate for port 2 as well.
Fixes: 1daa4303b4ca ("net/mlx4_core: Deprecate error message at ConnectX-2 cards startup to debug") Signed-off-by: Jack Morgenstein <[email protected]> Signed-off-by: Amir Vadai <[email protected]> Signed-off-by: David S. Miller <[email protected]>
net: dsa: fix filling routing table from OF description
According to description in 'include/net/dsa.h', in cascade switches
configurations where there are more than one interconnected devices,
'rtable' array in 'dsa_chip_data' structure is used to indicate which
port on this switch should be used to send packets to that are destined
for corresponding switch.
However, dsa_of_setup_routing_table() fills 'rtable' with port numbers
of the _target_ switch, but not current one.
This commit removes redundant devicetree parsing and adds needed port
number as a function argument. So dsa_of_setup_routing_table() now just
looks for target switch number by parsing parent of 'link' device node.
To remove possible misunderstandings with the way of determining target
switch number, a corresponding comment was added to the source code and
to the DSA device tree bindings documentation file.
This was tested on a custom board with two Marvell 88E6095 switches with
following corresponding routing tables: { -1, 10 } and { 8, -1 }.
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
Pull input fixes from Dmitry Torokhov:
"Updates for the input subsystem - two more tweaks for ALPS driver to
work out kinks after splitting the touchpad, trackstick, and potential
external PS/2 mouse into separate input devices.
Changes to support ALPS SS4 devices (protocol V8) will be coming in
4.1..."
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Input: alps - document stick behavior for protocol V2
Input: alps - report V2 Dualpoint Stick events via the right evdev node
Input: alps - report interleaved bare PS/2 packets via dev3
Commit 608cd71a9c7c ("tc: bpf: generalize pedit action") has added the
possibility to mangle packet data to BPF programs in the tc pipeline.
This patch adds two helpers bpf_l3_csum_replace() and bpf_l4_csum_replace()
for fixing up the protocol checksums after the packet mangling.
It also adds 'flags' argument to bpf_skb_store_bytes() helper to avoid
unnecessary checksum recomputations when BPF programs adjusting l3/l4
checksums and documents all three helpers in uapi header.
Moreover, a sample program is added to show how BPF programs can make use
of the mangle and csum helpers.
ipv6: protect skb->sk accesses from recursive dereference inside the stack
We should not consult skb->sk for output decisions in xmit recursion
levels > 0 in the stack. Otherwise local socket settings could influence
the result of e.g. tunnel encapsulation process.
ipv6 does not conform with this in three places:
1) ip6_fragment: we do consult ipv6_npinfo for frag_size
2) sk_mc_loop in ipv6 uses skb->sk and checks if we should
loop the packet back to the local socket
3) ip6_skb_dst_mtu could query the settings from the user socket and
force a wrong MTU
Furthermore:
In sk_mc_loop we could potentially land in WARN_ON(1) if we use a
PF_PACKET socket ontop of an IPv6-backed vxlan device.
Reuse xmit_recursion as we are currently only interested in protecting
tunnel devices.
NFC: st21nfca: fix st21nfca_get_iso14443_3_uid data copy
st21nfca_get_iso14443_3_uid() does not correctly copy the uid from
uid_skb->data to its gate parameter. "gate = uid_skb->data;" only
puts a pointer to uid_skb->data to the local variable gate.
This means that in st21nfca_hci_target_from_gate() the content
of "u8 uid[NFC_NFCID1_MAXSIZE]" local variable is never initialized
before being used in memcpy(target->nfcid1, uid, len).
Fix this by replacing the local variable assignment with a memcpy.
This was found by compiling Linux with
"gcc -Wunused-but-set-parameter".
NFC: st21nfcb: Retry i2c_master_send if it returns a negative value
i2c_master_send may return many negative values different than
-EREMOTEIO.
In case an i2c transaction is NACK'ed, on raspberry pi B+
kernel 3.18, -EIO is generated instead.
Hans de Goede [Sat, 4 Apr 2015 00:20:05 +0000 (17:20 -0700)]
Input: alps - report V2 Dualpoint Stick events via the right evdev node
On V2 devices the DualPoint Stick reports bare packets, these should be
reported via the "AlpsPS/2 ALPS DualPoint Stick" dev2 evdev node, which also
has the INPUT_PROP_POINTING_STICK propbit set.
Note that since there is no way to distinguish these packets from an external
PS/2 mouse (insofar as these laptops have an external PS/2 port) this means
that we will be reporting PS/2 mouse events via this evdev node too, as we've
been doing in kernel 3.19 and older.
This has been tested on a Dell Latitude D620 and a Dell Latitude E6400,
which both have a V2 touchpad + a DualPoint Stick which reports bare packets.
Hans de Goede [Sat, 4 Apr 2015 00:14:40 +0000 (17:14 -0700)]
Input: alps - report interleaved bare PS/2 packets via dev3
Bare packets should be reported via the same evdev device independent on
whether they are detected on the beginning of a packet or in the middle
of a packet.
This has been tested on a Dell Latitude E6400, where the DualPoint Stick
reports bare packets, which get reported via dev3 when the touchpad is
idle, and via dev2 when the touchpad and stick are used simultaneously.
This commit fixes this inconsistency by always reporting bare packets via
dev3. Note that since the come from a DualPoint Stick they really should be
reported via dev2, this gets fixed in a later commit.
Merge tag 'usb-4.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB fixes from Greg KH:
"Here are some small USB fixes and new device ids for 4.0-rc6. Nothing
major, some xhci fixes for reported problems, and some usb-serial
device ids.
All have been in linux-next for a while"
* tag 'usb-4.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
USB: ftdi_sio: Use jtag quirk for SNAP Connect E10
usb: isp1760: fix spin unlock in the error path of isp1760_udc_start
usb: xhci: apply XHCI_AVOID_BEI quirk to all Intel xHCI controllers
usb: xhci: handle Config Error Change (CEC) in xhci driver
USB: keyspan_pda: add new device id
USB: ftdi_sio: Added custom PID for Synapse Wireless product
David S. Miller [Sat, 4 Apr 2015 19:23:15 +0000 (15:23 -0400)]
Merge branch 'nf-hook-compress'
netfilter: Compress hook function signatures.
Currently netfilter hooks have a function signature that is huge and
has many arguments. This propagates from the hook entry points down
into the individual hook implementations themselves.
This means that if, for example, we want to change the type of one of
these arguments then we have to touch hundreds of locations.
The main initial motivation behind this is that we'd like to change
the signature of "okfn" so that a socket pointer can be passed in (and
reference counted properly) for the sake of using the proper socket
context in the case of tunnels whilst not releasing the top level user
socket from skb->sk (and thus releasing it's socket memory quota
usage) in order to accomodate this.
This also makes it clear who actually uses 'okfn', nf_queue(). It is
absolutely critical to make this obvious because any user of 'okfn'
down in these hook chains have the be strictly audited for
escapability. Specifically, escapability of references to objects
outside of the packet processing path. And that's exactly what
nf_queue() does via it's packet reinjection framework.
In fact this points out a bug in Jiri's original attempt to push the
socket pointer down through netfilter's okfn. It didn't grab and drop
a reference to the socket in net/netfilter/nf_queue.c as needed.
Furthermore, so many code paths are simplified, and should in fact be
more efficient because we aren't passing in arguments that often are
simply not used by the netfilter hook at all.
Further simplifications are probably possible, but this series takes
care of the main cases.
Unfortunately I couldn't convert ebt_do_table() because ebtables is
complete and utter crap and uses ebt_do_table() outside of the hook
call chains. But that should not be news to anyone.
Merge tag 'staging-4.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
Pull staging driver fixes from Greg KH:
"Here are some staging driver fixes, well, really all just IIO driver
fixes, for 4.0-rc6. They fix issues that have been reported with
these drivers.
All of these patches have been in linux-next for a while"
* tag 'staging-4.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
iio: imu: Use iio_trigger_get for indio_dev->trig assignment
iio: adc: vf610: use ADC clock within specification
iio/adc/cc10001_adc.c: Fix !HAS_IOMEM build
iio: core: Fix double free.
iio:inv-mpu6050: Fix inconsistency for the scale channel
staging: iio: dummy: Fix undefined symbol build error
iio: inv_mpu6050: Clear timestamps fifo while resetting hardware fifo
staging: iio: hmc5843: Set iio name property in sysfs
iio: bmc150: change sampling frequency
iio: fix drivers that check buffer->scan_mask
Merge tag 'tty-4.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
Pull tty/serial fixes from Greg KH:
"Here are 3 serial driver fixes for 4.0-rc6. They fix some reported
issues with the samsung and fsl_lpuart drivers.
All have been in linux-next for a while"
* tag 'tty-4.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
tty: serial: fsl_lpuart: clear receive flag on FIFO flush
tty: serial: fsl_lpuart: specify transmit FIFO size
serial: samsung: Clear operation mode on UART shutdown
projects / linux.git / log