HTTP GET results in TCP Retransmissions but not in valid HTTP


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()
    while (!Serial.available()) SPARK_WLAN_Loop();

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

void loop()
    if (client.available())
        char c =;
    if (!client.connected())

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.

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

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

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