The forum is locked.
The Ocean Color Forum has transitioned over to the Earthdata Forum (https://forum.earthdata.nasa.gov/). The information existing below will be retained for historical reference. Please sign into the Earthdata Forum for active user support.
We need to find out what part of the process is failing.
1. Is your network connection working?
Check that your network connection works by hitting a few websites you've never
been to before. If they come up then try an anonymous login to a few public FTP
servers (ftp.openbsd.org, ftp.microsoft.com). After you login make sure you can
do an directory listing with the "ls" command. If this works move on to step 2.
2. Can you connect to the Ocean Color servers at all?
There are a few possibilities on why you can't contact the Ocean Color servers.
The first possibility is that there is network connection problem to the main
Try to pull up the main Ocean Color website. Located at
http://oceancolor.gsfc.nasa.gov. If you can access that site then the main
distribution network is up and running correctly.
The second possibility is that the server you're trying to contact is temporarily
If you try you're FTP login and get nothing back it could be that the FTP server
is down temporarily. To see if there are problems with any system please
subscribe to the OBPG data processing/distribution list.
This can be done from the link:
You could also check the color of the stop light on the main Ocean Color
website. Anything other than green means there is a problem with the
distribution system. If the stoplight area mentions problems with an FTP
server please wait for the light go back to green before attempting another
FTP connection. If there is no description of the problem but the light is yellow
please wait for the light to return to green. Then try your connection again.
The third possibility is your public ip address has been placed on a block list.
Our servers are on a block of ip addresses assigned by NASA. Therefore we are
subject to all filters NASA has put in place. NASA has certain ip addresses it
is blocking for a variety of reasons. It is possible you are connecting from one
of those addresses.
It is also possible you have been put on OBPG's personal block list. This
results from our detection of activity we believe had malicious intent. The
usual cause of this is a script that is trying to retrieve files too quickly.
It is unusual for someone to be put on a block list. So contacting us about it
should be a last resort effort.
Before we check our block lists make sure the connection problem is not due to
something other than a block list on our side. Check with your systems administrators
to see if they have blocked you're access to our site either by ip address or by name.
If you would like us to check if your ip address has been put on a block list
please e-mail ftpobpg1 at seawifs.gsfc.nasa.gov with the public ip address you're
connecting from. To find out what your public ip address is please go to the
website http://www.ipchicken.com. Then send us the number that appears under
the title "Current IP Address".
If you can connect to the Ocean Color web server or can connect to the FTP
server move onto step 3.
3. Can you login to the FTP server?
For the first part of FTP (control connection) to work correctly you need to be able
to connect to the FTP server. After connecting you should be presented with a
banner message and login prompt.
From a command line client it is easy to tell if the FTP login is working. You
will be presented with a NASA login banner. Then a username and password prompt.
You login anonymously with the username "anonymous" or "ftp". The password is
your e-mail address. After that you should be at an FTP prompt. If you're using a
GUI client set it to login anonymously. Then to see if you logged in correctly
there is usually a window that scrolls all of the commands issued by the client.
You will have to scroll back through this window to see if the login completed
If you can login successfully and get to a FTP prompt move onto step 4.
4. Can you get a file listing or retrieve a file?
After logging in to the FTP server and getting to a prompt you should be able to
issue a "ls" command from a command line client. GUI clients issue this command
for you automatically when you login successfully. If this command is issued and
you get nothing back you might not be using the correct mode of FTP transfer.
To check this please refer to the question "Why is it when I login to your FTP
servers and try to get a file it fails?" in the post below.
After you have read this and verified you're using the correct client and FTP
settings please move to step 5.
5. All other steps have checked out and are working. Now what?
You should be to the point where you've made sure your FTP client supports
passive FTP, that it is turned on, have successfully logged in, and have tried
to retrieve a file or get a directory listing. At this point if retrieving a
file or getting a directory listing fails then there is not much you can do from
Our final suggestion is that you get in contact with your systems and network
administrators. They deal with these types of problems on a daily basis. They usually
have better access to information about the network setup at your location and
can provide you with more insight into why FTP may not be working correctly.
If your systems administrators say everything should work correctly and can reproduce
the same problem you're having then your last resort is sending OBPG an e-mail.
If you are going to send us an e-mail about an FTP problem we ask that you take
the time to read the whole FAQ first. In the body of the email you will need to
answer the following questions. If you do not answer each and every
question/request we will not be able to help you with your problem.
- What is the public IP address you're coming from? If you don't know please visit
http://www.ipchicken.com. Copy and paste into the e-mail the big number under
the words "Current IP Address".
- What is the data you are trying to retrieve?
- Where is the data you are trying to retrieve? The hostname of the server you
are trying to contact and (if you have it) the path to the data.
- How many times have you tried to retrieve the data?
- What are the exact times you tried to retrieve the data?
- What is the name and version of FTP client (program) you are using?
- What is the name and version of operating system you're using?
- Copy and paste the full text of you're failing FTP session to you're e-mail.
- What is the e-mail address of you're systems administrator?
Send the answers to these questions and a description of the problem to: ftpobpg1 at seawifs.gsfc.nasa.gov
There are a few reasons why this could be happening. First and foremost you
must make sure your FTP client (program) is using passive mode to connect to our
servers. FTP has 2 primary modes it can use. Active and passive. Active is used
by many FTP clients as the default transfer method. The problem with this is
active FTP does not work well with firewalls. When you login successfully
but your connection hangs on a "get" or "ls" command you're probably using FTP in
active mode. If this is the case then the message that will be returned to your
FTP client will be something to the effect of "501 EPRT: Operation not permitted"
or "501 PORT: Operation not permitted".
Today most modern FTP clients can be used in either active or passive FTP modes.
You just have to tell the client which mode to use. Most window based clients
have a configuration settings section where the mode can be set. Try searching
through the help section of the program with the word "passive" or "firewall" if
you have trouble finding the section with the setting. The command line FTP
clients use command line switches to set passive mode. If you're using a Unix type
operating system use the systems man pages (Ex. man ftp) to check the switches
and options of the FTP client you're trying to use. If you don't see anything in
these sections with the words passive or firewall then it's a good possibility
that FTP client does not support passive.
Please refer to this website for a good explanation of active vs passive FTP.
If you are sure your FTP program does not support passive or if you can't figure
out if it does then don't fret. There are lots of free FTP programs that support
passive mode. Below is a list of FTP programs (clients) by operating system that
are known to support passive mode.
Command Line Clients
Linux - ncftp, ftp included in Linux NetKit version .17 and above, wget, and yafc.
IRIX 6.0 - 6.5.8 - ncftp.
IRIX 6.5.14 and up - ncftp or ftp included in IRIX 6.5.14.
SUN Solaris 7 and 8 - ncftp.
SUN Solaris 9 - ncftp or ftp included in SUN OS 9.
FreeBSD 2.2.8 and up - ncftp or ftp included in FreeBSD.
OpenBSD 2.7 and up - ncftp or ftp included in OpenBSD.
Windows 95,98,2000,ME,NT & XP - ncftp or Kermit 95 2.0.
Mac OS X 10.2 and up- ncftp or ftp included in OS X.
Linux or FreeBSD - gFTP or konqueror.
Windows - FTP Explorer, Filezilla, coreftp.
Mac OS X - Cyberduck.
The following are known not to support passive ftp.
- FTP program that comes with SUN Solaris 7 and 8.
- Internet Explorer's 5.1 and above default settings. Needs to be turned on in
- Internet Explorer 5 set to passive mode and "file explorer" mode.
- FTP program that comes with IRIX 6.5.14 and below.
- FTP command line program that comes with windows 95, 98, NT, 2000, and XP.
OBPG suggests using ncftp as your FTP client. It is command line based but can
be used on almost all operating systems. It is very friendly to scripting
(ncftpget, ncftpls, ncftpput, ncftpbatch), free, and has automatic fallbacks to passive
if active does not work. It can be downloaded from http://www.ncftp.com/.
The second reason this could be failing is that your local network firewall/proxy
does not permit passive ftp connections. You will need to ask your local network
administrator if this is the case.
Always check with your local systems administrators first if you're having any problems
connecting to remote sites. They know the network configuration and restrictions better
It has been brought to our attention that some linux kernels after 2.6.7 have had window scaling turned on by default. Some routers on the net are rewriting the window scale TCP option on SYN packets as they pass through. The result is a misunderstanding over the real size of the receive window between our system and yours. If this is happening with your connection then you will not be able to contact our ftp servers at all.
Anybody running a current kernel who is having trouble connecting can try this work around to see if it helps. The following command will need to be executed with elevated privileges (root). This will turn off window scaling for that machine.
echo 0 > /proc/sys/net/ipv4/tcp_default_win_scale
After running this command try the ftp connection again. If it works then that was the problem. Add the following line to your / etc/sysctl.conf file so it executes on reboot.
net.ipv4.tcp_default_win_scale = 0
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill