rlucastemp

I have a Hawking Printserver, model number PS12U.  I had already set its IP address using the Windows software (it should be noted that you can ARP the printserver from Linux if need be; google for more info).  However, in order to set it up as a printer on my Linux machine, I needed the appropriate URI to feed to lpadmin.  I tried a number of things like ipp://192.168.0.1/lp1, etc., but finally gave up and used “printconf.”  The proper URI / URL to use, it appears, for addressing the Hawking PS12U is:

lpd://192.168.0.1/lp1

Where the IP address in the middle is naturally the one you’ve set for the Printserver and the “lp1” to “lp3” corresponds to the physical port on the PS12U to which you’ve connected the printer.

I didn’t say it was groundbreaking or an awesome fix, just info that I hadn’t been able easily to find.

Possible scenario: you wrote an ancient script using the CGI.pm module by Lincoln Stein, and it ran fine on your old RedHat 6.2 box with Perl 5.00503 and an ancient version of CGI.pm.   However, after reinstalling your script on a newer box with Perl 5.6, or else after upgrading your perl and/or CGI.pm, your script is broken and says

Undefined subroutine CGI::dump

Answer: in version 2.50 of CGI.pm, CGI::dump was changed to CGI::Dump. Try:

perl -pi -e ‘s/CGI::dump/CGI::Dump/’ yourscript.pl

FIX: “Undefined subroutine CGI::dump” crashes a formerly working script. …

I use SSH for everything from tunnelling outbound mail in order to avoid port 25 blocks on the freenet providers (such as www.personaltelco.net) to simple terminal sessions.  Also, most all of the time I am hooked up via a DSL or Cable modem with a router in front of it playing NAT tricks to get me to the outside network.  After about an hour (sometimes less) the SSH just hangs; from a Mac OS X terminal session it’s just unresponsive and needs to be killed, whereas on PuTTY on Windows, once it realizes the connection is no good it pops up a “Network error: Software caused connection abort” message.  The problem seemed to be worse with DSL from Verizon and Qwest, and seemed to be very mild with AT&T/Comcast cable in Cambridge, 02138 (advice: in Cambridge, you can’t go wrong with the Comcast digital cable.  I was getting speeds of (I seem to remember) almost a megabyte per second down and could pull down entire ISOs in minutes; debian net install on an old p233 was disk i/o limited and not network limited by what I could tell.

Happily, the good people at DSL Reports (www.dslreports.com) have put together an FAQ on this subject including some specific configuration options and links to more info:

http://www.dslreports.com/faq/7792

More on this as I determine if it actually works.

Update: So far, so good; a thunderstorm passing through caused a brief power cycle and that definitely reset the connection, but it seemed to hold otherwise, for example during lunch.  The real test will be leaving terminal sessions overnight.

Update: While looking for info on a superficially related problem, I came across this slashdot thread:

http://slashdot.org/askslashdot/00/06/24/0622236.shtml

This may also provide some assistance to seekers of info on this topic.  However! importantly, you should also examine the lengthy parenthetical in http://blogs.law.harvard.edu/rlucas/2003/11/17#a24 to determine if this is really your problem — the link to a TCP/IP theory page should help you as well.  This caveat is necessary because there are really two opposite problems that both manifest as “dropped ssh terminal sessions:” one, a NAT table on a cable/dsl router could be timing out (which argues for more frequently sending keepalive packets), or two, your connection could be flaking out briefly but coming back up fairly quickly (which argues against sending frequent keepalives).

FIX: SSH or telnet sessions timeout and drop connection on DSL or Cable modem behind NAT router …