SDK สำหรับ TESAIoT Dev Kit
คู่มืออ้างอิง API และ Tutorial (ModusToolbox)
Loading...
Searching...
No Matches

Variables

const uint8_t nus_gatt_database []
 blob ฐานข้อมูล GATT ที่อัดแน่นระดับไบต์ ซึ่งส่งให้ wiced_bt_gatt_db_init()
const uint16_t nus_gatt_database_len
 ความยาวของ blob เป็นไบต์ ส่งไปคู่กับตัว blob
const uint8_t NUS_UUID_SERVICE [16]
 UUID ของบริการขนาด 128 บิต (6E400001-B5A3-F393-E0A9-E50E24DCCA9E) เรียงไบต์ตามที่ส่งออกอากาศ
const uint8_t NUS_UUID_CHAR_RX [16]
 UUID ของ characteristic RX (6E400002-... จาก host ไปยังอุปกรณ์) ไม่มีที่ใดอ้างถึงในฐานะ symbol.
const uint8_t NUS_UUID_CHAR_TX [16]
 UUID ของ characteristic TX (6E400003-... จากอุปกรณ์ไปยัง host แบบ notify) มีสถานะเดียวกับ RX.

Detailed Description

ห้า symbol: blob ฐานข้อมูล GATT ความยาวของมัน และ UUID ของ NUS 3 ตัว คอมไพล์เฉพาะเมื่อ ENABLE_PAGE_BENTO_BUDDY=1 (ค่าตั้งต้นคือ 0, proj_cm33_ns/Makefile:64, :305) ให้ build ใหม่หลังจาก make getlibs — ดู Flag gate (อ่านก่อน)

การประกาศ: nus_gatt_db.h (header ที่ส่งมอบจริงประกาศทั้ง 5 ตัวเป็น extern ส่วน bento_secure_undeclared.h ที่เครื่องสร้างขึ้นระบุทั้ง 5 ตัวไว้ว่า "no declaration found" — การประกาศที่ควรใช้คือ nus_gatt_db.h) ตัวนิยามอยู่ใน nus_gatt_db.c ซึ่งถูกเก็บไว้ใน libbento_secure.a ทั้ง 5 ตัวนี้เป็น symbol ของข้อมูล ไม่ใช่ฟังก์ชัน: จำนวนที่นับได้ดิบ ๆ ด้วย grep คือจำนวนการประกาศ ส่วนจำนวนที่แก้ให้ถูกแล้วด้านล่างเป็นค่าที่ตรวจด้วยมือ handle ของ attribute เรียงต่อเนื่องกันที่ 0x01..0x0F (AIROC บางรุ่นปฏิเสธเมื่อมีช่องว่าง)

สิทธิ์ของ GATT ไม่ได้บังคับให้จับคู่ ฐานข้อมูลกำหนดให้ RX เป็น GATTDB_PERM_WRITE_CMD | GATTDB_PERM_WRITE_REQ, TX เป็น GATTDB_PERM_READABLE และ CCCD เป็น GATTDB_PERM_READABLE | GATTDB_PERM_WRITE_REQ โดยไม่มีบิต GATTDB_PERM_AUTH_* บนทั้งสามรายการ ตรวจจาก archive ที่ส่งมอบจริงได้ผลเดียวกัน: ใน libbento_secure.a สมาชิก bento_core_11.o ส่วน .rodata ของ handle 0x0C, 0x0E และ 0x0F มีค่าสิทธิ์เป็น 0x8C, 0x82 และ 0x0A ซึ่งไม่ปรากฏทั้ง AUTH_WRITABLE (0x40) และ AUTH_READABLE (0x10) (ตรวจเมื่อ 2026-08-29) ผลคือ peer ที่ยังไม่ได้จับคู่สามารถเขียน RX อ่าน TX และเปิด notification ได้ และจะไม่ได้รับ Insufficient Authentication

