Bluetooth: ATT: Respond with not support error for unknown PDUs #6

Vudentz · 2017-04-28T12:06:39Z

This ensures that an unkown request won't cause ATT to timeout since no
response is currently generated.

Signed-off-by: Luiz Augusto von Dentz [email protected]

This change is

jhedberg · 2017-04-28T19:29:04Z

subsys/bluetooth/host/att.c

+ if (att_op_get_type(hdr->code) != ATT_COMMAND) {
+ send_err_rsp(chan->conn, hdr->code, 0,
+ BT_ATT_ERR_NOT_SUPPORTED);
+ }


I'm not convinced that this is the right behavior. I'd have thought that unknown opcodes are essentially RFU, and any RFU fields are generally mandated to be ignored upon reception. So "not supported" is not quite the same as "unknown". Do you have some reference to the spec that says something about this?

Not sure how else we would handle new opcodes, if we just ignore we basically stall the request queue and no other request can be sent. Marcel had similar interpretation wich led us to change the behavior on BlueZ as well.

Do you have some reference to a section in the spec that this interpretation comes from?

BLUETOOTH SPECIFICATION Version 5.0 | Vol 3, Part F page 2179

If a server receives a request that it does not support, then the server shall
respond with the Error Response with the Error Code «Request Not
Supported», with the Attribute Handle In Error set to 0x0000.
If a server receives a command that it does not support, indicated by the
Command Flag of the PDU set to one, then the server shall ignore the
Command.

Note that the spec differentiate not supported request from commands, so only commands shall be ignored while request shall be replied. Now you can argue that request not supported is not exactly not understood, or something like that, still by not responding it will stall the request queue which inevitably will disconnect after 30 seconds and there is nowhere mentioned that an unknown PDU shall cause the server to disconnect. I don't know how likely it is to have any new requests introduced to ATT/GATT, but I guess it better to be safe than sorry if anything changes in the future.

BLUETOOTH SPECIFICATION Version 5.0 | Vol 3, Part F page 2173

A client may send attribute protocol requests to a server, and the server shall
respond to all requests that it receives.

Is it guaranteed that if the command flag is not set in an unrecognized PDU that it must then be a request PDU? There are more PDU types than requests and commands in ATT. Btw, I'm not saying that you're wrong (in that the patch would be better than not having it) but I still fail to see some unambiguous evidence for what's the right thing.

Oh, you'll want to rebase and reupload this one, since the rebase that was done for the bluetooth branch seems to have made github think this pull request contains multiple patches, when in reality it's just one.

Sure I will do this in a moment, regarding other types of PDUs honestly this seems an issue from the spec, though it is unlikely there will be new types of PDUs, other than notify and indicate. The spec also got inconsistent defining the notify and indicate PDUs, that should probably have its own mask like commands, instead the authors just jumped 0x1A and 0x1C.

This ensures that an unknown request won't cause ATT to timeout since no response is currently generated. Signed-off-by: Luiz Augusto von Dentz <[email protected]>

W25Q16FW Flash driver support Closes zephyrproject-rtos#6 See merge request blik/embedded/zephyr!11

Update code to boot on QEMU and UP Squared board

This makes the gatt metrics also available for gatt write-without-rsp-cb so it now prints the rate of each write: uart:~$ gatt write-without-response-cb 1e ff 10 10 Write #1: 16 bytes (0 bps) Write #2: 32 bytes (3445948416 bps) Write #3: 48 bytes (2596929536 bps) Write #4: 64 bytes (6400 bps) Write #5: 80 bytes (8533 bps) Write #6: 96 bytes (10666 bps) Write #7: 112 bytes (8533 bps) Write #8: 128 bytes (9955 bps) Write #9: 144 bytes (11377 bps) Write #10: 160 bytes (7680 bps) Write #11: 176 bytes (8533 bps) Write #12: 192 bytes (9386 bps) Write Complete (err 0) Write #13: 208 bytes (8533 bps) Write #14: 224 bytes (9244 bps) Write #15: 240 bytes (9955 bps) Write #16: 256 bytes (8000 bps) Signed-off-by: Luiz Augusto von Dentz <[email protected]>

