Re: Wininet PORT command
- From: "Paul Baker [MVP, Windows Desktop Experience]" <paulrichardbaker@xxxxxxxxxxxxxxxx>
- Date: Fri, 27 Feb 2009 10:25:03 -0500
I am now using the INTERNET_FLAG_PASSIVE flag so that it uses PASV instead
of PORT. It doesn't have to determine the local IP address and it works
fine.
I wanted it to be using PASV anyway. If my recollection is correct, it used
to use the default in Internet Options but that must have changed at some
point in WinInet.
My theory about why it changed with no change in documentation is:
1. One group of people complained that there is no way to force PORT and so
customers are able to "screw up" things for applications that must use PORT
by fiddling with that option. Simply omitting the INTERNET_FLAG_PASSIVE flag
did not force PORT. Adding another flag (giving four combinations of flag
and one global option) would cause mass confusion. Therefore, omitting
INTERNET_FLAG_PASSIVE to force PORT makes sense.
2. Another group of people complained that the behaviour of their
application suddenly changed because the gloval option default suddent
changed from PORT to PASV in Windows Server 2003 SP1 if I recall correctly.
3. Noone should complain that failing to use INTERNET_FLAG_PASSIVE does not
guarantee passive because it never did and what it does now is not contrary
to the documentation.
I am not sure if I want to go to the effort of seeking confirmation of this
change in behaviour and clarification of the documentation. Should I?
Paul
"Paul Baker [MVP, Windows Desktop Experience]"
<paulrichardbaker@xxxxxxxxxxxxxxxx> wrote in message
news:%2381Ik$2lJHA.4372@xxxxxxxxxxxxxxxxxxxxxxx
Please bear in mind that although we have only seen this problem on one
machine, it may not be machine specific. When I attempted to reproduce the
situation in a controlled environment on the *same* machine, I could not.
I cannot reproduce *exactly* the same environment, as only one instance
can be configured as in production because of all the work it does, but it
was as close as I could get it. This is mysterious to me.
It has ESET NOD32 Antivirus 3.0.684, as most machines on the network do.
Autoruns shows me 2 drivers, 1 service, 1 shell extension and 1 GUI
application associated with NOD32 and very little else. There are no third
party Winsock Providers, just mswsock.dll and winrnr.dll.
The Hosts file looks normal. The only line that is not commented out with
a pound sign reads "127.0.0.1 localhost".
No third party modules are loaded into my process (according to
dbghlp.EnumerateLoadedModules).
The problem was first encountered on 2/2 and now consistently occurs in
production.
The NOD32 program version was most recently updated on 2/6 and not updated
for months prior to that. This does not absolutely rule out NOD32. I am
not going to be popular if I suggest disabling or even uninstalling that
as a troubleshooting technique.
The software that uses WinInet is updated frequently but it has been
working in this situation for years, there are no related recent changes
and the problem can be reproduced after downgrading to the version in use
prior to the errors occuring.
No Windows Updates were installed since last June and everyone else who is
an administrator of the machine has confirmed that they did not install
anything around that time.
I have to be missing something obvious!!
Thanks,
Paul
"Volodymyr Shcherbyna" <v_scherbina@xxxxxxxxxxxxxxx> wrote in message
news:OpDJMi2lJHA.3380@xxxxxxxxxxxxxxxxxxxxxxx
So if it's the case just with one machine, I would start to look at its
configuration: anything filtering, routing, etc software?
--
Volodymyr M. Shcherbyna, blog: http://www.shcherbyna.com/
(This posting is provided "AS IS" with no warranties, and confers no
rights)
"Paul Baker [MVP, Windows Desktop Experience]"
<paulrichardbaker@xxxxxxxxxxxxxxxx> wrote in message
news:%23Hw3qe2lJHA.2384@xxxxxxxxxxxxxxxxxxxxxxx
Thanks, I thought about that. But I can only reproduce it on this one
machine in the instance of the process that is running in production. I
cannot even get another instance, that is configured a little
differently, or a test program to reproduce it. So I don't have anything
to debug against. And I see that all my tests are using the correct IP
address. So I am hoping for some theories on what factors could affect
something like this.
It's Windows Server 2003 R2 Service Pack 2.
Paul
"Volodymyr Shcherbyna" <v_scherbina@xxxxxxxxxxxxxxx> wrote in message
news:eaYKaY2lJHA.4128@xxxxxxxxxxxxxxxxxxxxxxx
Hello Paul,
Since you are MVP and you have an access to MSFT source code, you can
debug wininet sources :). Just Find plain XP SP2 (make sure it does not
update, as symbols will be different), and configure your debugger as
it's written at codepremium.
--
Volodymyr M. Shcherbyna, blog: http://www.shcherbyna.com/
(This posting is provided "AS IS" with no warranties, and confers no
rights)
"Paul Baker [MVP, Windows Desktop Experience]"
<paulrichardbaker@xxxxxxxxxxxxxxxx> wrote in message
news:evXyoU1lJHA.3888@xxxxxxxxxxxxxxxxxxxxxxx
We have an application that uses WinInet to connect to an FTP server.
Forgive me if I am posting this in the wrong place, but I suspect it's
more of a sockets problem than a WinInet problem.
Whenever it attempts to open a data connection, the server immediately
resets the control connection (ERROR_INTERNET_CONNECTION_RESET).
Wireshark shows me that it is sending a "PORT 127,0,0,1,<...>,<...>"
command. This gives rise to some questions and I am not sure how to
proceed.
1. What is causing it to send the IP address 127.0.0.1? This is the
loopback interface, it should be sending the "real" IP address.
2. Is the resetting of the control connection the server's way of
handling it, either because it sees it as a security violation or
doesn't know what to do?
3. Why is it that so far any attempts to reproduce it in a test
application with the same code base result in it sending the "real" IP
address and no failure?
4. I am not passing INTERNET_FLAG_PASSIVE. But I was expecting it to
use the default in Internet Options, which has "Use passive FTP..."
checked. Should it be? And if so, why is it not?
Thanks,
Paul
.
- References:
- Wininet PORT command
- From: Paul Baker [MVP, Windows Desktop Experience]
- Re: Wininet PORT command
- From: Volodymyr Shcherbyna
- Re: Wininet PORT command
- From: Paul Baker [MVP, Windows Desktop Experience]
- Re: Wininet PORT command
- From: Volodymyr Shcherbyna
- Re: Wininet PORT command
- From: Paul Baker [MVP, Windows Desktop Experience]
- Wininet PORT command
- Prev by Date: Re: multicast bind fails in vista
- Next by Date: Re: retriving mac address from IP
- Previous by thread: Re: Wininet PORT command
- Next by thread: C# use IO Completion
- Index(es):
Relevant Pages
|