Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

TCP/IP subtly broken on Opta (and possibly other platforms) #978

Closed
@fogzot

Description

@fogzot

Some changes done after 4.1.3 introduced a very subtle bug that garbles the data sent over TCP/IP, for example usingHttpClient. When using the following code:

    httpClient->beginRequest();    httpClient->get("/opta/002E003D3532511134313632/cfg");    httpClient->sendHeader("X-DNDG-Stamp", String(84814));    httpClient->sendHeader("X-DNDG-SerialNumber", "002E003D3532511134313632");    httpClient->sendHeader("X-DNDG-Applicationname", "ParkinGreen");    httpClient->sendHeader("X-DNDG-FirmwareVersion", String(2));    httpClient->sendHeader("X-DNDG-PublicKey", "2nNuFMzeh+ixOWo8bD4qUTpIN4KRf1O+zcFXJaSTKkcShr/lJdgVTxugFiH1SBEAe0caSUb3jw1Cs1o1PhmtgA==");    httpClient->sendHeader("X-DNDG-Signature", "vKFYrGgFdOP9KRQa7eYHEEa0DFl1tnIfIsYV/eFnCAh2U/JUjYDkUQspE6dUTkiPx+yM//sb5WV2ybp7kGlVzA==");    httpClient->endRequest();    Serial.print("Result: ");    Serial.println(httpClient->responseStatusCode());    httpClient->stop();

sometimes on the server side we receive partially corrupted content:

X-DNDG-Stamp: 84814X-DNDG-SerialNumber: 002E003D3532511134313632X-DNDG-FirmwareVersion2: X-DNDG-ApplicationName: ParkinGreenX-DNDG-PublicKey: 2nNuFMzeh+ixOWo8bD4qUTpIN4KRf1O+zcFXJaSTKkcShr/lJdgVTxugFiH1SBEAe0caSUb3jw1Cs1o1PhmtgA==X-DNDG-Signature: vKFYrGgFdOP9KRQa7eYHEEa0DFl1tnIfIsYV/eFnCAh2U/JUjYDkUQspE6dUTkiPx+yM//sb5WV2ybp7kGlVzA==

Note theX-DNDG-FirmwareVersion2: line, that should have beenX-DNDG-FirmwareVersion: 2. This happens more frequently when using an encrypted connection but also happens when using a plainEthernetClient (so it is not caused byHttpClient). Also, this happens more frequently when sending "large" payloads (> 100 bytes) in a short period of time.

We think this broke when the sockes writes were switched from blocking to non-blocking to address the "ethernet disconnected" problem without explicitly checking for theEAGAIN result to correctly retry and serialize the writes.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions


      [8]ページ先頭

      ©2009-2025 Movatter.jp