[WizFi360] TCP Server Port cannot be reopened while Ping is still responding
Wireless
- wizfi360-contest-ref
No replies yet. Be the first to reply.
Join the discussion.
Wireless
No replies yet. Be the first to reply.
Join the discussion.
Share projects and connect with makers.
Joined before the site update? first.
New to WIZnet Makers?
We sent a verification link to your address. Open it to activate your account, then log in.
Accounts from this email provider are reviewed by an administrator after verification. Approval usually takes one business day.
Already have an account?
Enter your email address. If it belongs to an account, we'll send a link to set a new password. Members who joined before the site update use this to set their password.
If an account uses that address, we sent a link to set a new password. The link works once and expires in 30 minutes.
Know your password?
Need an account?
RE: [WizFi360] TCP Server Port cannot be reopened while Ping is still responding
by Lihan__ WIZnet ·
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
AT+GMRso we can cross-reference against known issues. If you're not on the latest firmware, I'd recommend updating first.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.AT+CIPSTATUSoutput 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:
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:
AT+CIPSTATUSand trigger the recovery sequence if the server status is abnormal or there's no response.Additional checks for root cause
A few additional things worth verifying:
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.