summaryrefslogtreecommitdiff
path: root/net
AgeCommit message (Collapse)Author
2014-07-08net/hsr: Better variable names and update of contact info.Arvid Brodin
Signed-off-by: Arvid Brodin <arvid.brodin@alten.se> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-08ipconfig: add static to local variableFabian Frederick
ic_dev_xid is only used in ipconfig.c Cc: "David S. Miller" <davem@davemloft.net> Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> Cc: netdev@vger.kernel.org Signed-off-by: Fabian Frederick <fabf@skynet.be> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-08Bluetooth: Fix clearing HCI_LE_ADV for LE connectionsJohan Hedberg
All LE controllers always implicitly stop advertising when establishing connections. Therefore, be sure to clear the flag in the event handler for new LE connections. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-07-08Bluetooth: Fix toggling background scan when changing connectable stateJohan Hedberg
If the connectable state change doesn't require any special HCI commands the set_connectable_update_settings() function is used instead of the set_connectable_complete() function. We must therefore make sure to call hci_update_background_scan() there as well. This code path is used also when we're powered off, but that's fine since hci_update_background_scan() has the necessary checks for it. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-07-08Bluetooth: Fix connectable and discoverable supported settings valuesJohan Hedberg
The connectable and discoverable mgmt settings are supported both for LE and BR/EDR controllers so they do not belong behind a lmp_bredr_capable() condition. This patch fixes the issue in get_supported_settings(). Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-07-08Bluetooth: Fix setting STOPPING state for discoveryJohan Hedberg
If any of the HCI commands from the hci_stop_discovery function were successfully sent we need to set the discovery state to STOPPING. The Stop Discovery code was already handling this, but the code in clean_up_hci_state was not. This patch updates the hci_stop_discovery to return a bool to indicate whether it queued any commands and the clean_up_hci_state() function respectively to look at the return value and call hci_discovery_set_state() if necessary. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-07-08Bluetooth: Fix check for re-enabling advertisingJohan Hedberg
There are many different places that can disable LE scanning but we only want to re-enable advertising in hci_cc_le_set_scan_enable() for a very specific use case, which is when the active scanning part of Start Discovery is complete. Because of this, fix the discovery state check to test for the exact state. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-07-08Bluetooth: Fix advertising and active scanning co-existenceJohan Hedberg
Many controllers allow simultaneous active scanning and advertising (e.g. Intel and Broadcom) but some do not (e.g. CSR). It's therefore safest to implement mutual exclusion of these states in the kernel. This patch ensures that the two states are never entered simultaneously. Extra precaution needs to be taken for outgoing connection attempts in slave role (i.e. through directed advertising) in which case the operation that came first has precedence and the one that comes after gets a rejection. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-07-08Bluetooth: Stop advertising always before initiating a connectionJohan Hedberg
Most controllers do not support advertising while initiating an LE connection. We also have to first disable current advertising if the initiation is going to happen through direct advertising. Therefore, simply stop advertising as the first thing when starting to issue commands to establish an LE connection. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-07-08Bluetooth: Use the correct flag to decide to disable advertisingJohan Hedberg
When deciding to call disable_advertising() we're interested in the real state instead of the mgmt setting. Use therefore HCI_LE_ADV instead of the HCI_ADVERTISING flag. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-07-08Bluetooth: Simplify usage of the enable_advertising functionJohan Hedberg
By adding support for disabling advertising when necessary and doing the checks for existing LE connections inside the enable_advertising function we can simplify the calling code quite a lot. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-07-08Bluetooth: Use real advertising state to random address update decisionJohan Hedberg
Now that we have a flag for tracking the real advertising state we should use that to determine whether it's safe to update the random address or not. The couple of places that were clearing the flag due to a pending request need to be updated too. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-07-08Bluetooth: Remove unnecessary mgmt_advertising functionJohan Hedberg
Since the real advertising state is now tracked with its own flag we can simply set/unset the HCI_ADVERTISING flag in the set_advertising_complete function. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-07-08Bluetooth: Add flag to track the real advertising stateJohan Hedberg
Having a single HCI_ADVERTISING flag is problematic since it tries to track both the real advertising state and the corresponding mgmt setting. To make the logic simpler and more reliable add a new flag that only tracks the actual advertising state that has been written to the controller. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-07-07tcp: fix false undo corner casesYuchung Cheng
The undo code assumes that, upon entering loss recovery, TCP 1) always retransmit something 2) the retransmission never fails locally (e.g., qdisc drop) so undo_marker is set in tcp_enter_recovery() and undo_retrans is incremented only when tcp_retransmit_skb() is successful. When the assumption is broken because TCP's cwnd is too small to retransmit or the retransmit fails locally. The next (DUP)ACK would incorrectly revert the cwnd and the congestion state in tcp_try_undo_dsack() or tcp_may_undo(). Subsequent (DUP)ACKs may enter the recovery state. The sender repeatedly enter and (incorrectly) exit recovery states if the retransmits continue to fail locally while receiving (DUP)ACKs. The fix is to initialize undo_retrans to -1 and start counting on the first retransmission. Always increment undo_retrans even if the retransmissions fail locally because they couldn't cause DSACKs to undo the cwnd reduction. Signed-off-by: Yuchung Cheng <ycheng@google.com> Signed-off-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-07igmp: fix the problem when mc leave groupdingtianhong
The problem was triggered by these steps: 1) create socket, bind and then setsockopt for add mc group. mreq.imr_multiaddr.s_addr = inet_addr("255.0.0.37"); mreq.imr_interface.s_addr = inet_addr("192.168.1.2"); setsockopt(sockfd, IPPROTO_IP, IP_ADD_MEMBERSHIP, &mreq, sizeof(mreq)); 2) drop the mc group for this socket. mreq.imr_multiaddr.s_addr = inet_addr("255.0.0.37"); mreq.imr_interface.s_addr = inet_addr("0.0.0.0"); setsockopt(sockfd, IPPROTO_IP, IP_DROP_MEMBERSHIP, &mreq, sizeof(mreq)); 3) and then drop the socket, I found the mc group was still used by the dev: netstat -g Interface RefCnt Group --------------- ------ --------------------- eth2 1 255.0.0.37 Normally even though the IP_DROP_MEMBERSHIP return error, the mc group still need to be released for the netdev when drop the socket, but this process was broken when route default is NULL, the reason is that: The ip_mc_leave_group() will choose the in_dev by the imr_interface.s_addr, if input addr is NULL, the default route dev will be chosen, then the ifindex is got from the dev, then polling the inet->mc_list and return -ENODEV, but if the default route dev is NULL, the in_dev and ifIndex is both NULL, when polling the inet->mc_list, the mc group will be released from the mc_list, but the dev didn't dec the refcnt for this mc group, so when dropping the socket, the mc_list is NULL and the dev still keep this group. v1->v2: According Hideaki's suggestion, we should align with IPv6 (RFC3493) and BSDs, so I add the checking for the in_dev before polling the mc_list, make sure when we remove the mc group, dec the refcnt to the real dev which was using the mc address. The problem would never happened again. Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-07mac802154: at86rf230: add hw flags and merge opsAlexander Aring
This patch adds new mac802154 hw flags for transmit power, csma and listen before transmit (lbt). These flags indicates that the transceiver supports these features. If the flags are set and the driver doesn't implement the necessary functions, then ieee802154_register_device returns -ENOSYS "Function not implemented". This patch merges also all at86rf230 operations into one operations structure and set the right hw flags for the at86rf230 transceivers. Signed-off-by: Alexander Aring <alex.aring@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-07net: Fix NETDEV_CHANGE notifier usage causing spurious arp flushLoic Prylli
A bug was introduced in NETDEV_CHANGE notifier sequence causing the arp table to be sometimes spuriously cleared (including manual arp entries marked permanent), upon network link carrier changes. The changed argument for the notifier was applied only to a single caller of NETDEV_CHANGE, missing among others netdev_state_change(). So upon net_carrier events induced by the network, which are triggering a call to netdev_state_change(), arp_netdev_event() would decide whether to clear or not arp cache based on random/junk stack values (a kind of read buffer overflow). Fixes: be9efd365328 ("net: pass changed flags along with NETDEV_CHANGE event") Fixes: 6c8b4e3ff81b ("arp: flush arp cache on IFF_NOARP change") Signed-off-by: Loic Prylli <loicp@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-07net: Only do flow_dissector hash computation once per packetTom Herbert
Add sw_hash flag to skbuff to indicate that skb->hash was computed from flow_dissector. This flag is checked in skb_get_hash to avoid repeatedly trying to compute the hash (ie. in the case that no L4 hash can be computed). Signed-off-by: Tom Herbert <therbert@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-07ipv6: Implement automatic flow label generation on transmitTom Herbert
Automatically generate flow labels for IPv6 packets on transmit. The flow label is computed based on skb_get_hash. The flow label will only automatically be set when it is zero otherwise (i.e. flow label manager hasn't set one). This supports the transmit side functionality of RFC 6438. Added an IPv6 sysctl auto_flowlabels to enable/disable this behavior system wide, and added IPV6_AUTOFLOWLABEL socket option to enable this functionality per socket. By default, auto flowlabels are disabled to avoid possible conflicts with flow label manager, however if this feature proves useful we may want to enable it by default. It should also be noted that FreeBSD has already implemented automatic flow labels (including the sysctl and socket option). In FreeBSD, automatic flow labels default to enabled. Performance impact: Running super_netperf with 200 flows for TCP_RR and UDP_RR for IPv6. Note that in UDP case, __skb_get_hash will be called for every packet with explains slight regression. In the TCP case the hash is saved in the socket so there is no regression. Automatic flow labels disabled: TCP_RR: 86.53% CPU utilization 127/195/322 90/95/99% latencies 1.40498e+06 tps UDP_RR: 90.70% CPU utilization 118/168/243 90/95/99% latencies 1.50309e+06 tps Automatic flow labels enabled: TCP_RR: 85.90% CPU utilization 128/199/337 90/95/99% latencies 1.40051e+06 UDP_RR 92.61% CPU utilization 115/164/236 90/95/99% latencies 1.4687e+06 Signed-off-by: Tom Herbert <therbert@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-07flow_dissector: Use IPv6 flow label in flow_dissectorTom Herbert
This patch implements the receive side to support RFC 6438 which is to use the flow label as an ECMP hash. If an IPv6 flow label is set in a packet we can use this as input for computing an L4-hash. There should be no need to parse any transport headers in this case. Signed-off-by: Tom Herbert <therbert@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-07vxlan: Call udp_flow_src_portTom Herbert
In vxlan and OVS vport-vxlan call common function to get source port for a UDP tunnel. Removed vxlan_src_port since the functionality is now in udp_flow_src_port. Signed-off-by: Tom Herbert <therbert@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-07net: Call skb_get_hash in get_xps_queue and __skb_tx_hashTom Herbert
Call standard function to get a packet hash instead of taking this from skb->sk->sk_hash or only using skb->protocol. Signed-off-by: Tom Herbert <therbert@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-07net: Save TX flow hash in sock and set in skbuf on xmitTom Herbert
For a connected socket we can precompute the flow hash for setting in skb->hash on output. This is a performance advantage over calculating the skb->hash for every packet on the connection. The computation is done using the common hash algorithm to be consistent with computations done for packets of the connection in other states where thers is no socket (e.g. time-wait, syn-recv, syn-cookies). This patch adds sk_txhash to the sock structure. inet_set_txhash and ip6_set_txhash functions are added which are called from points in TCP and UDP where socket moves to established state. skb_set_hash_from_sk is a function which sets skb->hash from the sock txhash value. This is called in UDP and TCP transmit path when transmitting within the context of a socket. Tested: ran super_netperf with 200 TCP_RR streams over a vxlan interface (in this case skb_get_hash called on every TX packet to create a UDP source port). Before fix: 95.02% CPU utilization 154/256/505 90/95/99% latencies 1.13042e+06 tps Time in functions: 0.28% skb_flow_dissect 0.21% __skb_get_hash After fix: 94.95% CPU utilization 156/254/485 90/95/99% latencies 1.15447e+06 Neither __skb_get_hash nor skb_flow_dissect appear in perf Signed-off-by: Tom Herbert <therbert@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-07flow_dissector: Abstract out hash computationTom Herbert
Move the hash computation located in __skb_get_hash to be a separate function which takes flow_keys as input. This will allow flow hash computation in other contexts where we only have addresses and ports. Signed-off-by: Tom Herbert <therbert@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-076lowpan: mac802154: fix coding style issuesVarka Bhadram
This patch fixed the coding style issues reported by checkpatch.pl following issues fixed: CHECK: Alignment should match open parenthesis WARNING: line over 80 characters CHECK: Blank lines aren't necessary before a close brace '}' WARNING: networking block comments don't use an empty /* line, use /* Comment... WARNING: Missing a blank line after declarations WARNING: networking block comments start with * on subsequent lines CHECK: braces {} should be used on all arms of this statement Signed-off-by: Varka Bhadram <varkab@cdac.in> Tested-by: Alexander Aring <alex.aring@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-07netlink: Fix do_one_broadcast() prototype.Rami Rosen
This patch changes the prototype of the do_one_broadcast() method so that it will return void. Signed-off-by: Rami Rosen <ramirose@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-07tipc: fix link acknowledge logic in receive pathErik Hugne
Link state acks triggered from the receive path is done before the last received packet have been processed by the link layer. The effect of this is that the last received packet will not be included in the ack. This causes problems if the link window is set to TIPC_MIN_LINK_WIN, where the ack interval will be equal to the link tolerance, and the link enters a stop-and-go behavior. We move the ack logic to after link state processing, just before the packet is delivered to higher layers. Signed-off-by: Erik Hugne <erik.hugne@ericsson.com> Signed-off-by: Carl Sigurjonsson <carl.sigurjonsson@ericsson.com> Reviewed-by: Ying Xue <ying.xue@windriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-07tipc: refactor message delivery out of tipc_rcvErik Hugne
This is a cosmetic change, separating message delivery from the link state processing. Signed-off-by: Erik Hugne <erik.hugne@ericsson.com> Reviewed-by: Ying Xue <ying.xue@windriver.com> Reviewed-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-07Merge branch 'net_ovs_fixes' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/pshelar/openvswitch Pravin B Shelar says: ==================== Open vSwitch A set of fixes for net. First bug is related flow-table management. Second one is in sample action. Third is related flow stats and last one add gre-err handler for ovs. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-07tcp: switch snt_synack back to measuring transmit time of first SYNACKNeal Cardwell
Always store in snt_synack the time at which the server received the first client SYN and attempted to send the first SYNACK. Recent commit aa27fc501 ("tcp: tcp_v[46]_conn_request: fix snt_synack initialization") resolved an inconsistency between IPv4 and IPv6 in the initialization of snt_synack. This commit brings back the idea from 843f4a55e (tcp: use tcp_v4_send_synack on first SYN-ACK), which was going for the original behavior of snt_synack from the commit where it was added in 9ad7c049f0f79 ("tcp: RFC2988bis + taking RTT sample from 3WHS for the passive open side") in v3.1. In addition to being simpler (and probably a tiny bit faster), unconditionally storing the time of the first SYNACK attempt has been useful because it allows calculating a performance metric quantifying how long it took to establish a passive TCP connection. Signed-off-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: Yuchung Cheng <ycheng@google.com> Cc: Octavian Purdila <octavian.purdila@intel.com> Cc: Jerry Chu <hkchu@google.com> Acked-by: Octavian Purdila <octavian.purdila@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-07net: Performance fix for process_backlogTom Herbert
In process_backlog the input_pkt_queue is only checked once for new packets and quota is artificially reduced to reflect precisely the number of packets on the input_pkt_queue so that the loop exits appropriately. This patches changes the behavior to be more straightforward and less convoluted. Packets are processed until either the quota is met or there are no more packets to process. This patch seems to provide a small, but noticeable performance improvement. The performance improvement is a result of staying in the process_backlog loop longer which can reduce number of IPI's. Performance data using super_netperf TCP_RR with 200 flows: Before fix: 88.06% CPU utilization 125/190/309 90/95/99% latencies 1.46808e+06 tps 1145382 intrs.sec. With fix: 87.73% CPU utilization 122/183/296 90/95/99% latencies 1.4921e+06 tps 1021674.30 intrs./sec. Signed-off-by: Tom Herbert <therbert@google.com> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-07ipv4: icmp: Fix pMTU handling for rare caseEdward Allcutt
Some older router implementations still send Fragmentation Needed errors with the Next-Hop MTU field set to zero. This is explicitly described as an eventuality that hosts must deal with by the standard (RFC 1191) since older standards specified that those bits must be zero. Linux had a generic (for all of IPv4) implementation of the algorithm described in the RFC for searching a list of MTU plateaus for a good value. Commit 46517008e116 ("ipv4: Kill ip_rt_frag_needed().") removed this as part of the changes to remove the routing cache. Subsequently any Fragmentation Needed packet with a zero Next-Hop MTU has been discarded without being passed to the per-protocol handlers or notifying userspace for raw sockets. When there is a router which does not implement RFC 1191 on an MTU limited path then this results in stalled connections since large packets are discarded and the local protocols are not notified so they never attempt to lower the pMTU. One example I have seen is an OpenBSD router terminating IPSec tunnels. It's worth pointing out that this case is distinct from the BSD 4.2 bug which incorrectly calculated the Next-Hop MTU since the commit in question dismissed that as a valid concern. All of the per-protocols handlers implement the simple approach from RFC 1191 of immediately falling back to the minimum value. Although this is sub-optimal it is vastly preferable to connections hanging indefinitely. Remove the Next-Hop MTU != 0 check and allow such packets to follow the normal path. Fixes: 46517008e116 ("ipv4: Kill ip_rt_frag_needed().") Signed-off-by: Edward Allcutt <edward.allcutt@openmarket.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-07batman-adv: Use kasprintfHimangi Saraogi
kasprintf combines kmalloc and sprintf, and takes care of the size calculation itself. The semantic patch that makes this change is as follows: // <smpl> @@ expression a,flag; expression list args; statement S; @@ a = - \(kmalloc\|kzalloc\)(...,flag) + kasprintf(flag,args) <... when != a if (a == NULL || ...) S ...> - sprintf(a,args); // </smpl> Signed-off-by: Himangi Saraogi <himangi774@gmail.com> Acked-by: Julia Lawall <julia.lawall@lip6.fr> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-07vlan: Pass SIOC[SG]HWTSTAMP ioctls to real deviceStefan Sørensen
This allows applications to enable hardware timestamping without being aware of it being a vlan device and figuring out the real device. Signed-off-by: Stefan Sørensen <stefan.sorensen@spectralink.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-07ptp: Classify ptp over ip over vlan packetsStefan Sørensen
This extends the ptp bpf to also match ptp over ip over vlan packets. The ptp classes are changed to orthogonal bitfields representing version, transport and vlan values to simplify matching. Signed-off-by: Stefan Sørensen <stefan.sorensen@spectralink.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-07net: Simplify ptp class checksStefan Sørensen
Replace two switch statements enumerating all valid ptp classes with an if statement matching for not PTP_CLASS_NONE. Signed-off-by: Stefan Sørensen <stefan.sorensen@spectralink.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-07Bluetooth: Don't try background scanning if LE is not enabledJohan Hedberg
For adapters that do not support LE and ones where LE hasn't been enabled we shouldn't be trying to initiate background scanning. This patch adds an extra check to the hci_update_background_scan() to ensure that we bail out if HCI_LE_ENABLED is not set. Since we do allow user space to feed the kernel with LE connection parameters even when LE is not enabled we now need to also call hci_update_background_scan() as soon as LE gets enabled so that scanning gets started if necessary. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-07-07Bluetooth: Pass desired connection role to hci_connect_le()Johan Hedberg
If we have both LE scanning and advertising simultaneously enabled we need a way to tell hci_connect_le() in which role to initiate a connection. This patch adds a new parameter to the function to give it the necessary information. For auto-connect and mgmt_pair_device we always use master role, whereas for L2CAP users (in practice sockets) we use slave role whenever HCI_ADVERTISING is set and master role otherwise. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-07-07Bluetooth: Remove auth_type parameter from hci_connect_le()Johan Hedberg
The auth_type value which gets assigned to hci_conn->auth_type is something that's only used for BR/EDR connections and is of no value for LE connections. It makes therefore little sense to pass it to the hci_connect_le() function. This patch removes the parameter from the function. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-07-07Bluetooth: Enable passive scanning whenever we're connectableJohan Hedberg
Enabling passive scanning always when we're connectable aligns us with the BR/EDR page scanning. This is also consistent with the fact that the code dealing with passive scanning results will actively try to connect any direct advertising event when we're connectable. This patch implements the feature by adding the connectable condition to hci_update_background_scan() checks for starting scanning and by calling hci_update_background_scan() whenever the connectable state changes. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-07-07Bluetooth: Don't let background scanning interfering with discoveryJohan Hedberg
If we have an active discovery going on we shouldn't do any changes to LE scanning when hci_update_background_scan() is called (a call which can happen for many different reasons). This patch fixes the issue by returning from the function if the discovery state is anything else except DISCOVERY_STOPPED. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-07-07Bluetooth: Update discovery state earlier in hci_discovery_set_stateJohan Hedberg
In a subsequent patch the hci_update_background_scan() function will depend on being able to know the current discovery state. For this to be possible we need to set the new state early in the function. Since we also need to check what the old state was this patch introduces an extra variable for tracking it. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-07-07Bluetooth: Remove unnecessary return value from check_pending_le_connJohan Hedberg
Since the only caller of this function doesn't care about the return value anymore let's just remove it. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-07-07Bluetooth: Remove redundant IRK lookup in mgmt_device_found()Johan Hedberg
Now that we have the process_adv_report() function doing the IRK lookup and updating the bdaddr we don't need to do this anymore in mgmt.c in the mgmt_device_found() function. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-07-07Bluetooth: Fix connecting devices during LE device discoveryJohan Hedberg
If we have devices set as to be connected we should connect to them even during normal discovery if we get a connectable advertising event. If we also have HCI_CONNECTABLE set we should connect ADV_DIRECT_IND events even to devices that we don't have in our pend_le_conns list. This patch implements such behavior by passing the advertising report type to check_pending_le_conn() and calls that function regardless of what type of scanning we are doing. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-07-06Bluetooth: Enforce providing hdev->send driver callbackMarcel Holtmann
The hdev->send driver callback is mandatory to be provided by a driver before calling hci_register_dev. So enforce it and return EINVAL in case it is not available. All existing drivers are providing this callback anyway, so this is just an extra sanity check. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2014-07-06Bluetooth: Fix memory leaking when hdev->send returns an errorMarcel Holtmann
The drivers are allowed to just return an error from hdev->send callback and in that case the driver does not own the SKB. Which means that the caller has to free the SKB. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2014-07-06Bluetooth: Fix updating background scan for LE connect completeJohan Hedberg
When we get an LE connection complete event we should restart background scanning if there are any devices needing it. So far the code was only making the decision based on whether the completed connection had any stored parameters or not. This patch ensures that we trigger background scanning always when necessary. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-07-06Bluetooth: Skip unconfigured init procedure for raw-only devicesMarcel Holtmann
When the driver sets HCI_QUIRK_RAW_DEVICE, the controller will be set as unconfigured. However running the unconfigured init procecure is not useful since raw-only devices are not allowed to change its configuration. This change skips the init procedure and just allows user channel operation for this device. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>