HTTP GET results in TCP Retransmissions but not in valid HTTP

Troubleshooting
1

Hi,

I’m building a Philips HUE Wall switch.
So far I succeeded to create the actual switch logic using the HUE RESTful API.
Now I want the automate the registration process to the HUE IP Bridge. For this I used SSDP.
So far so good. The bridge responds to the SSDP query.
For me to identify if it is the HUE bridge that replied, I need to read the description.xml.

It seemed pretty simple but I can’t get it to work.
I build a little test program using the TCPClient example code.
After the connection is made there is no reply. At times it even crashes the core.

I used wireshark to check what happens. When the core connects I see a lot of TCP Retransmissions (Reassembly error, protocol TCP: New fragment overlaps old data) but no valid HTTP data.

Below is my test code. I hope someone can help me?

TCPClient client;
byte server[] = { 192, 168, 1, 196 };

void setup()
{
    Serial.begin(9600);
    while (!Serial.available()) SPARK_WLAN_Loop();

    Serial.println("connecting...");
    if (client.connect(server, 80))
    {
        Serial.println("connected");
        client.flush();
        client.println("GET /description.xml HTTP/1.1");
        //client.println("GET /index.html HTTP/1.1");
        client.println("HOST: 192.168.1.196:80");
        client.println("USER-AGENT: Spark/1.0");
        client.println("Accept: text/html, text/xml");
        client.println("CONNECTION: close");
        client.println();
        client.flush();
    }
    else
    {
        Serial.println("connection failed");
    }
}

void loop()
{
    if (client.available())
    {
        char c = client.read();
        Serial.print(c);
    }
    if (!client.connected())
    {
        Serial.println();
        Serial.println("disconnecting...");
        client.stop();
        for(;;);
    }
}
2

Fixed it…

The line client.println(“USER-AGENT: Spark/1.0”) meshed things up.

I got it working now but still a lot of TCP retransmissions according to Wireshark, but I guess that’s the way how client.print works.

3

Hi @jacco

Right now client.print on both Spark and Arduino sends one packet per character. There is a github issue to try to fix this for Spark. You can get a packet per string by creating your own buffer and using client.write(buff, len);

4

you’ll be amazed at the speed difference between the too… where a request took a couple of seconds to send with client.print its near on instant now with client.write

5

If that’s the case, and I’m sure it is, client.print/ln should really take the entire char array and client.write it. I have no idea why it wouldn’t but perhaps there’s some good reason