Hello,

Would you like to establish the communication over telnet?

However, USR-TCP232-T2 does not support for talking over the telnet. If you need, you can submit the requirement to our sales, our developers will evaluate and consider to do it according to your annual quantity.

Regards,

Serlynn

>However, USR-TCP232-T2 does not support for talking over the telnet.
Ok, lets say I don't want to talk not ove telnet, I want to use netcat. They problems
are exactly the same.
USR-TCP232-T2 implements an TCPSERVER mode, what exactly is this mode supporting
and why telnet is not supported? I can't read anything about not supported telnet in the documentation.
>If you need, you can submit the requirement to our sales, our developers will evaluate and
>consider to do it according to your annual quantity.
Oh yes :-) but please..the prototypes have to work first, hope you can understand that.
For sure I don't want to buy things that doesn't support anything over something.
Besides of that I remember to have asked about firmware updates..you marked the ticket as resolved, 
but where are the answes to my questions now?
Regards,
Holm

Hello, Holm

Sincerely apologize for no comments on the firmware. V4017 is already the latest version. 

I do not understand about this function/information, can you explain how you got this? Thank you for your explanation.

Regards,

Serlynn

What do you not understand? Netcat? Netcat is an standard program to solve network related problems in unix envirnonments like Linux, FreeBsd etc.. You can establish an TCP connection to an TCP Server on an USR-TCP232 Module using the command "nc  ip-address port-number", the program builds up the TCP connection and uses stdin and stdout to communicate. That's easy, isn't it? The only problem with this is the buggy TCP Software on the USR Module. I get storms of double Acks and connection Resets from the USR-TCP-232 when I want to use TCP conenctions. It isn't interesting if I whish to use the TCP-Server or the TCP-Client mode. The Modules "fires" over the ethernet until it breaks down and finally reboots. I even searched for a way to disable the internal webserver (since it uses TCP) ..but there is no way to do this it seems.. I think that happens every time a tcp connection gets lost and there is still content to transfer in the internal buffer of the USR-TCP232.
Next thing: If you use the internal webserver to reboot the module, it comes up after the reboot with an 404 error.
BTW: I use the FreeBSD Operating System for my development, that's the one that Sony uses for their Playstation or Netflix to serve videos over the Internet. His networking code is very fast, clean and bug free as far as I know.
You advertise TCPSERVER and TCPCLIENT mode for the USR-TCP232-T2 Modules, I think it's high time now to debug
those functions now..they are simply unusable in the current state of the firmware.
Your Firmware seems to be closed source, do you thinkthat this is an entirely good idea?
Regards,
Holm

Hello, Holm

Do you use the teamviewer? Plz send the teamviewer ID and the password when you are reday.

Thanks to you!

Regards,

Serlynn

No sorry, no Windows and no Teamviewer here. I'm developing on a Unix (FreeBSD) Machine.
Regards,
Holm

Hello,

Kindly provide the test method, by which you got the double ACKs and connection resets. We would like to test and check it ASAP.

Regards,

Serlynn

Do you have a Linux System there?
You need an Linux with installed wireshark and netcat (nc) package.
Regards,
Holm

Hello, Holm

We have the wireshark software in the windows system. 

Can you explain more about the process of test?

Regards,

Serlynn

Hi Holm, 

This is Simon who take over Serlynn. I will follow your problem. If the product is buggy and the bugs make your application doesn't work, we will fix them. 

To understand your problem well, please allow me to review them. 

1. 08:51:09.858001 IP fsnet-1.tsht.lan.telnet > unic.tsht.lan.21934: Flags [R.], seq 2, ack 51, win 2920, length 0 08:51:09.858005 IP unic.tsht.lan.21934 > fsnet-1.tsht.lan.telnet: Flags [.], ack 1, win 65535, length 0 

I am not familar with unix. But to my understanding, ACK 51, 51 is meaning order 51st ACK rather 51 pieces of ACK. Maybe I am wrong, Can I realize this problem in Windows Wireshark? The OS are different but I think the network packets should be same. Can you tell me how do you operate and setup USR-TCP232-T2? 

2.Next thing: If you use the internal webserver to reboot the module, it comes up after the reboot with an 404 error. 

When the module is restarting, if your browser flash web automatically, it will get the 404 error. Because the module is not boot up totally. Please understand it because we can not ask browser provider(Chrome, Firefox etc) how to make the browsers. 

3.Your Firmware seems to be closed source, do you thinkthat this is an entirely good idea? 

We have to do it, if we open the source we can not earn money, If we don't earn money, our company will be closed. And noone to develop new product and maintain old products. Please understand it. I am gald to discuss technical issue with you. If you have any idea, you can tell me more. 

Best regards 

Simon

Hi Simon, please be patient, I'm trying to recheck the issue with a friend and to find the shortest way to reproduce it.
I do have an Notebook with an old Windows Vista on one of the disks an will try that too.
I'll get back to you soon.
 

