Synergy S7SK board telnet dropping connection

Hi there,

Using SSP 1.0.0 I have a telnet connection set up like is done in the current DEX labs (just passing serial data with a fixed IP address) and I am seeing the connection drop sometimes.  It seems like when the connection is used it stays up but when I walk away and come back the connection may be gone.

Is this a known issue?  and is there a way to keep the connection?  or is it being fixed in the next release?

I may have just done something wrong.

thanks!

Steve S

  • I have the same problem.

  • In reply to marinayelken:

    Same here, any updates/insight? Symptom seems to be a RST being sent from the server and from there on the server no longer responds. Pings work OK, so the connection is still up.
  • In reply to RichZ:

    Hello Rich,

    Have you tried configuring all Ethernet pins to the highest drive capacity available?

    Regards
  • Hi Steve,
    the problem is the global timeout for unused telnet connections.
    The timeout is set to 600s and will be checked every 60s.
    If you want to chenge it, look at the nx_telnet_server.h in the folder ssp/inc/framework/el/nx_application_layer.
    There you can find the defines NX_TELNET_ACTIVITY_TIMEOUT and NX_TELNET_TIMEOUT_PERIOD.

    I hope that can solve your problem.

    Regards Martin
  • In reply to lmartin:

    Thanks for the feedback. I'm not sure either of these are the issue. We are actively using the telnet interface when it fails (issues a RST). Also, pings still work. I will make both mods however as they make sense for other use cases. Any other thoughts?
  • In reply to RichZ:

    Only the telnet connection will be closed by the telnet stack. The ping command is still working and processed by the icmp stack. So, i think all will be work fine ....

    Regards Martin
  • In reply to lmartin:

    Thanks again, but I think we are drifting off topic. The Telnet connection is the issue, not maintaining Ethernet connectivity. During usage I see the telnet server fail (send a RST) and therefore no longer reachable without a power cycle. This is not a pin power issue, nor a timeout setting, but a failure in the server itself I would think. I'll try to gather more details.