การจับคู่ที่ใช้จริงเป็นแบบ Just Works ble_nus.c กำหนด local_io_cap = BTM_IO_CAPABILITIES_NONE (NoInputNoOutput) และ auth_req = BTM_LE_AUTH_REQ_SC_BOND ซึ่งไม่มีบิต MITM ผลคือ link ถูกเข้ารหัสเพียงพอที่จะกันการดักฟังแบบ passive แต่ไม่มีการป้องกันผู้โจมตีแบบ MITM ที่ลงมือจริง และไม่มีการแสดง passkey ใด ๆ ทั้งการโฆษณา (advertising) ก็เปิดรับ central ทุกตัว ส่วนข้อมูลการผูกอุปกรณ์ (bonding) เก็บไว้ใน RAM เท่านั้น จึงหายไปทุกครั้งที่บูตใหม่

สิ่งที่จำกัดความเสี่ยงไว้ โมดูลนี้ไม่ได้ถูกคอมไพล์ตามค่าตั้งต้น ทั้งหมดถูกคุมด้วย ENABLE_PAGE_BENTO_BUDDY ซึ่งมีค่าเป็น 0 ในเทมเพลตทั้งสองแบบ (และถูกกำหนดเป็น 0 แบบตายตัวที่ bsps/TARGET_KIT_PSE84_AI/bsp_features.mk:90) ภาพเฟิร์มแวร์สำเร็จรูปทั้งสามคอร์ไม่มี symbol nus_, ble_nus_ หรือ wiced_bt_ แม้แต่ตัวเดียว (ตรวจเมื่อ 2026-08-30) วิทยุจึงไม่ถูกเปิดใช้เลย ข้อความข้างต้นจะมีผลก็ต่อเมื่อเปิดแฟล็กนี้เท่านั้น

โหมด DisplayOnly พร้อม passkey 6 หลักบน LE Secure Connections เป็นสิ่งที่ตั้งใจไว้ แต่ยังไม่ได้พัฒนา (ดู แกนกลางและการส่งของ NUS) เมื่อรวมกับการที่ชั้น GATT ไม่ได้เรียกร้องการจับคู่ก่อน จึงต้องถือว่า link นี้ยังไม่ผ่านการพิสูจน์ตัวตน และต้องวางการตรวจสอบสิทธิ์ไว้ที่ชั้นคำสั่ง ไม่ใช่ที่ชั้น GATT

variant ที่ใช้ได้
mtb-mpy และ mtb-only

Variable Documentation

◆ nus_gatt_database

const uint8_t nus_gatt_database[]
extern

blob ฐานข้อมูล GATT ที่อัดแน่นระดับไบต์ ซึ่งส่งให้ wiced_bt_gatt_db_init()

ข้อกำหนดการเรียกใช้
blob ฐานข้อมูล GATT ที่อัดแน่นระดับไบต์ ซึ่งส่งให้ wiced_bt_gatt_db_init() ต้องรักษาให้ตรงกับ enum nus_attr_handle ใน nus_gatt_db.h ตลอดเวลา ที่ใช้จริงมีเพียงแห่งเดียวคือภายใน ble_nus_init() call site ในเทมเพลต: 0 call site ใน archive อยู่ที่ ble_nus.c:630 (wiced_bt_gatt_db_init(nus_gatt_database, nus_gatt_database_len, NULL); ตัวนิยามอยู่ที่ nus_gatt_db.c:83 คอมไพล์รวมอยู่ใน libbento_secure.a ไม่ได้ส่งมอบมาเป็นซอร์ส)
variant ที่ใช้ได้
mtb-mpy และ mtb-only

◆ nus_gatt_database_len

const uint16_t nus_gatt_database_len
extern

ความยาวของ blob เป็นไบต์ ส่งไปคู่กับตัว blob

ข้อกำหนดการเรียกใช้
ความยาวของ blob เป็นไบต์ ส่งไปคู่กับตัว blob call site ในเทมเพลต: 0 call site ใน archive อยู่ที่ ble_nus.c:629-630 (พิมพ์เป็น log ในรูป (unsigned)nus_gatt_database_len แล้วจึงส่งต่อให้ wiced_bt_gatt_db_init ตัวนิยามอยู่ที่ nus_gatt_db.c:165 คอมไพล์รวมอยู่ใน libbento_secure.a ไม่ได้ส่งมอบมาเป็นซอร์ส)
variant ที่ใช้ได้
mtb-mpy และ mtb-only

◆ NUS_UUID_SERVICE

