openslx-ng/ipxe.git/src/net/tcp, branch v0.9.6

[i386] Change [u]int32_t to [unsigned] int, rather than [unsigned] long

2008-11-19T19:15:44+00:00

This brings us in to line with Linux definitions, and also simplifies adding x86_64 support since both platforms have 2-byte shorts, 4-byte ints and 8-byte long longs.

[makefile] Add -Wformat-nonliteral as an extra warning category

2008-10-10T17:41:24+00:00

-Wformat-nonliteral is not enabled by -Wall and needs to be explicitly specified. Modified the few files that use nonliteral format strings to work with this new setting in place. Inspired by a patch from Carl Karsten and an identical patch from Rorschach .

[iscsi] Fix LUN parsing in the iSCSI root-path

2008-09-27T22:53:31+00:00

[iscsi] Change default initiator name prefix to "iqn.2000-01.org.etherboot:"

2008-09-19T16:46:07+00:00

The domain etherboot.org was actually registered on 2000-01-09, not 2000-09-01. (To put it another way, it was registered on 1/9/2000 (US date format) rather than 1/9/2000 (sensible date format); this may illuminate the cause of the error.) "iqn.2000-09.org.etherboot:" is still valid as per RFC3720, but may be surprising to users, so change it to something less unexpected. Thanks to the anonymous contributor for pointing this one out.

[iSCSI] Add support for mutual CHAP

2008-08-11T02:43:12+00:00

Allow initiator to verify target authentication using CHAP.

[ftp] Terminate processing after receiving an error

2008-07-30T19:27:09+00:00

When an error reply (not 1xx, 2xx or 3xx) was received, ftp_reply() invoked ftp_done() to close connections, but did not return, and the rest of code in this function could try to send commands to the closed control connection. Signed-off-by: Sergey Vlasov

[ftp] Cope with RETR completion prior to all data received

2008-07-30T19:22:49+00:00

Based on a patch contributed by Sergey Vlasov : In my testing with "qemu -net user" the 226 response to RETR was often received earlier than final packets of the data connection; this caused the received file to become truncated without any error indication. Fix this by adding an intermediate state FTP_TRANSFER between FTP_RETR and FTP_QUIT, so that the transfer is considered to be complete only when both the end of data connection is encountered and the final reply to the RETR command is received.

[iSCSI] Produce meaningful errors on login failure

2008-06-03T22:47:20+00:00

Return the most appropriate of EACCES, EPERM, ENODEV, ENOTSUP, EIO or EINVAL depending on the exact error returned by the target, rather than just always returning EPERM. Also, ensure that error strings exist for these errors.

[iSCSI] Offer CHAP authentication only if we have a username and password

2008-04-24T12:48:29+00:00

Some EMC targets will fail if we advertise that we can authenticate with CHAP, but the target is configured to allow unauthenticated access to that target. We advertise AuthMethod=CHAP,None; the target should (I think) select AuthMethod=None for unprotected targets. IETD does this, but an EMC Celerra NS83 doesn't. Fix by offering only AuthMethod=None if the user hasn't supplied a username and password; this means that we won't be offering CHAP authentication unless the user is expecting to use it (in which case the target is presumably configured appropriately). Many thanks to Alessandro Iurlano for reporting and helping to diagnose this problem.

[http] gPXE is a HTTP/1.0 client, not a HTTP/1.1 client

2008-03-31T12:01:08+00:00

gPXE is not compliant with the HTTP/1.1 specification (RFC 2616), since it lacks support for "Transfer-Encoding: chunked". gPXE is, however, compliant with the HTTP/1.0 specification (RFC 1945), which does not require "Transfer-Encoding: chunked" to be supported. The only HTTP/1.1 feature that gPXE uses is the "Host:" header, but servers universally accept that one from HTTP/1.0 clients as an optional extension (it is obligatory for HTTP/1.1). gPXE does not, for example, appear to support connection caching. Advertising as a HTTP/1.0 client will typically make the server close the connection immediately upon sending the last data, which is actually beneficial if we aren't going to keep the connection alive anyway.