MSP430F5529 + CC3100 IOT test device hanya merespon beberapa situs web pengujian

Baru-baru ini saya telah mengerjakan proyek IoT menggunakan mikrokontroler MSP430F5529 dan prosesor jaringan CC3100, keduanya dari Texas Instrument. Untuk evaluasi saya menggunakan landasan peluncuran MSP430F5529 dan boosterpack CC3100 . Saya mencoba agar perangkat terhubung ke cloud. Saya telah berhasil mengimplementasikan aplikasi CC3100 get weather example yang terhubung ke www.openweathermap.org . Ini adalah contoh dari Sampel Aplikasi CC3100 SDK . Program ini berhasil menerima dan merespons balik dari situs web www.openweathermap.org . Aplikasi menggunakan metode GET membuat permintaan dari situs web.

Saya juga telah berhasil menguji kode terhadap www.mocky.io . Perangkat menerima kode status 200 respons OK. Tetapi ketika saya menguji terhadap requestb.in situs tes saya tidak mendapatkan kode respons kesalahan 408 Timeout atau kode respon pengalihan URL 302.

#define WEATHER_SERVER  "api.openweathermap.org"
#define TEST_SERVER  "requestb.in"
//#define TEST_SERVER  "www.mocky.io"

#define PREFIX_BUFFER   "GET /data/2.5/weather?q="
#define POST_BUFFER     "&APPID=xxxxxxxxxxxxxxxxxx&mode=xml&units=imperial HTTP/1.1\r\nHost:api.openweathermap.org\r\nAccept: */"
#define POST_BUFFER2    "*\r\n\r\n"

#define PREFIX_BUFFER_TEST    "GET /1m75pgt1"
#define POST_BUFFER_TEST_1    " HTTP/1.1\r\nHost:requestb.in\r\nAccept: */"
#define POST_BUFFER_TEST_2    "\r\n\r\n"*

//#define PREFIX_BUFFER_TEST      "GET /v2/5967a65d1100007d16b6c2b4"
//#define POST_BUFFER_TEST_1    " HTTP/1.1\r\nHost:www.mocky.io\r\nAccept: */"
//#define POST_BUFFER_TEST_2    "\r\n\r\n"*

Di bawah ini adalah utama yang mencakup beberapa kondisi pengaturan. Beberapa kode penanganan kesalahan telah dihapus karena singkatnya.

 int main(int argc, char** argv)
{
    _i32 retVal = -1;

    retVal = initializeAppVariables();
    ASSERT_ON_ERROR(retVal);



    /* Stop WDT and initialize the system-clock of the MCU */
    stopWDT();
    initClk();


    /*
     * Following function configures the device to default state by cleaning
     * the persistent settings stored in NVMEM (viz. connection profiles &
     * policies, power policy etc)
     *
     * Applications may choose to skip this step if the developer is sure
     * that the device is in its default state at start of application
     *
     * Note that all profiles and persistent settings that were done on the
     * device will be lost
     */
    retVal = configureSimpleLinkToDefaultState();


    /*
     * Assumption is that the device is configured in station mode already
     * and it is in its default state
     */
    retVal = sl_Start(0, 0, 0);

    /* Connecting to WLAN AP */
    retVal = establishConnectionWithAP();

    retVal = getCredentials();

    retVal = disconnectFromAP();

    return 0;
}

Di bawah ini adalah kode getCredentials () yang memanggil mendapatkan data.

<!-- language: lang-c -->
static _i32 getCredentials()
{
    _i32 retVal = -1;

    pal_Strcpy((char *)g_DeviceData.HostName, TEST_SERVER);

    retVal = getHostIP_Device();

    g_DeviceData.SockID = createConnection();
    ASSERT_ON_ERROR(g_DeviceData.SockID);

    retVal = getData();
    ASSERT_ON_ERROR(retVal);

    retVal = sl_Close(g_DeviceData.SockID);
    ASSERT_ON_ERROR(retVal);

    return 0;
}

Di bawah ini adalah fungsi getdata () di mana saya mendapatkan kesalahan.

