BX3105 stops responding whenusing multiple sockets


for my application, I use my own webserver implementation (works find with other tcp/ip chips), since later we have not only the BX3105 as network interface and the webserver must use all network interfaces. Therefore, I cannot use the BX3105 internal HTTP host.

I have 3 problems with this:

  1. I cannot use Port 80 for my own purpose, even when not using the chips internal HTTP server.
  2. Whenever I try to access port 80 from a browser I get a login page with SSID and Password, even when I only use the station mode.
  3. My biggest problem: The BX3105 stops responding sometimes while I handle multiple sockets. My browser opens multiple connections to the module on Port 8080. I handle the HTTP request on each socket and afterwards the socket is closed. But it might happen that I get no response when closing a socket. I receive incoming connections and incoming data but no responses for my commands, as seen below. The Data with COM29 is sent, the Data with COM2 is received.

09:19:58.479 COM29> AT+KTCPSND=2,\0d\0a\09\09\09\09\3c\2fdiv\3e\0d\0a\09\09\09\3c\2fdiv\3e\0d\0a\09\09\3c\2fdiv\3e\0d\0a\09\3c\2fcenter\3e\0d\0a\3c\2fbody\3e\0d\0a\3c\2fhtml\3e\0d\0a
09:19:58.490 COM2>
09:19:58.490 COM2> OK
09:19:58.492 COM29> AT+KTCPCLOSE=2,1
09:19:58.594 COM2>
09:19:58.596 COM2> +KTCP_SRVREQ: 1,3,“”,32753
09:19:58.596 COM2>
09:19:58.596 COM2> +KTCP_DATA: 3,331,GET /main.css HTTP/1.1
09:19:58.598 COM2> Host:
09:19:58.600 COM2> User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0
09:19:58.600 COM2> Accept: text/css,/;q=0.1
09:19:58.600 COM2> Accept-Language: de-DE,de;q=0.8,en-US;q=0.5,en;q=0.3
09:19:58.602 COM2> Accept-Encoding: gzip, deflate
09:19:58.602 COM2> DNT: 1
09:19:58.602 COM2> Connection: keep-alive
09:19:58.602 COM2>
09:19:58.602 COM2>
09:19:58.622 COM2>
09:19:58.624 COM2> +KTCP_SRVREQ: 1,4,“”,32756
09:19:58.624 COM2>
09:19:58.624 COM2> +KTCP_DATA: 4,315,GET /script.js HTTP/1.1
09:19:58.626 COM2> Host:
09:19:58.628 COM2> User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0
09:19:58.628 COM2> Accept: /
09:19:58.628 COM2> Accept-Language: de-DE,de;q=0.8,en-US;q=0.5,en;q=0.3
09:19:58.630 COM2> Accept-Encoding: gzip, deflate
09:19:58.630 COM2> DNT: 1
09:19:58.630 COM2> Connection: keep-alive
09:19:58.630 COM2>
09:19:58.630 COM2>
09:19:58.851 COM2>
09:19:58.853 COM2> +KTCP_SRVREQ: 1,5,“”,32757
09:19:58.853 COM2>
09:19:58.853 COM2> +KTCP_DATA: 5,315,GET /string.js HTTP/1.1
09:19:58.855 COM2> Host:
09:19:58.857 COM2> User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0
09:19:58.857 COM2> Accept: /
09:19:58.857 COM2> Accept-Language: de-DE,de;q=0.8,en-US;q=0.5,en;q=0.3
09:19:58.859 COM2> Accept-Encoding: gzip, deflate
09:19:58.859 COM2> DNT: 1
09:19:58.859 COM2> Connection: keep-alive
09:19:58.859 COM2>
09:19:58.859 COM2>
09:20:01.585 COM2>
09:20:01.586 COM2> +KTCP_SRVREQ: 1,6,“”,32755
09:20:06.573 COM29> AT+KTCPCLOSE=2,1
09:20:07.581 COM2>
09:20:07.582 COM2> +KTCP_NOTIF: 6,4
09:20:12.577 COM29> AT+KTCPCLOSE=2,1

I hope someone can help me here.

EDIT: It seems to happen only when KTCPCLOSE is sent too early after KTCP_SEND. The at reference stated, that the system must be rebooted when KTCPCLOSE=session,1 is used on a server socket. Is this also the case for sockets that were gained from a server socket via +KTCPSERVREQ? If I wait manually for 100ms it does not happen often, like before.

My firmware revision is R1.3.0.201816011422.BX310x_1 with a bootloader version 1.0. A firmware update with firmware updater v2 to version 2.5.0 did not work. Since I did not find any full version change list, I do not know if this is an error, that is already fixed in later revisions.

Best regards,
Tim Koczwara


You definitely need to use a newer version of firmware (there are a huge number of improvements in the later versions such as 2.5), given you are on version 1.3 then it is pretty certain that you unit is not able to be upgraded as it is too old (digital signature of the firmware changed mid way through the development process).

Only way to resolve this is to get your hands on a newer unit.



Hi Matt,

thanks for the response. I feared that this would be the case.
I try to get modules with a newer firmware. I hope my distributor does not only have old firmware modules.
Is there a way to identify “old chips” before mounting them on boards?

Best regards,
Tim Koczwara


There should not be any older units in the system anymore old units in the field any more as it was quite a while ago this happened.



Did you ever find the fix to this? I had a similar problem. Each time a session was closed by the client, it would increment session_id on the next connection until all 64 were used and then the system locked up. I solved mine by issuing AT+KTCPDEL=<tcp_session_id>. Note in your command list, the tcp_session_id in the KTCP_SRVREQ notification is being incremented but you keep closing session_id number 2. I think you should try keeping up with the server id that was closed in the +KTCP_NOTIF, so for +KTCP_NOTIF:6,4, issue AT+KTCPDEL=6. You can also try an AT+KTCPCFG? to list all of the tcp_session_id’s that are used up and not deleted. Once deleted, they are available for a new Client connection.

Thanks for the response, we will check whether this helps. At the moment we did not inspect it with the newer firmware 2.5.0.