-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Jeffrey,
On 1/20/14, 3:04 PM, Jeffrey Janner wrote: >> -----Original Message----- From: André Warnier >> [mailto:a...@ice-sa.com] Sent: Monday, January 20, 2014 1:47 PM To: >> Tomcat Users List Subject: Re: Cannot connect from outside using >> Tomcat 7/APR/SSL on AWS Windows system >> >> Jeffrey Janner wrote: >>>> -----Original Message----- From: André Warnier >>>> [mailto:a...@ice-sa.com] Sent: Monday, January 20, 2014 11:01 >>>> AM To: Tomcat Users List Subject: Re: Cannot connect from >>>> outside using Tomcat 7/APR/SSL on AWS Windows system >>>> >>>> Jeffrey Janner wrote: >>>>>> -----Original Message----- From: André Warnier >>>>>> [mailto:a...@ice-sa.com] Sent: Monday, January 20, 2014 >>>>>> 10:09 AM To: Tomcat Users List Subject: Re: Cannot >>>>>> connect from outside using Tomcat 7/APR/SSL on AWS >>>>>> Windows system >>>>>> >>>>>> Jeffrey Janner wrote: >>>>>>>> -----Original Message----- From: Ognjen Blagojevic >>>>>>>> [mailto:ognjen.d.blagoje...@gmail.com] Sent: Sunday, >>>>>>>> January 19, 2014 9:19 AM To: Tomcat Users List >>>>>>>> Subject: Re: Cannot connect from outside using Tomcat >>>>>>>> 7/APR/SSL on AWS Windows system >>>>>>>> >>>>>>>> Jeffrey, >>>>>>>> >>>>>>>> On 19.1.2014 6:03, Christopher Schultz wrote: >>>>>>>>>> <Connector address="10.4.1.20" port="443" >>>> maxHttpHeaderSize="8192" >>>>>>>>> Could it be as simple as having set the "address" >>>>>>>>> attribute? >>>>>>>> +1 >>>>>>>> >>>>>>>> BTW, setting attribute preverIPv4Stack=true on server >>>>>>>> side doesn't mean anything for the client. The client >>>>>>>> will try to connect with >>>>>> the >>>>>>>> protocol he prefers. The client may also fall back to >>>>>>>> other protocol (e.g. if IPv6 connection fails several >>>>>>>> times, try with >>>> IPv4). >>>>>>>> I see that access log is not configured. Is there a >>>>>>>> reason for >>>> that? >>>>>>>> Without access log you can't tell if the remote >>>>>>>> request reaches Tomcat or not. So, for start, I >>>>>>>> suggest you configure access log for Tomcat 7 and >>>>>>>> report back if something is logged after you >> try >>>>>>>> to connect from the remote host. Note that Tomcat may >>>>>>>> postpone writes >>>>>> to >>>>>>>> the log files, so make sure you stop Tomcat before >>>>>>>> you check >> your >>>>>> logs. >>>>>>>> If there is no record of remote requests in Tomcat 7 >>>>>>>> access >> logs, >>>> I >>>>>>>> suggest you analyze what is going on with Wireshark >>>>>>>> or some >> other >>>>>>>> packet analyzer. You can that see if the client: >>>>>>>> >>>>>>>> 1. tries to connect using IPv6 or IPv4, 2. is falling >>>>>>>> back, 3. which exactly IPv4/v6 adress does it use, 4. >>>>>>>> is TCP three-way handshake successfull. >>>>>>>> >>>>>>>> Only when you confirm that three-way handshake is >>>>>>>> succsessful >> and >>>>>>>> that the destionation IP adress is IPv4 "10.4.1.20", >>>>>>>> you may say >>>>>> that >>>>>>>> the request should have reached Tomcat. >>>>>>>> >>>>>>>> -Ognjen >>>>>>> Added the access log. Absolutely 0 entries from any >>>>>>> address that >>>> is >>>>>> not the local system. Can you configure your Tomcat-6 to >>>>>> run under your Java-7 ? (in the principle, I think that >>>>>> this should work; I don't know about the practice) This >>>>>> would help determine if the difference resides in the >>>>>> Java or the Tomcat. >>>>>> >>>>> Tried it a different way. Since TC7 is supposed to support >>>>> Java 1.6, >>>> switched my TC7 to use the existing Java6. >>>>> No luck. Noticed that 7.0.47 is old now. Going to try >>>>> 7.0.50. >>>>> >>>> Did you try a simple : >>>> >>>> telnet 10.4.1.20 <Tomcat listen port> >>>> >>>> (just to see if 'anything' from outside can connect to your >>>> AWS/Tomcat port) >>>> >>> Nope, just timeouts. >> >> If the connection is not rejected right away with a "connection >> refused by host", it normally means that a LISTEN port is opened >> on that port. >> >> Taken "strictly by the book" and according to your presumed >> accurate description of the symptoms above, >> >> A timeout suggests to me that the connection request packet (SYN >> ?) is received and accepted by the server, but that the return >> packet which should tell the client so (ACK ?), never makes it >> back to the client. Hence the client waits, until the timeout >> kicks in. >> >> Are you sure that this server has a route back to the client ? >> >> Or, are you sure that your descriptions so far are really >> accurate ? For example, is it really the same server on which you >> can make this succeed/fail just by switching the Java and/or >> Tomcat version, no other changes involved ? (Also see >> Konstantin's question about the apparent discrepancy between the >> netstat output and your server.xml). >> > Yep, just stopping one service and starting the other. It's > something weird with the server, since an identical Tomcat 6 > install wouldn't work with a copied and stripped configuration. > I'm double-checking everything, but I think the server's tied the > outside IP to the wrong internal IP. Trying to come up with a way > to check that. Note, the connectors and hosts my original posted > server.xml are taken from my original install, but that also has > another pair of connectors (different IPv4 address) and some hosts > that should only respond on that address, though they are all under > one service/engine combo. The troublesome address connectors and > hosts are commented out in the original and the original restarted > before I try to start the newer setups. I haven't caught-up with the whole thread, yet, but I can tell you that it's not an IP-mapping that is the problem: you said that a similarly-configured Tomcat 6 on the same machine works fine (with address="..." I presume). So AWS is configured properly. Did you configure jsvc differently (or use a new build of it) for the Tomcat 7 (or "duplicate" Tomcat 6) that don't work? Windows often will block network access to programs it does not recognize. Perhaps you have white-listed the existing Tomcat 6 binary that you're running, but not the newer one for Tomcat 7? - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJS3tQSAAoJEBzwKT+lPKRYDfsP/352s+VSaKDzqMRyP/VSY6TG 7ily+thf3JsUCIUkwzY3NhMmEC7tuOnV2OK9jGAKfBH7iFsLNdKIPuLiC3FSIXXz bDA8VAsPm+JpoMmZ7KOu0HOOnORziV7M0XpjkRrGDqjw0M7pNNVh3+t3N/KPaAPx AfQZOB38iCvu1SJipgMjNyoAnCMPPRy3voVRBx32tAvAtPG/7SYVwcJbMPCdK2Tp ShGRelk5t/K/ZfXNYK6ha7JO8QnfsNIQropMMZRY0RpzxFF+B4q78vlGdL2PpRbf h4x0G9FWiQqjAzHA5xVK6xCJXadKy9A5Mx46bT5VPAZKEx8zlJhd/igd3Ry87lMp EQjZqAovJblfOdfX5MZ6GBAC94fsJLdPQTKNbNjtHq4EJDfPKR1rUjIvOImPcr80 IJMPBkOXFUOdG4Enj/hkmkWZQPLe/3sLRerDbIByZeV0weDOrJUbUzmbqMnyhAda 7AEQ9JVdvzJpXKw2hB/EMXbPjkxLPyLL6WVZXtwp95hXkUuyf9YQF7nG85M3IKjb kbXiVMOBq3OW8KvChpcED0KC7DO5GsAxOxztpyPpqxy2nwhZ3GYSe4MkvAuNExoz QckMR1F/PtM/HuUfT4QUhNF+hfmLjIzuYFlOcJBjXAMDU6lGG08CrcO2HZCOB/UJ Iqzn9LutsNVs2ZhNoRtu =bukD -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
