linux-toradex.git/net/bluetooth/bnep, branch v4.10

net: remove MTU limits on a few ether_setup callers

2016-10-21T17:57:50+00:00

These few drivers call ether_setup(), but have no ndo_change_mtu, and thus
were overlooked for changes to MTU range checking behavior. They
previously had no range checks, so for feature-parity, set their min_mtu
to 0 and max_mtu to ETH_MAX_MTU (65535), instead of the 68 and 1500
inherited from the ether_setup() changes. Fine-tuning can come after we get
back to full feature-parity here.

CC: netdev@vger.kernel.org
Reported-by: Asbjoern Sloth Toennesen 
CC: Asbjoern Sloth Toennesen 
CC: R Parameswaran 
Signed-off-by: Jarod Wilson 
Signed-off-by: David S. Miller

net: deprecate eth_change_mtu, remove usage

2016-10-13T13:36:57+00:00

With centralized MTU checking, there's nothing productive done by
eth_change_mtu that isn't already done in dev_set_mtu, so mark it as
deprecated and remove all usage of it in the kernel. All callers have been
audited for calls to alloc_etherdev* or ether_setup directly, which means
they all have a valid dev->min_mtu and dev->max_mtu. Now eth_change_mtu
prints out a netdev_warn about being deprecated, for the benefit of
out-of-tree drivers that might be utilizing it.

Of note, dvb_net.c actually had dev->mtu = 4096, while using
eth_change_mtu, meaning that if you ever tried changing it's mtu, you
couldn't set it above 1500 anymore. It's now getting dev->max_mtu also set
to 4096 to remedy that.

v2: fix up lantiq_etop, missed breakage due to drive not compiling on x86

CC: netdev@vger.kernel.org
Signed-off-by: Jarod Wilson 
Signed-off-by: David S. Miller

treewide: replace dev->trans_start update with helper

2016-05-04T18:16:49+00:00

Replace all trans_start updates with netif_trans_update helper.
change was done via spatch:

struct net_device *d;
@@
- d->trans_start = jiffies
+ netif_trans_update(d)

Compile tested only.

Cc: user-mode-linux-devel@lists.sourceforge.net
Cc: linux-xtensa@linux-xtensa.org
Cc: linux1394-devel@lists.sourceforge.net
Cc: linux-rdma@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: MPT-FusionLinux.pdl@broadcom.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-can@vger.kernel.org
Cc: linux-parisc@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Cc: linux-hams@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Cc: linux-wireless@vger.kernel.org
Cc: linux-s390@vger.kernel.org
Cc: devel@driverdev.osuosl.org
Cc: b.a.t.m.a.n@lists.open-mesh.org
Cc: linux-bluetooth@vger.kernel.org
Signed-off-by: Florian Westphal 
Acked-by: Felipe Balbi 
Acked-by: Mugunthan V N 
Acked-by: Antonio Quartulli 
Signed-off-by: David S. Miller

Bluetooth: Do not filter multicast addresses by default

2015-12-11T09:46:16+00:00

A Linux PC is connected with another device over Bluetooth PAN using a
BNEP interface.

Whenever a packet is tried to be sent over the BNEP interface, the
function "bnep_net_xmit()" in "net/bluetooth/bnep/netdev.c" is called.
This function calls "bnep_net_mc_filter()", which checks (if the
destination address is multicast) if the address is set in a certain
multicast filter (&s->mc_filter). If it is not, then it is not sent out.

This filter is only changed in two other functions, found in
net/bluetooth/bnep/core.c": in "bnep_ctrl_set_mc_filter()", which is
only called if a message of type "BNEP_FILTER_MULTI_ADDR_SET" is
received. Otherwise, it is set in "bnep_add_connection()", where it is
set to a default value which only adds the broadcast address to the
filter:

set_bit(bnep_mc_hash(dev->broadcast), (ulong *) &s->mc_filter);

To sum up, if the BNEP interface does not receive any message of type
"BNEP_FILTER_MULTI_ADDR_SET", it will not send out any messages with
multicast destination addresses except for broadcast.

However, in the BNEP specification (page 27 in
http://grouper.ieee.org/groups/802/15/Bluetooth/BNEP.pdf), it is said
that per default, all multicast addresses should not be filtered, i.e.
the BNEP interface should be able to send packets with any multicast
destination address.

It seems that the default case is wrong: the multicast filter should not
block almost all multicast addresses, but should not filter out any.

This leads to the problem that e.g. Neighbor Solicitation messages sent
with Bluetooth PAN over the BNEP interface to a multicast destination
address other than broadcast are blocked and not sent out.

Therefore, in the default case, we set the mc_filter to ~0LL to not
filter out any multicast addresses.

Signed-off-by: Danny Schweizer 
Signed-off-by: Marcel Holtmann

net: Pass kern from net_proto_family.create to sk_alloc

2015-05-11T14:50:17+00:00

In preparation for changing how struct net is refcounted
on kernel sockets pass the knowledge that we are creating
a kernel socket from sock_create_kern through to sk_alloc.

Signed-off-by: "Eric W. Biederman" 
Signed-off-by: David S. Miller

Bluetooth: bnep: Handle BNEP connection setup request

2015-04-03T21:21:34+00:00

With this patch kernel will be able to handle setup request. This is
needed if we would like to handle control mesages with extension
headers. User space will be only resposible for reading setup data and
checking if scenario is conformance to specification (dst and src device
bnep role). In case of new user space, setup data must be leaved(peek
msg) on queue. New bnep session will be responsible for handling this
data.

Signed-off-by: Grzegorz Kolodziejczyk 
Signed-off-by: Marcel Holtmann

Bluetooth: bnep: Add support to extended headers of control frames

2015-04-03T21:21:34+00:00

Handling extended headers of control frames is required BNEP
functionality. This patch refractor bnep rx frame handling function.
Extended header for control frames shouldn't be omitted as it was
previously done. Every control frame should be checked if it contains
extended header and then every extension should be parsed separately.

Signed-off-by: Grzegorz Kolodziejczyk 
Signed-off-by: Marcel Holtmann

Bluetooth: bnep: Add support for get bnep features via ioctl

2015-04-03T21:21:34+00:00

This is needed if user space wants to know supported bnep features
by kernel, e.g. if kernel supports sending response to bnep setup
control message. By now there is no possibility to know supported
features by kernel in case of bnep. Ioctls allows only to add connection,
delete connection, get connection list, get connection info. Adding
connection if it's possible (establishing network device connection) is
equivalent to starting bnep session. Bnep session handles data queue of
transmit, receive messages over bnep channel. It means that if we add
connection the received/transmitted data will be parsed immediately. In
case of get bnep features we want to know before session start, if we
should leave setup data on socket queue and let kernel to handle with it,
or in case of no setup handling support, if we should pull this message
and handle setup response within user space.

Signed-off-by: Grzegorz Kolodziejczyk 
Signed-off-by: Marcel Holtmann

Bluetooth: bnep: Return err value while sending cmd is not understood

2015-04-03T17:52:35+00:00

Send command not understood response should be verified if it was
successfully sent, like all send responses.

Signed-off-by: Grzegorz Kolodziejczyk 
Signed-off-by: Marcel Holtmann

Bluetooth: Restrict BNEP flags to only valid ones

2015-04-02T05:44:02+00:00

The BNEP flags should be clearly restricted to valid ones. So this puts
extra checks in place to ensure this.

Signed-off-by: Marcel Holtmann 
Signed-off-by: Johan Hedberg