This makes the gatt metrics also available for gatt write-without-rsp-cb so it now prints the rate of each write: uart:~$ gatt write-without-response-cb 1e ff 10 10 Write zephyrproject-rtos#1: 16 bytes (0 bps) Write zephyrproject-rtos#2: 32 bytes (3445948416 bps) Write zephyrproject-rtos#3: 48 bytes (2596929536 bps) Write zephyrproject-rtos#4: 64 bytes (6400 bps) Write zephyrproject-rtos#5: 80 bytes (8533 bps) Write zephyrproject-rtos#6: 96 bytes (10666 bps) Write zephyrproject-rtos#7: 112 bytes (8533 bps) Write zephyrproject-rtos#8: 128 bytes (9955 bps) Write zephyrproject-rtos#9: 144 bytes (11377 bps) Write zephyrproject-rtos#10: 160 bytes (7680 bps) Write zephyrproject-rtos#11: 176 bytes (8533 bps) Write zephyrproject-rtos#12: 192 bytes (9386 bps) Write Complete (err 0) Write zephyrproject-rtos#13: 208 bytes (8533 bps) Write zephyrproject-rtos#14: 224 bytes (9244 bps) Write zephyrproject-rtos#15: 240 bytes (9955 bps) Write zephyrproject-rtos#16: 256 bytes (8000 bps) Signed-off-by: Luiz Augusto von Dentz <[email protected]>

fix zephyr fs/sdcard issue

This makes the gatt metrics also available for gatt write-without-rsp-cb so it now prints the rate of each write: uart:~$ gatt write-without-response-cb 1e ff 10 10 Write #1: 16 bytes (0 bps) Write #2: 32 bytes (3445948416 bps) Write #3: 48 bytes (2596929536 bps) Write #4: 64 bytes (6400 bps) Write #5: 80 bytes (8533 bps) Write #6: 96 bytes (10666 bps) Write #7: 112 bytes (8533 bps) Write #8: 128 bytes (9955 bps) Write #9: 144 bytes (11377 bps) Write #10: 160 bytes (7680 bps) Write #11: 176 bytes (8533 bps) Write #12: 192 bytes (9386 bps) Write Complete (err 0) Write #13: 208 bytes (8533 bps) Write #14: 224 bytes (9244 bps) Write #15: 240 bytes (9955 bps) Write #16: 256 bytes (8000 bps) Signed-off-by: Luiz Augusto von Dentz <[email protected]>

…yrproject-rtos#6)

* Include HOSTAP_BASE to fix header file paths * Select WEP automatically through Kconfig Signed-off-by: Chaitanya Tata <[email protected]>

…v-6801 CP9314 v0.1.1

# This is the 1st commit message: posix: Tests for putmsg Add in tests for putmsg impl and headers Signed-off-by: Abhinav Srivastava <[email protected]> # This is the commit message zephyrproject-rtos#2: posix: Tests for putmsg Add tests for implentation and header file. Signed-off-by: Abhinav Srivastava <[email protected]> # This is the commit message zephyrproject-rtos#3: posix: fix stropts_h.c faulty imports and function usage # This is the commit message zephyrproject-rtos#4: posix: fix streams config symbol Makes more sense to use CONFIG_POSIX_STROPTS Signed-off-by: Abhinav Srivastava <[email protected]> # This is the commit message zephyrproject-rtos#5: Revert "posix: fix streams config symbol" This reverts commit aa03b70. Signed-off-by: Abhinav Srivastava <[email protected]> # This is the commit message zephyrproject-rtos#6: Update tests/posix/headers/src/stropts_h.c Co-authored-by: Chris Friedt <[email protected]>

