Re: [tcpconnect] doing nothing- SM any help here???
This WebDNA talk-list message is from 2001
It keeps the original formatting.
numero = 37964
interpreted = N
texte = I appear to be the only one ever to encounter this situation... Any information available from Smith Micro?Recap: [TCPCONNECT] not working on client's Windows (some NT variant) server - the code that works perfectly on my MacOS X server and used to work fine on client's server (UPS and CyberCash access) now returns BLANK - no error, no reply, nothing. All other WebCat code is working without a hitch.A note from my client's ISP: >The only thing we have done in the last month or so is to turn off >ICMP packets in response to the CODE RED WORM. We need more info >from your WEB guy as to what WEBCATALOG is trying to do with the >TCPCONNECT before we can be of much help.What system services does TCPCONNECT require that may have become unavailable?Would re-installing WEBCAT be likely to make any difference?Would upgrading from 4.02 rc1 to 4.02rc2 be likely to make any difference?Any input at all would be helpful.- BrianAt 12:49 PM 8/16/2001, Brian Fries wrote: >The server has been rebooted - more than once - and I have tried >using the IP number instead of the domain name for UPS, to no >avail... > >The exact same code running on my MacOS X server works fine, while >on my client's Windows server I get no response at all from the >[tcpconnect] context. > >Is there some system service that [tcpconnect] uses on Windows that >may not be running an may be causing this problem? > >Brian > >At 6:23 AM +0000 8/8/2001, Peter Werno wrote: >>Hello Brian, >> >>as it is a Windows-Box, rebooting may help :-) >>Something else that came to my mind was DNS setup. Maybe the Server >>doesn't get the DNS-information for UPS? Have you tried using the >>IP-Address instead? >> >>Just a guess... >> >>Ciao, >> >>Peter >> >>On Tue, 7 Aug 2001 15:35:43 >> Brian Fries
wrote: >>> I have a client running WC 4.0.2 rc1 on a Windows box (not sure what >>> windows - I assume some NT variant). In his checkout pages, the code >>> is doing a TCPCONNECT to UPS, but absolutely nothing is being >>> returned. When I run the exact same TCPCONNECT call on my Mac OS X >>> server (same WC rev), it works perfectly fine. The key line is: >>> >>> [text show=f]fullResponse=[tcpconnect >>> host=www.ups.com&port=80][tcpsend][msgOut][/tcpsend][/tcpconnect][/text] >>> >>> >>> [msgOut] is correctly set (verified identical to that sent from my >>> server), but when this is hit on his server, [fullResponse] comes >>> back empty, while on my server it returns a proper response value. >>> >>> It is as though [tcpconnect] is doing nothing at all. I didn't do the >>> original development on this site, but was called in to clean up the >>> messes left behind by the previous developer. During earlier test >>> cycles, this [tcpconnect] problem did not show itself, so I assume it >>> was working fine. The code hasn't changed since then. >>> >>> ... one other odditity I found: when I put a [version] tag on this >>> page, I get the value 1.5 returned, while the [version] tag on the >>> admin statistics page returns the correct 4.0.2 rc1 value. Anyone >>> seen this behavior before? >>> >>> Any thoughts or suggestions on getting the [tcpconnect] working >>> properly? Would rebooting the machine be likely to help? >>> >>> Thanks, >>> Brian -- <= Brian C. Fries, BrainScan Software http://www.brainscansoftware.com =>------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://search.smithmicro.com/
Associated Messages, from the most recent to the oldest:
I appear to be the only one ever to encounter this situation... Any information available from Smith Micro?Recap: [tcpconnect] not working on client's Windows (some NT variant) server - the code that works perfectly on my MacOS X server and used to work fine on client's server (UPS and CyberCash access) now returns BLANK - no error, no reply, nothing. All other WebCat code is working without a hitch.A note from my client's ISP: >The only thing we have done in the last month or so is to turn off >ICMP packets in response to the CODE RED WORM. We need more info >from your WEB guy as to what WEBCATALOG is trying to do with the >TCPCONNECT before we can be of much help.What system services does TCPCONNECT require that may have become unavailable?Would re-installing WEBCAT be likely to make any difference?Would upgrading from 4.02 rc1 to 4.02rc2 be likely to make any difference?Any input at all would be helpful.- BrianAt 12:49 PM 8/16/2001, Brian Fries wrote: >The server has been rebooted - more than once - and I have tried >using the IP number instead of the domain name for UPS, to no >avail... > >The exact same code running on my MacOS X server works fine, while >on my client's Windows server I get no response at all from the >[tcpconnect] context. > >Is there some system service that [tcpconnect] uses on Windows that >may not be running an may be causing this problem? > >Brian > >At 6:23 AM +0000 8/8/2001, Peter Werno wrote: >>Hello Brian, >> >>as it is a Windows-Box, rebooting may help :-) >>Something else that came to my mind was DNS setup. Maybe the Server >>doesn't get the DNS-information for UPS? Have you tried using the >>IP-Address instead? >> >>Just a guess... >> >>Ciao, >> >>Peter >> >>On Tue, 7 Aug 2001 15:35:43 >> Brian Fries wrote: >>> I have a client running WC 4.0.2 rc1 on a Windows box (not sure what >>> windows - I assume some NT variant). In his checkout pages, the code >>> is doing a TCPCONNECT to UPS, but absolutely nothing is being >>> returned. When I run the exact same TCPCONNECT call on my Mac OS X >>> server (same WC rev), it works perfectly fine. The key line is: >>> >>> [text show=f]fullResponse=[tcpconnect >>> host=www.ups.com&port=80][tcpsend][msgOut][/tcpsend][/tcpconnect][/text] >>> >>> >>> [msgOut] is correctly set (verified identical to that sent from my >>> server), but when this is hit on his server, [fullResponse] comes >>> back empty, while on my server it returns a proper response value. >>> >>> It is as though [tcpconnect] is doing nothing at all. I didn't do the >>> original development on this site, but was called in to clean up the >>> messes left behind by the previous developer. During earlier test >>> cycles, this [tcpconnect] problem did not show itself, so I assume it >>> was working fine. The code hasn't changed since then. >>> >>> ... one other odditity I found: when I put a [version] tag on this >>> page, I get the value 1.5 returned, while the [version] tag on the >>> admin statistics page returns the correct 4.0.2 rc1 value. Anyone >>> seen this behavior before? >>> >>> Any thoughts or suggestions on getting the [tcpconnect] working >>> properly? Would rebooting the machine be likely to help? >>> >>> Thanks, >>> Brian -- <= Brian C. Fries, BrainScan Software http://www.brainscansoftware.com =>------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://search.smithmicro.com/
Brian Fries
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...
Related Readings:
Running _every_ page through WebCat ? (1997)
WebCatalog f2 Installation (1997)
URL for Discussion Archive (1997)
Sample Tearoom Search Error (1997)
Fun with Dates - revisited (1997)
Web Hosters with WebCatalog support (2000)
Spiders (1998)
Running 2 two WebCatalog.acgi's (1996)
How To question on setting up downloads (1997)
Using Plug-In while running 1.6.1 (1997)
PCS Frames-Default page is solution! (1997)
Getting URL's entered manually (1997)
Signal Raised (1997)
Talk List Suggestions (1997)
Linux Orderfile Error (2002)
I can help! (1996)
Cart -> Date and Time (2004)
[FIXED] Preserving file creation dates on [copyfile] (2007)
Carts & Refering URLs (1997)
U&P IIS concept (1998)