Thiết bị kiểm tra IOT MSP430F5529 + CC3100 chỉ đáp ứng với một số trang web kiểm tra


8

Gần đây tôi đã làm việc trên một dự án IoT bằng bộ vi điều khiển MSP430F5529 và bộ xử lý mạng CC3100 cả từ Texas Cụ. Để đánh giá Tôi đang sử dụng bệ phóng MSP430F5529 và booster booster CC3100 . Tôi đang cố gắng để thiết bị kết nối với đám mây. Tôi đã triển khai thành công ứng dụng lấy ví dụ thời tiết CC3100 kết nối với www.openweathermap.org . Đây là ví dụ từ CC3100 SDK Application Application . Chương trình nhận và trả lời thành công từ trang web www.openweathermap.org . Ứng dụng sử dụng phương thức GET đưa ra yêu cầu từ trang web.

Tôi cũng đã thử nghiệm thành công mã chống lại www.mocky.io . Thiết bị nhận được mã trạng thái phản hồi 200 OK. Nhưng khi tôi kiểm tra trang web thử nghiệm requestb.in, tôi không nhận được mã phản hồi lỗi Hết thời gian 408 hoặc mã phản hồi chuyển hướng URL là 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"*

Dưới đây là chính bao gồm một số điều kiện thiết lập. Một số mã xử lý lỗi đã được gỡ bỏ để cho ngắn gọn.

 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;
}

Dưới đây là mã getCredentials () gọi lấy dữ liệu.

<!-- 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;
}

Dưới đây là hàm getdata () trong đó tôi đang gặp lỗi.