Flush all messages and invoke `abort()` when a k_panic() or k_oops() is hit in native_posix mode. One of the main purposes of `native_posix` is to provide debug convenience. When running in a debugger, `abort()` stops execution which provides a backtrace and the ability to inspect all variables. A practical use case is fuzzing failures in SOF, see an example in: thesofproject/sof#8632 In such a case, this commit adds value even before using a debugger. Without this commit, confusingly meaningless stack trace: ``` INFO: seed corpus: files: 1097 min: 1b max: 428b total: 90853b rss: 58Mb Exiting due to fatal error ==314134== ERROR: libFuzzer: fuzz target exited #0 0x81d9637 in __sanitizer_print_stack_trace (zephyr.exe+0x81d9637) #1 0x80cc42b in fuzzer::PrintStackTrace() (zephyr.exe+0x80cc42b) zephyrproject-rtos#2 0x80ab79e in fuzzer::Fuzzer::ExitCallback() FuzzerLoop.cpp.o zephyrproject-rtos#3 0x80ab864 in fuzzer::Fuzzer::StaticExitCallback() (zephyr.exe+ zephyrproject-rtos#4 0xf783dfe8 (/usr/lib32/libc.so.6+0x3dfe8) zephyrproject-rtos#5 0xf783e1e6 in exit (/usr/lib32/libc.so.6+0x3e1e6) zephyrproject-rtos#6 0x82a5488 in posix_exit boards/posix/native_posix/main.c:51:2 SUMMARY: libFuzzer: fuzz target exited ``` Thanks to this commit the `k_panic()` location is immediately available in the logs without even running anything: ``` INFO: seed corpus: files: 1097 min: 1b max: 428b total: 90853b rss: 58Mb ==315176== ERROR: libFuzzer: deadly signal LLVMSymbolizer: error reading file: No such file or directory #0 0x81d9647 in __sanitizer_print_stack_trace (zephyr.exe+0x81d9647) #1 0x80cc43b in fuzzer::PrintStackTrace() (zephyr.exe+0x80cc43b) zephyrproject-rtos#2 0x80ab6be in fuzzer::Fuzzer::CrashCallback() FuzzerLoop.cpp.o zephyrproject-rtos#3 0x80ab77b in fuzzer::Fuzzer::StaticCrashSignalCallback() zephyrproject-rtos#4 0xf7f3159f (linux-gate.so.1+0x59f) zephyrproject-rtos#5 0xf7f31578 (linux-gate.so.1+0x578) zephyrproject-rtos#6 0xf788ea16 (/usr/lib32/libc.so.6+0x8ea16) zephyrproject-rtos#7 0xf783b316 in raise (/usr/lib32/libc.so.6+0x3b316) zephyrproject-rtos#8 0xf7822120 in abort (/usr/lib32/libc.so.6+0x22120) zephyrproject-rtos#9 0x82afbde in ipc_cmd src/ipc/ipc3/handler.c:1623:2 NOTE: libFuzzer has rudimentary signal handlers. Combine libFuzzer with AddressSanitizer or similar for better crash reports. SUMMARY: libFuzzer: deadly signal ``` Full stack trace When running zephyr.exe in gdb: ``` ./scripts/fuzz.sh -- -DEXTRA_CFLAGS="-O0 -g3" gdb ./zephyr.exe backtrace zephyrproject-rtos#2 0xf783b317 in raise () from /usr/lib32/libc.so.6 zephyrproject-rtos#3 0xf7822121 in abort () from /usr/lib32/libc.so.6 zephyrproject-rtos#4 0x082afbdf in ipc_cmd (_hdr=0x8b...) at src/ipc/ipc3/handler.c:1623 zephyrproject-rtos#5 0x082fbf4b in ipc_platform_do_cmd (ipc=0x8b161c0) at src/platform/posix/ipc.c:162 zephyrproject-rtos#6 0x082e1e07 in ipc_do_cmd (data=0x8b161c0 <heapmem+1472>) at src/ipc/ipc-common.c:328 zephyrproject-rtos#7 0x083696aa in task_run (task=0x8b161e8 <heapmem+1512>) at zephyr/include/rtos/task.h:94 zephyrproject-rtos#8 0x083682dc in edf_work_handler (work=0x8b1621c <heapmem+1564>) at zephyr/edf_schedule.c:32 zephyrproject-rtos#9 0x085245af in work_queue_main (workq_ptr=0x8b15b00 <edf_workq>,...) at zephyr/kernel/work.c:688 zephyrproject-rtos#10 0x0823a6bc in z_thread_entry (entry=0x8523be0 <work_queue_main>,.. at zephyr/lib/os/thread_entry.c:48 zephyrproject-rtos#11 0x0829a6a1 in posix_arch_thread_entry (pa_thread_status=0x8630648 .. at zephyr/arch/posix/core/thread.c:56 zephyrproject-rtos#12 0x0829c043 in posix_thread_starter (arg=0x4) at zephyr/arch/posix/core/posix_core.c:293 zephyrproject-rtos#13 0x080f6041 in asan_thread_start(void*) () zephyrproject-rtos#14 0xf788c73c in ?? () from /usr/lib32/libc.so.6 ``` Signed-off-by: Marc Herbert <[email protected]>

