moparisthebest/curl
1
0
Fork 0
mirror of https://github.com/moparisthebest/curl synced 2024-11-16 06:25:03 -05:00
Code Issues Releases Wiki Activity
dc0a671213
curl/tests/data/test1009

48 lines
532 B
Plaintext
Raw Normal View History

Kim Rinnewitz reported that --local-port didn't work with TFTP transfers. This happened because the tftp code always uncondionally did a bind() without caring if one already had been done and then it failed. I wrote a test case (1009) to verify this, but it is a bit error-prone since it will have to pick a fixed local port number and since the tests are run on so many different hosts in different situations I add it in disabled state.
2007-10-04 06:01:41 -04:00
<testcase>
<info>
<keywords>
TFTP
TFTP RRQ
I enabled test 1009 and made the --local-port use a wide range to reduce the risk of failures.
2007-10-04 17:26:26 -04:00
--local-port
Kim Rinnewitz reported that --local-port didn't work with TFTP transfers. This happened because the tftp code always uncondionally did a bind() without caring if one already had been done and then it failed. I wrote a test case (1009) to verify this, but it is a bit error-prone since it will have to pick a fixed local port number and since the tests are run on so many different hosts in different situations I add it in disabled state.
2007-10-04 06:01:41 -04:00
</keywords>
</info>
#
# Server-side
<reply>
<data>
a chunk of
data
returned
to client
</data>
</reply>
#
# Client-side
<client>
<server>
tftp
</server>
<name>
I enabled test 1009 and made the --local-port use a wide range to reduce the risk of failures.
2007-10-04 17:26:26 -04:00
TFTP retrieve with --local-port
Kim Rinnewitz reported that --local-port didn't work with TFTP transfers. This happened because the tftp code always uncondionally did a bind() without caring if one already had been done and then it failed. I wrote a test case (1009) to verify this, but it is a bit error-prone since it will have to pick a fixed local port number and since the tests are run on so many different hosts in different situations I add it in disabled state.
2007-10-04 06:01:41 -04:00
</name>
<command>
I enabled test 1009 and made the --local-port use a wide range to reduce the risk of failures.
2007-10-04 17:26:26 -04:00
tftp://%HOSTIP:%TFTPPORT//1009 --local-port 44444-45444
Kim Rinnewitz reported that --local-port didn't work with TFTP transfers. This happened because the tftp code always uncondionally did a bind() without caring if one already had been done and then it failed. I wrote a test case (1009) to verify this, but it is a bit error-prone since it will have to pick a fixed local port number and since the tests are run on so many different hosts in different situations I add it in disabled state.
2007-10-04 06:01:41 -04:00
</command>
</client>
#
# Verify pseudo protocol after the test has been "shot"
<verify>
<protocol>
opcode: 1
mode: octet
tftp tests: verify sent options too The tftpd test server now logs all received options and thus all TFTP test cases need to match them exactly. Extended test 283 to use and verify --tftp-blksize.
2015-11-06 04:52:19 -05:00
tsize: 0
blksize: 512
timeout: 6
filename: /1009
Kim Rinnewitz reported that --local-port didn't work with TFTP transfers. This happened because the tftp code always uncondionally did a bind() without caring if one already had been done and then it failed. I wrote a test case (1009) to verify this, but it is a bit error-prone since it will have to pick a fixed local port number and since the tests are run on so many different hosts in different situations I add it in disabled state.
2007-10-04 06:01:41 -04:00
</protocol>
</verify>
</testcase>
Reference in New Issue Copy Permalink