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 wroom firmware configuration is as follows:
- AT version:18.104.22.168(Jul 14 2016 18:54:01)
compile time:Jul 19 2016 18:44:44
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.
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?