const uint8_t NUS_UUID_SERVICE[16]
extern

UUID ของบริการขนาด 128 บิต (6E400001-B5A3-F393-E0A9-E50E24DCCA9E) เรียงไบต์ตามที่ส่งออกอากาศ

ข้อกำหนดการเรียกใช้
UUID ของบริการขนาด 128 บิต เรียงไบต์ตามที่ส่งออกอากาศ (6E400001-B5A3-F393-E0A9-E50E24DCCA9E แบบ little-endian) ที่ใช้จริงมีเพียงแห่งเดียวคือ payload ของ scan response call site ในเทมเพลต: 0 call site ใน archive อยู่ที่ ble_nus.c:684 (srsp[0].p_data = (uint8_t *)NUS_UUID_SERVICE; ตัวนิยามอยู่ที่ nus_gatt_db.c:48 คอมไพล์รวมอยู่ใน libbento_secure.a ไม่ได้ส่งมอบมาเป็นซอร์ส)
variant ที่ใช้ได้
mtb-mpy และ mtb-only

◆ NUS_UUID_CHAR_RX

const uint8_t NUS_UUID_CHAR_RX[16]
extern

UUID ของ characteristic RX (6E400002-... จาก host ไปยังอุปกรณ์) ไม่มีที่ใดอ้างถึงในฐานะ symbol.

ข้อกำหนดการเรียกใช้
ไม่มีที่ใดอ้างถึงในฐานะ symbol ในทรีใดเลย: ไบต์ 16 ตัวชุดเดียวกันถูกวางดิบ ๆ ไว้ใน nus_gatt_database[] แล้ว (nus_gatt_db.c:83) extern มีอยู่เพื่อเครื่องมือและการทดสอบฝั่ง host ไม่มีเส้นทางโค้ดใดในเฟิร์มแวร์ที่ต้องใช้มัน ตัวอย่างที่เขียนขึ้นเองแสดงงานที่ชอบธรรมเพียงงานเดียวของมัน — คือการหาตำแหน่งของ characteristic ภายใน blob
variant ที่ใช้ได้
mtb-mpy และ mtb-only
ตัวอย่าง (เขียนขึ้นเอง — ไม่มี call site ในของที่ส่งมอบจริง)
static void bento_ex_nus_uuid_char_rx(void)
{
/* Scan the byte-packed GATT DB for the RX characteristic's UUID —
* the only place the bytes actually live in firmware. */
const uint8_t *found = NULL;
for (uint16_t i = 0; i + 16u <= nus_gatt_database_len; i++) {
if (memcmp(&nus_gatt_database[i], NUS_UUID_CHAR_RX, 16u) == 0) {
found = &nus_gatt_database[i]; /* decl or value entry */
break;
}
}
if (found == NULL) {
/* DB and header drifted out of lock-step — a bug worth failing
* a host-side test over. */
}
}

◆ NUS_UUID_CHAR_TX

const uint8_t NUS_UUID_CHAR_TX[16]
extern

UUID ของ characteristic TX (6E400003-... จากอุปกรณ์ไปยัง host แบบ notify) มีสถานะเดียวกับ RX.

ข้อกำหนดการเรียกใช้
มีสถานะเดียวกับ NUS_UUID_CHAR_RX: ถูกอ้างถึงในรูปไบต์ดิบภายใน nus_gatt_database[] เท่านั้น ไม่มีเส้นทางโค้ดใดในเฟิร์มแวร์ที่ใช้ symbol ตัวนี้
variant ที่ใช้ได้
mtb-mpy และ mtb-only
ตัวอย่าง (เขียนขึ้นเอง — ไม่มี call site ในของที่ส่งมอบจริง)
static void bento_ex_nus_uuid_char_tx(void)
{
/* A 16-byte UUID as it arrives from a discovery log / sniffer —
* little-endian on-air order on both sides, so identification is a
* straight compare: */
uint8_t uuid_le[16];
memcpy(uuid_le, NUS_UUID_CHAR_TX, sizeof(uuid_le));
bool is_tx = (memcmp(uuid_le, NUS_UUID_CHAR_TX, 16u) == 0);
(void)is_tx; /* true: notify-side characteristic */
}