drivers: modem: sim7080: handle F_GETFL/F_SETFL in offload_ioctl

[dafiest-hub]

Problem

With CONFIG_NET_SOCKETS_SOCKOPT_TLS=y (native TLS over the offloaded socket, e.g. CONFIG_MQTT_LIB_TLS=y), every connection attempt over the SIM7080 driver fails before AT+CAOPEN is ever sent. The only visible symptom is a confusing cleanup-path error:

<err> modem_simcom_sim7080_sock: AT+CACLOSE=0 ret: -5
<err> net_mqtt: mqtt_connect: -22

Root cause

ztls_connect_ctx() (subsys/net/lib/sockets/sockets_tls.c) calls zsock_fcntl(F_GETFL) on the underlying offloaded socket to clear/restore O_NONBLOCK around the TLS handshake, before issuing the underlying connect(). The driver's offload_ioctl() only handles the three poll ioctls, so F_GETFL hits the default: branch (errno = EINVAL, return -1). The TLS layer then aborts the connect, the socket is closed (producing the AT+CACLOSE=0 on a socket that was never opened), and mqtt_connect() surfaces -EINVAL.

Fix

Handle ZVFS_F_GETFL and ZVFS_F_SETFL by returning 0: the offloaded socket is always blocking, and non-blocking reads are requested per call via MSG_DONTWAIT. This is the same approach used by the ublox-sara-r4 and hl78xx drivers.

Testing

Tested on SIM7080G (Cat-M1, Telcel MX) hardware on esp32_devkitc/esp32/procpu, connecting to an EMQX broker on port 8883 with CONFIG_NET_SOCKETS_SOCKOPT_TLS=y + CONFIG_MQTT_LIB_TLS=y (mbedTLS in software over the plain-TCP offload): without this change mqtt_connect() always fails with -EINVAL; with it the TLS handshake completes and the MQTT session (CONNACK, QoS1 subscribe/publish) runs normally.

Disclosure

This issue was diagnosed and the fix developed with the assistance of an AI tool (Claude Code); the change was reviewed and verified on real hardware by the author.

🤖 Generated with Claude Code

https://claude.ai/code/session_01P1pQeLhNjvsTrXARmZ3LwK

[github-actions]

Hello @dafiest-hub, and thank you very much for your first Pull Request (PR) to the Zephyr Project!

All PRs must pass our Continuous Integration (CI) pipeline before merging. When the pipeline run for your PR completes, you are expected to investigate the results, fix any errors, and update your PR for a fresh round of review.

Since this is your first contribution, a project community member must manually approve your CI run (this helps us avoid abuse of our CI system). A bot should assign some reviewers who can start the run for you soon.

As a heads-up, you will probably have to update your PR to fix CI issues and address review feedback in order to get it ready for merge. Some key rules for updating your PR are:

• do amend problematic commits on your computer and force push the fixed commits into your PR branch on GitHub
• don't push new commits just to fix problems in existing PR commits (amend your commits instead)
• don't close your PR and open an updated one unless reviewers specifically request it (force push to your branch instead)
• do rebase your PR branch onto our main branch and force push to this PR to resolve merge conflicts
• don't merge our main branch into your PR branch to fix merge conflicts

Also, see:

• Contribution Guidelines for details on how contributing to Zephyr works
• Contributor Expectations to learn what our community expects from you
• Reviewer Expectations to learn what you can expect from community members who review this PR

If you are stuck or need help, you can join us on Discord and ask questions; many community members try to help new contributors there 😊. Try to pick a Discord channel that is associated with the technical details of your request. If you're not sure, use the #general channel.