/*!
    \brief This function Obtains the required data from the server

    \param[in]      none

    \return         0 on success, -ve otherwise

    \note

    \warning
*/
static _i32 getData()
{
    _u8 *p_startPtr = NULL;
    _u8 *p_endPtr = NULL;
    _u8* p_bufLocation = NULL;
    _i32 retVal = -1;

    pal_Memset(g_DeviceData.Recvbuff, 0, sizeof(g_DeviceData.Recvbuff));

    /* Puts together the HTTP GET string. */
    p_bufLocation = g_DeviceData.SendBuff;

    pal_Strcpy(p_bufLocation, PREFIX_BUFFER_TEST);
    p_bufLocation += pal_Strlen(PREFIX_BUFFER_TEST);

    pal_Strcpy(p_bufLocation, POST_BUFFER_TEST_1);
    p_bufLocation += pal_Strlen(POST_BUFFER_TEST_1);

    pal_Strcpy(p_bufLocation, POST_BUFFER_TEST_2);

    /* Send the HTTP GET string to the open TCP/IP socket. */
    retVal = sl_Send(g_DeviceData.SockID, g_DeviceData.SendBuff, pal_Strlen(g_DeviceData.SendBuff), 0);
    if(retVal != pal_Strlen(g_DeviceData.SendBuff))
        ASSERT_ON_ERROR(HTTP_SEND_ERROR);

    /* Receive response */
    retVal = sl_Recv(g_DeviceData.SockID, &g_DeviceData.Recvbuff[0], MAX_SEND_RCV_SIZE, 0);
    if(retVal <= 0)
        ASSERT_ON_ERROR(HTTP_RECV_ERROR);

    g_DeviceData.Recvbuff[pal_Strlen(g_DeviceData.Recvbuff)] = '\0';
    return SUCCESS;
}

Keamanan untuk titik akses diatur sebagai

#define SEC_TYPE        SL_SEC_TYPE_WPA_WPA2    /* Security type of the Access point */

Akhirnya ada beberapa perangkat sensor POC yang dibuat dengan CC3100 yang perlu mentransfer data ke cloud. Untuk kesederhanaan kita menggunakan paket booster, pada akhirnya kita perlu mendapatkan perangkat sensor POC berkomunikasi ke cloud melalui Wifi.

Perbedaannya adalah karena situs requestb.in membutuhkan HTTP over TLS dengan SNI

Ini adalah cukup kompleks HTTP / HTTPS protokol dan keamanan pertanyaan kemungkinan yang lebih baik dibahas di tempat lain dalam sistem SE, dan sebagian besar mengenai rincian dari requestb.inlayanan yang Anda menguji melawan daripada apa pun proyek IOT Anda mungkin akhirnya akan lakukan. Tapi selama itu tetap di sini ...

Debugging requestb.in kode respons ketika mencoba HTTP pada port 80

Kamu berkata:

Tetapi ketika saya menguji terhadap requestb.in situs pengujian saya tidak mendapatkan kode respons kesalahan 408 Timeout atau kode respon pengalihan URL 302.

Mari lihat apa yang terjadi:

curl -i http://requestb.in/xxxxxxxx
HTTP/1.1 301 Moved Permanently
Location: https://requestb.in/xxxxxxxx

Status HTTP 301 adalah "Dipindahkan Secara Permanen", sedangkan 302 yang Anda harapkan kadang-kadang digunakan untuk pengalihan sementara . Karena mereka mungkin tidak berencana untuk membiarkan Anda menggunakan HTTP pada soket TCP biasa pada port 80, pengalihan permanen yang mereka kirim adalah respons yang lebih benar.

Itu akan jauh lebih bermanfaat jika Anda telah menangkap kode status yang _was_ kirim daripada hanya daftar dua yang _tidak dikirim_

Bagaimanapun, apa yang dikatakan server adalah bahwa kita harus menggunakan HTTPS.

Jadi apa yang perlu Anda lakukan untuk terhubung ke server melalui HTTPS?

Pada tingkat dasar, HTTPS berarti berbicara HTTP melalui koneksi yang dijamin dengan TLS (atau sebelumnya, SSL), daripada melakukannya melalui soket TCP biasa.

CC3100 Anda mendukung TLS dan SSL , dan ada beberapa informasi minimal tentang memodifikasi salah satu contoh klien HTTP SDK untuk melakukan koneksi HTTPS dengan membuat saluran yang aman, tersedia di http://processors.wiki.ti.com/index.php / CC3100_HTTP_Client

Namun, dalam hal requestb.inini mungkin tidak cukup.

Jika Anda mengirim permintaan GET yang sangat sederhana ke s_clientperintah openssl (atau melakukan hal yang sama pada CC3100)

