Re: Odd sockets problem?

I'll have them do some netstat tests.

The production and test are the same IP, but it's the port
that seems to be goofing up.

>From the AS/400 app, if they use 8080 (test) or 8081 (prod)
for the port, it always seems to connect to 8081 (prod).

>From IE, it works just fine.

I'm going to have him do netstat while connecting to port
8080 and see what netstat says.  If it says 8080, I can
assume it's something with NAT or the networking... if it
says 8081, then I can assume a bug in my program.  But I've
done a bajillion tests, debugged, etc and haven't been able
to see how it could happen.

On Mon, 29 Nov 2004 11:34:28 -0600
 "John Brandt Sr." <pgmr@xxxxxxxxxxxxxxx> wrote:
> Do a NETSTAT during the retrieval. The IP address for
> that job for the
> connection to the remote port should show the production
> IP as opposed to
> the development IP. If it doesn't, then it is a NAT that
> is catching it
> between the 400 and the web server. Logs on the web
> server should show the
> HTTP request coming from the 400 on the production
> machine.
> 
> John Brandt 
> iStudio400.com 
> (903) 523-0708 
> Home of iS/ODBC - MSSQL access from iSeries and RPG. 
> 
> 
> 
> 
> -----Original Message-----
> From: Brad Stone [mailto:brad@xxxxxxxxxxxx]
> Sent: Monday, November 29, 2004 11:29 AM
> To: Midrange Systems Technical Discussion
> Subject: Re: Odd sockets problem?
> 
> 
> That is my thought, but I'm not sure how to tell him how
> to
> look for those types of issues.
> 
> Are there ways to do trace routes to particular ports?
>  And
> if I have him do it from windows (dos), would it be the
> same as from his browser?  Or would IE have anything set
> up
> with it that would cause this sort of problem?
> 
> On Mon, 29 Nov 2004 12:15:18 -0500
>  Jeff Silberberg <jsilberberg@xxxxxxxxxxxxxx> wrote:
> > 
> > Brad,
> > 
> >         Could you have a Firewall / NAT server doing
> some
> > port mapping on 
> > either end ? Trace Routes..
> > 
> >         His workstation with a browser, may be being
> > handled different 
> > than the IP address in the AS/iSeries box. Depending on
> > the rules along the way..
> > 
> >         JMS...
> > 
> > At 12:05 PM 11/29/2004, you wrote:
> > >Ok, here's the scoop.
> > >
> > >I have a customer using my GETURI utility to work with
> > web
> > >services.  He is testing on some IntrAnet services.
> > >
> > >He says he has 2 enviroments set up.  One on port 8080
> > >which is a test environment, and one on ports 8081 and
> > 80
> > >which are production.
> > >
> > >>From a web browser, if he specifies port 8080 or
> 8081,
> > he
> > >gets the right server.
> > >
> > >But from GETURI, he says if he uses port 8080 or port
> > 8081,
> > >he always gets a response back from the 8081 (prod)
> box.
> > >
> > >I had him place a static document on each server.  The
> > test
> > >one said TEST, the Prod one said PROD.  He tested with
> > the
> > >browser, and got the appropriate document.
> > >
> > >He then tested with GETURI, and always got the PROD
> > >document no matter if he specified 8080 or 8081 for
> the
> > >port number.
> > >
> > >I've tripled checked the source, debugged, and
> couldn't
> > >find any way that the port could be getting changed.
> > >
> > >I also had him test on my web site on port 80 and port
> > 8080
> > >which should reveal different results.  Port 80 worked
> > >fine, port 8080 resulted in no connection, most likely
> > >because their firewall is blocking that port (which
> then
> > >proves that the port GETURI was using works fine).  He
> > got
> > >the same results on his browser.
> > >
> > >I'm really pulling my hair out on this one.  I've got
> > >hundreds of users using this without this problem, so
> > I'm
> > >leaning towards some sort of odd web server config
> (they
> > >are running all websphere servers) or networking
> > problem.
> > > But I'm running out of ideas on where to look.
> > >
> > >What would cause his browser and GETURI (which uses
> > sockets
> > >APIS) to act differently?    Thanks for any ideas...
>  I
> > >know there are a lot out there with more netorking
> know
> > how
> > >than me that could offer possible ideas.
> > 
> > Jeffrey Silberberg
> > CompuDesigns, Inc.
> > Atlanta, GA. 30350
> > 
> > As soon as I know the answers
> > They change the questions !
> > --
> > This is the Midrange Systems Technical Discussion
> > (MIDRANGE-L) mailing list
> > To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> > To subscribe, unsubscribe, or change list options,
> > visit:
> > http://lists.midrange.com/mailman/listinfo/midrange-l
> > or email: MIDRANGE-L-request@xxxxxxxxxxxx
> > Before posting, please take a moment to review the
> > archives
> > at http://archive.midrange.com/midrange-l.
> > 
> 
> Bradley V. Stone
> BVS.Tools
> www.bvstools.com
> --
> This is the Midrange Systems Technical Discussion
> (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit:
> http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the
> archives
> at http://archive.midrange.com/midrange-l.
> 
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system
> (http://www.grisoft.com).
> Version: 6.0.799 / Virus Database: 543 - Release Date:
> 11/19/04
>  
> 
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system
> (http://www.grisoft.com).
> Version: 6.0.802 / Virus Database: 545 - Release Date:
> 11/26/04
>  
> --
> This is the Midrange Systems Technical Discussion
> (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit:
> http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the
> archives
> at http://archive.midrange.com/midrange-l.
> 

Bradley V. Stone
BVS.Tools
www.bvstools.com