In order to understand this bug in more detail I'll need some debugging information from cups.  Please edit /etc/cups/cupsd.conf and change the 'LogLevel' line to read:

LogLevel debug2

Then run '/sbin/service cups restartlog' and attempt to connection from the guest machine again.  Then attach the /var/log/cups/error_log file from the host machine.

Thanks.

Created attachment 342560 [details]
Error Log of CUPS

What does '/sbin/ifconfig' say?

I think what's going on is that the virtualbox network interface is not being seen as a local interface, possibly because it is point-to-point?

The output of '/sbin/ifconfig' is as follows:

eth0      Link encap:Ethernet  HWaddr 00:24:1D:16:8E:8E  
          inet addr:203.73.249.181  Bcast:203.73.249.255  Mask:255.255.255.0
          inet6 addr: fe80::224:1dff:fe16:8e8e/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6818239 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5101351 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:3357579375 (3.1 GiB)  TX bytes:417147408 (397.8 MiB)
          Interrupt:20 Base address:0xc000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:142 errors:0 dropped:0 overruns:0 frame:0
          TX packets:142 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:21121 (20.6 KiB)  TX bytes:21121 (20.6 KiB)

I'm afraid this is working as designed then.  The request is sent over the loopback interface, but is trying to refer to the host by a name not known to it.  Use the host machine's FQDN instead.

It will be somewhat inconvenient if the host is just a personal work station with a dynamic IP.  Since the IP of the host will vary from time to time, the setting of CUPS server in the guest machine needs to change accordingly.  Is it possible to allow a specified IP address of the request over the loopback interface?

You can use "ServerAlias *" to allow any hostname.  Then you can use the machine's externally-visible address.

The guest machine can access the external IP address of the host machine without any problem.  However, since the external IP address of the host machine is dynamic, every time we want to print in the guest machine, we will need to set the CUPS server's IP according to the current host's IP.  That will cause some trouble.

On the contrary, the internal NAT IP (10.0.2.2) of the host is fixed.  And it will be quite suitable for the CUPS server IP setting.  So, I am wondering if there is any possibility to allow a certain IP (say, 10.0.2.2) to access the CUPS server.

I have just use "ServerAlias *" to see if it is ok for "http://10.0.2.2:631".  But it didn't work.

Did anyone find a solution for this using the NAT device? I want to print from a WinXP VM to the host Cups-PDF printer but I can't establish contact with the cups http server from the VM NAT interface. I've tried the host's real IP address, its FQDN, 10.0.2.2... and I keep getting http 400 errors. I have ServerAlias * in my cupsd.conf.

Thanks!

Old CUPS did provide the solution.  But new CUPS enhance the security and disable the connection from the loopback interface...

Try to print to a Post-Script file to a shared directory.
Then you can print that file within the host...

I have partly resolved the problem.
In the guest, install putty and login to create a tunnel with the following data :
host : 10.0.2.2
SSH -> tunnel : local port 1631, remote port localhost:631

You can now access to the cups page with http://localhost:1631
And you can create a new printer with this adress : http://localhost:1631/printers/...

I am forced to use 10.0.2.2:631 to access cups, because we do virtualise Windows machine which are on vpn, and which does not have local network access (using QEMU-KVM with libvirt, user session). Hence, we do have to path through the gateway (10.0.2.2, which map to 127.0.0.1 when cups do receives the request)

I do have other complex solutions (like using another cups on our enterprise network forwarding to the cups linux host, some kind of http header rewrite, put the vpn under linux and not on Windows ...), but this is not the good way to work around this problem in my pov, and far over from my knowledge.

Looking at the cupsd source code, the "valid_host" function in "cups-1.7.0/scheduler/client.c:4174" do tests to ensure the request is local if it comes from the loopback interface. It would be great if we can add another address in the test in order to make valid_host return true.

May be there is a simpler solution you know, which would make me happy!

How to reproduce:
$ virt-manager --connect=qemu:///session
(I launch qemu as a regular user)
- install a small linux distro with firefox,
- launch cups on the host machine
- in firefox from the guest
  - 10.0.2.2:631 shows "Bad Request"
  - 192.168.122.1:631 shows host cups instance.

But in my case, I cannot use the local network.

Thanks for your support!
Adrien