It would be interesting to see the Negotiate Protocol exchange. It sounds as though the print station is using an older dialect.
Chris -)----- On Tue, Oct 22, 2002 at 08:00:42PM +0200, Eddie Lania wrote: > Hello folks, > > Regarding the story below, has there ever been done some effort to acomplish > this? > We use several of these so called "windows print stations" at work, but > whatever I have tried with samba, cups, etc, I can't get it to work. > Perhaps this is an issue that has allready been solved in the past, but I > couldn't find anything in this direction. > > Any help would be appreciated. > > Eddie. > > ----------------------- > > > From: "Wim Verhoogt" > Subject: Printing on printers connected to Intel InBusiness print > stations > Date: Tue, 17 Jul 2001 18:44:39 +0200 > > L.S., > > I've been struggling to print with Intel InBusiness print stations. These > stations are labeled as "for use with Windows only" by Intel. > I found out that they emulate a Windows machine exporting two printer > shares, one for each connector. The NetBIOS name of the stations is the > Device ID, and the shares are //device_id/Printer1 and //device_id/Printer2 > I tried to print to these shares with smbclient's print command, but > received various errors. > Some reverse-engineering (tcpdump is your friend :-) ) showed that you have > to specify a remote filename of DEV\LPT1 (or DEV\LPT2 for the 2nd share - > haven't tested that), and that SMB_COM_WRITE (0x0B) must be used to write > to the share. Smbclient uses WRITE_COM_ANDX (0x2F). This doesn't return an > error, but garbles the print data. > I've patched smbclient to support this. I implemented a new option (-H) > which will direct smbclient to write using SMB_COM_WRITE. The put command > can now be used to print to the InBusiness stations. The print command won't > work because it doesn't support specifying a remote filename.With this hack > and a CUPS backend script, my server now exports 3 printers, connected to > these stations, and I'm happy :-) > I was wondering if this new feature of smbclient can be incorporated in the > official SAMBA distribution, so that I don't need to patch smbclient for > each new release. I doubt that the new -H option is the best way to do that, > it just happened to be a quick and easy way to solve my problem. > > The patch used was: > > --- client.c Fri Jul 6 04:01:20 2001 > +++ /home/wim/cvs/samba/source/client/client.c Mon Jul 9 16:33:41 2001 > @@ -79,6 +79,7 @@ > BOOL prompt = True; > > int printmode = 1; > +BOOL inBusiness_hack = False; > > static BOOL recurse = False; > BOOL lowercase = False; > @@ -1031,8 +1032,10 @@ > DEBUG(0,("Error reading local file: %s\n", strerror(errno) )); > break; > } > - > - ret = cli_write(cli, fnum, 0, buf, nread, n); > + if (inBusiness_hack) > + ret = cli_smbwrite(cli, fnum, buf, nread, n); > + else > + ret = cli_write(cli, fnum, 0, buf, nread, n); > > if (n != ret) { > DEBUG(0,("Error writing file: %s\n", cli_errstr(cli))); > @@ -2415,7 +2418,7 @@ > } > > while ((opt = > - getopt(argc, argv,"s:O:R:M:i:Nn:d:Pp:l:hI:EU:L:t:m:W:T:D:c:b:A:")) != > EOF) { > + getopt(argc, argv,"s:O:R:M:i:Nn:d:Pp:l:hI:EU:L:t:m:W:T:D:c:b:A:H")) != > EOF) { > switch (opt) { > case 's': > pstrcpy(servicesf, optarg); > @@ -2571,6 +2574,9 @@ > break; > case 'b': > io_bufsize = MAX(1, atoi(optarg)); > + break; > + case 'H': > + inBusiness_hack = True; > break; > default: > usage(pname); > > --__--__-- > > -- Samba Team -- http://www.samba.org/ -)----- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)----- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)----- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/ -)----- [EMAIL PROTECTED]