Since we've switched to spoolss printing (samba 2.2.4) it seems that the server is always trying to connect to the client. [2002/06/11 10:52:41, 3] lib/util_sock.c:open_socket_out(843) Connecting to 10.0.40.80 at port 445 [2002/06/11 10:52:41, 2] lib/util_sock.c:open_socket_out(871) error connecting to 10.0.40.80:445 (Connection refused) [2002/06/11 10:52:41, 3] lib/util_sock.c:open_socket_out(843) Connecting to 10.0.40.80 at port 139 I've traced this back in the source to the "spoolss_connect_to_client" call in rpc_server/srv_spoolss_nt.c. It seems this is used to reply back to the client with printing info. However, in our environment, such connections typically fail, as we disable the "Server" service on NT/W2K clients as much as possible. In those cases, printing still works fine, so I'm starting to wonder if these back connections are absolutely needed. They are especially annoying when the back connection is made to a firewalled client; it slows down response of the print server enormously (the server waits until the back connection times out). So, I was thinking; is there an smb.conf option (or could it be implemented) to disable these back connections? What would the impact be if I modified the src_spoolss_replyopenprinter() routine to always return false? Would that break anything? Thx, Tom.
On Tue, 11 Jun 2002, Tom Vandepoel wrote:> Since we've switched to spoolss printing (samba 2.2.4) it seems that the > server is always trying to connect to the client. > > [2002/06/11 10:52:41, 3] lib/util_sock.c:open_socket_out(843) > Connecting to 10.0.40.80 at port 445 > [2002/06/11 10:52:41, 2] lib/util_sock.c:open_socket_out(871) > error connecting to 10.0.40.80:445 (Connection refused) > [2002/06/11 10:52:41, 3] lib/util_sock.c:open_socket_out(843) > Connecting to 10.0.40.80 at port 139 > > I've traced this back in the source to the "spoolss_connect_to_client" > call in rpc_server/srv_spoolss_nt.c. It seems this is used to reply back > to the client with printing info.This is the printer change notification back channel.> However, in our environment, such connections typically fail, as we > disable the "Server" service on NT/W2K clients as much as possible. In > those cases, printing still works fine, so I'm starting to wonder if > these back connections are absolutely needed. They are especially > annoying when the back connection is made to a firewalled client; it > slows down response of the print server enormously (the server waits > until the back connection times out). > > So, I was thinking; is there an smb.conf option (or could it be > implemented) to disable these back connections? What would the impact be > if I modified the src_spoolss_replyopenprinter() routine to always > return false? Would that break anything?Better to just comment out the SPOOLSS_RFFPCN and SPOOLSS_RFNPCN server functions. However, certain changes will not be reflected on the client such as josb listings, etc.... btw....this is MS's model. You'll have the same problem with a Win2k print server. I do agree that it is a brain dead design... cheers, jerry --------------------------------------------------------------------- Hewlett-Packard http://www.hp.com SAMBA Team http://www.samba.org -- http://www.plainjoe.org "Sam's Teach Yourself Samba in 24 Hours" 2ed. ISBN 0-672-32269-2 --"I never saved anything for the swim back." Ethan Hawk in Gattaca--
On Tue, Jun 11, 2002 at 11:12:08AM +0200, Tom Vandepoel wrote:> Since we've switched to spoolss printing (samba 2.2.4) it seems that the > server is always trying to connect to the client. > > [2002/06/11 10:52:41, 3] lib/util_sock.c:open_socket_out(843) > Connecting to 10.0.40.80 at port 445 > [2002/06/11 10:52:41, 2] lib/util_sock.c:open_socket_out(871) > error connecting to 10.0.40.80:445 (Connection refused) > [2002/06/11 10:52:41, 3] lib/util_sock.c:open_socket_out(843) > Connecting to 10.0.40.80 at port 139 > > I've traced this back in the source to the "spoolss_connect_to_client" > call in rpc_server/srv_spoolss_nt.c. It seems this is used to reply back > to the client with printing info.It's actually for the printer notifcation stuff. I.e if you have a port monitor open on one machine, then print a document from a second machine, the port monitor will be notified asynchonrously that a new document has been spooled. Under Windows 9x/ME this doesn't happen. The port monitor must poll every 15 seconds or so to see if new jobs have been spooled.> However, in our environment, such connections typically fail, as we > disable the "Server" service on NT/W2K clients as much as possible. In > those cases, printing still works fine, so I'm starting to wonder if > these back connections are absolutely needed. They are especially > annoying when the back connection is made to a firewalled client; it > slows down response of the print server enormously (the server waits > until the back connection times out).I've been poking at these last week and I'm pretty sure if there is an error creating the back channel connection, it just falls back to polling mode. Also, with a back channel connection open when you hit 'Apply' on a printer properties dialog box the hourglass appears until all notification data has been sent to connected clients which can slow things down.> So, I was thinking; is there an smb.conf option (or could it be > implemented) to disable these back connections? What would the impact be > if I modified the src_spoolss_replyopenprinter() routine to always > return false? Would that break anything?Good idea. It should affect anything. If you find any problems with this post them to the list! Regards, Tim.