Bug 498711 - CUPS did not accept the connection from the guest virtual machine (VirutalBox 2.2.2)
CUPS did not accept the connection from the guest virtual machine (VirutalBox...
Product: Fedora
Classification: Fedora
Component: cups (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Tim Waugh
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-05-02 07:39 EDT by CW Lin
Modified: 2014-03-23 04:28 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-05-06 07:55:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Error Log of CUPS (28.69 KB, text/plain)
2009-05-05 19:44 EDT, CW Lin
no flags Details

  None (edit)
Description CW Lin 2009-05-02 07:39:52 EDT
Description of problem:
I have VirtualBox-2.2.2_46594_fedora9-1.i386 installed on
A virtual machine was created with the following NAT configuration:
Ethernet adapter :

        Connection-specific DNS Suffix  . :
        IP Address. . . . . . . . . . . . :
        Subnet Mask . . . . . . . . . . . :
        Default Gateway . . . . . . . . . :

When I try to use the browser of the guest machine to open the connection to the CUPS server with "", the error message "400 Bad Request" is shown.

Version-Release number of selected component (if applicable):

Some error messages in "":
W [02/May/2009:17:38:23 +0800] Request from "localhost" using invalid Host: field ""

How reproducible:
Open IE/Firefox with URL "http://guest_machine_gateway:631/"

Steps to Reproduce:
1. Create an virtual machine of VirtualBox
2. Open IE/Firefox with URL "http://guest_machine_gateway:631/"
Actual results:
Can not use shared-printer in the guest machine.

Expected results:
Shared-printer is ready to use in the guest machine.

Additional info:
Comment 1 Tim Waugh 2009-05-05 14:10:28 EDT
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.

Comment 2 CW Lin 2009-05-05 19:44:42 EDT
Created attachment 342560 [details]
Error Log of CUPS
Comment 3 Tim Waugh 2009-05-06 06:42:59 EDT
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?
Comment 4 CW Lin 2009-05-06 07:35:28 EDT
The output of '/sbin/ifconfig' is as follows:

eth0      Link encap:Ethernet  HWaddr 00:24:1D:16:8E:8E  
          inet addr:  Bcast:  Mask:
          inet6 addr: fe80::224:1dff:fe16:8e8e/64 Scope:Link
          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:  Mask:
          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)
Comment 5 Tim Waugh 2009-05-06 07:55:13 EDT
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.
Comment 6 CW Lin 2009-05-06 10:42:25 EDT
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?
Comment 7 Tim Waugh 2009-05-06 11:26:33 EDT
You can use "ServerAlias *" to allow any hostname.  Then you can use the machine's externally-visible address.
Comment 8 CW Lin 2009-05-06 12:09:34 EDT
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 ( 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, to access the CUPS server.

I have just use "ServerAlias *" to see if it is ok for "".  But it didn't work.
Comment 9 Luis Garrido 2009-07-23 20:44:20 EDT
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, and I keep getting http 400 errors. I have ServerAlias * in my cupsd.conf.

Comment 10 CW Lin 2009-07-23 23:56:44 EDT
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...
Comment 11 dunse 2010-02-25 05:06:57 EST
I have partly resolved the problem.
In the guest, install putty and login to create a tunnel with the following data :
host :
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/...
Comment 12 Adrien Guichard 2014-03-23 04:28:27 EDT
I am forced to use 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 (, which map to 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
  - shows "Bad Request"
  - shows host cups instance.

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

Thanks for your support!

Note You need to log in before you can comment on or make changes to this bug.