Puppy LAN 101

[gcmartin]

... 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.

[smokey01]

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

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

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

Ummm. We're talking about the laptop? You should have been using the URI

Code: Select all

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

[smokey01]

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

[rcrsn51]

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.

How do I find and close the pupshare

Reboot everything - both client and server.

[smokey01]

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.

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.



Thanks

[rcrsn51]

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".

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.

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.

[rcrsn51]

On the CLIENT machine, open your web browser and go to this address

Code: Select all

http://192.168.0.3:631

What happens? If you get access, go to

Code: Select all

http://192.168.0.3:631/printers

[smokey01]

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

It is.

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

It is

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?

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.

Does your modem/router have an internal firewall?

Yes but it's off

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.

[rcrsn51]

Thank you so much.

So what happened? Can you now print from the client to the server? Which way?

[smokey01]

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

[rcrsn51]

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: Select all

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: Select all

192.168.2.10 BRN_792F89

[smokey01]

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.

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?

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.

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

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.

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.

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.

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

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

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

[rcrsn51]

Just out of curiosity - was it the firewall on the server or on the client that caused the problem? Or both?

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.

[vektor_alian]

Try Pupserver 435 from archive.org