Flush all messages and invoke `abort()` when a k_panic() or k_oops() is hit in native_posix mode. One of the main purposes of `native_posix` is to provide debug convenience. When running in a debugger, `abort()` stops execution which provides a backtrace and the ability to inspect all variables. A good, sample use case is fuzzing failures in SOF, see an example in: thesofproject/sof#8632 In such a case, this commit adds value even before using a debugger. Without this commit, confusingly meaningless stack trace: ``` INFO: seed corpus: files: 1097 min: 1b max: 428b total: 90853b rss: 58Mb Exiting due to fatal error ==314134== ERROR: libFuzzer: fuzz target exited #0 0x81d9637 in __sanitizer_print_stack_trace (zephyr.exe+0x81d9637) #1 0x80cc42b in fuzzer::PrintStackTrace() (zephyr.exe+0x80cc42b) zephyrproject-rtos#2 0x80ab79e in fuzzer::Fuzzer::ExitCallback() FuzzerLoop.cpp.o zephyrproject-rtos#3 0x80ab864 in fuzzer::Fuzzer::StaticExitCallback() (zephyr.exe+ zephyrproject-rtos#4 0xf783dfe8 (/usr/lib32/libc.so.6+0x3dfe8) zephyrproject-rtos#5 0xf783e1e6 in exit (/usr/lib32/libc.so.6+0x3e1e6) zephyrproject-rtos#6 0x82a5488 in posix_exit boards/posix/native_posix/main.c:51:2 SUMMARY: libFuzzer: fuzz target exited ``` Thanks to this commit the `k_panic()` location is now immediately available in test logs without even running anything locally: ``` INFO: seed corpus: files: 1097 min: 1b max: 428b total: 90853b rss: 58Mb @ WEST_TOPDIR/sof/src/ipc/ipc3/handler.c:1623 ZEPHYR FATAL ERROR: 3 ==315176== ERROR: libFuzzer: deadly signal LLVMSymbolizer: error reading file: No such file or directory #0 0x81d9647 in __sanitizer_print_stack_trace (zephyr.exe+0x81d9647) #1 0x80cc43b in fuzzer::PrintStackTrace() (zephyr.exe+0x80cc43b) zephyrproject-rtos#2 0x80ab6be in fuzzer::Fuzzer::CrashCallback() FuzzerLoop.cpp.o zephyrproject-rtos#3 0x80ab77b in fuzzer::Fuzzer::StaticCrashSignalCallback() zephyrproject-rtos#4 0xf7f3159f (linux-gate.so.1+0x59f) zephyrproject-rtos#5 0xf7f31578 (linux-gate.so.1+0x578) zephyrproject-rtos#6 0xf788ea16 (/usr/lib32/libc.so.6+0x8ea16) zephyrproject-rtos#7 0xf783b316 in raise (/usr/lib32/libc.so.6+0x3b316) zephyrproject-rtos#8 0xf7822120 in abort (/usr/lib32/libc.so.6+0x22120) zephyrproject-rtos#9 0x82afbde in ipc_cmd src/ipc/ipc3/handler.c:1623:2 NOTE: libFuzzer has rudimentary signal handlers. Combine libFuzzer with AddressSanitizer or similar for better crash reports. SUMMARY: libFuzzer: deadly signal ``` The full stack trace is now immediately available when running zephyr.exe in gdb: ``` ./scripts/fuzz.sh -- -DEXTRA_CFLAGS="-O0 -g3" gdb build-fuzz/zephyr/zephyr.exe run backtrace zephyrproject-rtos#2 0xf783b317 in raise () from /usr/lib32/libc.so.6 zephyrproject-rtos#3 0xf7822121 in abort () from /usr/lib32/libc.so.6 zephyrproject-rtos#4 0x082afbdf in ipc_cmd (_hdr=0x8b...) at src/ipc/ipc3/handler.c:1623 zephyrproject-rtos#5 0x082fbf4b in ipc_platform_do_cmd (ipc=0x8b161c0) at src/platform/posix/ipc.c:162 zephyrproject-rtos#6 0x082e1e07 in ipc_do_cmd (data=0x8b161c0 <heapmem+1472>) at src/ipc/ipc-common.c:328 zephyrproject-rtos#7 0x083696aa in task_run (task=0x8b161e8 <heapmem+1512>) at zephyr/include/rtos/task.h:94 zephyrproject-rtos#8 0x083682dc in edf_work_handler (work=0x8b1621c <heapmem+1564>) at zephyr/edf_schedule.c:32 zephyrproject-rtos#9 0x085245af in work_queue_main (workq_ptr=0x8b15b00 <edf_workq>,...) at zephyr/kernel/work.c:688 zephyrproject-rtos#10 0x0823a6bc in z_thread_entry (entry=0x8523be0 <work_queue_main>,.. at zephyr/lib/os/thread_entry.c:48 zephyrproject-rtos#11 0x0829a6a1 in posix_arch_thread_entry (pa_thread_status=0x8630648 .. at zephyr/arch/posix/core/thread.c:56 zephyrproject-rtos#12 0x0829c043 in posix_thread_starter (arg=0x4) at zephyr/arch/posix/core/posix_core.c:293 zephyrproject-rtos#13 0x080f6041 in asan_thread_start(void*) () zephyrproject-rtos#14 0xf788c73c in ?? () from /usr/lib32/libc.so.6 ``` Signed-off-by: Marc Herbert <[email protected]>

