<feed xmlns='http://www.w3.org/2005/Atom'>
<title>src/libexec/tftpd/Makefile, branch release/13.4.0</title>
<subtitle>FreeBSD source tree</subtitle>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/'/>
<entry>
<title>Remove $FreeBSD$: one-line sh pattern</title>
<updated>2023-08-23T17:43:30+00:00</updated>
<author>
<name>Warner Losh</name>
<email>imp@FreeBSD.org</email>
</author>
<published>2023-08-22T01:32:01+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=023fc80ee38a117fa65b2ccb2abf8bdc7dbd6fd9'/>
<id>023fc80ee38a117fa65b2ccb2abf8bdc7dbd6fd9</id>
<content type='text'>
Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/

Similar commit in main:
(cherry picked from commit d0b2dbfa0ecf)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/

Similar commit in main:
(cherry picked from commit d0b2dbfa0ecf)
</pre>
</div>
</content>
</entry>
<entry>
<title>Add some functional tests for tftpd(8)</title>
<updated>2018-03-09T15:30:20+00:00</updated>
<author>
<name>Alan Somers</name>
<email>asomers@FreeBSD.org</email>
</author>
<published>2018-03-09T15:30:20+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=888651fcd900b81fdf0d766d9e05639e7a94f881'/>
<id>888651fcd900b81fdf0d766d9e05639e7a94f881</id>
<content type='text'>
tftpd(8) is difficult to test in isolation due to its relationship with
inetd.  Create a test program that mimics the behavior of tftp(1) and
inetd(8) and verifies tftpd's response in several different scenarios.

These test cases cover all of the basic TFTP protocol, but not the optional
parts.

PR:		157700
PR:		225996
PR:		226004
PR:		226005
MFC after:	3 weeks
Differential Revision:	https://reviews.freebsd.org/D14310
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
tftpd(8) is difficult to test in isolation due to its relationship with
inetd.  Create a test program that mimics the behavior of tftp(1) and
inetd(8) and verifies tftpd's response in several different scenarios.

These test cases cover all of the basic TFTP protocol, but not the optional
parts.

PR:		157700
PR:		225996
PR:		226004
PR:		226005
MFC after:	3 weeks
Differential Revision:	https://reviews.freebsd.org/D14310
</pre>
</div>
</content>
</entry>
<entry>
<title>Conditionalize all code that uses tcpd.h behind `LIBWRAP` guard</title>
<updated>2017-01-06T04:27:07+00:00</updated>
<author>
<name>Enji Cooper</name>
<email>ngie@FreeBSD.org</email>
</author>
<published>2017-01-06T04:27:07+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=4eb4663b0e9042ce0161d0ffffbbc85ffd799c08'/>
<id>4eb4663b0e9042ce0161d0ffffbbc85ffd799c08</id>
<content type='text'>
This will allow the code to stand by itself without libwrap

MFC after:	2 weeks
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This will allow the code to stand by itself without libwrap

