To access IPP-over-USB printer: Emulate remote machine in the network

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

To access IPP-over-USB printer: Emulate remote machine in the network

Till Kamppeter-3
tl;dr: Creating an emulated remote machine representing a USB printer as
it was a network printer, without VM with it's own kernel

Hi,

I am developing the ippusbxd daemon to support IPP-over-USB printers:

https://github.com/tillkamppeter/ippusbxd/

Modern network printers use IPP (Internet Printing Protocol) for clients
communicating with them. Also CUPS uses this protocol. In contrary
toolder, simpler protocols one cannot only simply send jobs (and pray)
but also request status info and, very important for driverless
printing, request information about the printer's capabilities.

To make all this possible on a USB printer (and even accessing the
printer's web admin interface) IPP-over-USB was introduced:

ftp://ftp.pwg.org//pub/pwg/ipp/whitepaper/draft-ippusbspecification-20110510.pdf

ippusbxd mirrors the IPP printer into the network, so that it can be
handled like a network printer, espocially to access the web interface
with a browser and to make CUPS and cups-browsed handle the printer like
a network printer.

In the beginning I used localhost:60000 which makes polling capabilities
and status, printing, and web interface work, but the printer could not
be Avahi-broadcasted and so CUPS and cups-browsed could not discover it.

Then I tried the "dummy" network device with an IPv6 ULA IP address.
This I could broadcast with Avahi and the broadcasts only appeared on
the local machine, as I wanted to have it, but I could only work with th
(awkward) IP address and not with host names, as Avahi broadcasts only
the one host name of the system and this hostname resolves only into the
system's network IP, not the IP of the dummy interface. Printing and
capability/status polling works IP-based, but not the web admin
interface of the printer.

See also my earlier discussion about this here on the list in the "Using
the dummy0 interface for a local-only service to be broadcasted by
Avahi" thread.

Now my new idea would be the following:

Is it possible to emulate a remote machine in the network, without
creating a virtual machine (with its own Linux kernel)?

The emulated remote machine should have its own IP (can be IPv6) and
host name (and ideally its own ports) and it should be on an interface
which supports multicast (like dummy, so that one can Avahi-broadcast
the emulated machine to the local machine). The emulation should by
fired up by ippusbxd and the printer be cuoled to that machine, so that
one can access the IPP-over-USB printer like a remote network printer,
ideally via hostname:631 for printing and hostname:80 for the web interface.

Is this possible?

    Till



--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
TJ
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: To access IPP-over-USB printer: Emulate remote machine in the network

TJ
On 16/01/17 18:05, Till Kamppeter wrote:
> In the beginning I used localhost:60000 which makes polling capabilities
> and status, printing, and web interface work, but the printer could not
> be Avahi-broadcasted and so CUPS and cups-browsed could not discover it.
>
Possibly not the ideal solution but did you test whether using
avahi-daemon.conf's "deny-interfaces=" with a single interface name that
it is safe to ignore (a throw-away dummy interface) would work?

I ask because the man-page for avahi-daemon.conf seems to imply that the
interface default action is to ignore 'lo' and any point-to-point
interfaces, but if using "deny-interfaces=" without any
"allow-interfaces=" it will use all interfaces not specified - which
implies that it would then use 'lo'. E.g:

# allow-interfaces=
deny-interfaces=dummy0
# implication is that 'lo' will be used

If the functionality is only required for the localhost's CUPS service
this might be sufficient.



--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: To access IPP-over-USB printer: Emulate remote machine in the network

Till Kamppeter-3
On 01/21/2017 09:56 AM, TJ wrote:

> On 16/01/17 18:05, Till Kamppeter wrote:
>> In the beginning I used localhost:60000 which makes polling capabilities
>> and status, printing, and web interface work, but the printer could not
>> be Avahi-broadcasted and so CUPS and cups-browsed could not discover it.
>>
> Possibly not the ideal solution but did you test whether using
> avahi-daemon.conf's "deny-interfaces=" with a single interface name that
> it is safe to ignore (a throw-away dummy interface) would work?
>
> I ask because the man-page for avahi-daemon.conf seems to imply that the
> interface default action is to ignore 'lo' and any point-to-point
> interfaces, but if using "deny-interfaces=" without any
> "allow-interfaces=" it will use all interfaces not specified - which
> implies that it would then use 'lo'. E.g:
>
> # allow-interfaces=
> deny-interfaces=dummy0
> # implication is that 'lo' will be used
>
> If the functionality is only required for the localhost's CUPS service
> this might be sufficient.
>
>
>

I doubt that this will actually work. The loopback interface "lo" is not
multicast-capable whereas the Avahi/DNS-SD broadcasting works only with
multicast interfaces.

Did you already try something like that? Were you actually able to do
DNS-SD broadcasts on "lo"?

    Till


--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: To access IPP-over-USB printer: Emulate remote machine in the network

Till Kamppeter-3
In reply to this post by TJ
On 01/21/2017 09:56 AM, TJ wrote:

> On 16/01/17 18:05, Till Kamppeter wrote:
>> In the beginning I used localhost:60000 which makes polling capabilities
>> and status, printing, and web interface work, but the printer could not
>> be Avahi-broadcasted and so CUPS and cups-browsed could not discover it.
>>
> Possibly not the ideal solution but did you test whether using
> avahi-daemon.conf's "deny-interfaces=" with a single interface name that
> it is safe to ignore (a throw-away dummy interface) would work?
>
> I ask because the man-page for avahi-daemon.conf seems to imply that the
> interface default action is to ignore 'lo' and any point-to-point
> interfaces, but if using "deny-interfaces=" without any
> "allow-interfaces=" it will use all interfaces not specified - which
> implies that it would then use 'lo'. E.g:
>
> # allow-interfaces=
> deny-interfaces=dummy0
> # implication is that 'lo' will be used
>
> If the functionality is only required for the localhost's CUPS service
> this might be sufficient.
>
>
>

I have done some testing, modifying the avahi-daemon.conf as described,
restarting avahi-daemon, and running avahi-discover to see which
services get broadcasted on which interfaces. The "lo" interface did not
appear, also not after running

sudo ip link set lo multicast on

This should activate multicast support on lo if this is possible (at
least "ifconfig" shows the activated multicast flag).

It seems that lo does definitively not have broadcasting support, as

sudo ip link set lo broadcast 127.255.255.255

errors with "Invalid argument".

See also

http://serverfault.com/questions/554503/how-do-i-add-a-broadcast-ip-to-the-loopback-interface-under-os-x-using-ifconfig

http://serverfault.com/questions/421389/how-to-add-a-broadcast-address-to-loopback-with-ifconfig-on-a-os-x

So it looks like that we need to work with an extra interface (dummy0
with IPv6) and find a way to let Avahi broadcast the interface's own
host name or the interface's IP address instead of the system's host
name or we need a way to make ippusbxd emulate a remote host with its
own host name and IP address but not creating a virtual machine, if this
would be possible.

    Till


--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: To access IPP-over-USB printer: Emulate remote machine in the network

Seth Arnold
On Wed, Feb 22, 2017 at 04:42:46PM -0300, Till Kamppeter wrote:
> So it looks like that we need to work with an extra interface (dummy0 with
> IPv6) and find a way to let Avahi broadcast the interface's own host name or

Would you mind changing the name to something that would more clearly
reflect the reason why this dummy interface exists?

e.g., cups0 or cupsbrowser or cupslocal.

Ideally it'd be unique enough that searching the web for the name would
return our documentation about it and nothing else. 'dummy0' would easily
fail that test.

Thanks

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: To access IPP-over-USB printer: Emulate remote machine in the network

Till Kamppeter-3
On 02/23/2017 12:47 AM, Seth Arnold wrote:

> On Wed, Feb 22, 2017 at 04:42:46PM -0300, Till Kamppeter wrote:
>> So it looks like that we need to work with an extra interface (dummy0 with
>> IPv6) and find a way to let Avahi broadcast the interface's own host name or
>
> Would you mind changing the name to something that would more clearly
> reflect the reason why this dummy interface exists?
>
> e.g., cups0 or cupsbrowser or cupslocal.
>
> Ideally it'd be unique enough that searching the web for the name would
> return our documentation about it and nothing else. 'dummy0' would easily
> fail that test.

I also came already to this idea and in my most recent tests I called
the interface "ippusbxd". I set up the interface for testing with the
following commands:

sudo ip link add ippusbxd type dummy
sudo ip link set ippusbxd up
sudo ip link set ippusbxd multicast on
sudo ip -6 addr add 'fd00:1:1::1/64' dev ippusbxd

Note that for the testing I use a fixed IP address. For production a
random one should be chosen.

    Till






--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Loading...