I'm a phone guy but I think this is a circuit problem. I am posting both on circuit and network because I think both may have run into it.

I have IP access to quite a few of Mitel SX200 ICP's and do backups by ftp. In the normal course of things I enter in a file name for the backup and the systems archives and compresses the file and uploads it to my server where it shows up as a .gz file (I do not have to put the file extension on when naming). Recently when trying to do a routine backup on a couple of the PBXs everything looked to be going perfectly in the switch but when the file shows up on my server it has no file extension on it and is not compressed.

These were working okay before and the only thing I can find in common is that both have changed ISP (therefore circuits) since I last tried to back up. Anything on the new circuit that could be causing "noise" or causing this kind of file to show up?

Just a little more info - I have not changed any parameters in the PBX and there is no place to change anything regarding back ups. Also other PBXs I work with are working exactly the way they are supposed to (I backed up a couple after I noticed the problem with the two I am referring to)

sounds like a port forwarding issue in the router or the firewall.

No that is not a problem - I can get to the switch fine and at the beginning of the back up it goes out and tests the ftp connection the server set up on my computer. It goes through the whole back up procedure fine but when the files shows up on my machine it is way too big and not in the correct format. As I said it is weird. These are the only two properties that I have experienced problems with and they have had circuit changes since the last time I ran a back up

For a start, it would be helpful if you let us know:

1. OS & version of server and your computer
2. Name & version of FTP server and client software

Also, how do you know that the files are not compressed? The absense of an extension does not necessarily mean anything.

Interesting. Anything else apart from the circuit change with the 2 that don't work? Was the hardware or software upgraded? Is there a firewall at the customer's site and if so, did their firewall config change?

I am using Pure Admin on Linux. I know the file is not compressed due to the size. These are the only two properties that are not working correctly. All the other backups I do work just fine. I usually dial in and program the routers that connect to the telephone system. I do not know if there is any firewall between my router and the internet. These two properties are owned by two different entities and one of them has another property that works fine.

I would go down this list:

1. Do the new ISPs restrict certain ports/services/ip addresses? (not likely for business access but you never know)

2. Is there a managed/regularly updated firewall on the customer's side? Managed firewalls get regular updates which may change their configurations. This usually happens automatically.

3. Did the hardware or software change in the phone system?

4. Is the customers' own access working OK otherwise? There could be some crapware/attack by a hacker?

Access is working fine for customer. No change in the software on the PBX (in fact found another system with exactly the same software level and it backed up fine).

I also did a SW upgrade on the PBX yesterday and I am still getting the wrong kind of file back. I sincerely do not believe this is related to the PBX or my server (as other sites work fine)

The only thing I can find (and don't know if it is pertinent or not) is that in the routers I am using at the two sites I am having problems with is that I am getting the following messages in the logs. I do not see them on other sites.

[INFO] Fri Nov 28 03:45:00 2008 Blocked packet from 192.168.0.1 to 239.255.255.100 that was received from the wrong network interface (IP address spoofing)
[INFO] Fri Nov 28 03:31:00 2008 Previous message repeated 14 times

Looks like a firewall entry. But it was in November, so unless the date & time on the router has not been set properly this is a very old message. I wouldn't even think that the info log would be large enough to still maintain entries from November, but maybe there's very little action on that router and/or the logging.
FYI, the router rejected the packet because it seems it is coming to its WAN (external) address from an internal (private) address (192.168.X.X).

Sph,

thanks. I kinda figured that's what was happening and the date and time have probably not been set in the router.

The error message is correct for the wrong reason, and it should have no bearing on your problem. The 239.x range is part of multi-cast - generally non-routed traffic.
The first thing to do when a scripted process isn't working right for any system is to manually do the script yourself and watch for errors that may be failing the script but not preventing it from working.

Also you are a not very clear on when in the script the compression happens. It is possible to setup a FTP Server such that if a flat file is requested with a compressed extension (.gz or gzip in this case) that the file is compressed and then sent. This is something that the remote FTP server has to support, your local system has no effect except for how the file is requested in your script.

You also imply though you don't state that each of the systems being backed up have their own scripts. If that is the case, compare the scripts for two similar systems and see what is different. one of those two should show you the problem plainly.