David/fix cfun

* services: add RemoteHW-Deploy w/ snapshot of zephyrtest-blue * update target directory

hci_packet_complete(buf, buf_size) should check whether buf_size is enough. For instance, hci_packet_complete can receive buf with buf_size 1, leading to the buffer overflow in cmd->param_len, which is buf[3]. This can happen when rx_thread() receives two frames in over 512 bytes and the first frame size is 511. Then, rx_thread() will call hci_packet_complete() with 1. ==5==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000000ad81c2 at pc 0x0000005279b3 bp 0x7fffe74f5b70 sp 0x7fffe74f5b68 READ of size 2 at 0x000000ad81c2 thread T6 #0 0x5279b2 (/root/zephyr.exe+0x5279b2) zephyrproject-rtos#1 0x4d697d (/root/zephyr.exe+0x4d697d) zephyrproject-rtos#2 0x7ffff60e5daa (/lib/x86_64-linux-gnu/libc.so.6+0x89daa) (BuildId: 2e01923fea4ad9f7fa50fe24e0f3385a45a6cd1c) 0x000000ad81c2 is located 2 bytes to the right of global variable 'rx_thread.frame' defined in '/mnt/hdd1/sungwoo/zephyr-afl/zephyr/drivers/bluetooth/hci/userchan.c' (0xad7fc0) of size 512 SUMMARY: AddressSanitizer: global-buffer-overflow (/root/zephyr.exe+0x5279b2) Thread T6 created by T2 here: #0 0x48c17c (/root/zephyr.exe+0x48c17c) zephyrproject-rtos#1 0x530192 (/root/zephyr.exe+0x530192) zephyrproject-rtos#2 0x4dcc22 (/root/zephyr.exe+0x4dcc22) Thread T2 created by T1 here: #0 0x48c17c (/root/zephyr.exe+0x48c17c) zephyrproject-rtos#1 0x530192 (/root/zephyr.exe+0x530192) zephyrproject-rtos#2 0x4dcc22 (/root/zephyr.exe+0x4dcc22) Thread T1 created by T0 here: #0 0x48c17c (/root/zephyr.exe+0x48c17c) zephyrproject-rtos#1 0x52f36c (/root/zephyr.exe+0x52f36c) zephyrproject-rtos#2 0x5371dc (/root/zephyr.exe+0x5371dc) zephyrproject-rtos#3 0x5312a6 (/root/zephyr.exe+0x5312a6) zephyrproject-rtos#4 0x52ed7b (/root/zephyr.exe+0x52ed7b) zephyrproject-rtos#5 0x52eddd (/root/zephyr.exe+0x52eddd) zephyrproject-rtos#6 0x7ffff6083c89 (/lib/x86_64-linux-gnu/libc.so.6+0x27c89) (BuildId: 2e01923fea4ad9f7fa50fe24e0f3385a45a6cd1c) ==5==ABORTING Signed-off-by: Sungwoo Kim <[email protected]>

