asmostopheles
Programmer
I have a set of scripting that is used on a help desk to automate uploading of scripted fixes to SCO UNIX machines. The client is currently rolling out a broadband solution to these boxes so i am working with adding a telnet option to send down these files. The problem we have is that any file over about 1500 bytes it ends up failing transmission. Sending the same file over dial-up works fine. Zmodem is used to send the file. The UNIX boxes are using the old 1987 version of zmodem (not sure of the release number off hand although i could probably get it if it is needed to resolve this).
watching the packet traffic shows that the first packet sends, proper ack is recieved, second packet is sent, may recieve ack for second packet, may get a duplicate ack for the first packet. if the second packet was successful, the 3rd packet will almost always fail, again recieving a duplicate ack for the previous packet. the packet attempts to resend, the same duplicate ack is recieved again, after a few more of these the file transfer just fails.
the MTU on the port the transmission is going through is set to 1400.
we can download files from the UNIX box without any issues, its just uploading files to the UNIX box that has this issue.
This leads me to believe we could have an issue with the recieve buffer on the UNIX box, after checking the source for rz.c on these boxes we can see the recieve buffer is set to 133.
Affecting change on the remote machines is really not an option, its in excess of 10,000 boxes that would need to be changed and the client does not seem inclined to do anything to change their configuration.
So...
my question is, is there something within aspect/procomm that could be done to work with this issue, we are looking at taking the older version of zmodem source that the remote boxes have and creating a new DLL/DLP to utilize with the scripting to see if this resolves the issue, but this is obviously not the most ideal resolution to the issue and could be time consuming.
I would appreciate any insight or help resolving this issue.
thanks.
watching the packet traffic shows that the first packet sends, proper ack is recieved, second packet is sent, may recieve ack for second packet, may get a duplicate ack for the first packet. if the second packet was successful, the 3rd packet will almost always fail, again recieving a duplicate ack for the previous packet. the packet attempts to resend, the same duplicate ack is recieved again, after a few more of these the file transfer just fails.
the MTU on the port the transmission is going through is set to 1400.
we can download files from the UNIX box without any issues, its just uploading files to the UNIX box that has this issue.
This leads me to believe we could have an issue with the recieve buffer on the UNIX box, after checking the source for rz.c on these boxes we can see the recieve buffer is set to 133.
Affecting change on the remote machines is really not an option, its in excess of 10,000 boxes that would need to be changed and the client does not seem inclined to do anything to change their configuration.
So...
my question is, is there something within aspect/procomm that could be done to work with this issue, we are looking at taking the older version of zmodem source that the remote boxes have and creating a new DLL/DLP to utilize with the scripting to see if this resolves the issue, but this is obviously not the most ideal resolution to the issue and could be time consuming.
I would appreciate any insight or help resolving this issue.
thanks.