Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Sun 09 Dec 2018, 20:03
All times are UTC - 4
 Forum index » House Training » Users ( For the regulars )
Puppy LAN 101
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 2 of 2 [29 Posts]   Goto page: Previous 1, 2
Author Message
gcmartin

Joined: 14 Oct 2005
Posts: 6730
Location: Earth

PostPosted: Tue 03 May 2011, 20:36    Post subject: Re: Meeting Smokey01 request for requirements  

smokey01 wrote:
... would like to document my learning experience in a stand alone PDF document.[/b] ...
That most certainly would be helpful to the Puppy, Linux many. Many Windows users commonly go thru this when trying to get their LANs operational with Linux PCs present.

Check your PM for a messageHope this helps.

_________________
Get ACTIVE Create Circles; Do those good things which benefit people's needs!
We are all related ... Its time to show that we know this!
3 Different Puppy Search Engines or use DogPile
Back to top
View user's profile Send private message 
smokey01


Joined: 30 Dec 2006
Posts: 2792
Location: South Australia :-(

PostPosted: Wed 04 May 2011, 04:14    Post subject:  

rcrsn51 wrote:
We need to get our terminology right. The SERVER is the machine that has the printers plugged into it. Your CLIENT machine is supposedly your laptop.


The SERVER is the desktop computer that has the printers plugged into it and the IP of the SERVER is 192.168.0.3

rcrsn51 wrote:
In the previous post, you have stated that 192.168.0.3 is the server AND that 192.168.0.4 is the server. You need to get this straight.

I'm not sure where I said that. Anyway, the CLIENT is another desktop computer and it's IP address is 192.168.0.4


smokey01 wrote:
Do I need to setup the printer for the CLIENT on the client machine

rcrsn51 wrote:
Ummm. We're talking about the laptop? You should have been using the URI
Code:
ipp://192.168.0.?:631/printers/Samsung_ML-1660_Series
on the laptop.


What should the ? mark represent 3 or 4

I also noticed it takes a long tome to scan the network when using pnethood and often doesn't find any shares.

By typing pnethood 192.168.0.3 in a terminal window pnethood connects to pupserver very fast.

Thanks

_________________
Software <-> Distros <-> Tips <-> Newsletters
Back to top
View user's profile Send private message Visit poster's website 
smokey01


Joined: 30 Dec 2006
Posts: 2792
Location: South Australia :-(

PostPosted: Wed 04 May 2011, 05:56    Post subject:  

It looks like I was too clever for my own good. Using pnethood 192.168.0.3 was fast to find the pupshare on the SERVER but now I can't connect to it as it looks like it has not been disconnected properly, and is refusing further connections.

How do I find and close the pupshare?

Thanks

_________________
Software <-> Distros <-> Tips <-> Newsletters
Back to top
View user's profile Send private message Visit poster's website 
rcrsn51


Joined: 05 Sep 2006
Posts: 12360
Location: Stratford, Ontario

PostPosted: Wed 04 May 2011, 07:20    Post subject:  

smokey01 wrote:
What should the ? mark represent 3 or 4

The ? should be the IP address of the server. The URI should be typed in the CUPS setup of the client.
Quote:
How do I find and close the pupshare

Reboot everything - both client and server.
Back to top
View user's profile Send private message 
smokey01


Joined: 30 Dec 2006
Posts: 2792
Location: South Australia :-(

PostPosted: Thu 05 May 2011, 05:09    Post subject:  

rcrsn51 wrote:
smokey01 wrote:
What should the ? mark represent 3 or 4

The ? should be the IP address of the server. The URI should be typed in the CUPS setup of the client.
Quote:
How do I find and close the pupshare

Reboot everything - both client and server.


I am able to connect to the SERVER again. Thanks.

The printing part has got me stumped.

Using the CUPS method I don't understand why my CLIENT can't see the two printers attached to my SERVER. According to everything I have read the CLIENT should see them when using CUPS in the find printers mode.

Hold the bus: Both of my printers are connected to the SERVER via USB ports, not the router. Will this make a difference?

I have tried using the ipp://192.168.0.3:631/printers/Samsung_ML-1660_Series method on the CLIENT. It then continues and asks to select a printer driver so I choose the correct driver and follow the prompts. Still no Joy.

Sad Sad Sad Sad Sad Sad Sad Sad Sad Sad Sad Evil or Very Mad Evil or Very Mad Evil or Very Mad Evil or Very Mad

Thanks

_________________
Software <-> Distros <-> Tips <-> Newsletters
Back to top
View user's profile Send private message Visit poster's website 
rcrsn51


Joined: 05 Sep 2006
Posts: 12360
Location: Stratford, Ontario

PostPosted: Thu 05 May 2011, 10:10    Post subject:  

smokey01 wrote:
Using the CUPS method I don't understand why my CLIENT can't see the two printers attached to my SERVER. According to everything I have read the CLIENT should see them when using CUPS in the find printers mode.

Are you looking in Administration > Find New Printers or under the Printers tab? The latter is correct. However, we already know that Pnethood has great difficulty finding Samba shares on your network. So it's no surprise that the client would have trouble finding shared printers. But I don't know why that would be.

Go back to the server and verify that it is configured correctly. Each printer should say (Idle, Accepting jobs Shared). Also verify in the Administration section that you have checked "Share printers connected to this system".

Quote:
Hold the bus: Both of my printers are connected to the SERVER via USB ports, not the router. Will this make a difference?

No. The whole point of the exercise is to make the server's local printers sharable.

Quote:
I have tried using the ipp://192.168.0.3:631/printers/Samsung_ML-1660_Series method on the CLIENT. It then continues and asks to select a printer driver so I choose the correct driver and follow the prompts. Still no Joy.

What exactly went wrong? Do you have both Puppy firewalls turned off? Does your modem/router have an internal firewall?

If you can't make the printers sharable via CUPS, your other option is to use the Samba server. This is described in the Samba-TNG How-to.
Back to top
View user's profile Send private message 
rcrsn51


Joined: 05 Sep 2006
Posts: 12360
Location: Stratford, Ontario

PostPosted: Thu 05 May 2011, 10:17    Post subject:  

On the CLIENT machine, open your web browser and go to this address
Code:
http://192.168.0.3:631

What happens? If you get access, go to
Code:
http://192.168.0.3:631/printers
Back to top
View user's profile Send private message 
smokey01


Joined: 30 Dec 2006
Posts: 2792
Location: South Australia :-(

PostPosted: Thu 05 May 2011, 17:28    Post subject:  

rcrsn51 wrote:


Go back to the server and verify that it is configured correctly. Each printer should say (Idle, Accepting jobs Shared).

It is.

rcrsn51 wrote:
Also verify in the Administration section that you have checked "Share printers connected to this system".

It is

Quote:
I have tried using the ipp://192.168.0.3:631/printers/Samsung_ML-1660_Series method on the CLIENT. It then continues and asks to select a printer driver so I choose the correct driver and follow the prompts. Still no Joy.

rcrsn51 wrote:
What exactly went wrong? Do you have both Puppy firewalls turned off?

No but I thought I had the 631 port open. I then opened port 631 on the SERVER and YaHoo the CLIENT could see the printer using the http://192.168.0.3:631/printers command from a browser.

rcrsn51 wrote:
Does your modem/router have an internal firewall?

Yes but it's off

rcrsn51 wrote:
If you can't make the printers sharable via CUPS, your other option is to use the Samba server. This is described in the Samba-TNG How-to.

I had tried that too but now we know why that didn't work, bloody firewalls.

Thank you so much.

_________________
Software <-> Distros <-> Tips <-> Newsletters
Back to top
View user's profile Send private message Visit poster's website 
rcrsn51


Joined: 05 Sep 2006
Posts: 12360
Location: Stratford, Ontario

PostPosted: Thu 05 May 2011, 18:04    Post subject:  

Quote:
Thank you so much.

So what happened? Can you now print from the client to the server? Which way?
Back to top
View user's profile Send private message 
smokey01


Joined: 30 Dec 2006
Posts: 2792
Location: South Australia :-(

PostPosted: Fri 06 May 2011, 04:43    Post subject:  

Sorry rcrsn51 I got a bit carried away in all the excitement.

In CUPS I installed the remote printer with the http://102.168.0.3:631/printers/Samsung_ML-1660_Series

I also installed the Samsung_ML-1660_Series printer driver on the client although I didn't think that would be necessary. I wasn't able to work out how to continue the setup without completing this step.

Even if I used the ipp:// method it prompted me to install a driver by choosing make then model.

Is this the correct way or is there a simpler way?

Grant

_________________
Software <-> Distros <-> Tips <-> Newsletters
Back to top
View user's profile Send private message Visit poster's website 
rcrsn51


Joined: 05 Sep 2006
Posts: 12360
Location: Stratford, Ontario

PostPosted: Fri 06 May 2011, 09:00    Post subject:  

smokey01 wrote:
In CUPS I installed the remote printer with the http://102.168.0.3:631/printers/Samsung_ML-1660_Series

I also installed the Samsung_ML-1660_Series printer driver on the client although I didn't think that would be necessary. I wasn't able to work out how to continue the setup without completing this step.

Even if I used the ipp:// method it prompted me to install a driver by choosing make then model.

Is this the correct way or is there a simpler way?

Supplying the driver for a remote printer can be confusing.

1. Suppose you have a standalone networked printer running off its own ethernet or wifi port. Then the client must have the correct driver and must format the print job before sending it to the printer. In CUPS, you would usually install the printer with the socket:// protocol.

2. Suppose your printer is connected to the server via a USB or parallel port (like yours). In most cases, the client computer will auto-detect the shared printer, so no installation is required. Your application software will immediately see the printer. In CUPS, the printer will be listed as using the ipp:// protocol. You don't need to install a driver on the client because the server handles the formatting of the print job.

3. Suppose the client computer can't auto-detect the shared printer. You will then manually install the printer using the ipp:// protocol. (The http:// protocol is actually the same thing.) However this protocol indicates that the server will format the print job, so you shouldn't need to provide a driver or select a Make/Model. In CUPS, you can use Raw/Raw Queue instead. You don't need to install a driver package.

4. You use ipp:// but install a driver and specify a Make/Model. That suggests that the client machine will now format the print job. When CUPS on the server receives the job, it is smart enough to recognize that the job has already been formatted and sends it directly to the printer. But this may depend on how CUPS on the server is configured.

5. The client machine is running Windows. The simplest printer setup is to select a Postscript driver. This is equivalent to #3 above, so the print job leaves the Windows machine unformatted and CUPS on the server handles the formatting.

6. The client machine is running Windows, but you want to use the official Windows printer driver because it has more features. This is now a #4 situation because the client will do the formatting. Again, this depends on how CUPS on the server is configured. You may need to install the printer on the SERVER using Raw/Raw Queue to prevent it from doing any extra formatting.

7. You are using a Samba server to handle network printing. On the client, you will use the smb:// protocol. This will require a printer driver on the client, and formatting will be done by the client. When the Samba server receives the print job, it sends it directly to the CUPS queue.

8. You have a networked printer like in #1, but want to use the lpd:// protocol instead of socket://. (Some Brother printers can be installed this way.) This is similar to a Windows setup because you get to use NetBIOS names instead of IP addresses. The client supplies the driver and the URI looks like
Code:
lpd://BRN_792F89/BINARY_P1

However, Puppy still must resolve the NetBIOS name into an IP address, so you need a line in /etc/hosts to do this.
Code:
192.168.2.10 BRN_792F89
Back to top
View user's profile Send private message 
smokey01


Joined: 30 Dec 2006
Posts: 2792
Location: South Australia :-(

PostPosted: Fri 06 May 2011, 10:01    Post subject:  

[quote="rcrsn51"]
smokey01 wrote:
In CUPS I installed the remote printer with the http://102.168.0.3:631/printers/Samsung_ML-1660_Series

I also installed the Samsung_ML-1660_Series printer driver on the client although I didn't think that would be necessary. I wasn't able to work out how to continue the setup without completing this step.

Even if I used the ipp:// method it prompted me to install a driver by choosing make then model.

Is this the correct way or is there a simpler way?

rcrsn51 wrote:
Supplying the driver for a remote printer can be confusing.

My original thoughts were correct. It was the firewall that confused the situation. When it blocked the connection I thought I was doing something wrong. What is the best way to test to see if the ports are open or closed?

rcrsn51 wrote:
1. Suppose you have a standalone networked printer running off its own ethernet or wifi port. Then the client must have the correct driver and must format the print job before sending it to the printer. In CUPS, you would usually install the printer with the socket:// protocol.

That makes sense as it needs to have a driver installed and it's not using the one on the SERVER computer.

rcrsn51 wrote:
2. Suppose your printer is connected to the server via a USB or parallel port (like yours). In most cases, the client computer will auto-detect the shared printer, so no installation is required. In CUPS, the printer will be listed as using the ipp:// protocol. You don't need to install a driver on the client because the server handles the formatting of the print job.

Agreed and the CLIENT could see the printers on the server with the http://192.168.0.3:631/printers URL

rcrsn51 wrote:
3. Suppose the client computer can't auto-detect the shared printer. You will then manually install the printer using the ipp:// protocol. (The http:// protocol is actually the same thing.) However this protocol indicates that the server will format the print job, so you shouldn't need to provide a driver or select a Make/Model. In CUPS, you can use Raw/Raw Queue instead. You don't need to install a driver package.

This was very helpful as I didn't understand the RAW/RAW approach. The process did ask for a Manufacturer and Model. By selecting Raw for the Manufacturer and Raw for Model did the trick.

rcrsn51 wrote:
4. You use ipp:// but install a driver and specify a Make/Model. That suggests that the client machine will now format the print job. When CUPS on the server receives the job, it is smart enough to recognize that the job has already been formatted and sends it directly to the printer. But this may depend on how CUPS on the server is configured.

It was obviously smart enough as it printed perfectly just as though the print job was sent from the SERVER.

rcrsn51 wrote:
5. The client machine is running Windows. The simplest printer setup is to select a Postscript driver. This is equivalent to #3 above, so the print job leaves the Windows machine unformatted and CUPS on the server handles the formatting.

Thanks but I hope I don't need this information anytime soon, but it will be useful for others using a Windows CLIENT.

rcrsn51 wrote:
6. The client machine is running Windows, but you want to use the official Windows printer driver because it has more features. This is now a #4 situation because the client will do the formatting. Again, this depends on how CUPS on the server is configured. You may need to install the printer on the SERVER using Raw/Raw Queue to prevent it from doing any extra formatting.

Understand

rcrsn51 wrote:
7. You are using a Samba server to handle network printing. On the client, you will use the smb:// protocol. This will require a printer driver on the client, and formatting will be done by the client. When the Samba server receives the print job, it sends it directly to the CUPS queue.

Yes this makes sense. I haven't tried the Samba print server since my last failed attempt but I assume it would work fine now that I have the 631 ports open on firewalls in both computers.

Did I mention &^$*^$ firewalls Embarassed

Thanks again. All is working now, both file access and printing. File access via Samba and Printing via CUPS.

_________________
Software <-> Distros <-> Tips <-> Newsletters
Back to top
View user's profile Send private message Visit poster's website 
rcrsn51


Joined: 05 Sep 2006
Posts: 12360
Location: Stratford, Ontario

PostPosted: Fri 06 May 2011, 10:15    Post subject:  

Just out of curiosity - was it the firewall on the server or on the client that caused the problem? Or both?
Quote:
What is the best way to test to see if the ports are open or closed?

Don't know. But consider this. Because your network is behind a router, your machines are invisible to the outside world. So running firewalls on your Puppy machines serves no useful purpose. All they do is give you a false sense of security and complicate file/printer sharing.

There was a long discussion about this recently and no one was able to refute the above opinion with any hard evidence.

However, I would be happy to hear an opinion from someone on how Samba shares on a LAN could theoretically be exposed to the outside world. I suppose that this could involve a badly-configured router.
Back to top
View user's profile Send private message 
vektor_alian

Joined: 20 Feb 2018
Posts: 31

PostPosted: Fri 23 Feb 2018, 17:09    Post subject:  

Try Pupserver 435 from archive.org
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 2 of 2 [29 Posts]   Goto page: Previous 1, 2
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » House Training » Users ( For the regulars )
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1122s ][ Queries: 11 (0.0164s) ][ GZIP on ]