Vudentz force-pushed the bluetooth branch from c380d62 to cf9565c Compare April 28, 2017 12:08

zephyr-github force-pushed the bluetooth branch from 9ed8923 to 1914fc3 Compare April 28, 2017 13:06

Vudentz force-pushed the bluetooth branch from cf9565c to dd945db Compare April 28, 2017 13:18

jhedberg reviewed Apr 28, 2017

View reviewed changes

jhedberg self-assigned this May 1, 2017

jhedberg force-pushed the bluetooth branch from 1914fc3 to e588ca0 Compare May 1, 2017 12:55

Bluetooth: ATT: Respond with not support error for unknown PDUs

721ef08

This ensures that an unknown request won't cause ATT to timeout since no response is currently generated. Signed-off-by: Luiz Augusto von Dentz <[email protected]>

Vudentz force-pushed the bluetooth branch from dd945db to 721ef08 Compare May 1, 2017 14:44

Vudentz changed the base branch from bluetooth to core May 2, 2017 07:14

Vudentz changed the base branch from core to master May 2, 2017 07:15

jhedberg approved these changes May 2, 2017

View reviewed changes

nashif merged commit 024de97 into zephyrproject-rtos:master May 2, 2017

pizi-nordic mentioned this pull request Apr 30, 2018

Logging Subsystem Enhancements #6186

Closed

10 tasks

magilus mentioned this pull request Feb 3, 2019

Dead loop of the kernel during Bluetooth Mesh pressure communication #12726

Closed

frasa added a commit to blik-GmbH/zephyr that referenced this pull request Mar 25, 2019

Merge branch 'feat-w25q16fw-flash-driver-support' into 'dev'

3ebf6ef

W25Q16FW Flash driver support Closes zephyrproject-rtos#6 See merge request blik/embedded/zephyr!11

This was referenced Jun 13, 2019

kernel timeout_list repeatedly add a thread #16793

Closed

Bluetooth: Mesh: Rx buffer exhaustion causes deadlock #16864

