Issue when sending UDP packets to broadcast IP address

[jimyates]

The problem:

When the wroom is acting as a host and we try to send UDP packets to the broadcast IP address in the same network segment as the wroom, (wroom IP 10.11.12.1, send-to IP 10.11.12.255) we regularly receive a “SEND FAIL” response from the wroom. Furthermore, wireshark shows alternating sequences of packets being received with and without checksum errors.

NOTE: I am not describing a failure to RECEIVE UDP packets; the issue is that the wroom does not send the packets and returns "SEND FAIL" instead, despite having given the > in response to the CIPSEND command.

When the wroom is acting as a host and sending UDP packets to the individual IP address of a computer that is a client of the wroom, (Wroom IP 10.11.12.1, client IP 10.11.12.2) the messages pass perfectly to that single computer, and no “SEND FAIL” is created. The problem does not exist in this configuration, it only exists when sending to the broadcast IP address in the same network segment as the wroom.

NOTE that the ONLY thing that changes between what works for individual IP and what does NOT work for broadcast IP is the IP address of the UDP connection. Everything else remains the same, including the data transmitted.

Furthermore, when the wroom is acting as a client, we can broadcast the UDP packets through the remote host (a WIFI router) by creating the UDP connection on the wroom to the host using the host IP and replacing the last octet with 255. (host IP is 192.168.0.1, so connection is created using 192.168.0.255) This sends all packets with no “SEND FAIL” and it is received by all computers attached to the remote host.

The configuration:

The wroom firmware configuration is as follows:

AT version:1.3.0.0(Jul 14 2016 18:54:01)
SDK version:2.0.0(656edbf)
compile time:Jul 19 2016 18:44:44

The wroom is controlled using AT commands from an external processor.
The wroom is set up as softAP only (CWMODE=2) (except when demonstrating that broadcast IP to remote network works as expected)
Transfer mode (CIPMODE) is 0, normal
The wroom is configured to allow four client connections, but the number of active client connections does NOT change the symptoms of the problem we are experiencing; the problem remains exactly the same even if there is NO client connected.
The wroom IP as host is 10.11.12.1
The UDP port is opened using AT+CIPSTART=0,"UDP", “10.11.12.255”, 10110, 10111, 0)
We are using AT+CIPSEND=0,<number of bytes> to begin the send of a UDP packet
We wait for > from wroom (we always get the >, it is never missing)
Then we send the <number of bytes> we specified and wait for response.
For demonstration of the problem here, the <number of bytes> is 100.

The evaluation of the problem:

To demonstrate this problem I have sent UDP packets where each packet starts with the letter "J" followed by a 5 digit ASCII sequential packet number. You can look at the UDP packets in the wireshark data and will see Jxxxxx as the start of the packet where xxxxx is the sequence number of the packet given to the wroom after receiving > in response to CIPSEND.

I have included three wireshark logs (in the zip), one with packets sent to 10.11.12.2, and two with packets sent to 10.11.12.255. The file name containing "wireshark of delayed sending..." is the log where I implemented a 30ms delay between issuing CIPSEND commands.

The log of data sent to the non-broadcast IP (10.11.12.2) shows that the data is sent properly. There are no checksum errors. This works as expected.

The log of data sent to the broadcast IP (10.11.12.255) shows a repeating pattern as follows:

a series of packets is sent with no errors. These have sequential packet numbers.
a series of packets is sent with checksum errors. These have sequential packet numbers, so all were received OK. Furthermore, there is no gap in the sequence number between these and the previous series that was sent without errors.
missing packets. (no, they are not in the list...they are missing!) There is a gap in packet sequence numbers after the last packet in each series of packets with checksum errors and the first packet of the next series without checksum errors. These missing packets are those where the CIPSEND command resulted in a "SEND FAIL". This is not a failure to receive, it is a failure to send. I have validated that the missing packets are those where I receive a "SEND FAIL" response from the wroom.

The "delayed sending" log shows the results of adding a 30 ms delay between send attempts. While this almost, but not completely, eliminates the "SEND FAIL" response, it does not change the checksum error issue and also results in a significant and unacceptable (200-300 ms) delay between the series of packets that are sent without checksum error and those that are. It is during this time that, without the delay, the "SEND FAIL" packets occur. Additionally, implementing the delay significantly changes the ratio of non-checksum error packets to checksum-error packets.

My questions:

This appears to be a bug.
If it IS a bug, can we get it fixed? Quickly?
If this is not a bug what is happening, and why?

[ESP_Faye]

Hi,

Sorry that we cannot duplicate your problem, we tested it for 1 hour, and it is alway SEND OK.
Here is our test steps.

Code: Select all

AT+CWMODE=2

OK
AT+CWSAP="APESP","88888888",5,3

OK
AT+CIPAP="10.11.12.1","10.11.12.1","255.255.255.0"

OK
AT+CIPMUX=1

OK
AT+CIPSTART=0,"UDP","10.11.12.255",10110,10111,0
0,CONNECT

OK
AT+CIPSEND=0,100

OK
>
Recv 100 bytes

SEND OK
AT+CIPSEND=0,100

OK
>
Recv 100 bytes

SEND OK
AT+CIPSEND=0,100

OK
>
Recv 100 bytes

SEND OK
AT+CIPSEND=0,100

OK
>
Recv 100 bytes

SEND OK


Could you provide your test steps (AT commands list), we will test it exactly as your way.

Thanks for your interest in ESP8266!

[jimyates]

In our setup, the wroom is installed on a board and the USART communication is taking place between a microprocessor on the board and the wroom on the board, so I cannot directly capture the communications between the two. In an effort to provide you with the information you need, I have done the following:

There is a USART port on our device that I can communicate with via USB, in addition to the USART that the wroom TX/RX USART is connected to.

Whenever the TX USART on our device that is connected to the RX USART on the wroom is interrupted (ready to send data to the wroom) in the interrupt routine I push the same byte of data that is sent to the wroom USART TX onto to the secondary USART TX in the following instruction.

Whenever the RX USART on our device that is connected to the TX USART on the wroom is interrupted (receiving data from the wroom) in the RX interrupt routine, I copy the incoming byte received from the wroom to the secondary USART TX on our device.

Using wireshark, I have captured all data on the secondary USART, which RECEIVES everything transmitted to and received from the wroom USART. That is what is in the attached wireshark log.

Using PuTTY, I have captured the text of what is being pushed onto our secondary USART. This was captured beginning just after a reboot, so the initial junk data in the file is the wroom response to boot. This file is easier to use than the wireshark version because it does not have USB messaging in it. It was not captured at exactly the same time as the wireshark version, so you cannot directly correlate the two.

The setup that you included in your email should be good to replicate the problem; it is very similar to what I am doing. After the setup, in my main loop I have code that does this:

loop{

SendToWroom("AT+CIPSEND=0,100");

WaitToReceive(">");

SendToWroom(<100 bytes>);

WaitForWroomToRespondWithSendResult(); (wait until you receive one of SEND OK, SEND FAIL, or ERROR.

Continue immediately when received)

}
The wroom does not fail on every send, and if sending slowly, it does not fail often at all. When sending as in the loop above, with no delays between send, it fails OFTEN!

In the logs I attached, I rebooted our device at the beginning of the log and you can see everything that takes place in the setup of the wroom. After that, I begin sending data to the wroom, which alternatively works and fails, as shown in the wifi logs sent previously.