Wizfi250 strange close


#1

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


#2

hi, which firmware version you use ?


#3

Latest sable firmware (1.0.3.3)


#4

have a try with the 1.0.5.2


#5

According release notice no related changes from 1.0.3.3. to 1.0.5.2.

Firmware page of Wiz250


#6

maybe or maybe not …as you want …


#7

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


#8

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 …


#9

Dear Phil31!

In theory yes.

But in practice our system is an embedded industrial device.
We use wifi module as a chip.
It is hard wired to PCB, and has no feature to “repair” (e.g. download firmware).
Moreover wizfi module not implement method to upgrade firmware by MCU.
Have method only to upgrade by smart script run on DOS? computer or by OTA mode using built-in web server.

Other side we can’t use unoffcical firmware beacuse many reason.

kzsolt2


#10

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


#11

Dear Phil31!

Now the main problem is a socket strange close.
I have still no information, this problem is exists on 1.0.5 firmware or not.

Other question is, if 1.0.5 fw is work well, then why it is not a official firmware? Why not used for new produced Wiz250 module?
Other sides, our product is delivered to unattended sations. If there is any “leak” in firmware, then it can be cause mass repair requirement on a far cities. This is why I need to thkin twice before step forward.

kzsolt2


#12

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


#13

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


#14

yes OTA solution may be enough.

keep us informed if 1.0.5.2 solved your issue

regards


#15

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


#16

where do you find this in update hystory ?
i juste read :slight_smile:
<v1.0.5.2>
Fixed Data mode problem in UDP
Added TCP Server Multi Connection


#17

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