--- title: "[WizFi360] TCP Server Port cannot be reopened while Ping is still responding" url: "https://maker.wiznet.io/forum/16044" markdown_url: "https://maker.wiznet.io/forum/16044/md" type: "Forum topic" category: "Wireless" author: "ehgjs1112" created: "2026-04-21T07:37:11+09:00" last_activity: "2026-05-07T11:05:22+09:00" language: "en" tags: ["wizfi360-contest-ref"] views: 4 replies: 1 source: "WIZnet Makers forum (https://maker.wiznet.io/forum/)" --- # [WizFi360] TCP Server Port cannot be reopened while Ping is still responding ## Question Asked by ehgjs1112 on 2026-04-21 in Wireless. Hello, ​I am currently developing a product using the **WizFi360** module. I am experiencing an intermittent issue where the TCP Server port closes during operation and cannot be accessed. ​**Symptoms:** - ​**Network Status:** The connection to the AP and the assigned IP address are maintained without any issues. - ​**Ping Test:** The module responds to ICMP Pings from external devices normally. - ​**Port Status:** The designated TCP Server port becomes closed, and any connection attempts are rejected. Currently, I do not have a logic to re-execute the AT+CIPSERVER command automatically after this failure occurs. - ​**Frequency:** This happens intermittently during long-term operation. ​**Environment:** - ​**Operation Mode:** Station Mode - ​**Function:** TCP Server ​Since the Ping responses are normal, it seems the Wi-Fi stack is still alive, but the TCP layer seems to lose its "Listen" state. Could you please provide information on why this happens or a technical guide on how to reliably recover this state via software (AT commands) without a hardware reset? ​I look forward to your professional advice. ​Best regards, 안녕하세요, WizFi360을 사용하여 제품을 개발 중입니다. ​TCP Server 모드로 동작 중에 간헐적으로 서버 포트가 닫힌 후, 다시 열리지 않는 현상이 발생하여 문의드립니다. ​**상세 현상:** 1. ​**네트워크 상태:** AP 연결 및 IP 할당 상태는 유지됨. 2. ​**Ping 테스트:** 외부에서 모듈 IP로 Ping을 날리면 정상적으로 응답함. 3. ​**포트 상태:** 설정한 TCP Server 포트가 닫혀 있으며, 접속 시도 시 거부됨. 이 경우 다시 AT+CIPSERVER 명령으로 다시 오픈을 시도 ㅎㅏ지않음 ​**사용 환경:** - ​**설정:** Station Mode / TCP Server - ​**증상 발생 빈도:** 장시간 구동 시 간헐적으로 발생 ​Ping 응답이 오는 것으로 보아 Wi-Fi 스택은 살아있는 것 같은데, TCP 레이어에서 Listen 상태가 풀려버리는 이유나 이를 소프트웨어적으로 확실하게 복구할 수 있는 가이드가 있는지 확인 부탁드립니다. ## Replies ### Reply 1 by Lihan__, 2026-05-07 Hello, Let me start with an analysis of the symptom you described, then walk through the recommended diagnostic steps and recovery logic. **Symptom analysis** When Ping responds normally but only the TCP Server port refuses connections, it typically means the Wi-Fi link layer and ICMP handling are still alive, but the module's internal TCP listen socket or socket table resources have been exhausted. WizFi360 in multi-connection mode (AT+CIPMUX=1) can handle a maximum of 5 simultaneous connections (IDs 0–4), and when a client disconnects abnormally (power loss, RF dropout, etc.), the module-side socket may not be released immediately and can remain in a half-open state. If these accumulate and the listen backlog gets blocked, new SYNs won't be accepted even though the rest of the stack looks healthy. **Things to verify first** 1. **Firmware version** — Please share the output of `AT+GMR` so we can cross-reference against known issues. If you're not on the latest firmware, I'd recommend updating first. 2. **AT+CIPSTO setting** — Please run `AT+CIPSTO?` to check the current TCP Server timeout. If it's set to 0, the connection will never time out, which is not recommended. A value of 0 or very large means abnormally terminated client sockets stay occupied indefinitely, which directly matches your symptom. **Recommended: 60–180 seconds.** 3. **AT+CIPSTATUS at the moment of failure** — Next time the issue occurs, please capture `AT+CIPSTATUS` output before recovering. It will tell us exactly which socket state is stuck. **Recommended software recovery sequence** To recover without a hardware reset, I'd recommend implementing the following stepwise recovery on the MCU side: ```plaintext [Step 1] AT+CIPSTATUS // Check current connection state [Step 2] AT+CIPCLOSE=5 // Force-close all active sockets (or 0~4 individually) [Step 3] AT+CIPSERVER=0 // Delete the TCP Server [Step 4] (wait 200~500 ms) [Step 5] AT+CIPMUX=1 // Re-confirm multi-connection mode [Step 6] AT+CIPSERVER=1, // Re-open the TCP Server ``` If this sequence doesn't recover the module, fall back to `AT+RST` (soft reset) followed by full re-initialization. **Recovery trigger strategy** The most reliable approach is to combine two mechanisms: - **Periodic health check (e.g., every 30–60 s)** — Parse `AT+CIPSTATUS` and trigger the recovery sequence if the server status is abnormal or there's no response. - **External watchdog** — On the MCU side, if no client connection event has been observed for a defined window (e.g., 5 minutes), proactively run the recovery sequence. Tune the threshold to your traffic profile to avoid false positives in low-traffic deployments. **Additional checks for root cause** A few additional things worth verifying: - How clients terminate sessions just before the failure (graceful close vs. abrupt disconnect) - Number of concurrent clients and typical session length - The AP's idle timeout setting (some APs forcibly close long-idle TCP sessions, which can leave module-side sockets in a zombie state) Once we have your firmware version, the CIPSTO setting, and a CIPSTATUS snapshot at the moment of failure, we can give you a more precise diagnosis. Best regards. --- Source: https://maker.wiznet.io/forum/16044