I'm running into a really weird problem...

I have a network at home that looks like this:

1. Slackware desktop on wired ethernet
2. Linksys WAP54G wifi access point
3. Slackware laptop on wifi
4. Ubuntu desktop on wifi
5. WinXP laptop on wifi
6. HP LaserJet 3052 on wired ethernet

When I print from the Slackware desktop or the WinXP laptop, everything works fine.

When I try to print from either of the Linux wifi systems, nothing prints (the status light on the printer never even blinks). Even weirder, the printer seems to partially lock up -- after that, I can't print from the Slackware desktop until I power-cycle the printer.

It doesn't seem to be a connectivity issue. I can see the printer's built-in web config page from any of the computers - ethernet or wifi - even after the printing locks up.

Looking at tcpdump traces for the Ubuntu machine, I can see PostScript code being sent to the printer, but the printer never sends TCP ACKs (or they never reach the Ubuntu box), and eventually the connection times out.

I've upgraded the firmware in both the WAP54g and the printer.

The wifi otherwise works fine. I've never had any problems web browsing, etc. from any of the systems.

Does anyone have a guess as to what might be going on?

Check out Ubuntu apparmor's cups profile...it defaults to blocking cups to all but the local machine ( last time I looked anyways )

I'd be interested to hear what you find.

I assume you are trying to print directly and cups on each computer is configured identically for the printers URI.
You could try printing through the slackware desktop by configuring cups to share the printer and allow port 631 traffic if running a firewall. Then add a printer on the wireless boxes using the slackware desktop.

Your printer uses common HP printing languages so if it was a driver issue you could change to any PCL6, PCL5e or even a postscript compatible printer driver to see if that makes a difference.

1 members found this post helpful.

A couple things I forgot to mention...

All of the Linux boxes are using CUPS, with identical configurations for the printer: JetDirect connection (port 9100, direct to the printer), and a PostScript driver.

I've also tried using LPD instead of JetDirect, and I get exactly the same result -- the machines on wifi can't print, and the printer locks up.

Switching the Ubuntu machine over to wired ethernet immediately fixes the problem. Printing works fine with no change in configuration. This isn't a long-term solution -- my wife isn't so happy with an ethernet cable running down the hallway :-)

I'm not familiar with AppArmor, but I doubt that's the problem, given that (1) I see the same problem on the Slackware laptop (no AppArmor) over wifi, and (2) the Ubuntu system works correctly over wired ethernet. But I really don't know anything about AppArmor, so let me know if I'm missing something.

Printing through the Slackware desktop using CUPS sharing might be a workaround - I'll give that a try later.

I'm still very curious to figure out what's going on here. It feels like the WAP54g is eating some of the packets (but only when the printer is involved).

A bit strange that wireless works except for printing.

What are you using for a router/gateway?

The Slackware desktop is the router/gateway. It has a second ethernet card connected to a DSL modem; it runs an iptables firewall, configured for NAT; and it also runs a DHCP daemon.

The wifi is via a Linksys WAP54g (which is an access point only - no DHCP or NAT).

All of the computers, the printer, and the wifi access point are behind the firewall - they all have 192.168.1.x addresses.

I also have a WAP54G but I do not have it attached to my network anymore. Its been awhile since I looked at its settings but do not think it had anything to block or restrict traffic on a particular port. Have you tried printing via the desktop yet?

Just tried setting things up to print via the CUPS server running on the desktop, and that seems to work fine. My best guess is that there are bugs in the TCP stack in the printer and/or the WAP54g that happen to interact in a really weird way. Still seems pretty strange though.

You are correct about the WAP54g -- it doesn't have any sort of firewall functionality. The only thing it can do is restrict to a list of MAC addresses (which I have turned off).