Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[jim1850]

The configuration:

- Home Office, Alabama
SCO OpenServer V
Cisco VPN Endpoint router
DSL Broadband Internet connection (speed ?)

- Remote Office, Ohio
Windows 2k, all service packs
Cisco VPN software client v4.6
Roadrunner cable modem (1M-dn/256k-up)
Dot-matrix printer locally connected to LPT1

- Jriver ICE.TCP-Plus
Build 24
Emulation 7.10a/32
Windows Interface 8.5

- "PC Print" configuration
Standard settings except I enabled..
Delete on cancel
Show status message
Command timeout 40sec

Problem:
Icelp seems to be suffering from a variation on the theme from the movie "Groundhog Day".

I'm located at the remote office attempting to connect to the home office to print a few reports.  With a unix spooled report completed, I start Icelp at my PC and the results I get are very inconsistent.  

The "Icelp Printing" dialog box will appear with the name and size of the pending print job.  The Windows printer icon will appear on the task bar as if something is about to print.  Suddenly the "Icelp Printing" dialog disappears, the Windows printer icon disappears, and nothing happens.

Other times the "Icelp Printing" dialog box appears with the name and size of the same print job.  The Windows printer icon will appear on the task bar, and after about 50 seconds the printer will start to print; then pause, then print, then pause, then print.  The % complete will slowly increase and then everything just stops, closes, and that is it (though the icelp icon remains active on the task bar).

After a minute elapses the "Icelp Printing" dialog box reappears and everything starts over.  The farthest along the print job has ever completed is 5%.

I've ran a 1000 ping test against the remote server and the the average ping time was 105ms with a 1% packet loss.  Nothing terrible.  Ice.tcp terminal sessions with the remote server seem to move along okay.  I've even pinged the server while icelp was doing it's thing and the connection seemed okay.  The VPN Client statistics show consistent packet encryption and decryption with only an occational dumped packet.  I just don't understand why the printing seems so sporatic.

The home office tested the setup using icelp at their end and said it works great, but of course they are not working over the internet.  Here's the transcripts of an icelp debug session.  It didn't tell me much, maybe it does you...

Time: 16:04:27.    Date: 2.16.2005.
Connection established to host 192.168.1.200.
Windows:ICELP*
HI_ICELP

Windows:DIR:/usr/tmp*
OK

Windows:IS_FILE?hp1200*
Print job hp1200-9501_1.
Size 177202 bytes.
Windows:TRANSFER*
PCPCPCPCPCPCPCPCPCPCPCPCPCPCPCPCPCPCEND OF THE CYCLE.



Time: 16:08:12.    Date: 2.16.2005.
Connection established to host 192.168.1.200.
Windows:ICELP*
HI_ICELP

Windows:DIR:/usr/tmp*
No reply.Closing...
END OF THE CYCLE.



Time: 16:10:00.    Date: 2.16.2005.
Connection established to host 192.168.1.200.
Windows:ICELP*
HI_ICELP

Windows:DIR:/usr/tmp*
OK

Windows:IS_FILE?hp1200*
Print job hp1200-9501_1.
Size 177202 bytes.
Windows:TRANSFER*
PCPCPCPCPCPCPCPCPCEND OF THE CYCLE.



Time: 16:12:59.    Date: 2.16.2005.
Connection established to host 192.168.1.200.
Windows:ICELP*
HI_ICELP

Windows:DIR:/usr/tmp*
OK

Windows:IS_FILE?hp1200*
Print job hp1200-9501_1.
Size 177202 bytes.
Windows:TRANSFER*
PCPCPCPCPCPC

I'm not saying that this isn't a connection issue, but I don't observe this to be the case.  Any insight you might be able to offer would be appreciated.  Thanks.

[Bob]

Thanks for the EXCELLENT detail in your message.

Given what you said, it's hard to see how the problem could be the actual transfer. ICELP is using TCP not UDP so the completion of transfer should be guaranteed on any link with >75% thoughput.

Some thoughts that come to mind:
You COULD try creating a new printer on the remote PC printing to a FILE to see if it will get the whole job then. This is trying to see if the print spooler and/or printer has anything to do with the problem.

Looking at the network side of things, since ICELP is moving a lot of data (unlike emulation) it will most aways be sending MTU sized blocks across the network. It COULD be that there is a MTU mismatch or fragmentation issue in the connection so that large packets get dumped. Googling around did bring up some different references to MTU's with VPN's. The VPN reduces the maximum MTU because of the added header info. Maybe something in your path isn't figuring this out. (there is a protocol called MTU path discovery that MAY come into play here).

[jim1850]

Hi Bob, thanks for the prompt reply.  Yeah, I already checked my MTU and did some ping testing with the -l and -f switches before I sent off my original post.  My MTU is set at 1300 which appears to work best with the VPN client software.

After a day of scratchin' my head here at work, last night I installed a copy of the ICE.TCP software on my laptop, packed up the old wide carriage dot-matrix, and hauled it all home to try it over my Verizon wireless DSL connection.  Sure enough the whole setup was a printin' fool and all the reports came across without any issues at all.

Brought it all back into work today, same printer, same laptop, same software, same problem.  The only two variables now are the Roadrunner cable modem service and the time of day.  I might wait until the folks down south call it a day to see if the problem persists when the server isn't under load, but I'm betting the problem has something to do with Roadrunner.

RR tech support assured me that they don't throttle traffic on their service, but I'm not sure that I'm buying it.  http, ftp, pop3, smtp work fine with the service, but some of these more obscure applications that I use seem to function with less reliability.  Unfortunately we are in an area where our isp choices are very limited.

Anyway, I just wanted to be sure that I didn't overlook something in the configuration of icelp or if maybe you had one of those undocumented command line switches up your sleeve that would fix every ailment that I could ever encounter.  Thanks again.

[Bob]

I wonder if RR is doing something weird with uncommon protocols. I noticed that a machine that I tend to which is connected to the internet via RR buisness service will NOT pass DNS queries to servers other than theirs. In my case there is obviously some kind of filtering going on.

[jim1850]

Since my original post appears to have gathered a number of views I thought I'd provide an update.  I had pretty much given up on using Roadrunner since ICElp printing was so sporatic over Roadrunner and Roadrunner support kept telling me that their network was not the cause.

I then sought out a company that tried to provide wireless broadband internet service to our building only to find that the local interstate overpass was blocking the signal path.  So adsl out.  Idsl out.  Wireless broadband a no go.  Roadrunner unusable for obscure applications.  So goes life in the poor end of town.

Then on miraculous Monday March 7th,  feeling like I needed a little abuse to start the week, I tried printing a report from our home office using ICElp over the Roadrunner service.  I establish the VPN connection, execute ICE.TCP, initiate ICElp, then suddenly the printer starts buzzing away.  Line after beautiful line of print is appearing.  No pauses, no error messages, no dropped connections, and this has been the case for the past three days.

I have never received any calls or responses to my e-mails from Roadrunner informing me that something has changed.  So I have no idea if this is just a fluke or if some problem has actually been fixed.  Call it divine intervention, call it plausible deniability, call it what you will, but ICElp is now working great and life is good.

[Bob]

Excellent, good to hear.

I fear that there is some sort of movement, esp among the big guys, to give us less than a pure filter free connection to the internet. It may be a harbinger of attempts to control content by certain interests.

Stay tuned. eff.org might be a good site to check into occassionally.