Lorawan-stack: Integrasi Stasiun Dasar: Kondisi balapan dalam penanganan koneksi ulang menyebabkan kegagalan permanen penerusan uplink

Dengan pembaruan terkini, batas waktu tampaknya telah diubah dari 60 detik menjadi 600 detik. Tetapi masalah yang mendasarinya tetap ada dan dapat direproduksi secara andal dengan langkah-langkah di atas.

Saya akan mencoba untuk mensimulasikan ini dan mengubah pengaturan Proxy untuk melihat di mana masalahnya. Tetapi harus dicatat bahwa ini tampaknya hanya mempengaruhi sebagian dari gateway.
Dalam grafik berikut, tepi naik dari lonjakan dalam pesan status sesuai dengan jendela siaga 600-an. Setiap kali gateway terhubung kembali, kami mencatat pesan status tunggal (yang menyebabkan lonjakan ini). Tetapi jika Anda melihat lalu lintas, penurunannya sedikit tetapi tidak cukup drastis untuk menunjukkan adanya masalah dengan semua gateway:

Hai Krishna, masalah ini tidak terkait dengan pemutusan sisi server tetapi pada cara server menangani pemutusan sisi klien yang tidak bersih dengan segera menyambungkan kembali. Masalah ini memengaruhi semua gateway berbasis Stasiun Dasar dan dapat direproduksi secara andal dengan instruksi di atas.

Pola kesalahannya seperti ini:

• Perangkat memutuskan koneksi dengan tidak jelas (siklus daya, hard reset, penurunan WiFi, cabut / plugin TTIG, dll.)
• Perangkat segera terhubung kembali
• Selama 600 detik setelah putuskan (nomor ini dulu 60 detik) paket yang diteruskan terlihat di LNS
• Setelah 600 detik dan setelahnya, paket yang diteruskan TIDAK terlihat di LNS

Meningkatkan batas waktu dari 60-an menjadi 600-an membuat masalah menjadi lebih parah: Dengan 60-an, pengguna, yang mencabut TTIG-nya hanya harus menunggu selama 60-an sebelum memasangnya kembali untuk menghindari masalah. Ini mungkin cukup sering terjadi terutama ketika orang melakukan reset pabrik. Sekarang dengan 600-an, persentase yang lebih besar akan mengalami masalah, yang juga dapat diamati.

