[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
20020626: NEXRAD Level III data in WSI format (cont.)
- Subject: 20020626: NEXRAD Level III data in WSI format (cont.)
- Date: Thu, 27 Jun 2002 13:05:53 -0600
>From: Louis Nguyen <address@hidden>
>Organization: NASA/Langley
>Keywords: 200206241856.g5OIuJa26379 NEXRAD imagery
Louis,
>The network people said they were able to see communication from port
>388.
>See email below. There must be something wrong with my setup.
I was reminded that there were a number of things that were
configurable with firewalls: port, protocol(s), etc. It is possible
that the firewall there has not been enabled to pass through both TCP
and UDP. From the firewall traffic log sent along by Lynne E., this
looks to be setup OK.
For reference (mainly for the tracking system), we have a web page that
addresses some of the issues related to LDM access through firewalls:
http://www.unidata.ucar.edu/packages/ldm/networkSecurityAndSetup.html
I am intrigued by Lynne's comment:
"Angler just sends a reset to 198.181.231.53 when it trys to contact
angler on port 388. Do you have TCP wrappers on by chance?"
Have you found anything on your end?
Tom
>-Louis
>
>
>Lynne Eklund wrote:
>>
>> Remember- the firewall allows outgoing traffic with few exceptions.
>> Angler seems to be sending and receiving traffic on port 388 without
>> any problem. Angler just sends a reset to 198.181.231.53 when it trys
>> to contact angler on port 388. Do you have TCP wrappers on by chance?
>>
>> Four samples follow- the first two are your attempts this morning
>> from angler to 198.181.231.53. The pattern indicated it completed
>> normally since it sent a "finish".
>>
>> The second two samples at 13:32 and 15:44 seem to be failed attempts from
>> 198.181.231.53 to angler. These are where angler sent a "reset".
>>
>> source-IP.port > destination-IP.port | flag
>> | S= synchronize
>> | P= push data
>> V F= finish
>> 08:49:32 128.155.17.143.5032 > 198.181.231.53.388: S 811848400:811848400(0)
> win 49152 <mss 1460,nop,nop,sackOK>
>> 08:49:32 198.181.231.53.388 > 128.155.17.143.5032: S 2685571129:2685571129(0
> ) ack 811848401 win 64860 <nop,nop,sackOK,mss 1380>
>> 08:49:32 128.155.17.143.5032 > 198.181.231.53.388: . ack 1 win 49152 (DF)
>> 08:49:32 128.155.17.143.5032 > 198.181.231.53.388: P 1:117(116) ack 1 win 49
> 152 (DF)
>> 08:49:32 198.181.231.53.388 > 128.155.17.143.5032: . ack 117 win 64860
>> 08:49:32 198.181.231.53.388 > 128.155.17.143.5032: P 1:33(32) ack 117 win 64
> 860
>> 08:49:32 128.155.17.143.5032 > 198.181.231.53.388: . ack 33 win 49152 (DF)
>> 08:49:34 198.181.231.53.388 > 128.155.17.143.5032: P 33:861(828) ack 117 win
> 64860
>> 08:49:34 128.155.17.143.5032 > 198.181.231.53.388: . ack 861 win 49152 (DF)
>> 08:49:38 128.155.17.143.5032 > 198.181.231.53.388: F 117:117(0) ack 861 win
> 49152 (DF)
>> 08:49:38 198.181.231.53.388 > 128.155.17.143.5032: . ack 118 win 64860
>> 08:49:38 198.181.231.53.388 > 128.155.17.143.5032: F 861:861(0) ack 118 win
> 64860
>> 08:49:38 128.155.17.143.5032 > 198.181.231.53.388: . ack 862 win 49152 (DF)
>>
>> This seems to indicate angler successfully started a conversation with
>> 198.181.231.53, atm.geo.nsf.gov, on port 388. This was before the rule was
>> added in at 10:20am. It worked because angler initiated the conversation.
>>
>> Later, a second conversation seems complete also:
>> source-IP.port > destination-IP.port | flag
>> | S= synchronize
>> | P= push data
>> V F= finish
>> 10:24:35 128.155.17.143.5398 > 198.181.231.53.388: S 1687746160:1687746160(0
> ) win 49152 <mss 1460,nop,nop,sackOK>
>> 10:24:35 198.181.231.53.388 > 128.155.17.143.5398: S 2888554131:2888554131(0
> ) ack 1687746161 win 64860 <nop,nop,sackOK,mss 1380>
>> 10:24:35 128.155.17.143.5398 > 198.181.231.53.388: . ack 1 win 49152 (DF)
>> 10:24:35 128.155.17.143.5398 > 198.181.231.53.388: P 1:117(116) ack 1 win 49
> 152 (DF)
>> 10:24:35 198.181.231.53.388 > 128.155.17.143.5398: . ack 117 win 64744
>> 10:24:35 198.181.231.53.388 > 128.155.17.143.5398: P 1:33(32) ack 117 win 64
> 860
>> 10:24:35 128.155.17.143.5398 > 198.181.231.53.388: . ack 33 win 49152 (DF)
>> 10:24:37 198.181.231.53.388 > 128.155.17.143.5398: . 33:1413(1380) ack 117 w
> in 64860
>> 10:24:37 198.181.231.53.388 > 128.155.17.143.5398: P 1413:2793(1380) ack 117
> win 64860
>> 10:24:37 128.155.17.143.5398 > 198.181.231.53.388: . ack 1413 win 49152 (DF)
>> 10:24:37 198.181.231.53.388 > 128.155.17.143.5398: . 2793:4173(1380) ack 117
> win 64860
>> 10:24:37 128.155.17.143.5398 > 198.181.231.53.388: . ack 2793 win 49152 (DF)
>> 10:24:37 198.181.231.53.388 > 128.155.17.143.5398: P 4173:5553(1380) ack 117
> win 64860
>> 10:24:37 128.155.17.143.5398 > 198.181.231.53.388: . ack 4173 win 49152 (DF)
>> 10:24:37 128.155.17.143.5398 > 198.181.231.53.388: . ack 5553 win 49152 (DF)
>> 10:24:37 198.181.231.53.388 > 128.155.17.143.5398: . 5553:6933(1380) ack 117
> win 64860
>> 10:24:37 198.181.231.53.388 > 128.155.17.143.5398: P 6933:8313(1380) ack 117
> win 64860
>> 10:24:37 198.181.231.53.388 > 128.155.17.143.5398: P 8313:8369(56) ack 117 w
> in 64860
>> 10:24:37 128.155.17.143.5398 > 198.181.231.53.388: . ack 6933 win 49152 (DF)
>> 10:24:37 128.155.17.143.5398 > 198.181.231.53.388: . ack 8313 win 49152 (DF)
>> 10:24:37 128.155.17.143.5398 > 198.181.231.53.388: . ack 8369 win 49152 (DF)
>> 10:24:47 128.155.17.143.5398 > 198.181.231.53.388: F 117:117(0) ack 8369 win
> 49152 (DF)
>> 10:24:47 198.181.231.53.388 > 128.155.17.143.5398: . ack 118 win 64860
>> 10:24:47 198.181.231.53.388 > 128.155.17.143.5398: F 8369:8369(0) ack 118 wi
> n 64860
>> 10:24:47 128.155.17.143.5398 > 198.181.231.53.388: . ack 8370 win 49152 (DF)
>>
>> The packets are the same both inside and outside the firewall, so we are
>> not blocking anything. What are the symptoms you see? The attempt at 12:30p
> m
>> looks basically the same.
>>
>> source-IP.port > destination-IP.port | flag
>> | S= synchronize
>> | P= push data
>> V F= finish
>> 13:32:30 198.181.231.53.33810 > 128.155.17.143.388: S 2650030429:2650030429(
> 0) win 32850 <nop,nop,nop,nop,nop,nop,timestamp 16747934 0,nop,nop,sackOK,mss
> 1380>
>> 13:32:30 128.155.17.143.388 > 198.181.231.53.33810: R 0:0(0) ack 2650030430
> win 0
>> 13:32:53 198.181.231.53.33816 > 128.155.17.143.388: S 3312188725:3312188725(
> 0) win 32850 <nop,nop,nop,nop,nop,nop,timestamp 16750214 0,nop,nop,sackOK,mss
> 1380>
>> 13:32:53 128.155.17.143.388 > 198.181.231.53.33816: R 0:0(0) ack 3312188726
> win 0
>>
>> This attempt demonstrates the firewall is not blocking port 388 because
>> angler answers 198.181.231.53 when it connects to port 388. It just immedia
> tely
>> sends a reset. The same thing happened later.
>>
>> source-IP.port > destination-IP.port | flag
>> | S= synchronize
>> | P= push data
>> V F= finish
>> 15:44:34 198.181.231.53.34915 > 128.155.17.143.388: S 3814039045:3814039045(
> 0) win 32850 <nop,nop,nop,nop,nop,nop,timestamp 17540249 0,nop,nop,sackOK,mss
> 1380>
>> 15:44:34 128.155.17.143.388 > 198.181.231.53.34915: R 0:0(0) ack 3814039046
> win 0
>> 15:44:49 198.181.231.53.34916 > 128.155.17.143.388: S 366787476:366787476(0)
> win 32850 <nop,nop,nop,nop,nop,nop,timestamp 17541760 0,nop,nop,sackOK,mss 1
> 380>
>> 15:44:49 128.155.17.143.388 > 198.181.231.53.34916: R 0:0(0) ack 366787477 w
> in 0
>> 15:45:04 198.181.231.53.34917 > 128.155.17.143.388: S 3163746281:3163746281(
> 0) win 32850 <nop,nop,nop,nop,nop,nop,timestamp 17543269 0,nop,nop,sackOK,mss
> 1380>
>> 15:45:04 128.155.17.143.388 > 198.181.231.53.34917: R 0:0(0) ack 3163746282
> win 0
>> 15:45:19 198.181.231.53.34919 > 128.155.17.143.388: S 135199690:135199690(0)
> win 32850 <nop,nop,nop,nop,nop,nop,timestamp 17544779 0,nop,nop,sackOK,mss 1
> 380>
>> 15:45:19 128.155.17.143.388 > 198.181.231.53.34919: R 0:0(0) ack 135199691 w
> in 0
>> 15:45:34 198.181.231.53.34921 > 128.155.17.143.388: S 1641988398:1641988398(
> 0) win 32850 <nop,nop,nop,nop,nop,nop,timestamp 17546288 0,nop,nop,sackOK,mss
> 1380>
>> 15:45:34 128.155.17.143.388 > 198.181.231.53.34921: R 0:0(0) ack 1641988399
> win 0
>> 15:45:49 198.181.231.53.34924 > 128.155.17.143.388: S 2251677879:2251677879(
> 0) win 32850 <nop,nop,nop,nop,nop,nop,timestamp 17547797 0,nop,nop,sackOK,mss
> 1380>
>> 15:45:49 128.155.17.143.388 > 198.181.231.53.34924: R 0:0(0) ack 2251677880
> win 0
>> 15:46:04 198.181.231.53.34926 > 128.155.17.143.388: S 3476756341:3476756341(
> 0) win 32850 <nop,nop,nop,nop,nop,nop,timestamp 17549306 0,nop,nop,sackOK,mss
> 1380>
>> 15:46:04 128.155.17.143.388 > 198.181.231.53.34926: R 0:0(0) ack 3476756342
> win 0
>> 15:46:43 198.181.231.53.34931 > 128.155.17.143.388: S 3777289185:3777289185(
> 0) win 32850 <nop,nop,nop,nop,nop,nop,timestamp 17553137 0,nop,nop,sackOK,mss
> 1380>
>> 15:46:43 128.155.17.143.388 > 198.181.231.53.34931: R 0:0(0) ack 3777289186
> win 0
>>
>> < From address@hidden Wed Jun 26 17:47:12 2002
>> < From: Louis Nguyen <address@hidden>
>> < X-Accept-Language: en
>> < MIME-Version: 1.0
>> < To: Lynne Eklund <address@hidden>
>> < CC: address@hidden
>> < Subject: Re: [Fwd: port 388]
>> < Content-Transfer-Encoding: 7bit
>> <
>> < Lynne,
>> <
>> < I'm having problems getting data in and out through this port. Could
>> < you please double check to see if you allow access to this port in
>> < both direction.
>> <
>> < Thanks,
>> <
>> < -Louis
>> <
>> <
>
>
>Unidata Support wrote:
>>
>> >From: Louis Nguyen <address@hidden>
>> >Organization: NASA/Langley
>> >Keywords: 200206241856.g5OIuJa26379 NEXRAD imagery
>>
>> Louis,
>>
>> Sorry I couldn't respond to this as soon as it came in, but we had
>> a meeting that just ended.
>>
>> >The weird thing is there's nothing in the log file
>> >(~ldm/logs/ldmd.log). I installed from binaries.
>>
>> I stopped and restarted the LDM on atm.geo.nsf.gov, and have seen it
>> successfully feed other sites the NEXRAD data. One thing I note is
>> that I can not do an ldmping or notifyme to your machine from either
>> atm or any machine here at the UPC. This seems to indicate that port
>> 388 is not open for traffic coming from us to you. This would explain
>> the pq_sequence failure we see in the atm LDM log file. Can you
>> check with your network guys and make sure that the port is open in
>> both directions? Thanks.
>>
>> >I'm runnign this on
>> >an SGI IRIX6.5.15. Want me to re-compile and install from src?
>>
>> I think the problem is still related to access through the firewall.
>> If we find out that it isn't, it may be a good idea to build the LDM
>> from source (as a last ditch effort).
>>
>> Tom
>> ****************************************************************************
> <
>> Unidata User Support UCAR Unidata Program
> <
>> (303)497-8643 P.O. Box 3000
> <
>> address@hidden Boulder, CO 80307
> <
>> ----------------------------------------------------------------------------
> <
>> Unidata WWW Service http://www.unidata.ucar.edu/
> <
>> ****************************************************************************
> <
>
**************************************************************************** <
Unidata User Support UCAR Unidata Program <
(303)497-8643 P.O. Box 3000 <
address@hidden Boulder, CO 80307 <
---------------------------------------------------------------------------- <
Unidata WWW Service http://www.unidata.ucar.edu/ <
**************************************************************************** <
