Wizfi250 strange close

Question

Dear Everybody! Socket registred as service and as TCP server normal. After the connection established the server (wizfi250) are triggered to close by AT+SMGMT=n. The result is irregular close F-F-R instead F-F-A, and any next connection request are rejected with R. 20:40:05.740748 IP (tos 0x0, ttl 128, id 8, offset 0, flags [none], proto TCP (6), length 40) _ 192.168.198.242.asa-appl-proto > 192.168.198.11.43486: Flags [F.], cksum 0x221b (correct), seq 1, ack 1, win 2048, length 0_ _ 0x0000: 4500 0028 0008 0000 8006 2c79 c0a8 c6f2_ _ 0x0010: c0a8 c60b 01f6 a9de bf2d cbbe c714 7993_ _ 0x0020: 5011 0800 221b 0000 0000 0000 0000_ 20:40:05.740858 IP (tos 0x10, ttl 64, id 28363, offset 0, flags [DF], proto TCP (6), length 40) _ 192.168.198.11.43486 > 192.168.198.242.asa-appl-proto: Flags [F.], cksum 0x134a (correct), seq 1, ack 2, win 5840, length 0_ _ 0x0000: 4510 0028 6ecb 4000 4006 bda5 c0a8 c60b_ _ 0x0010: c0a8 c6f2 a9de 01f6 c714 7993 bf2d cbbf_ _ 0x0020: 5011 16d0 134a 0000_ 20:40:05.746541 IP (tos 0x0, ttl 128, id 9, offset 0, flags [none], proto TCP (6), length 40) _ 192.168.198.242.asa-appl-proto > 192.168.198.11.43486: Flags [R.], cksum 0x2a17 (correct), seq 2, ack 1, win 0, length 0_ _ 0x0000: 4500 0028 0009 0000 8006 2c78 c0a8 c6f2_ _ 0x0010: c0a8 c60b 01f6 a9de bf2d cbbf c714 7993_ _ 0x0020: 5014 0000 2a17 0000 0000 0000 0000_ Later any connection request answered with reset. 20:49:55.297520 IP (tos 0x10, ttl 64, id 18731, offset 0, flags [DF], proto TCP (6), length 60) _ 192.168.198.11.33674 > 192.168.198.242.asa-appl-proto: Flags [S], cksum 0x8006 (correct), seq 3483667042, win 5840, options [mss 1460,sackOK,TS val 639817 ecr 0,nop,wscale 7], length 0_ _ 0x0000: 4510 003c 492b 4000 4006 e331 c0a8 c60b_ _ 0x0010: c0a8 c6f2 838a 01f6 cfa4 8a62 0000 0000_ _ 0x0020: a002 16d0 8006 0000 0204 05b4 0402 080a_ _ 0x0030: 0009 c349 0000 0000 0103 0307_ 20:49:55.302203 IP (tos 0x0, ttl 128, id 19, offset 0, flags [none], proto TCP (6), length 40) _ 192.168.198.242.asa-appl-proto > 192.168.198.11.33674: Flags [R.], cksum 0xc1f8 (correct), seq 0, ack 3483667043, win 0, length 0_ _ 0x0000: 4500 0028 0013 0000 8006 2c6e c0a8 c6f2_ _ 0x0010: c0a8 c60b 01f6 838a 0000 0000 cfa4 8a63_ _ 0x0020: 5014 0000 c1f8 0000 0000 0000 0000_ Any idea how to worakround this problem? kzsolt

phil31 · Answer

hi, which firmware version you use ?

phil31 · Answer

have a try with the 1.0.5.2

kzsolt2 · Answer

According release notice no related changes from 1.0.3.3. to 1.0.5.2. Firmware page of Wiz250

phil31 · Answer

maybe or maybe not …as you want …

kzsolt2 · Answer

Ok, temporary solution: Socket close and then chip reset.

phil31 · Answer

yes but it will require more or less 10 to re associate and re open TCP server. if user try to access to your device, hi will not be happy ! flash the new firmware take 5 minutes, you can roll back if you want …

phil31 · Answer

1.0.5.2 is of course an official release, but stamped “beta” i’m using it since more or less 2 years. if you need multi socket support with your TCP server, then no choice, you need at least 1.0.4.x (from my memory…) yes you can upload by MCU, i do it !.. you need to implement Ymodem protocol. then you can do it by OTA, but for production, it’s not really fast. regards

phil31 · Answer

Hello, i don’t know if your problem exist on 1.0.5.2 … i just suggest you test (as i’m using this last beta version since several years). what i know is that 1.0.5.2 work at least as 1.0.3. i’ve got some small troubles when i try to activate multi sockets feature … but no problems with others functions. why it’s not an official fw … only Wiznet team can answer … ! if this is critical, i just suggest that you test all possibility/solution before you release ! and for sure, implement at least a watchdog feature in your CPU ! for same reasons of you, as my products are all overs the worlds, i implement a solution to allow W250 FW update. as explain, it use the Ymodem protocol. regards

kzsolt2 · Answer

Dear Phil! OK. I try it. But looks like the easy way to do it (MCU case) is a OTA upgrade. MCU send a start OTA AT command, then technican can upgrade firmware using a wifi networked computer. The Ymodem implementation is take a long time. kzsolt2

phil31 · Answer

yes OTA solution may be enough. keep us informed if 1.0.5.2 solved your issue regards

kzsolt2 · Answer

Dear Phil! As the “Update history” say the protocol violation still exists on version 1.0.5.2 . If I try to close connection on socket server (by AT command), then I recognize F-F-R sequence instead F-F-A. And the socket hang in state where all packet responded with R. kzsolt2

kzsolt2 · Answer

Dear Phil! There is some misunderstanding. I wish to say, I NOT see any related changes in update history. This mean, no related changes from 1.0.3 to 1.0.5 . kzsolt2