Apakah menyakitkan untuk menonaktifkan waktu tunggu ini sama sekali? Basic Station tidak TCP tetap hidup secara default (https://github.com/lorabasics/basicstation/blob/c29b8502f8c715daecec6666835da6e981dc820a/src/sys.c#L637). Bukankah itu cukup untuk memeriksa keaktifan koneksi?

Bagi saya sepertinya kebiasaan error juga, ketika provider memutuskan koneksi internet Anda dan Anda mendapatkan IP baru di reconnect :(
Saat ini setiap hari TTIG Gateway saya tidak lagi berfungsi, dan ketika saya menunjukkan ke dalam log dari aplikasi saya, nilai terakhir yang saya terima singkat sebelum koneksi diputus dan kemudian disambungkan kembali.
Untuk menjalankan gateway lagi, saya harus mencabutnya, menunggu sebentar lalu menyambungkannya lagi.

Tetapi perilaku ini hanya terjadi sejak 29.01, sebelumnya ini tidak pernah menjadi masalah.

@JackGruber dapatkah Anda mengonfirmasi bahwa Anda juga dapat menerima uplink dengan baik selama 600 detik pertama setelah koneksi internet terputus? (Tepatnya: 600 detik, dikurangi waktu yang diperlukan modem dan gateway untuk terhubung kembali sepenuhnya.)

Atau jika Anda tidak melihat uplink apa pun dalam 600 detik tersebut: seberapa sering perangkat Anda melakukan transmisi? (Dengan kata lain: apakah Anda berharap menerima beberapa uplink selama 600 detik itu?)

Perangkat yang saya pantau memancarkan setiap 5 menit.

02:42 Rangka RX
02:47 Rangka RX
02:53 Rangka RX
02:56 Hubungkan kembali
02:58 Rangka RX
tanpa bingkai
07:30 Cabut / pasang kembali TTIG
07:36 Rangka RX

Mempertimbangkan 600 detik setelah koneksi ulang 2:56, saya rasa setelah uplink 2:58 orang mungkin juga mengharapkan uplink 3:03 (yang masih sebelum 2:56 ditambah 600 detik = 3:06). Tapi mungkin batas waktu 600 detik disetel ulang setelah uplink 2:53 (daripada setelah beberapa pesan keep-hidup / status), membuat TTN keliru menghapus konteks / status tepat saat uplink 3:03 harus diterima. (Dan tentu saja, uplink mungkin tidak diterima karena alasan lain juga.)

Selain itu, semua baik-baik saja saat memulai ulang TTIG pada pukul 7:30, dan kemudian tidak mengalami masalah lagi 600 detik setelah itu, tampaknya mengkonfirmasi analisis ( hebat ) oleh @beitler , yang mengasumsikan bahwa TTN secara keliru menghapus beberapa konteks / status bersama di sekitar 3:03 atau 3:06.

Hari ini saya melihat lebih dekat pada waktu
Saya juga telah melampirkan logfile dari TTIG.
Sayangnya bukan dari saat ISP menyambungkan kembali.
Jika diinginkan saya membuat log jangka panjang, sehingga koneksi ulang juga disertakan
TTIG.log

Jadwal waktu (UTC + 1)
02:46 Pesan RX
02:51 Pesan RX
02:56 Pesan RX
02:58 Pesan RX
02:58 Sambungan kembali ISP
03:01 Pesan RX
03:03 Pesan RX
03:06 Pesan RX
tidak ada lagi Pesan diterima

Konsol TTN
Status: tidak terhubung
Terakhir Dilihat: 11/2/2020 03:05:04

06:46 Short Un- / Replug TTIG (Tidak ada daya selama 10 Dtk)

Konsol TTN
Status: terhubung
Terakhir Dilihat: 11/2/2020 06:47:12

06:48 Pesan RX
....

Saya menemukan kesalahan dalam aturan firewall saya, koneksi utama CUPS (rjs.sm.tc) tidak diizinkan, hanya CUPS-BACKUP (mh.sm.tc).

Terima kasih telah melaporkan, kami telah mengidentifikasi masalahnya dan sedang memperbaikinya. Masalah ini ada di basis kode milik kami, tetapi akan ditutup di sini.

Apakah ada yang berubah di backend sejak +/- 18h siang ini?
Sekarang hampir tidak mungkin untuk menjalankan TTN Indoor Gateway selama lebih dari 10 menit, sementara itu berfungsi dengan baik sejauh yang saya tahu selama berbulan-bulan.
Perubahan alamat IP melalui server DHCP memang memberikan 10 menit konektivitas ke jaringan TTN, tetapi kemudian hilang lagi. (replug juga berfungsi selama 10 menit)

@ TD-er, apakah Anda membiarkannya dicabut selama lebih dari 10 menit (600 detik)?

Seperti dijelaskan di atas, yang dibutuhkan sejak perubahan 6 Februari. Sebelum 7 Februari, harus dicabut selama 60 detik. Tidak jelas bagi saya apakah perbaikan gabungan hari ini juga telah diterapkan.

Tidak, tidak dicabut selama itu.
Saat dicabut, itu hanya dicabut selama beberapa detik.
Dengan perubahan DHCP pada alamat IP, unit bahkan tidak pernah mengalami siklus daya, unit hanya menerima IP baru dari server DHCP dan dengan demikian membangun kembali koneksi jaringannya. Ini membuatnya bekerja hampir tepat 10 menit sampai tidak tersedia lagi.

Sekarang saya akan mencabutnya sebentar dan kemudian melihat apa yang terjadi setelah saya memasangnya kembali.

Apakah itu dimatikan selama kira-kira 25 menit dan sekarang dicolokkan selama sekitar 15 menit dan masih berfungsi :) Akan melihat apakah masih berjalan besok pagi.

Kami merilis v3.5.3 hari ini yang berisi perbaikan, dan kemungkinan besar dapat menerapkannya ke server tempat TTIG terhubung. Mudah-mudahan itu akan segera teratasi.

Mari berharap itu belum diterapkan, karena gateway dalam ruangan saya sekarang offline lagi sekitar 3 jam.

Kami belum mendengar masalah ini setelah penerapan perbaikan terbaru. Silakan buka kembali jika diamati lagi.