..addendum:
I've found a windows Port of the netcat tool here:
https://eternallybored.org/misc/netcat/
You can have a look at it, I'm sure it will be useful for your job.
You can set up tcp and udp servers and clients easily from the cmd line with it.
Regards,
Holm

Hi Holm,

We have our TCP/UDP tool to build connection. You can use our software.

Once you can recurrence and capture the packets, please let us know.

Best regards

Simon

TEST V1.4.exe [1.1 MB]

Ok, it's nice that you have your tool, but I can't use it. I have to build an application
using an different operating system, therefore I have to use the utilities that run there.
The link to netcat was provided to give YOU the ability to erproduce an verify what
happens here.
I'm not even shure if microsofts TCPIP stack is acting the same way as that from the
BSD's.
Regards,
Holm

...
in the meantime I've tested my Hardware with an older USR TCP232-T Module, the windows-config SW says this
module (00:26:e7:bb:57:24) has a Version 4.14.
This older modules don't has an AT - Command mode to setup ..right?
Interestingly this old module doesn't seem to exhibit that "Ethernet Packet War" problem that I have with the newer 
one. I've set it up with the windows software as TCP server on Port 2323, it works flawlessly so far...
To answer your question above how I have setup the modules..I've tried several ways. Internet config with DHCP or without, using an static address, TCPSERVER Mode, several Ports. Setup with the AT-CMD set (preferred, since I can do 
this with that embedded computer System to which the module is connected trough an SC16IS740 SPI to UART bridge chip) or with the web interface. The problem is the same every time. If I send characters to the module over the UART and there is no TCP connection from somewhere this "Ethernet Packet War" between the Unix machine and the modules begins, the module gets busy, I can't connect to it ..until the module reboots (easily to see with wireshark, it reconfigures using bootp). After that the module responds for a few seconds, then the packet war starts again...reboot.
Since resetting the module or my embedded CPU or both doesn't change anything on that behavior, I think the problem
is related to the behavior of the TCPIP stack from my Unix host..but..many servers on the world using this system and the old module doesn't get chocked on that.
Regards,
Holm

This configuration should be sufficient.
at+wann
+OK=DHCP,192.168.50.59,255.255.255.0,192.168.50.254
at+dns
+OK=192.168.50.49
at+sock
+OK=TCPS,192.168.50.59,2323
at+tcpse
+OK=KEEP
at+mac
+OK=D8B04CE4542E
at+mid
+OK=USR-TCP232-T2
Then open an serial connection to the module (my program and hardware should be transparent) and open an
telnet connection to the module, port 2323.
I've simple playing to transfer some ascii data, sometimes after closing the connection to port 2323 while sending data, reopening the connection or something the system freaks out, the module and the host doing that paket war thing, sometimes it is sufficient to just let stay the connection for a while to produce this, but I don't found a thing that trigges this 100% of the time until now. It that "storm" happens the yellow LED at the RJ45 connector is blinking fast but the controller is sending no data to the USR Module.
I've uploaded a wireshark dump file to http://www.thst.de/files/2-dump.pcapng.gz for packet analysis.
Regards,
Holm

..sorry typo:
http://www.tsht.de/files/2-dump.pcapng.gz
Regards,
Holm

Hi Holm,

I will check this issue with third party software. Thank you for you information.

Best regards

Simon

I've asked a friend of mine to look into that file I've uploaded to tell what's going on. I'll translate here what he wrote to me in german yesterday:
"It isn't fully clear who from booth partners pays against the rules in that "I sent you an Reset" and "I send you an zero Window" game. But it is clear after short reading of the RFC's  that a normal End of an TCP connection is , when eighter side sends *one" FIN Packet. If both partners received an valid FIN Packet from the other side, the connection is closed.
But the USR Module sends after receiving an FIN Packet from the FreeBSD Host a RST.. instead to properly closing down the connection and sending his own FIN Packet.
Sometimes this works, sometimes not.  Without the ability to direct to a concrete place in the RFC, I'm thinking that sending an RST as Answer to an received FIN isn't an proper Answer..."
So why you send RSTs after the closing of the connection?
Regards,
Holm

https://en.wikipedia.org/wiki/Transmission_Control_Protocol#/media/File:Tcp_state_diagram_fixed_new.svg
..no RST Packets involved.
Regards,
Holm

Hi Holm,

We know it is not standard. We can remove RST packet if you want. 

If we remove this RST packet, in some conditions the TCP client may fail to connect to server.

If you want we remove it, please tell us. But the firmware may be finished in next week.

Best regards

Simon

It seems that would solve my problem. 
I't s unclear to how that not existing RST should prevent cleints ot connect, you should at least try to
properly end the connection sending an FIN Packet from your side to the client, that's the normal way.
After that you could send an RST response if the client still tries to connect to that session.
BTW: How ist the Firmare to be changed, is there a possibility an the USR Modules Website or have
I to connect an SWD Device?
Regards,
Holm

Hi Holm,

I have already put up your problem in our OA system.

