netcat problems on OpenServer 5.0.4 - SCO

This is a discussion on netcat problems on OpenServer 5.0.4 - SCO ; using netcat.elf command I have problem printing small ASCII files on Lexmar printer 4227plus connected on the LAN by a D-Link printer server DP301P+. Only if I execute consecutively several time (5 or 6 times) the string command below, the ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: netcat problems on OpenServer 5.0.4

  1. netcat problems on OpenServer 5.0.4

    using netcat.elf command I have problem printing small ASCII files on
    Lexmar printer 4227plus connected on the LAN by a D-Link printer server
    DP301P+.
    Only if I execute consecutively several time (5 or 6 times) the string
    command below, the printer works.
    The string command is:

    cat filename | /usr/local/bin/netcat -h 126.0.0.23 -p 9100

    The small file is an ascii file that contains only some characters.
    From windows OS if I print from notepad the same file the printer work
    right.
    I have no problem to print small files on a Laser Hp 4200n with internal LAN
    drive.
    May you have some suggestion or solution?
    Thanks



  2. Re: netcat problems on OpenServer 5.0.4

    I found the solution downloading netcat.hp.model from this link:
    ftp://ftp.aplawrence.com/pub/netcat/netcat.hp.model

    and followed instruction indicated here:
    ftp://ftp.aplawrence.com/pub/netcatscript

    Using netcat script as I posted before, can cause the problems that I said
    before.
    Bye
    Marco




  3. Re: netcat problems on OpenServer 5.0.4


    ----- Original Message -----
    From: "clucom"
    Newsgroups: comp.unix.sco.misc
    To:
    Sent: Monday, March 05, 2007 3:08 AM
    Subject: Re: netcat problems on OpenServer 5.0.4


    >I found the solution downloading netcat.hp.model from this link:
    > ftp://ftp.aplawrence.com/pub/netcat/netcat.hp.model
    >
    > and followed instruction indicated here:
    > ftp://ftp.aplawrence.com/pub/netcatscript
    >
    > Using netcat script as I posted before, can cause the problems that I said
    > before.
    > Bye
    > Marco



    Some print servers basically suck.

    First, just you understand the context here, If it were me I wouldn't waste
    10 minutes wondering why that d-link doesn't work perfectly. And if I
    wouldn't consider that a good investment of my own time, I can't very well
    consider it a good investment of your time or your customers. Now from that,
    imagine how much less must I regard spending any time at all to help someone
    else do that which I wouldn't waste 10 minutes doing for myself or for one
    of my own customers? That may be part of why you're not getting lots of
    answers. Anyone who has been around enough to have some useful insight into
    this also probably feels the same way. If the question were about an hp,
    then we'd know at least it wasn't a waste of time trying to figure it out
    because we'd know at least the tools were solid.

    That said, every now and then despite the best intentions, one does get
    saddled with junk and has to make a reasonable effort to make it work if at
    all possible. So I do have more advice than "get a real print server and
    junk that d-link".
    That is merely my first and best advice.
    (my personal list of dependable names is just HP and Intel. Some people
    would add Axel to that but I wouldn't)

    So...
    With several cheap print servers I've found that even though they nominally
    "support" a fistfull of protocols, they are only reliable on a few of them,
    and sometimes not really reliable on any.
    Several in particular are poor at raw tcp but ok at netbios (windows file &
    print sharing, aka SMB, aka CIFS).
    That's presumably because they manage to test and debug the method windows
    users will use more or less thouroughly, and probably barely test the other
    protocols at all. Some are a little better than that and are OK at lpd/lpr
    as well as netbios.

    So, if it were me, if I thought the customer would tolerate another possible
    "oops, guess that didn't work either, sorry", which I basically never think
    that, I'd try using lpr/lpd instead of netcat.

    If that failed to be reliable then it's a toss up whether I'd junk it at
    that point or give it one more shot using samba or facetwin (netbios)
    instead of netcat or lpd/lpr. Most times if it was for a customer I'd not
    waste any time on it at all. One hour of on-site time costs the customer
    more than a proper print server and going back 2 or 3 times to deal with the
    thing racks up several hours.

    ..... _unless_ you have some strong reason to feel sure about the d-link,
    like, you already have several of them out in the field being hammered with
    reasonably heavy/busy production work, hooked to the same type of printer
    (different printers behave differently, especially when it comes to parallel
    port speed and handshaking, so 10 rock solid laser printers don't mean a
    whole lot towards proving it should be just as reliable with a dot matrix).

    Another thing to check is the data in the print job. When using raw tcp
    sometimes you have to be more careful about always sending some printer
    control or escape sequence that tells the printer to stop waiting for more
    data, print whatevers in the buffer and eject the page.
    That might be a trailing form-feed, or a printer reset (Esc-E for hp
    lasers), etc...

    --
    Brian K. White -- brian@aljex.com -- http://www.aljex.com/bkw/
    +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
    filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!


  4. Re: netcat problems on OpenServer 5.0.4

    clucom wrote:
    > using netcat.elf command I have problem printing small ASCII files on
    > Lexmar printer 4227plus connected on the LAN by a D-Link printer server
    > DP301P+.
    > Only if I execute consecutively several time (5 or 6 times) the string
    > command below, the printer works.
    > The string command is:
    >
    > cat filename | /usr/local/bin/netcat -h 126.0.0.23 -p 9100
    >
    > The small file is an ascii file that contains only some characters.
    > From windows OS if I print from notepad the same file the printer work
    > right.
    > I have no problem to print small files on a Laser Hp 4200n with internal LAN
    > drive.
    > May you have some suggestion or solution?
    > Thanks


    DP301P+ and netcat will not work reliably if they work at all. The
    DP301P+ is a classic example of a junk print server. They will work
    somewhat with lpd, at least with 5.0.6. I had been using Netgear
    PS-102s but they are no longer available so I tried a DP301P+. I now
    use it on a low use dot matrix with lpd. Acts up more than the other
    dozen or so print servers we use combined. What I do have that works
    great with netcat are Netgear PS-102s, A wide variety of Kyocera/Mita
    built in servers FS3750, FS3800, FS3830, FS4000, KM1820, KM5530, C5016
    HPs and another ancient print server which I can't recall at the moment.

    You can of course use the DP301P+ with lpd or samba but then you lose
    all the great benefits of netcat.

    Don't waste anymore time on it.
    Just my 2 cents worth!

    Good Luck

    Glenn


  5. Re: netcat problems on OpenServer 5.0.4


    ----- Original Message -----
    From: "Glenn"
    Newsgroups: comp.unix.sco.misc
    To:
    Sent: Tuesday, March 06, 2007 10:07 PM
    Subject: Re: netcat problems on OpenServer 5.0.4


    > clucom wrote:
    >> using netcat.elf command I have problem printing small ASCII files on
    >> Lexmar printer 4227plus connected on the LAN by a D-Link printer server
    >> DP301P+.
    >> Only if I execute consecutively several time (5 or 6 times) the string
    >> command below, the printer works.
    >> The string command is:
    >>
    >> cat filename | /usr/local/bin/netcat -h 126.0.0.23 -p 9100
    >>
    >> The small file is an ascii file that contains only some characters.
    >> From windows OS if I print from notepad the same file the printer work
    >> right.
    >> I have no problem to print small files on a Laser Hp 4200n with internal
    >> LAN drive.
    >> May you have some suggestion or solution?
    >> Thanks

    >
    > DP301P+ and netcat will not work reliably if they work at all. The
    > DP301P+ is a classic example of a junk print server. They will work
    > somewhat with lpd, at least with 5.0.6. I had been using Netgear PS-102s
    > but they are no longer available so I tried a DP301P+. I now use it on a
    > low use dot matrix with lpd. Acts up more than the other dozen or so
    > print servers we use combined. What I do have that works great with
    > netcat are Netgear PS-102s, A wide variety of Kyocera/Mita built in
    > servers FS3750, FS3800, FS3830, FS4000, KM1820, KM5530, C5016 HPs and
    > another ancient print server which I can't recall at the moment.
    >
    > You can of course use the DP301P+ with lpd or samba but then you lose all
    > the great benefits of netcat.


    Actually except for one thing, you can use lpd in a way that is just as good
    as netcat just by using rlpr as a drop in replacement for netcat.
    ie: where a netcat command might be "netcat -h 192.168.1.20 -p 9100"
    the equivalent rlpr command is "rlpr -H 192.168.1.20 -P RAW1"
    You have to find out the lpd queue names for the print server you're using,
    and note that some print servers offer multiple queues for the same physical
    ports, and they treat the data differently based on what queue you asked
    for. For HP JetDirects, RAW1 means send the data to port 1 without modifying
    it at all, ala netcat. TEXT1 will do crlf translation etc..

    I was about to describe the one thing you lose, and I just realized you
    don't even lose that.

    With netcat, it's easy to print to a remote site even if the remote site has
    several printers on different print servers. Because all the remote print
    servers can be listening on different tcp ports and you can have the remote
    router port-forward the different ports to the different print servers. Or,
    if the router can also to port mapping, it's even simpler because then the
    print servers can listen on their normal standard/default ports even if
    they're all the same model and so all listening on the same, say, 9100.

    With lpd, all traffic is always on port 515, which at first glance means you
    can only set up one print server at a remote site, by port-forwarding port
    515.
    (not counting obvious and impractical brute force approaches like installing
    a linux or unix or even a windows box at the remote site with all the
    printers configured in it)
    But rlpr allows you to specify an arbitrary tcp port, so as long as the
    remote router can do portmapping (many do, even cheap ones, but some cheap
    ones don't) then it's no problem.

    One advantage to lpd is it's a more informative protocol. You can query the
    status of the print server and of a print job.

    rlpr and a sort of unified net printer interface script that uses both
    netcat and rlpr and all the existing standard interface scripts is here:
    http://www.aljex.com/bkw/sco/#rlpnc

    That includes a netcat binary and the Net interface script knows the full
    explicit path to that binary, so it's self contained and ready to go out of
    the box for netcat usage.
    To allow lpd also, just install rlpr from that same page.

    As far as this particular threads original problem, my other post hopefully
    showed I agree completely with you about the dlink print server.

    Brian K. White -- brian@aljex.com -- http://www.aljex.com/bkw/
    +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
    filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!


+ Reply to Thread