Riot: IEEE802.15.4: HW Auto ACK dianggap berbahaya

Dalam kebanyakan kasus, praktik ini bisa berbahaya.

Berbicara secara realistis, seberapa sering hal ini menyebabkan bahaya yang sebenarnya? Berapa persentase pesan yang diterima saat benar-benar dibuang oleh MCU?

Radio beralih ke mode TX saat menerima (#11256)

Kasing ini unik untuk radio dengan buffer penerima/pemancar bersama, bukan? Jadi hanya mempengaruhi kelas perangkat at86rf2xx

Ini bisa menghasilkan perilaku aneh,…

Apakah Anda memiliki beberapa contoh di mana ini menyebabkan masalah?

Jadi, saya mengusulkan untuk membiarkan ACK Otomatis sebagai opsional dan menerapkan respons ACK dalam perangkat lunak

Apakah Anda memiliki beberapa angka tentang dampak ini? Ukuran flash/penggunaan RAM, tetapi juga penggunaan daya karena MCU harus bangun lebih lama. Juga berapa banyak waktu yang ada antara penerimaan bingkai dan batas waktu ack dan apakah realistis untuk menangani perangkat lunak ACK jika radio terhubung melalui SPI?

Selain memiliki L2 yang lebih andal

Saya agak skeptis tentang klaim ini (jika itu belum jelas dari komentar saya), menangani serangan L2 adalah kasus real-time yang lembut (tenggat waktu yang hilang akan menurunkan layanan) dan menanganinya dalam perangkat lunak menempatkan persyaratan yang sulit pada perilaku RIOT secara real-time.

Saya tidak keberatan perangkat lunak L2 menyerang jika itu adalah persyaratan yang sulit untuk beberapa lapisan MAC tertentu, tetapi itu tidak disebutkan dari deskripsi di sini.

Hai @bergzand

Berbicara secara realistis, seberapa sering hal ini menyebabkan kerusakan yang sebenarnya? Berapa persentase pesan yang diterima saat benar-benar dibuang oleh MCU?

Untuk lapisan atas itu bukan masalah besar (mengingat mereka biasanya upaya terbaik).
Namun, beberapa lapisan MAC dan sub-MAC (OpenThread, TSCH) menggunakan ACK untuk memperbarui informasi tetangga.

Kasing ini unik untuk radio dengan buffer penerima/pemancar bersama, bukan? Jadi hanya mempengaruhi kelas perangkat at86rf2xx

Benar. Saya hanya menunjukkan skenario di mana ini mungkin terjadi.

Apakah Anda memiliki beberapa contoh di mana ini menyebabkan masalah?

Memberikan informasi yang salah kepada pengguna lapisan MAC (misalnya Pembuatan Tautan Mesh) mungkin akan mempengaruhi kualitas tautan. Saya sadar meskipun kami belum memiliki hal seperti itu di RIOT (dan tumpukan yang menggunakannya sudah mengimplementasikan fitur tersebut).

Apakah Anda memiliki beberapa angka tentang dampak ini? Ukuran flash/penggunaan RAM, tetapi juga penggunaan daya karena MCU harus bangun lebih lama. Juga berapa banyak waktu yang ada antara penerimaan bingkai dan batas waktu ack dan apakah realistis untuk menangani perangkat lunak ACK jika radio terhubung melalui SPI?

Sayangnya tidak. Karena tidak diterapkan, saya tidak punya angka untuk dibandingkan. Saya hanya memiliki beberapa cabang pengujian dengan ACK otomatis, tetapi saya tidak menguji lebih dalam.

Saya agak skeptis tentang klaim ini (jika itu belum jelas dari komentar saya), menangani serangan L2 adalah kasus real-time yang lembut (tenggat waktu yang hilang akan menurunkan layanan) dan menanganinya dalam perangkat lunak menempatkan persyaratan yang sulit pada perilaku RIOT secara real-time.

Ada beberapa informasi dari Tiny OS bahwa software ACK cenderung memiliki penurunan yang lebih tinggi (https://vs-git.informatik.uni-kl.de/engel/tinyos/blob/020c6a6d8cc542bf58ca6afb8b1bf24efbe381de/doc/txt/tep126.txt) tetapi setidaknya tidak ada positif palsu.
AFAIK IEEE802.15.4 tidak berbicara tentang batasan keras (hanya tentang nilai batas waktu). Jika paket ACK tidak terkirim tepat waktu, paket tersebut dianggap hilang. Tetapi seperti yang dikatakan sebelumnya, saya tidak memiliki informasi tentang seberapa baik kinerja OS dengan ACK perangkat lunak. Akan menarik untuk memiliki beberapa tolok ukur

Saya tidak keberatan perangkat lunak L2 menyerang jika itu adalah persyaratan yang sulit untuk beberapa lapisan MAC tertentu, tetapi itu tidak disebutkan dari deskripsi di sini.

Kami tetap perlu mengimplementasikan perangkat lunak ACK untuk radio yang tidak mendukung ACK Otomatis dan fitur yang tidak tersedia di akselerator perangkat keras (sejujurnya saya tidak mengetahui radio yang mendukung ACK yang Ditingkatkan).
Pertanyaannya adalah, apakah kita ingin ini menjadi opsional atau wajib untuk konfigurasi default kita? Seperti yang dijelaskan sebelumnya, idenya bukan untuk menghapus dukungan ACK Otomatis tetapi untuk mendapatkan dukungan L2 yang lebih baik. Kami masih dapat mengaktifkan ACK Otomatis jika kami mau (itulah sebabnya saya mengusulkan untuk menambahkan topi radio di https://github.com/RIOT-OS/RIOT/pull/11473)

Mungkin saya salah tetapi solusinya tampak sederhana:

• Kami menerapkan ARQ (hardware independent) -> kami menginginkannya terlepas dari diskusi ini.
• Kami membandingkan kinerja (dan interoperabilitas) implementasi perangkat keras vs perangkat lunak.
• Kami merancang untuk pengaturan default khusus platform, yang tidak mencegah kompilasi yang lain.

Sebagai simpul samping: Fakta bahwa kami tidak pernah menghadapi masalah yang disorot oleh @jia200x dapat dikaitkan dengan hilangnya lapisan MAC di atas radio di RIOT. Selain itu, dengan radio lossy berdaya rendah, kami tetap mentolerir kerugian tertentu.

Seberapa penting ACK perangkat lunak untuk 6TiSCH? IIRC, OpenWSN menggunakan perangkat lunak ACK sebagian untuk melacak kualitas tautan antar tetangga.

Seberapa penting ACK perangkat lunak untuk 6TiSCH? IIRC, OpenWSN menggunakan perangkat lunak ACK sebagian untuk melacak kualitas tautan antar tetangga.

6TiSCH tidak menentang ACK perangkat keras, tetapi memerlukan ACK yang Ditingkatkan untuk menyampaikan informasi waktu. Di OpenWSN, ini ditangani oleh pkg itu sendiri.

*dan ACK yang Ditingkatkan tidak didukung oleh perangkat keras yang saya ketahui.

Selain itu, masalah dengan kemampuan pengakuan perangkat keras dalam beberapa kasus adalah bahwa ia bertanggung jawab penuh atas mekanisme tanpa harus mengungkapkan informasi yang relevan, seperti ACK yang diterima atau jumlah percobaan ulang. Dengan 6TiSCH Anda dapat mengirimkan ulang sebuah frame di sel lain, yang memerlukan informasi semacam ini. Jadi, OpenWSN mendasarkan pada kumpulan fitur perangkat radio terbatas dan mengimplementasikan semua komponen MAC lainnya dalam perangkat lunak.

Masalah ini secara otomatis ditandai sebagai basi karena tidak ada aktivitas terbaru. Ini akan ditutup jika tidak ada aktivitas lebih lanjut yang terjadi. Jika Anda ingin saya mengabaikan masalah ini, tandai dengan label "Negara: jangan basi". Terima kasih atas kontribusi Anda.