I think it will take serveral days to update firmware.

You can upgarde firmware with our setup software. Here is a guide book about firmware upgrading.

Best regards

Simon

Upgrading firmware method of Serial-to-Ethernet products_V1.0.1.pdf [318.9 KB]

This week is almost gone now...is there anything new on this topic?
Regards,
Holm

Hi Holm,

I get the informed that the firmware may finished in next Wednesday.

Best regards

Simon

What's up Simon?
Regards,
Holm

Hi Holm,

Please try this firmware, I have tested it and it seems good.

Best regards

Simon

USR-TCP232-T2-S2-V4017(V1.2.3)-20180524141803.bin [182.5 KB]

ok...I've read the Firmware Upgrade manual http://h.usriot.com/index.php?c=download&model=ticket_reply&id=2593&key=AJqvxs, Downloaded the Setup Software from http://www.usriot.com/usr-m0-setup-software/, installed it on a windows Vista computer and run it. I've searched the Module, changed the setup to an static IP Address, Reset the module..all fine but there isn't any "Firmware upgrade"  Item in the "File" Menu at top left. There is an "User Config" that responds with an authentication question..entered admin/admin as setup as default but nothing changes.
There is simply no possibility to do an firmware upgrade. The program identifies it self with "USR M0 V2.2.2.279".
Question again: How is this firmware to be upgraded?

..ok, finally found the right button menu, tried and got a timeout. Module seems to be dead now, connected another one
and do some tests.
Is there a way to restore the dead module?
Regards,
Holm

Hi Holm, 

Please read upgrade manual.

If you can not rescue it, the only way is sent it to us.

Best regards

Simon

I've successfully "reanimated" the dead module, fine.
Sending it back to you does'nt make any economical sense, the postage
has  the same price tag a a new module unfortunately, besides of that
the module is soldered in on a daughterboard with an SC16IS740 to 
communicate over an SPI interface (The ARM CPU on the USR module
could do this too, ...hint for future products?)
I've checked with the new firmware..it behaves differently, the USR Module
doesn't reboot spontaneously anymore, but the Problem with the connection
reset persists. Why you need to send an connection reset instead of a FIN packet?
I'm trying to connect People from the FreeBSD development team to find out
why FreeBSDs TCPIP Stack is sending Zero Window packets at all which seems
to be one half of my problem..but the other half are that connection resets from the
USR module. Why you wouldn't terminate a session the usual way as all others do?
FreeBSDs and Linux TCP/IP stacks are that what gets mostly used in embedded devices 
such as Routers, NAS or other Boxes. You can copy BSDs Stack for free..it makes sense
in my eyes to support interoperability with that devices and not using a"nonstandard" way.
Next thing: You really should provide at least some binary firmware file which helps
to reanimate dead Modules. I understand your problem to not support illegal copies of
your modules but sending back them to china is no possible way in global economics.
Regards,
Holm

Hi Holm,

1. We don't have SPI to Ethernet product plan. There is two reason, SPI is too complex for most customer. It is difficult for them to understand and control Chip select and master/slave mode. In the market there are some SPI to ethernet chip solution. Do you know wiznet?

2. It is difficult to explan why the product designed as it now. There are a lot of customers do not use standard protocol. We just find a best way to suit most customer.

3. It is limited by solution and chip resource we don't have perfect way to upgrade firmware. If some modules brick in upgrade process, you can contact sales.

Best regards

Simon

1. That's a joke, isn't it? Yes, I know the Wiznet Modules and Chips and since you aren't able to deliver a firmware that properly handles TCP Connections that would be my next try.
2. The next joke. A Lot of customers that don't use a standard Protocol on the Internet? Don't want to use the proper protocol? You made faulty software because customers want it?
3. Yes. 
You should change you advertisements. That is'nt a Telnet Server Protocol as it was meant by the standards. There should be a FIN packet and his aknowledegement, not an connection reset. Simply write that you build an Interface module that uses his own protocol and using it with standard Hardware can have some side effects.
I had'nt bought your modules if I had known that fact!

Hi Holm,

I just tell you why we won't develop SPI to ethernet module. I don't think it is a joke that we don't provide SPI module for customers. Our product design is based on market requirment.  If we really get a lot of feedbacks about this RST packet, we would like to modify it in common firmware. But it is only your system crashed after that packet. No matter what, we modify the firmware for you once we know your issue. I think we already do everything we need to do.

By the way, it is your right to choose your supplier, if you have better choice you can choose them. 

Best regards

Simon

Not my system crashed, the USR module has done that with the original Firmware (reboots).
My problem ist that your modules is generating endless traffic on my Network, a customer want's
to order 1000 environmental sensor modules which I wanted to equip with your modules. Because
I don't know which computers and other network equipment is used in the customers networks,
I simply can't trust that they work or just behaving a little "non standard" and triggering ethernet
storms in that networks. No Thanks.
Yes, you clearly doing anything for not getting that order.
Regards,
Holm