The library should be using internal socket API functions
so that we do not need to depend on POSIX_API inside the
network stack.
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
Make sure that the error message does not overflow the transmit buffer
when copying the error message string.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
There's not really much to do when the transmission of the error reply
fails, but we can at least log the failure.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Use client context to seperate buffer usage.
Use new `TFTP_EVT_DATA` event to send data to application.
Use new `TFTP_EVT_ERROR` event to report error to application.
Update `tftp_get()` and `tftp_put()` API to use the client context.
Signed-off-by: Jun Qing Zou <jun.qing.zou@nordicsemi.no>
Add a callback for READ request to download files with arbitrary length.
Define TFTP_BLOCK_SIZE in API header for application to allocate buffer.
Signed-off-by: Jun Qing Zou <jun.qing.zou@nordicsemi.no>
As of today <zephyr/zephyr.h> is 100% equivalent to <zephyr/kernel.h>.
This patch proposes to then include <zephyr/kernel.h> instead of
<zephyr/zephyr.h> since it is more clear that you are including the
Kernel APIs and (probably) nothing else. <zephyr/zephyr.h> sounds like a
catch-all header that may be confusing. Most applications need to
include a bunch of other things to compile, e.g. driver headers or
subsystem headers like BT, logging, etc.
The idea of a catch-all header in Zephyr is probably not feasible
anyway. Reason is that Zephyr is not a library, like it could be for
example `libpython`. Zephyr provides many utilities nowadays: a kernel,
drivers, subsystems, etc and things will likely grow. A catch-all header
would be massive, difficult to keep up-to-date. It is also likely that
an application will only build a small subset. Note that subsystem-level
headers may use a catch-all approach to make things easier, though.
NOTE: This patch is **NOT** removing the header, just removing its usage
in-tree. I'd advocate for its deprecation (add a #warning on it), but I
understand many people will have concerns.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Logging v1 has been removed and log_strdup wrapper function is no
longer needed. Removing the function and its use in the tree.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
In order to bring consistency in-tree, migrate all subsystems code to
the new prefix <zephyr/...>. Note that the conversion has been scripted,
refer to zephyrproject-rtos#45388 for more details.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
With the introduction of `EXPERIMENTAL` and `WARN_EXPERIMENTAL` in
Zephyr all subsys/net and drivers/ethernet/Kconfig.e1000 settings
having `[EXPERIMENTAL]` in their prompt has has been updated to include
`select EXPERIMENTAL` so that developers can enable warnings when
experimental features are enabled.
The following settings has EXPERIMENTAL removed as they are considered
mature:
- NET_OFFLOAD
- NET_PROMISCUOUS_MODE
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
- bugfix: Accept initial tftp server reply from a port different than
the one used to establish the connection (typically 69) as mandated
by RFC 1350. Previous implementation was not standard compliant.
- bugfix: close socket in case of error or timeout.
- bugfix: Reset retransmit counter after receipt of a good packet.
- bugfix: Use CONFIG_TFTP_LOG_LEVEL to set log level.
- api: upon successful receipt of the file set `client.user_buf_size`
to the size of the file received.
- Restructure the code, comments.
- Limit usage of global variables.
- Limit usage of `goto`.
Signed-off-by: Piotr Mienkowski <piotr.mienkowski@gmail.com>
Adding RFC1350 compliant support for TFTP Client in Zephyr. The
current implementation is minimal and only supports the ability
to get a file from the server.
Things for the future include support for putting files to
server and adding support for RFC2347.
Signed-off-by: Bilal Wasim <bilalwasim676@gmail.com>
Jukka Rissanen