Closed

xiaoliang314 mentioned this pull request Jun 26, 2019

Bluetooth: Fix various deadlock issues when running low on buffers #16870

Closed

finikorg pushed a commit to finikorg/zephyr that referenced this pull request Aug 16, 2019

Merge pull request zephyrproject-rtos#6 from dcpleung/sof_zephyr

4a6dd9c

Update code to boot on QEMU and UP Squared board

dcpleung mentioned this pull request Aug 22, 2019

Dynamic interrupt does not work with multi-level interrupts #18570

Closed

lgl88911 pushed a commit to lgl88911/zephyr that referenced this pull request Jun 25, 2020

Merge pull request zephyrproject-rtos#6 from madmachineio/fs_issue_fix

72afaed

fix zephyr fs/sdcard issue

anchao mentioned this pull request Jul 30, 2020

Bluetooth: Mesh: Fix tx seg buffer with NULL pointer reference #27251

Merged

github-actions bot mentioned this pull request Feb 10, 2021

provide support for the ST S2LP 802.15.4 Radio #16086

Closed

12 tasks

RafaelLeeImg mentioned this pull request Jan 19, 2022

Kernel usage fault when using semaphore with multi-threading #41963

Closed

piotrParf mentioned this pull request Feb 9, 2022

BLE Testing functions do not work properly #42534

Closed

yroeht mentioned this pull request Oct 10, 2022

aarch32: use vector base address register for v7-A #51035

Closed

sjanc mentioned this pull request May 16, 2023

Assert when executing GATT/SR/GAW/BV-14-C test #57930

Closed

pkunieck pushed a commit to pkunieck/zephyr that referenced this pull request Jul 18, 2023

Simplify the container API usage, allows one-line workflow call (zeph…

90511ed

…yrproject-rtos#6)

rriveramcrus pushed a commit to CirrusLogic/zephyr-drivers that referenced this pull request Sep 19, 2023

Merge pull request zephyrproject-rtos#6 from Cirrus-Logic-Software/dr…

a78fbb4

…v-6801 CP9314 v0.1.1

talih0 mentioned this pull request Dec 13, 2023

subsys: shell_telent: don't close connection on EAGAIN #66287

Merged

sreeramIfx mentioned this pull request Apr 12, 2024

Compilation error with ARM Compiler 6 #71416

Closed

lgl88911 mentioned this pull request May 18, 2024

Linking picolibc's srand to esp32c3 causes startup fault #69708

Closed

ldenefle pushed a commit to ldenefle/zephyr that referenced this pull request Jun 20, 2024

Merge pull request zephyrproject-rtos#6 from converge-io/david/fix_cfun

4905530

David/fix cfun

zephyrbot mentioned this pull request Jun 27, 2024

manifest: update cmsis-nn to v6.0.0 & tflite-micro #73995

Merged

LukaszMrugala pushed a commit to LukaszMrugala/zephyr that referenced this pull request Jul 3, 2024

services: create remoteHW-deploy (zephyrproject-rtos#6)

6eb7640

* services: add RemoteHW-Deploy w/ snapshot of zephyrtest-blue * update target directory

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Bluetooth: ATT: Respond with not support error for unknown PDUs #6

Bluetooth: ATT: Respond with not support error for unknown PDUs #6

Vudentz commented Apr 28, 2017 •

edited by galak

Loading

jhedberg Apr 28, 2017

Vudentz Apr 28, 2017

jhedberg May 1, 2017

Vudentz May 1, 2017

Vudentz May 1, 2017

jhedberg May 1, 2017

jhedberg May 1, 2017

Vudentz May 1, 2017

Bluetooth: ATT: Respond with not support error for unknown PDUs #6

Bluetooth: ATT: Respond with not support error for unknown PDUs #6

Conversation

Vudentz commented Apr 28, 2017 • edited by galak Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Vudentz commented Apr 28, 2017 •

edited by galak

Loading