bluetooth-next pull request for net-next:
- Proper support for BCM4330 and BMC4334
- Various improvements for firmware download of Intel controllers
- Update management interface revision to 20
- Support for AOSP HCI vendor commands
- Initial Virtio support
Signed-off-by: Luiz Augusto
Hi Emil,
On Sun, Mar 21, 2021 at 4:23 PM Emil Lenngren wrote:
>
> Hi,
>
> Den mån 22 mars 2021 kl 00:01 skrev Luiz Augusto von Dentz
> :
> > Or we do something like
> > https://lore.kernel.org/linux-bluetooth/20201024002251.1389267-1-luiz.de...@gmail.com/,
> &g
s
> fix. :)
Or we do something like
https://lore.kernel.org/linux-bluetooth/20201024002251.1389267-1-luiz.de...@gmail.com/,
that said the reason we didn't applied my patches was that the
controller would be the one generating invalid data, but it seems you
are reproducing with vhci controller which is only used for emulating
a controller and requires root privileges so it is unlikely these
conditions would happens with hardware itself, in the other hand as
there seems to be more and more reports using vhci to emulate broken
events it perhaps more productive to introduce proper checks for all
events so we don't have to deal with more reports like this in the
future.
> Others =
>
> Please let me know if there is any confuses.
> Best wishes!
--
Luiz Augusto von Dentz
> ? syscall_enter_from_user_mode+0x1d/0x50
> do_syscall_64+0x33/0x40
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> Fixes: 0fc1a726f897 ("Bluetooth: sco: new getsockopt options
> BT_SNDMTU/BT_RCVMTU")
> Reported-by: Hulk Robot
> Signed-off-by: Wei Yongjun
imed out2.648 seconds
Add Ext Advertising - Success (Shortened name) Timed out1.993 seconds
Add Ext Advertising - Success (Short name) Timed out2.004 seconds
These tests expect the Set Extended Scan Response Data to be send but
it is not and then it times out, the problem seems to be that
get_adv_instance_scan_rsp_len does check for things like include
local-name on instances other than 0, also we probably need to include
some logic to check if the instance is really scannable to begin with.
--
Luiz Augusto von Dentz
o test, also tester supports the concept of 'not run'
which we can probably use for experimental commands.
> Thanks,
> Daniel
>
> On Thu, Oct 29, 2020 at 5:04 PM Luiz Augusto von Dentz
> wrote:
> >
> > Hi Daniel,
> >
> > On Thu, Oct 29, 2020 at 3:25
Hi Daniel,
On Thu, Oct 29, 2020 at 3:25 PM Daniel Winkler wrote:
>
> Hi Luiz,
>
> Thank you for the feedback regarding mgmt-tester. I intended to use
> the tool, but found that it had a very high rate of test failure even
> before I started adding new tests. If you have a strong preference for
>
luetooth: Use intervals and tx power from mgmt cmds
> > Bluetooth: Query LE tx power on startup
> > Bluetooth: Change MGMT security info CMD to be more generic
> >
> > include/net/bluetooth/hci.h | 7 +
> > include/net/bluetooth/hci_core.h | 12 +-
> > include/net/bluetooth/mgmt.h | 49 +++-
> > net/bluetooth/hci_core.c | 47 +++-
> > net/bluetooth/hci_event.c| 19 ++
> > net/bluetooth/hci_request.c | 29 ++-
> > net/bluetooth/mgmt.c | 424 +--
> > 7 files changed, 542 insertions(+), 45 deletions(-)
> >
> > --
> > 2.28.0.709.gb0816b6eb0-goog
> >
--
Luiz Augusto von Dentz
fs entry, force_bredr_smp,
> > > by moving it from the SMP registration to the BR/EDR controller init
> > > section. hci_debugfs_create_bredr is only called when HCI_SETUP and
> > > HCI_CONFIG is not set.
> > >
> > > Signed-off-by: Claire Chang
> Revie
>
> @@ -138,6 +140,8 @@ int set_def_system_config(struct sock *sk, struct hci_dev
> *hdev, void *data,
> case 0x0019:
> case 0x001a:
> case 0x001b:
> + case 0x001d:
> + case 0x001e:
> if (len != sizeof(u16)) {
> bt_dev_warn(hdev, "invalid length %d, exp %zu
> for type %d",
> len, sizeof(u16), type);
> @@ -251,6 +255,12 @@ int set_def_system_config(struct sock *sk, struct
> hci_dev *hdev, void *data,
> hdev->def_le_autoconnect_timeout =
>
> msecs_to_jiffies(TLV_GET_LE16(buffer));
> break;
> + case 0x0001d:
> + hdev->advmon_allowlist_duration =
> TLV_GET_LE16(buffer);
> + break;
> + case 0x0001e:
> + hdev->advmon_no_filter_duration =
> TLV_GET_LE16(buffer);
> + break;
> default:
> bt_dev_warn(hdev, "unsupported parameter %u", type);
> break;
> --
> 2.28.0.681.g6f77f65b4e-goog
>
--
Luiz Augusto von Dentz
Hi Archie,
On Tue, Sep 22, 2020 at 12:37 AM Archie Pusaka wrote:
>
> Hi Luiz,
>
> On Tue, 22 Sep 2020 at 01:13, Luiz Augusto von Dentz
> wrote:
> >
> > Hi Archie,
> >
> > On Mon, Sep 21, 2020 at 1:31 AM Archie Pusaka wrote:
> > >
> > > F
Hi Archie,
On Tue, Sep 22, 2020 at 12:48 AM Archie Pusaka wrote:
>
> Hi Luiz,
>
> On Tue, 22 Sep 2020 at 01:15, Luiz Augusto von Dentz
> wrote:
> >
> > Hi Archie,
> >
> >
> > On Mon, Sep 21, 2020 at 12:56 AM Archie Pusaka wrote:
> > >
ck_link_mode(conn->hcon)) {
> + (!hci_conn_check_link_mode(conn->hcon) ||
> + !l2cap_check_enc_key_size(conn->hcon))) {
I wonder if we couldn't incorporate the check of key size into
hci_conn_check_link_mode, like I said in the first patch checking the
enc key size should not be specific to L2CAP.
> conn->disc_reason = HCI_ERROR_AUTH_FAILURE;
> result = L2CAP_CR_SEC_BLOCK;
> goto response;
> --
> 2.28.0.681.g6f77f65b4e-goog
>
--
Luiz Augusto von Dentz
; + hcon->enc_key_size >= min_key_size);
While this looks fine to me, it looks like this should be placed
elsewhere since it takes an hci_conn and it is not L2CAP specific.
> }
>
> static void l2cap_do_start(struct l2cap_chan *chan)
> --
> 2.28.0.681.g6f77f65b4e-goog
>
--
Luiz Augusto von Dentz
. */
> idr_for_each(&hdev->adv_monitors_idr, &free_adv_monitor,
> hdev);
> --
> 2.28.0.618.gf4bc123cb7-goog
This looks like a kernel patch so you shouldn't be prefixing it with
BlueZ as it might confuse CI.
--
Luiz Augusto von Dentz
On Wed, Aug 19, 2020 at 11:23 AM Pali Rohár wrote:
>
> On Wednesday 19 August 2020 11:21:00 Luiz Augusto von Dentz wrote:
> > Hi Pali,
> >
> > On Wed, Aug 19, 2020 at 7:37 AM Pali Rohár wrote:
> > >
> > > On Friday 14 August 2020 12:56:05 Luiz
Hi Pali,
On Wed, Aug 19, 2020 at 7:37 AM Pali Rohár wrote:
>
> On Friday 14 August 2020 12:56:05 Luiz Augusto von Dentz wrote:
> > Hi Joseph,
> >
> > On Thu, Aug 13, 2020 at 1:42 AM Joseph Hwang wrote:
> > >
> > > It is desirable to expose the wideba
le_pkts;
> + unsigned intsco_pkt_len;
Id use sco_mtu to so the following check actually does what it intended to do:
https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/tree/net/bluetooth/sco.c#n283
Right now it seems we are using the buffer length as MTU but I think
we should actually use the packet length if it is lower than the
buffer length, actually it doesn't seems SCO packets can be fragmented
so the buffer length must always be big enough to carry a full packet
so I assume setting the packet length as conn->mtu will always be
correct.
>
> __u16 block_len;
> __u16 block_mtu;
> --
> 2.28.0.236.gb10cc79966-goog
>
--
Luiz Augusto von Dentz
; int level, int optname,
> err = -EFAULT;
> break;
>
> + case BT_SCO_PKT_LEN:
> + if (put_user(sco_pi(sk)->pkt_len, (u32 __user *)optval))
> + err = -EFAULT;
> + break;
Couldn't we expose this via BT_SNDMTU/BT_RCVMTU?
> default:
> err = -ENOPROTOOPT;
> break;
> --
> 2.28.0.236.gb10cc79966-goog
>
--
Luiz Augusto von Dentz
not familiar with bluetooth debugging but I am willing to provide
> any logs, do tests and try patches.
>
> I am running fedora 32 on the affected system which has built-in intel
> wireless/bluetooth card,
>
> PCI (wifi) part:
> 47:00.0 Network controller: Intel Corporation Wi-Fi 6 AX200 (rev 1a)
>
> USB (bluetooth) parrt:
> Bus 011 Device 004: ID 8087:0029 Intel Corp.
>
> My .config attached (custom built kernel)
>
> Best regards,
> Maxim Levitsky
>
--
Luiz Augusto von Dentz
>> + skb_queue_walk_safe(&hdev->pending_acl_q, skb, tmp) {
> >> >>> + hdr = (struct hci_acl_hdr *)skb->data;
> >> >>> + handle = hci_handle(__le16_to_cpu(hdr->handle));
> >> >>> +
> >> >>> + if (handle == oldest_handle) {
> >> >>> + __skb_unlink(skb, &hdev->pending_acl_q);
> >> >>> + kfree_skb(skb);
> >> >>> + }
> >> >>> + }
> >> >>> +
> >> >>> + if (!skb_queue_empty(&hdev->pending_acl_q))
> >> >>> + queue_delayed_work(hdev->workqueue,
> >> >>> &hdev->remove_pending_acl,
> >> >>> +PENDING_ACL_TIMEOUT);
> >> >>> +}
> >> >>> +
> >> >>
> >> >> So I am wondering if we make this too complicated. Since generally
> >> >> speaking we can only have a single HCI connect complete anyway at a
> >> >> time. No matter if the controller serializes it for us or we do it for
> >> >> the controller. So hci_conn_add could just process the queue for
> >> >> packets with its handle and then flush it. And it can flush it no
> >> >> matter what since whatever other packets are in the queue, they can not
> >> >> be valid.
> >> >>
> >> >> That said, we wouldn’t even need to check the packet handles at all. We
> >> >> just needed to flag them as already out-of-order queued once and hand
> >> >> them back into the rx_q at the top. Then the would be processed as
> >> >> usual. Already ooo packets would cause the same error as before if it
> >> >> is for a non-existing handle and others would end up being processed.
> >> >>
> >> >> For me this means we just need another queue to park the packets until
> >> >> hci_conn_add gets called. I might have missed something, but I am
> >> >> looking for the least invasive option for this and least code
> >> >> duplication.
> >> >
> >> > I'm not aware of the fact that we can only have a single HCI connect
> >> > complete event at any time. Is this also true even if two / more
> >> > peripherals connect at the same time?
> >> > I was under the impression that if we have device A and B both are
> >> > connecting to us at the same time, we might receive the packets in
> >> > this order:
> >> > (1) ACL A
> >> > (2) ACL B
> >> > (3) HCI conn evt B
> >> > (4) HCI conn evt A
> >> > Hence the queue and the handle check.
> >>
> >> my reading from the LL state machine is that once the first LL_Connect_Req
> >> is processes, the controller moves out of the advertising state. So no
> >> other LL_Connect_Req can be processed. So that means that connection
> >> attempts are serialized.
> >>
> >> Now if you run AE and multiple instances, that might be different, but
> >> then again, these instances are also offset in time and so I don’t see how
> >> we can get more than one HCI_Connection_Complete event at a time (and with
> >> that a leading ACL packet).
> >>
> >> Regards
> >>
> >> Marcel
> >>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "ChromeOS Bluetooth Upstreaming" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an
> >> email to chromeos-bluetooth-upstreaming+unsubscr...@chromium.org.
> >> To post to this group, send email to
> >> chromeos-bluetooth-upstream...@chromium.org.
> >> To view this discussion on the web visit
> >> https://groups.google.com/a/chromium.org/d/msgid/chromeos-bluetooth-upstreaming/7BBB55E0-FBD9-40C0-80D9-D5E7FC9F80D2%40holtmann.org.
--
Luiz Augusto von Dentz
on = HCI_ERROR_AUTH_FAILURE;
> >>> + result = L2CAP_CR_SEC_BLOCK;
> >>> + goto response;
> >>> + }
> >>> +
> >>> + l2cap_add_pending_encrypt_conn(conn, req, ident, rsp_code,
> >>> +amp_id);
> >>> + result = L2CAP_CR_PEND;
> >>> goto response;
> >>> }
> >>
> >> So I am actually wondering if the approach is not better to send back a
> >> pending to the connect request like we do for everything else. And then
> >> proceed with getting our remote L2CAP information. If these come back in
> >> encrypted, then we can assume that we actually had encryption enabled and
> >> proceed with a L2CAP connect response saying that all is fine.
> >
> > I wonder if we should resolve this by having different queues in
> > hci_recv_frame (e.g. hdev->evt_rx), that way we can dequeue the HCI
> > events before ACL so we first update the HCI states before start
> > processing the L2CAP data, thoughts? Something like this:
> >
> > https://gist.github.com/Vudentz/464fb0065a73e5c99bdb66cd2c5a1a2d
>
> No. We need to keep things serialized. We actually have to reject unencrypted
> packets.
>
> So whatever we do needs to be behind a quirk and an explicit opt-in.
While I agree we are just working around the real issue, Id guess
processing the event before ACL would work (I haven't tested it yet)
much better than leaving this up to the L2CAP layer since that
requires a timer in order for us to e.g. accept/reject the connection
request, also since this problem is known to affect other events as
well (e.g. data for ATT coming before Connection Complete) I guess
using the time the kernel takes to schedule the rx_work as the window
where we would assume the packets arrived 'at same time' so we can
resolve the conflicts between endpoints. On top of this we could
perhaps consider using a delayed work for rx_work so the driver can
actually tune up what is the time window (perhaps for USB that should
be the polling interval) where we would consider events and data that
have arrived at same time.
Or are you saying that the conflict resolution I proposed would
actually break things? I could picture any event that if it were
processed before the data at such a short time window would, note here
I'm talking about miliseconds not seconds so it is not that this will
be doing much reordering and if we go with delayed work it should be
relatively simple to add a Kconfig option(build-time)/module(runtime)
parameter to btusb to configure the interface were we would do such
reordering which the default could be 0 in which case we can just keep
queuing everything on rx_q.
> Regards
>
> Marcel
>
--
Luiz Augusto von Dentz
ACL is secure enough (if not SDP) */
> > if (psm != cpu_to_le16(L2CAP_PSM_SDP) &&
> > !hci_conn_check_link_mode(conn->hcon)) {
> > - conn->disc_reason = HCI_ERROR_AUTH_FAILURE;
> > - result = L2CAP_CR_SEC_BLOCK;
> > + if (!queue_if_fail) {
> > + conn->disc_reason = HCI_ERROR_AUTH_FAILURE;
> > + result = L2CAP_CR_SEC_BLOCK;
> > + goto response;
> > + }
> > +
> > + l2cap_add_pending_encrypt_conn(conn, req, ident, rsp_code,
> > +amp_id);
> > + result = L2CAP_CR_PEND;
> > goto response;
> > }
>
> So I am actually wondering if the approach is not better to send back a
> pending to the connect request like we do for everything else. And then
> proceed with getting our remote L2CAP information. If these come back in
> encrypted, then we can assume that we actually had encryption enabled and
> proceed with a L2CAP connect response saying that all is fine.
I wonder if we should resolve this by having different queues in
hci_recv_frame (e.g. hdev->evt_rx), that way we can dequeue the HCI
events before ACL so we first update the HCI states before start
processing the L2CAP data, thoughts? Something like this:
https://gist.github.com/Vudentz/464fb0065a73e5c99bdb66cd2c5a1a2d
> That also means no queuing of packets is required.
>
> Regards
>
> Marcel
>
--
Luiz Augusto von Dentz
ld be in charge to decide if the link
should be disconnected or not.
> > Please share your thoughts on this.
>
> I am look into this. Just bare with me for a bit to verify the call chain.
>
> Regards
>
> Marcel
>
--
Luiz Augusto von Dentz
Hi Alex,
On Mon, Jan 22, 2018 at 5:33 PM, Alexander Aring wrote:
> Hi,
>
> 2018-01-22 8:00 GMT-05:00 Luiz Augusto von Dentz :
>> Hi Alex,
>>
> ...
>>>
>>> or is there a special bluetooth API call needed, like the current case
>>> with debugfs.
Hi Alex,
On Wed, Jan 17, 2018 at 3:37 PM, Alexander Aring wrote:
> Hi,
>
> 2018-01-17 7:15 GMT-05:00 Luiz Augusto von Dentz :
>> Hi,
>>
>> On Wed, Jan 17, 2018 at 1:47 AM, Guo Yi wrote:
>>> This patch fix the bluetooth 6lowpan disconnect fail bug.
>>&g
onn_hash_lookup_le(hdev, addr, *addr_type);
> + hcon = hci_conn_hash_lookup_le(hdev, addr, lookup_type);
> hci_dev_unlock(hdev);
>
> if (!hcon)
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Luiz Augusto von Dentz
ddr;
> - struct lowpan_btle_dev *dev;
> -
> - dev = lowpan_btle_dev(netdev);
>
> saddr = peer->lladdr;
>
> --
> 2.11.0
Acked-by: Luiz Augusto von Dentz
--
Luiz Augusto von Dentz
wrong only if you look at 6LoWPAN interface as being owned by
6lowpan modules, but it doesn't, in fact it won't anything by itself
so it basically acts as a library to that perform 6LoWPAN operation on
the packet level, thus why it is possible to switch from virtual to
real interface. Also
ences,
but in reality, these technologies are competing for the same market
so I don't think it will happen, unfortunately.
> - Alex
>
> [0]
> https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=814f1b243d2c63928f6aa72d66bec0e5fae2f4a9
--
Luiz Augusto von Dentz
- return;
> -
> - lowpan_cb(skb)->status = 0;
> + BT_DBG("chan %p resume", chan);
> }
>
> static long chan_get_sndtimeo_cb(struct l2cap_chan *chan)
> --
> 2.11.0
It should be possible to queue the packets on l2cap_chan_send, Im not
sure why we have this suspend logic in the first place so perhaps
Jukka can shed some light here.
--
Luiz Augusto von Dentz
ct
> net_device *netdev,
> }
>
> daddr = peer->lladdr;
> - peer_addr = &peer->chan->dst;
> + *peer_addr = peer->chan->dst;
> *peer_addr_type = peer->chan->dst_type;
> lowpan_cb(skb)->chan = peer->chan;
>
> --
> 2.11.0
Reviewed-by: Luiz Augusto von Dentz
--
Luiz Augusto von Dentz
From: Alexander Aring
This patch adds support for 48 bit 6LoWPAN address length
autoconfiguration which is the case for BTLE 6LoWPAN.
Signed-off-by: Alexander Aring
Signed-off-by: Luiz Augusto von Dentz
Reviewed-by: Stefan Schmidt
Acked-by: David S. Miller
---
net/ipv6/addrconf.c | 17
From: Patrik Flykt
Set MAC address length according to the 6LoWPAN link layer in use.
Bluetooth Low Energy uses 48 bit addressing while IEEE802.15.4 uses
64 bits.
Signed-off-by: Patrik Flykt
Reviewed-by: Stefan Schmidt
---
net/6lowpan/core.c | 11 ++-
1 file changed, 10 insertions(+),
From: Luiz Augusto von Dentz
This allow technologies such as Bluetooth to use its native lladdr which
is eui48 instead of eui64 which was expected by functions like
lowpan_header_decompress and lowpan_header_compress.
Signed-off-by: Luiz Augusto von Dentz
Reviewed-by: Stefan Schmidt
From: Alexander Aring
The skb->pkt_type need to be set by L2, but on 6LoWPAN there exists L2
e.g. BTLE which doesn't has multicast addressing. If it's a multicast or
not is detected by IPHC headers multicast bit. The IPv6 layer will
evaluate this pkt_type, so we force set this type while uncompre
From: Patrik Flykt
Set BTLE MAC addresses that are 6 bytes long and not 8 bytes
that are used in other places with 6lowpan.
Signed-off-by: Patrik Flykt
Signed-off-by: Luiz Augusto von Dentz
Reviewed-by: Stefan Schmidt
---
net/bluetooth/6lowpan.c | 19 ---
1 file changed, 8
From: Luiz Augusto von Dentz
According to RFC 7668 U/L bit shall not be used:
https://wiki.tools.ietf.org/html/rfc7668#section-3.2.2 [Page 10]:
In the figure, letter 'b' represents a bit from the
Bluetooth device address, copied as is without any changes on any
bit. This
From: Luiz Augusto von Dentz
These patches fixes lladdr length to be 6 bytes long and not 8 which cause
neighbor advertisement to be sent with wrong lladdr including FF:FE filler
bytes for eui64.
Note: This does not fix some of the existing crashes which I hope to address
in a different set
From: Alexander Aring
This patch adds support for 48 bit 6LoWPAN address length
autoconfiguration which is the case for BTLE 6LoWPAN.
Signed-off-by: Alexander Aring
Signed-off-by: Luiz Augusto von Dentz
Reviewed-by: Stefan Schmidt
Acked-by: David S. Miller
---
net/ipv6/addrconf.c | 17
From: Luiz Augusto von Dentz
According to RFC 7668 U/L bit shall not be used:
https://wiki.tools.ietf.org/html/rfc7668#section-3.2.2 [Page 10]:
In the figure, letter 'b' represents a bit from the
Bluetooth device address, copied as is without any changes on any
bit. This
From: Patrik Flykt
Set BTLE MAC addresses that are 6 bytes long and not 8 bytes
that are used in other places with 6lowpan.
Signed-off-by: Patrik Flykt
Signed-off-by: Luiz Augusto von Dentz
Reviewed-by: Stefan Schmidt
---
net/bluetooth/6lowpan.c | 19 ---
1 file changed, 8
From: Patrik Flykt
Set MAC address length according to the 6LoWPAN link layer in use.
Bluetooth Low Energy uses 48 bit addressing while IEEE802.15.4 uses
64 bits.
Signed-off-by: Patrik Flykt
Reviewed-by: Stefan Schmidt
---
net/6lowpan/core.c | 11 ++-
1 file changed, 10 insertions(+),
From: Luiz Augusto von Dentz
This allow technologies such as Bluetooth to use its native lladdr which
is eui48 instead of eui64 which was expected by functions like
lowpan_header_decompress and lowpan_header_compress.
Signed-off-by: Luiz Augusto von Dentz
Reviewed-by: Stefan Schmidt
From: Alexander Aring
The skb->pkt_type need to be set by L2, but on 6LoWPAN there exists L2
e.g. BTLE which doesn't has multicast addressing. If it's a multicast or
not is detected by IPHC headers multicast bit. The IPv6 layer will
evaluate this pkt_type, so we force set this type while uncompre
From: Luiz Augusto von Dentz
These patches fixes lladdr length to be 6 bytes long and not 8 which cause
neighbor advertisement to be sent with wrong lladdr including FF:FE filler
bytes for eui64.
Note: This does not fix some of the existing crashes which I hope to address
in a different set
Hi Alex,
On Sun, Feb 26, 2017 at 8:38 AM, Alexander Aring wrote:
>
> Hi,
>
> okay now I am finally confused.
>
> On 02/24/2017 01:14 PM, Luiz Augusto von Dentz wrote:
>> From: Alexander Aring
>>
>> This patch adds support for 48 bit 6LoWPAN address length
&g
From: Luiz Augusto von Dentz
This allow technologies such as Bluetooth to use its native lladdr which
is eui48 instead of eui64 which was expected by functions like
lowpan_header_decompress and lowpan_header_compress.
Signed-off-by: Luiz Augusto von Dentz
Reviewed-by: Stefan Schmidt
From: Patrik Flykt
Set MAC address length according to the 6LoWPAN link layer in use.
Bluetooth Low Energy uses 48 bit addressing while IEEE802.15.4 uses
64 bits.
Signed-off-by: Patrik Flykt
Reviewed-by: Stefan Schmidt
---
net/6lowpan/core.c | 11 ++-
1 file changed, 10 insertions(+),
From: Patrik Flykt
Set BTLE MAC addresses that are 6 bytes long and not 8 bytes
that are used in other places with 6lowpan.
Signed-off-by: Patrik Flykt
Signed-off-by: Luiz Augusto von Dentz
Reviewed-by: Stefan Schmidt
---
net/bluetooth/6lowpan.c | 19 ---
1 file changed, 8
From: Luiz Augusto von Dentz
These patches fixes lladdr length to be 6 bytes long and not 8 which cause
neighbor advertisement to be sent with wrong lladdr including FF:FE filler
bytes for eui64.
Note: This does not fix some of the existing crashes which I hope to address
in a different set
From: Alexander Aring
This patch adds support for 48 bit 6LoWPAN address length
autoconfiguration which is the case for BTLE 6LoWPAN.
Signed-off-by: Alexander Aring
Signed-off-by: Luiz Augusto von Dentz
Reviewed-by: Stefan Schmidt
---
net/ipv6/addrconf.c | 17 -
1 file
From: Alexander Aring
The skb->pkt_type need to be set by L2, but on 6LoWPAN there exists L2
e.g. BTLE which doesn't has multicast addressing. If it's a multicast or
not is detected by IPHC headers multicast bit. The IPv6 layer will
evaluate this pkt_type, so we force set this type while uncompre
From: Luiz Augusto von Dentz
Accourding to RFC 7668 U/L bit shall not be used:
https://wiki.tools.ietf.org/html/rfc7668#section-3.2.2 [Page 10]:
In the figure, letter 'b' represents a bit from the
Bluetooth device address, copied as is without any changes on any
bit. This
From: Luiz Augusto von Dentz
This allow technologies such as Bluetooth to use its native lladdr which
is eui48 instead of eui64 which was expected by functions like
lowpan_header_decompress and lowpan_header_compress.
Signed-off-by: Luiz Augusto von Dentz
Reviewed-by: Stefan Schmidt
From: Alexander Aring
This patch adds support for 48 bit 6LoWPAN address length
autoconfiguration which is the case for BTLE 6LoWPAN.
Signed-off-by: Alexander Aring
Signed-off-by: Luiz Augusto von Dentz
Reviewed-by: Stefan Schmidt
---
net/ipv6/addrconf.c | 17 -
1 file
From: Alexander Aring
The skb->pkt_type need to be set by L2, but on 6LoWPAN there exists L2
e.g. BTLE which doesn't has multicast addressing. If it's a multicast or
not is detected by IPHC headers multicast bit. The IPv6 layer will
evaluate this pkt_type, so we force set this type while uncompre
From: Patrik Flykt
Set MAC address length according to the 6LoWPAN link layer in use.
Bluetooth Low Energy uses 48 bit addressing while IEEE802.15.4 uses
64 bits.
Signed-off-by: Patrik Flykt
---
net/6lowpan/core.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/
From: Patrik Flykt
Set MAC address length according to the 6LoWPAN link layer in use.
Bluetooth Low Energy uses 48 bit addressing while IEEE802.15.4 uses
64 bits.
Signed-off-by: Patrik Flykt
Reviewed-by: Stefan Schmidt
---
net/6lowpan/core.c | 11 ++-
1 file changed, 10 insertions(+),
From: Patrik Flykt
Set BTLE MAC addresses that are 6 bytes long and not 8 bytes
that are used in other places with 6lowpan.
Signed-off-by: Patrik Flykt
Signed-off-by: Luiz Augusto von Dentz
Reviewed-by: Stefan Schmidt
---
net/bluetooth/6lowpan.c | 19 ---
1 file changed, 8
From: Luiz Augusto von Dentz
These patches fixes lladdr length to be 6 bytes long and not 8 which cause
neighbor advertisement to be sent with wrong lladdr including FF:FE filler
bytes for eui64/iid.
Note: This does not fix some of the existing crashes which I hope to address
in a different set
; David, is that ok with you?
>
>
> On 02/17/2017 04:50 PM, Luiz Augusto von Dentz wrote:
>>
>> From: Alexander Aring
>>
>> This patch adds support for 48 bit 6LoWPAN address length
>> autoconfiguration which is the case for BTLE 6LoWPAN.
>>
>&g
62 matches
Mail list logo
