Port 21/22 access & CRC error in downloaded files?
First off thanx to all of you who have helped me get set up from scratch thus far. My latest conquest has to do with corrupt files and finding out why they are corrupt. Namely, compressed files such as .zip and .rar.
My first lead was and still is that i am uploading over port 22 (SS) and if i'm not mistaken, the files are getting encrypted when going up. I thought this was it but i don't know
I am unnable to upload on any account i create for Port 21 so thats gotta get fixed. I am able to login and even though i gave an account as many overwrite,upload and administrator privaledges it says access denied when trying to upload. If i log in under port 22 as root i have no problem upping.
I did some reading about this over the net and what i read suggested that when uploading via port 22, the file changes to ASCII format. Well i made sure it was uploading in Binary format and it still would not work.
I read further and some say this problem exists when Netscape users download from an Apache server and suggests making an .htaccess file so the server knows what to do with a .ZIP or a .RAR file. This can't be the solution cause even ie5 and 6 users are getting the errors.
The errors they get while unpacking a downloaded file is, CRC read error xxxx (should be xxxxx)
I am using Webmin 0.99 to create accounts on an Apache2 webserver on a Redhat 7.2 box.
The files are being compressed with either winzip8.1 or winrar3.0
let me add, i am able to unpack the files successfully after creating them and users can unpack them when they are sent by other means (ICQ, IRC, AIM). The problem happens when they are downloaded from the server
1. Is there something i am missing? Is there some process that should be enabled in Redhat or Apache? and why is it only with certain files? Others work fine.
2. If i was to somehow find a way to upload via port 21 (with the help of ppl here) do you think this would solve my problem?
3. Does the problem exist because i am using Cogent bandwith and it takes a longer route than usual and possibly becomes corrupt on the way to the user?
4. Does this CRC thing sound familiar to anyone here?
5. and offhand, why am i ONLY able to login as Root or perform actions(upload, make folders, rename, CHMOD) on port 22 and not Port 21?
Well, I think I can answer 3 and 5. (I don't run ftp as a server, so I can't answer your other questions.)
3.) I strongly doubt that Cogent has anything to do with this. I think that if Cogent was at its worst, you'd just have to wait a little longer for it to transfer, or if it got really bad, it might time out. But permission denied errors shouldn't have anythign to do with bandwidth.
5.) I'm just venturing a guess, but here's my thought. Port 22 (ssh) is encrypted, whereas 21 (ftp) is not. Therefore, logging in as root via ftp is a VERY bad idea -- anyone on your network could run a packet sniffer and get your root password. Create an "ftp" account or something, and use that, giving it as little permission as you can. (You can always log in as root via ssh and copy files to where you want them, change permissions, etc.) So my guess is that it's just for security, and it's a good idea.
Your issue with the "CRC" error sounds like something completely unrelated to ftp/ssh problems. This is a highly unscientific guess, but Apache 2 is still kind of "new," and it's possible that it's a bug in Apache. (This is just sort of a wild guess with no factual basis, so take it for what it's worth.)
Originally posted by fog Well, I think I can answer 3 and 5. (I don't run ftp as a server, so I can't answer your other questions.)
3.) But permission denied errors shouldn't have anythign to do with bandwidth.
sorry i think i confused some people here. I was hypothesizing Cogent bandwith to the corrupted data (zip, rar). like bad bandwith = bad data transfer? Since the CRC error is somewhat related to size, maybe the whole file is not gettting to the user.
Also I don't think Apache2 is the problem with the data. Its gotta be the way its being uploaded.
i wish i knew how to set up an account that would allow me to upload via port 21
I asked my provider FDCServers for help and they just suggested buying a control panel! How can a control panel fix this issue? That makes no sense!
I should in all theory be able to create an account with full access to Port 21 and login(which i already did) and in theory be able to upload files even in areas created by a root at port 22
You gave me some things to think about
anyone else have any insights as to why this would be happening?
Hmm... I believe that TCP/IP is designed so if you drop frames, they're repeated, so unless somethings' really messed up, that shouldn't be a problem.
I can't help with creating an account, though you could do it from the command line with the "adduser" command -- you might want to set their home directory to /home/ftp or something, and then, if you desire, you can log in and copy them over to the right place -- it'd be a little more work, but if someone "sniffs" your password, all they can do is copy what you've recently uploaded, or upload a bunch of stuff. (And if you're real paranoid, you could assign a disk quota so that they couldn't even fill up your disk.)
I'm not sure that the control panel is necessarily causing the problem, though from what you've said it sounds like you're struggling with Webmin. I strongly doubt that a new control panel will really cure your problems, though.
So you can login via ftp (port 21), and upload stuff? I was under the impression that you couldn't. However, I'd be really hesitant about having any "privileged" accounts on ftp; someone could easily upload MP3s, use your server for warez, fill up your drive, and download anything on your server. A much better solution is to have an account with as few priviledges as possible, and then copy things over via ssh, which affords you great security. Let me know if I can help further.
Reading along, i found this that strengthens my hypothesis about data loss during transfer over Cogent lines!
even though this speaks of phone lines, could this be true for other types of data lines? I've never had this problem with .zip files before until i started using Cogent
Q: I downloaded the zip file, but Winzip 7.0 said that it was an "invalid archive" (or similar such error message).
A: Unfortunately this means there was a downloading error, and you may have to download the file again. Sometimes it is possible to repair a damaged archive, but it is often easier to simply download it again. One common error is a "CRC (cyclic redundancy check) error" usually caused by telephone line noise or a general transfer error. The best solution is simply to download the file again, but if it was a very large file (and hence a very long wait) you may want to try some other things first. Although the amount of data lost varies, it is sometimes possible to retrieve at least parts of it. When unzipping files, Winzip will extract the files to the selected directory, until it reaches the CRC error and informs you of this with an information box. Don't click "OK". Instead, find the relevant directory with Windows Explorer and copy the damaged file into another directory. Then click "OK" in Winzip (which will delete the damaged file) and use your backup.
Why did I get a CRC error in my download?
CRC error are not really often, but everyone always gets one. A CRC error is when a file is corrupt. This particular file doesn't necessarily have a virus. When a file has a CRC error, it was probably resumed too much and some bytes got lost during the stops. This also happens when a file isn't completely downloaded, or if you download at a too fast of a speed.
read somewhere else that Cogent lines dont work the same way as others. On a standard line when you download a file it will find the fastest or direct path to the user downloading it whereas with Cogent, the file travels through a particular route reguardless of where you are downloading from. Your server might be a block away from you in Chicago but the data will have to travel to Florida, New York, Alaska, Texas, then go back to you.
when multiple people download the same file at once on Cogent, the data may be getting corrupt when it hits itself. I guess something like a data collision occurs that corrupts the file. What is weird is that if i allow downloading of an mpeg file by multiple users at the same time (unzipped, uncompressed), everything is seamless. Once the format is changed to something else is when this CRC thing is possible
i still dont get it all but i need to find a solution to this.
I gathered this from reading off here and google
can someone bring more light to the whole Cogent Bandwith Hypothesis?
how its different than other types of bandwith
There is definitely something wrong with your ftp server configuration and/or your ftp client software (on your computer, that you are using for uploading... what software are you using?) and/or the file permissions on your server.
i've tried using WS_FTP and Globalscape CuteFTPPro
they are both uploading in Binary mode by default
i've uploaded from a different place and get the same error
i've had a user send a file that they zipped over IRC then i uploaded that and that one had no error on the initial test download. I went somewhere else this morning and downloaded it again from a different location and it now has the CRC error
permissions set on the server are default permissions. as far as i know or users would not be able to view any webpage or download files (standard CHMOD 755 permissions looks like)