following when trying to upload configuration or download images
from it: The TFTP server doesn't support the blocksize option.
My curiousity was triggered, it took me some reading of RFCs and
other documentation to find out what was possible and what could
be done. Was plain TFTP very simple in its handshake, TFTP with
options was kind of messy because of its backwards capability: The
first packet returned could either be an acknowledgement of options,
or the first data packet.
Going through the source code of src/libexec/tftpd and going through
the code of src/usr.bin/tftp showed that there was a lot of duplicate
code, and the addition of options would only increase the amount
of duplicate code. After all, both the client and the server can
act as a sender and receiver.
At the end, it ended up with a nearly complete rewrite of the tftp
client and server. It has been tested against the following TFTP
clients and servers:
- Itself (yay!)
- The standard FreeBSD tftp client and server
- The Fedora Core 6 tftp client and server
- Cisco router tftp client
- Extreme Networks tftp client
It supports the following RFCs:
RFC1350 - THE TFTP PROTOCOL (REVISION 2)
RFC2347 - TFTP Option Extension
RFC2348 - TFTP Blocksize Option
RFC2349 - TFTP Timeout Interval and Transfer Size Options
RFC3617 - Uniform Resource Identifier (URI) Scheme and Applicability
Statement for the Trivial File Transfer Protocol (TFTP)
It supports the following unofficial TFTP Options as described at
http://www.compuphase.com/tftp.htm:
blksize2 - Block size restricted to powers of 2, excluding protocol headers
rollover - Block counter roll-over (roll back to zero or to one)
From the tftp program point of view the following things are changed:
- New commands: "blocksize", "blocksize2", "rollover" and "options"
- Development features: "debug" and "packetdrop"
If you try this tftp/tftpd implementation, please let me know if
it works (or doesn't work) and against which implementaion so I can
get a list of confirmed working systems.
Author: Edwin Groothuis <edwin@FreeBSD.org>
- Revise manual page for correctness and completeness
- Reinstate the `-y' (nroff) flag
- Drop gmake(1) dependency, builds with BSD make(1)
- Tweak port description and Makefile markup and syntax
- Pet portlint(1)
Mentioned in PR: ports/119680 [1]
Patches obtained from: Debian
The usage of the miniUPnP client library is useful whenever an application
needs to listen for incoming connections.
Examples : P2P applications, FTP clients for active mode, IRC (for DCC)
or IM applications, network games, any server.
WWW: http://miniupnp.free.fr/
relayd is a daemon to relay and dynamically redirect incoming
connections to a target host. Its main purposes are to run as a
load-balancer, application layer gateway, or transparent proxy. The
daemon is able to monitor groups of hosts for availability, which is
determined by checking for a specific service common to a host group.
WWW: http://spootnik.org/relayd/
# This port will work on $OSVERSION >= 700049.
# If you want to use on RELENG_6, apply a patch in
# http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf_table.c.diff?r1=1.67&r2=1.68
relays the data transfered between the source and the destination.
The goal of this module is to abstract the different methods used to
connect from the proxy to the destination.
A proxy is a program that transfer data across a network boundary
between a client and a server. Net::Proxy introduces the concept of
"connectors" (implemented as Net::Proxy::Connector subclasses), which
abstract the server part (connected to the client) and the client part
(connected to the server) of the proxy.
This architecture makes it easy to implement specific techniques to
cross a given network boundary, possibly by using a proxy on one side of
the network fence, and a reverse-proxy on the other side of the fence.
WWW: http://search.cpan.org/dist/Net-Proxy
PR: ports/119301
Submitted by: Philippe Audeoud <jadawin at tuxaco.net>
