Failing to download files from s3 aws platform on i.MX6 platform

Technical Support
, , , ,
1

Hi,

Platform Details
SoC: Toradex i.MX6QDL (custom carrier board)
Module: GSM modem (PPP-based connectivity)
OS: Linux 4.14.170 (Yocto-based)
OpenSSL: 1.1.1g
Connectivity: PPP over cellular (M2M SIM)

Problem Summary

On the embedded device, basic network connectivity is functioning correctly:

  • ICMP works (ping 8.8.8.8, google.com)

  • DNS resolution works

However, HTTPS/TLS connections consistently fail with the following error:

write:errno=104 (Connection reset by peer)
SSL handshake has read 0 bytes

This issue occurs when connecting to Amazon Web Services S3 endpoints as well as general HTTPS servers (e.g., Google). The same commands work without any issues when executed from a standard PC on a regular network.

Observed Behavior

  1. Standard TLS connection (fails)
    Command:
    openssl s_client -connect google.com:443 -servername google.com

Result:

  • TCP connection is established

  • TLS ClientHello is sent

  • Immediate TCP reset (RST) is received

  • No ServerHello response

  1. AWS/S3 access (fails)
    HTTPS downloads from S3 using wget fail with:
    Connection reset by peer

  2. TLS without SNI (works)
    After applying:
    sysctl -w net.ipv4.route.min_adv_mss=1200
    sysctl -w net.ipv4.tcp_base_mss=1200

Command:
openssl s_client -connect <S3_IP>:443 -noservername

Result:

  • TLS handshake completes successfully

  • Valid S3 certificate is received

  • HTTP response is returned (400 expected due to missing Host header)

  1. Python workaround (SNI disabled)
    Disabling SNI in the TLS handshake allows successful downloads. This confirms that the TLS stack is functioning correctly and suggests the issue is at the network level.

Test Matrix

IP:443 (no SNI) → Success
IP:443 (with SNI = *.amazonaws.com) → Connection reset
s3.amazonaws.com:443 → Connection reset
s3.ap-south-1.amazonaws.com:443 → Connection reset

Key Observation

TLS ClientHello packets containing the SNI extension trigger an immediate TCP reset, while TLS connections without SNI succeed. This indicates possible Deep Packet Inspection (DPI) or carrier/network-level filtering.

We wanted to understand the following:

  1. Why does this issue occur specifically on the embedded device using the M2M SIM? We also tested with a different custom board and a regular SIM card and observed the same behavior.

  2. Is there a recommended or supported approach to resolve this issue without disabling SNI, since disabling SNI is not a viable long-term solution?

Thanks,
Adnan

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

I appreciate your detailed description of the TLS/SNI connectivity issue. However, the problem you’re describing appears to be related to network/cellular carrier filtering rather than Toradex-specific software or hardware configuration.

Based on your findings, this appears to be Deep Packet Inspection (DPI) by your M2M cellular carrier that’s blocking TLS connections with SNI extensions - a common practice by some carriers to control bandwidth or filter certain types of traffic.

Recommendations

Since this is primarily a network/carrier-level issue rather than a Toradex platform issue, I’d suggest:

  1. Contact your cellular carrier - This is the most direct approach since they control the DPI filtering
  2. Consider alternative carriers - Test with different M2M providers that may have less restrictive policies
  3. VPN tunneling - Establish a VPN connection to bypass DPI filtering
  4. Alternative protocols - Consider using non-HTTPS protocols where possible

Toradex-Specific Resources

For networking and connectivity development on Toradex platforms, you might find these resources helpful(1):

  • Network and Connectivity documentation - covers Wi-Fi, Bluetooth, and networking applications
  • Application Development guides - for developing connectivity solutions on embedded Linux

You may also find relevant discussions on the Toradex Community by searching for “cellular connectivity” or “M2M networking.”

Since this appears to be a carrier-level restriction rather than a platform-specific issue, the solution will likely need to be implemented at the network level rather than through Toradex software configuration.

Best regards,
Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

3

Hi @adnan ,

From the logs, it appears that the issue is not specific to AWS S3, but rather that HTTPS/TLS connections are failing in general. Since the same behavior is observed when connecting to other HTTPS endpoints, it would be helpful to narrow down the root cause.

Could you please provide the following information?

  • Which Toradex module and carrier board are you using?

  • Which BSP/Torizon OS version are you running?

  • Does the issue occur only with your application, or can it also be reproduced using commands such as:

    wget https://www.google.com
curl -v https://www.google.com
openssl s_client -connect google.com:443

  • Does the same test work on another network (for example, using a mobile hotspot)?