/*!
    \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;
}

Bảo mật cho điểm truy cập được thiết lập là

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

Cuối cùng, có vài thiết bị cảm biến POC được chế tạo với CC3100 cần truyền dữ liệu lên đám mây. Để đơn giản, chúng tôi đang sử dụng boosterpack, cuối cùng chúng tôi cần phải có các thiết bị cảm biến POC giao tiếp với đám mây qua Wifi.


Tôi đang bỏ phiếu để đóng câu hỏi này ngoài chủ đề vì vấn đề thực sự của câu hỏi là về việc sử dụng HTTP cơ bản và ở mức độ thấp hơn một nền tảng nhúng cụ thể, không phải Internet of Things, do đó, điểm chung là các câu hỏi HTTP khác đầu tiên, và không thực sự cho các câu hỏi IoT khác cả.
Chris Stratton

1
FYI ví dụ requestb.in cụ thể trong mã của bạn rõ ràng đã hết thời gian và bây giờ là 404 khi được truy cập qua HTTP qua TLS với SNI như hoạt động cho các mã hiện tại hợp lệ.
Chris Stratton

@mico, tôi nhận thấy rằng bạn đã xóa câu trả lời của bạn. Ngoài ra, bạn đề cập đến việc thêm một "s" vào http. Tôi không chắc làm thế nào tôi có thể đạt được đề nghị của bạn. Bạn có thể vui lòng cho tôi một số hiểu biết.
dùng8055

@ChrisStratton, Xin lỗi khi biết rằng bạn bỏ phiếu để đóng câu hỏi này. Bạn có thể vui lòng giới thiệu cho tôi một trang web hỏi đáp tốt để đặt câu hỏi này không?
dùng8055

Bạn có nhận được những tin nhắn 302 và 408 đó hay không? Nếu không, sau đó bạn nhận được tin nhắn gì?
mico

Câu trả lời:


5

Sự khác biệt là do trang requestb.in yêu cầu HTTP qua TLS với SNI

Đây là một giao thức HTTP / HTTPS khá phức tạp câu hỏi bảo mật có khả năng được giải quyết tốt hơn ở những nơi khác trong hệ thống SE và chủ yếu liên quan đến các chi tiết về requestb.indịch vụ mà bạn đang thử nghiệm thay vì bất kỳ dự án IoT nào bạn có thể thực hiện. Nhưng miễn là nó vẫn còn ở đây ...


Gỡ lỗi mã phản hồi requestb.in khi thử HTTP trên cổng 80

Bạn đã nói:

Nhưng khi tôi kiểm tra trang web thử nghiệm requestb.in, tôi không nhận được mã phản hồi lỗi Hết thời gian 408 hoặc mã phản hồi chuyển hướng URL là 302.

Hãy xem điều gì xảy ra:

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

Trạng thái HTTP 301 là "Đã di chuyển vĩnh viễn", trong khi 302 mà bạn mong đợi đôi khi được sử dụng để chuyển hướng tạm thời . Vì có lẽ họ không có kế hoạch cho phép bạn sử dụng HTTP trên ổ cắm TCP đơn giản trên cổng 80, nên chuyển hướng vĩnh viễn mà họ gửi là phản hồi chính xác hơn.

Sẽ hữu ích hơn rất nhiều nếu bạn đã nắm bắt được mã trạng thái mà _was_ đã gửi thay vì chỉ liệt kê hai cái mà _were_ không gửi

Ở bất cứ giá nào, điều mà máy chủ đang nói là chúng ta phải sử dụng HTTPS.


Vậy bạn cần làm gì để kết nối với máy chủ thông qua HTTPS?

Ở cấp độ cơ bản, HTTPS chỉ đơn giản là nói HTTP qua kết nối được bảo mật bằng TLS (hoặc trước đó là SSL), thay vì thực hiện trên ổ cắm TCP đơn giản.

CC3100 của bạn hỗ trợ TLS và SSL và có một số thông tin tối thiểu về việc sửa đổi một trong các ví dụ máy khách HTTP của SDK để thực hiện kết nối HTTPS bằng cách thay vào đó là tạo một kênh bảo mật, có sẵn tại http: // Processors.wiki.ti.com/index.php / CC3100_HTTP_Client

Tuy nhiên, trong trường hợp requestb.innày có thể không đủ.

Nếu bạn chuyển một yêu cầu GET rất đơn giản thành s_clientlệnh openssl (hoặc thực hiện tương tự trên CC3100)

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

(đó sleeplà để tạo openssl chờ phản hồi thay vì gác máy khi kết thúc đầu vào)

Bạn sẽ nhận được một lỗi kỳ lạ:

Thói quen SSL: SSL23_GET_SERVER_HELLO: sslv3 lỗi bắt tay cảnh báo

Bạn có thể nghĩ điều này có liên quan đến các phiên bản SSL so với TLS, nhưng thực tế là vì nó requestb.inyêu cầu một thứ gọi là Chỉ định tên máy chủ (Wikipedia) . Điều này có nghĩa là bạn cần nói với ngăn xếp SSL để báo cho máy chủ biết tên máy chủ nào sẽ được xác thực là.

Tiếp tục với các cuộc biểu tình dòng lệnh, chúng tôi chỉ cần thêm một -servernameđối số:

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

Nếu điều này được thực hiện với hàm băm URL của một cá thể requestb.in hợp lệ, nó sẽ tạo ra một kết quả và hiển thị trong bảng nhật ký của trình duyệt đã tạo ra nó.


Triển khai chỉ định tên máy chủ (SNI) trên CC3xxx

Có một số bài trên diễn đàn cho thấy việc thực hiện TLS trên CC3xxx đã không được hỗ trợ SNI, và rằng không có kế hoạch cụ thể để thêm video này; tuy nhiên, bạn có thể xác minh nếu đó vẫn là trường hợp.

Nhưng điều quan trọng cần nhớ là có một nhóm các lớp mạng liên quan:

WiFi
  IP packets
    TCP session
      TLS session
        HTTP protocol

Vì CC3100 cho phép bạn nói TCP (và trên thực tế bạn đang làm như vậy trong mã hiện tại của mình), bạn có thể tự do "mang theo" triển khai TLS của riêng bạn có hỗ trợ SNI. Ví dụ, bài đăng trên blog này thảo luận về việc chuyển giao TLS (trước đây là PolarSSL) cho CC3xxx và đề cập đến SNI là khả năng.

TL; DR

requestb.inlà một mục tiêu đầy thách thức vì nó yêu cầu bạn nói HTTP qua một phiên được bảo mật bằng TLS và thực hiện Chỉ định tên máy chủ . Nếu nói chuyện với máy chủ này không phải là một phần của dự án cuối cùng của bạn, bạn có thể thấy tốt hơn là chỉ cần chuyển sang các máy chủ đó - những dự định sử dụng với các máy khách nhúng tối thiểu trên các thiết bị IoT có thể được cấu hình để giúp mọi việc dễ dàng hơn một chút không sử dụng SNI.

Sẽ hiệu quả hơn rất nhiều nếu bạn có thói quen nắm bắt chi tiết các vấn đề bạn gặp phải - phát triển nhúng luôn là thách thức để gỡ lỗi và càng ít thông tin về các thất bại bạn nắm bắt thông qua đăng nhập hoặc trình gỡ lỗi, càng mất nhiều thời gian để đoán .


Có vẻ là một câu trả lời tốt, nhưng là ngoài tầm hiểu biết của tôi. Tôi hy vọng đạt được mức độ kiến ​​thức chuyên sâu này trong tương lai gần. Nhưng cảm ơn bạn rất nhiều vì đã trả lời.
dùng8055

1
Yêu cầu SNI thực sự làm cho nó trở nên phức tạp - khuyến nghị của tôi là bỏ qua requestb.in, tập trung vào các yêu cầu của bất cứ điều gì bạn thực sự cố gắng nói trong dự án thực của bạn và nếu cần, hãy tìm một dịch vụ giả mạo tương tự như yêu cầu đó.
Chris Stratton

Bây giờ khi đọc điều này và sau khi xóa hai nỗ lực cạnh tranh của tôi, tôi đề nghị như vậy, làm điều gì đó hiệu quả hơn. Và chấp nhận nỗ lực của Chris.
mico

1

Rất có khả năng cả openweathermap.org và www.mocky.io đều hỗ trợ http hoặc cổng 80. Dưới đây là một vài manh mối.

openweathermap.org

Sơ đồ mở

openweathermap-url

www.mocky.io

nhạo báng

mocky-url

Hình như requestb.in chỉ hỗ trợ HTTPS hoặc cổng 443.

requestb.in

yêu cầu

url yêu cầu

Điều này có thể giải thích vấn đề. Dưới đây là một số tài liệu tham khảo có thể giúp đỡ.

Trong biểu dữ liệu CC3100 không có tài liệu tham khảo nào về CC3100 hoạt động với HTTPS. Tất cả các tham chiếu chỉ đến HTTP. Điều này có lẽ tốt hơn giải thích vấn đề. Đính kèm bên dưới một ngoại trừ từ bảng dữ liệu.

CC3100 - Bảng dữ liệu chấp nhận

Có vẻ như mỗi bảng dữ liệu CC3120 hỗ trợ HTTPS. Đính kèm bên dưới là ngoại trừ bảng dữ liệu. Có một vài tài liệu tham khảo về HTTPS.

CC3100 - Bảng dữ liệu chấp nhận

Con đường khả dĩ nhất là thay thế CC3100 bằng CC3120.

Người giới thiệu:


1
Sau nhiều lần chỉnh sửa giới thiệu lỗi và sau đó sửa lỗi, giờ đây đây có thể là một câu trả lời thực sự. Nhưng bạn thực sự vẫn cần phải viết lại nó: nếu luận điểm của bạn là một trang web chỉ hỗ trợ http và trang kia chỉ https, thì bạn chỉ cần nói trước.
Chris Stratton

2
Và phân tích của bạn về CC3100 và đề xuất thay thế vẫn hoàn toàn sai lầm. Nó nói rõ ràng rằng nó hỗ trợ TLS / SSL, trong khi bạn cố gắng tranh luận rằng nó không bằng cách nhìn nhầm vào khả năng của máy chủ web, khi câu hỏi không liên quan gì đến việc trở thành một máy chủ. Câu hỏi thực sự không sử dụng thư viện HTTP, mà là thực hiện thủ công trên một ổ cắm TCP. Để liên hệ với máy chủ HTTPS, nó sẽ cần thực hiện các hoạt động tương tự trên đỉnh kết nối SSL.
Chris Stratton
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.