(echo -en "GET /xxxxxxxx HTTP/1.1\nHost: requestb.in\n\n" ; sleep 10) | \
openssl s_client -connect requestb.in:443

( sleepis untuk membuat openssl menunggu respons daripada hangup pada akhir input)

Anda akan mendapatkan kesalahan aneh:

Rutinitas SSL: SSL23_GET_SERVER_HELLO: kegagalan jabat tangan sslv3 peringatan

Anda mungkin ada hubungannya dengan versi SSL vs TLS, tetapi sebenarnya itu karena requestb.inmemerlukan sesuatu yang disebut Indikasi Nama Server (Wikipedia) . Ini secara efektif berarti Anda harus memberi tahu tumpukan SSL untuk memberi tahu server mana nama server yang harus diautentikasi.

Melanjutkan dengan demonstrasi baris perintah, kami cukup menambahkan -servernameargumen:

(echo -en "GET /xxxxxxxx HTTP/1.1\nHost: requestb.in\n\n" ; sleep 10) |\
openssl s_client -connect requestb.in:443 -servername requestb.in

Jika ini dilakukan dengan hash URL dari requestb.in yang valid dalam contoh, itu menghasilkan hasil dan terlihat di panel log browser yang dibuat itu.

Menerapkan Indikasi Nama Server (SNI) di CC3xxx

Ada beberapa posting forum menunjukkan bahwa pelaksanaan TLS pada CC3xxx telah tidak didukung SNI, dan bahwa tidak ada rencana konkret untuk menambahkan ini; Namun, Anda dapat memverifikasi jika itu masih terjadi.

Tetapi penting untuk diingat bahwa ada pohon lapisan jaringan yang terlibat:

WiFi
  IP packets
    TCP session
      TLS session
        HTTP protocol

Karena CC3100 memungkinkan Anda untuk berbicara TCP (dan sebenarnya Anda melakukannya dalam kode yang ada), Anda bebas untuk "membawa sendiri" implementasi TLS yang memang memiliki dukungan SNI. Sebagai contoh, posting blog ini membahas porting TLS (sebelumnya PolarSSL) yang dipasangi librari ke CC3xxx dan menyebutkan SNI sebagai kapabilitas.

TL; DR

requestb.inadalah target yang menantang karena mengharuskan Anda berbicara HTTP selama sesi yang dijamin dengan TLS dan menerapkan Indikasi Nama Server . Jika berbicara dengan host ini bukan bagian dari proyek pamungkas Anda, mungkin lebih baik Anda beralih ke host-host yang ada - yang dimaksudkan untuk digunakan dengan klien seminimal mungkin yang tertanam pada perangkat IoT mungkin dikonfigurasikan untuk membuat segalanya sedikit lebih mudah dengan tidak menggunakan SNI.

Ini juga akan jauh lebih efisien jika Anda terbiasa menangkap detail masalah yang Anda temui - pengembangan yang disematkan selalu menantang untuk di-debug, dan semakin sedikit informasi tentang kegagalan yang Anda tangkap melalui pencatatan atau debugger, semakin banyak waktu yang dihabiskan untuk menebak. .

Sangat mungkin bahwa openweathermap.org dan www.mocky.io mendukung http atau port 80. Berikut adalah beberapa petunjuk.

openweathermap.org

www.mocky.io

Sepertinya requestb.in hanya mendukung HTTPS atau port 443.

requestb.in

Ini mungkin menjelaskan masalahnya. Di bawah ini ada beberapa referensi yang mungkin bisa membantu.

Dalam datasheet CC3100 tidak ada referensi ke CC3100 yang bekerja dengan HTTPS. Semua referensi hanya untuk HTTP. Ini mungkin lebih baik menjelaskan masalahnya. Lampirkan di bawah ini kecuali dari lembar data.

Sepertinya per lembar data CC3120 mendukung HTTPS. Lampirkan di bawah ini kecuali dari lembar data. Ada beberapa referensi ke HTTPS.

Jalur ke depan yang paling mungkin adalah mengganti CC3100 dengan CC3120.

Referensi:

• Server Uji HTTP yang menerima panggilan GET / Pos
• Mengumumkan Httpbin.org
• CC3100 SimpleLink ™ Wi-Fi® Network Processor
• CC3120 SimpleLink ™ Wi-Fi® Prosesor Jaringan Nirkabel
• Server HTTP CC3100