Gambit,
>> In the OnReadFile event, when GrantAccess returns False, the server
>> doesn't answer anything instead of returning a "file not found"
>> error message to the TFTP client.
>
> You never said anything about that earlier.
Nope, because I didn't notice it immediately: I started testing the case
that works (i.e. where a file is to be found). And when the TFTPed file
actually exists in the TFTP directory, I give back GrantAccess set to
True, and everything works fine. Ditto in single homing for both
GrantAccess set to True and False.
The only case that doesn't work is the case where we have both
multi-homing AND GrantAccess set to false, resulting in that exception
sequence we both traced.
So whatever the problem, it seems to be related to the use of this very
code path.
>> I so far traced the code through the exception handlers to the
>> point where it is supposed to send of a "File not found" message
>> as a reply, but haven't yet got to the point where I could see what
>> prevents the send from occurring.
>
> The only thing that can be preventing it is a socket error, or a
> firewall/router blocking the packet before it reaches the client.
But if it where a firewall problem or a socket error, , while would the
whole dialog work in the very same program run when I set GrantAccess to
True in the same run?
And if it's why would it happen when the machine has two IP addresses
and not one?
IOW, in all tests sequences, the client requests always come from the
same client on the same wired network, and we see:
When the machine is single-homed:
- client requests a file that exists => file is sent, SUCCESS
- client now requests another file that doesn't exist => file is not
sent, "file not found" error is returned, SUCCESS
When the machine is dual-homed:
- client requests a file that exists => file is sent, no protocol error,
SUCCESS,
- client now requests another file that doesn't exist => no reply from
TFTP Server, *FAILURE*.
Indidentally, all along since I ran into the first problem with the
one-year old packaged version, I have also checked the same client
request scenario using Philippe Jounin's excellent small DHCP / TFTP /
FTP / SysLog server, (TFTPD32, see
http://tftpd32.jounin.net/tftpd32_download.html)
The idea was to eliminate as much as possible an issue such as firewall,
DHCP, IP config or whatever issue local to the test machines.
And Jounin's TFTPD32 indeed works fine under the same testing condition
(same machine, same client, same NICs enabled).
That didn't surprise me that much, as the Indy TFTP code worked
perfectly on the same single-homed machine, but I had to be real sure.
Also, one of the client software part that I use for my testing is the
PXE client embedded in most NICs, that allows to remote boot PCs. This
firmware gets its address and a boot loader file name from a DHCP
server, then tries to get the boot loader file using the filepath it got
from DHCP.
> Incidently, do you have any anti-virus programs running at the
> time of your tests? Either McAfee or Norton (I forget which one)
> is known to interfer with Indy sockets sometimes.
I am running an up-to-date version of Norton AV, and I jun ran a test
sequence after disabling it with the same results. In addition, the NAV
I'm running is the garden variety, not the "internet protection" bulky
mess. It's the minimal file access scan version, so I wouldn't expect it
to mess up too much with my ports, except may be on the TCP / EMail ones.
> procedure SendError(UDPBase: TIdUDPBase; APeerIP: string;
> const APort: Integer; E: Exception);
> (<snip>)
I had landed with the debugger precisely to the place you show in the
code you copied when I said in a previous message:
"I so far traced the code through the exception handlers to the point
where it is supposed to send of a "File not found" message as a reply",
but haven't yet got to the point where I could see what prevents the
send from occurring",
The exact place I was stuck at is:
procedure SendError(UDPBase: TIdUDPBase;
APeerIP: string; const Aport:Integer;
E: Exception);
var
ErrNumber: Word;
begin
ErrNumber := ErrUndefined;
if E is EIdTFTPFileNotFound then ErrNumber := ErrFileNotFound; //
(...)
SendError(UDPBase, APeerIP, APort, ErrNumber, E.Message);
end;
But I'm not done yet, because when I <F8> on the incarnation of
SendError copied above, things are OK, parms seem OK, ErrNumber gets set
to ErrFileNotFound.
But then, when the 4-parms SendError call happens:
SendError(UDPBase, APeerIP, APort, ErrNumber, E.Message);
I seem to immediately recur in the previous exception handler that got
me there on the first place (with nothing sent out, looking at the LAN
analyzer living in the same machine).
Tracing with the debugger (<F8>, the loop seems infinite.
But that's in fact not the case, though, since the test program doesn't
show any pathological CPU peak when ran outside of the debugger. It just
doesn't answer, still waiting for the next retry from the client (that
it will process but without answering either,) etc.
<F7> tracing through the 4-parms version of the SendError routine is
very tricky, though, and I haven't yet been successful at pinning down
the place where and reason why it happens.
I'm going to get back at it <sigh>. /Ph.
