This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

TCPnet Error Codes

I posted earlier and got no response and just wanted to follow up once more.

I have RL-ARM TCPnet setup on a device and it only connects and sends and email via the SMTP functions about 50% of the time; all other times it comes back with SMTP_EVT_TIMEOUT or SMTP_EVT_ERROR as shown here: http://www.keil.com/support/man/docs/rlarm/rlarm_smtp_connect.htm

Unfortunately the descriptions of what those error mean is very lacking: in terms of what caused any possible timeout or protocol error.

The following page has a link for error functions but the link actually just takes you to the Ethernet functions page. http://www.keil.com/support/man/docs/rlarm/rlarm_tn_func_ref.htm

I have run Wireshark but the switch I'm using doesn't support port mirroring so I have no way to see the actual data entering and leaving the device and onto the network. I can however see the DHCP request, offer, ack etc.

If anyone has used the TCPnet libraries before and has had any experience with the SMTP functionality, any help is appreciated.

  • There are several reasons that might be causing your problem. Try a debug library and capture the messages. Start with full SMTP debug, and post the log here.

    You can not use an ethernet switch, if you want to track the traffic with Wireshark. However old LAN hubs might be used for that, as hubs are not smart and forward LAN packets to all ethernet ports.

  • Note that hubs are very hard to find anymore, but a modern supervised switch can be used - most supervised switches supports mirroring of data to a supervision port just to allow an IT admin to listen in to help find problems.

    There are lots of quite inexpensive supervised switches on the market.

  • I am looking into using the debug library with my setup.

    My switch is new, so it is very unlikely it sends all packets to all ports. In addition it is a very basic one and non programmable, so I can't configure port mirroring.

    If I can't get the debug working the best option may be buying a supervised switch.

  • No - switches do not send all packets to all ports. If they did, then they wouldn't be switches but stupid hubs.

    But supervised switches often have an administrative interface where an administrator can configure that he wants all traffic on port "n" to be duplicated on a dedicated monitor port, where he can connect a tcp-dump application and analyze exactly what happens on port "n".