Gambit,
> You do not need to index into the Bindings like that. Add()
> returns the necessary TIdSocketHandle object pointer.
Understood and fixed. Thanks.
> Then there has to be something else happening. Either the UDP
> packets are not being sent to the correct IP/Port to begin with,
> or they are being blocked along the way.
Reminder:
One IP is on the wired network.
The other IP is my WiFi network.
The TFTP client is on the same hub as the server station (hub as in
"promiscuous mode needed for LAN analysis") and always calls the wired
IP address of the server (it doesn't even know about the WiFi IP).
I run the server with the WiFi disabled, one IP: Everything works.
I plug the WiFi (not changing anything else, client still on the wired
LAN) and restart the delphi app: the packet comes into the server (LAN
analyser), is not answered, and the OnReadFile breakpoint never triggers.
I unplug the WiFi adapter and restart the delphi app, everything works
fine again.
So everything else being identical (including the incoming requests, as
confirmed by the LAN analyzer), the simple fact of adding or removing
the second IP makes the problem come and go.
IMHO, that pretty much removes any concern about firewalling, routing
and whatever issues, which were the first ones I considered - and discarded.
And if I simply reverse the order in which the bindings are created so
that the wired LAN is ahead of the collection, I get ONE answer on the
first TFTP request. Which seems to point to the server only listening on
the first address that I bound, for some reason.
> When was the last time you downloaded it, though? The snapshot
> has been 10.1.5 for a long time now, but has received many updates.
Frankly, I'm not quite sure, but that's definitely over 6 months ago. I
used whatever 10.1.5 was considered as "stable" back then - I didn't go
for the snapshot.
Looking at the source files, the most recent ones I found have been
modified nearly one year ago, Oct 19th, 2005, so it might even be more
than 6 months.
Since the update process is rather delicate and painful (specially the
cleaning up, where forgetting to remove some old file can have various
hard to relate consequences), I try to limit the odds of breaking
existing working apps with new snapshot code, and tend to only update
when an "official release" occurs, or when some bug I experienced is
know to have been fixed.
Which might actually be the case <sigh>.
>> At startup, TFTPServer only listen to the first of its
>> bindings.
>
> Not true. It actively listens on all entries in the
> Bindings collection equally.
I find "Not true" a bit harsh, here:
I'm convinced that it's designed to behave as you say. But I've done
enough homework to be just as convinced that for some reason, the Indy
version I have does not behave as designed. I'm not saying it's not my
fault either. I'm just trying to figure it out. And with the very
extensive Googlin' I've done on both web and newsgroups before I started
to post here, it does seem like so many of us have been trying to run
multi-homed UDP servers either with Indy 10. So it's not like claiming
that TObject has a bug. ;-)
I appears that with the experimental data I provided above (and the Indy
version that I have), the TFTP UDP server only answers on the first of
the entries I bind. And since the client requests only come from the
wired LAN, nothing happens when the WiFi LAN is bounded first.
And I did check that the request does come in.
I started yesterday to study the Indy source code (the one year old that
I have to start with), and even though this is quite a bit of work, I'm
starting to see more precisely what's going on, and if I understand it
properly, it confirms what I'm seeing.
When I have figured it out clearly with a little help from the debugger,
I'll look at the sources for the current snapshot and see if anything
has changed in that area. /Ph.