MFC after:	2 weeks
</pre>
</div>
</content>
</entry>
<entry>
<title>Convert to LIBADD</title>
<updated>2014-11-25T21:18:18+00:00</updated>
<author>
<name>Baptiste Daroussin</name>
<email>bapt@FreeBSD.org</email>
</author>
<published>2014-11-25T21:18:18+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=ee5a34ecba51f02e3bf46b112e265abf976f39b6'/>
<id>ee5a34ecba51f02e3bf46b112e265abf976f39b6</id>
<content type='text'>
Reduce overlinking
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Reduce overlinking
</pre>
</div>
</content>
</entry>
<entry>
<title>Properly use LDADD &amp; DPADD to link against libwrap.</title>
<updated>2012-05-19T05:10:47+00:00</updated>
<author>
<name>Marcel Moolenaar</name>
<email>marcel@FreeBSD.org</email>
</author>
<published>2012-05-19T05:10:47+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=fab3e10ec33d48f5ace00a388f5c0d1d5e082b0e'/>
<id>fab3e10ec33d48f5ace00a388f5c0d1d5e082b0e</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Make WARNS=6 clean.</title>
<updated>2010-09-24T10:40:17+00:00</updated>
<author>
<name>Marius Strobl</name>
<email>marius@FreeBSD.org</email>
</author>
<published>2010-09-24T10:40:17+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=04ebad38428c939dcc6c0fdeecd601282ae49fab'/>
<id>04ebad38428c939dcc6c0fdeecd601282ae49fab</id>
<content type='text'>
MFC after:	1 week
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
MFC after:	1 week
</pre>
</div>
</content>
</entry>
<entry>
<title>Try to adhere to style.Makefile(5).</title>
<updated>2010-09-23T14:06:15+00:00</updated>
<author>
<name>Marius Strobl</name>
<email>marius@FreeBSD.org</email>
</author>
<published>2010-09-23T14:06:15+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=e865ab086cb43c901edfa5422f5c7def4817d414'/>
<id>e865ab086cb43c901edfa5422f5c7def4817d414</id>
<content type='text'>
MFC after:	3 days
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
MFC after:	3 days
</pre>
</div>
</content>
</entry>
<entry>
<title>Remove an explicit assignment of the CFLAGS variable intended for</title>
<updated>2010-09-15T10:32:32+00:00</updated>
<author>
<name>Rui Paulo</name>
<email>rpaulo@FreeBSD.org</email>
</author>
<published>2010-09-15T10:32:32+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=7ed09cd53578ec7c31da1d188056e41a90127593'/>
<id>7ed09cd53578ec7c31da1d188056e41a90127593</id>
<content type='text'>
debugging purposes only.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
debugging purposes only.
</pre>
</div>
</content>
</entry>
<entry>
<title>Go ahead and merge the work edwin@ on tftpd into the tree.  It is a</title>
<updated>2010-05-04T06:19:19+00:00</updated>
<author>
<name>Warner Losh</name>
<email>imp@FreeBSD.org</email>
</author>
<published>2010-05-04T06:19:19+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=5276e6398137bcf9ea40715400a287fd62c23c3e'/>
<id>5276e6398137bcf9ea40715400a287fd62c23c3e</id>
<content type='text'>
lot better than what's in the tree now.  Edwin tested it at a prior
employer, but can't test it today.  I've found that it works a lot
better with the various uboot versions that I've used in my embedded
work.  Here's the pkg-descr from the port that describes the changes:

It all started when we got some new routers, which told me the
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 &lt;edwin@FreeBSD.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
lot better than what's in the tree now.  Edwin tested it at a prior
employer, but can't test it today.  I've found that it works a lot
better with the various uboot versions that I've used in my embedded
work.  Here's the pkg-descr from the port that describes the changes:

It all started when we got some new routers, which told me the
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 &lt;edwin@FreeBSD.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Make WARNS=6 the default for libexec/.</title>
<updated>2010-01-02T09:50:19+00:00</updated>
<author>
<name>Ed Schouten</name>
<email>ed@FreeBSD.org</email>
</author>
<published>2010-01-02T09:50:19+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=1100c0013116f4af50d7a5b8bf23db2a13892714'/>
<id>1100c0013116f4af50d7a5b8bf23db2a13892714</id>
<content type='text'>
Just like bin/ and sbin/, I think setting WARNS to the highest value
possible will make it more attractive for people to fix warnings.

- The WARNS variable is set in the Makefile in the directory of the
  application itself, making it more likely that it will be removed out
  of curiosity to see what happens.
- New applications will most likely build with WARNS=6 out of the box,
  because the author would more likely fix the warnings during
  development than lower WARNS.

Unfortunately almost all apps in libexec require a lowered value of
WARNS.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Just like bin/ and sbin/, I think setting WARNS to the highest value
possible will make it more attractive for people to fix warnings.

- The WARNS variable is set in the Makefile in the directory of the
  application itself, making it more likely that it will be removed out
  of curiosity to see what happens.
- New applications will most likely build with WARNS=6 out of the box,
  because the author would more likely fix the warnings during
  development than lower WARNS.

Unfortunately almost all apps in libexec require a lowered value of
WARNS.
</pre>
</div>
</content>
</entry>
</feed>
