Opened 5 years ago

Closed 5 years ago

Last modified 5 weeks ago

#605 closed request (pending)

Printing from iPhone

Reported by: Stuart Cheshire Owned by: cdoyle@…
Priority: minor Milestone: ietf-086
Component: printers Keywords:
Cc: My Current Location:
My MAC Address: My OS:

Description

A question, when you have time. Someone asked me how "term-printer" appears on iPhone. I thought I knew, but I tried this query, and got no results:

% dig +short _ipp._tcp.meeting.ietf.org. ptr

So, now I'm confused. Can you tell me how you are making "term-printer" appear on iPhone? Thanks.

Stuart Cheshire

Change history (12)

comment:1 Changed 5 years ago by llynch@…

Component: incomingprinters
Owner: changed from llynch@… to ralfvin@…
Status: newassigned

comment:2 Changed 5 years ago by ralfvin@…

Owner: changed from ralfvin@… to cdoyle@…

comment:3 Changed 5 years ago by cdoyle@…

Priority: tbdminor

The terminal room printer is available at the following FQDN

term-printer.meeting.ietf.org

This name resolves to the IP 130.129.48.18 IPv4 address. The printer is IPv6 capable, but this functionality is not in use at this time.

The print server that services this printer runs on the printer itself, so if you were trying to dig for the Internet Printing Protocol on the meeting.ietf.org domain, you weren't going to find it.

iPhone and iPad printing is supported for this device via AirPrint?, and we have just tested this to make sure it works.

Please let me know if this answers your question.

Colin

comment:4 Changed 5 years ago by bzeeb+ietf@…

And to add to this, there are

_pdl-datastream._tcp
_universal._sub._ipp._tcp

PTR records pointing to the appropriate term-printer records.

comment:5 Changed 5 years ago by Stuart Cheshire

On 13 Mar 2013, at 15:31, IETF Meeting/NOC wrote:

> #605: Printing from iPhone
> -----------------------------+--------------------------------
>      Reporter:  cheshire@…  |                Owner:  cdoyle@…
>          Type:  request     |               Status:  assigned
>      Priority:  minor       |            Milestone:  ietf-86
>     Component:  printers    |           Resolution:
>      Keywords:              |  My Current Location:
> My MAC  Address:             |                My OS:
> -----------------------------+--------------------------------
> 
> Comment (by bzeeb+ietf@…):
> 
> And to add to this, there are
> 
> _pdl-datastream._tcp
> _universal._sub._ipp._tcp
> 
> PTR records pointing to the appropriate term-printer records.

Ah! Thanks so much for your help. I get it now.

What confused me is that there's no "_ipp._tcp" entry, only the subtype "_universal". Interestingly it still works fine with the iPhone. Was the "_ipp._tcp" entry just missed out by mistake, or was there some reason you deliberately did that?

The intention is that if this returns a result:

> % dig +short _universal._sub._ipp._tcp.meeting.ietf.org. ptr
> term-printer._ipp._tcp.meeting.ietf.org.

... then this should too:

> % dig +short _ipp._tcp.meeting.ietf.org. ptr

If having that record was creating problems, then please let me know because I'd like to understand why.

Stuart Cheshire

comment:6 Changed 5 years ago by cdoyle@…

Thanks, BZ. Looks like I need to do a bit of reading on Bonjour!

C
On 3/13/13 6:41 PM, Stuart Cheshire wrote:
> On 13 Mar 2013, at 15:31, IETF Meeting/NOC wrote:
>
>> #605: Printing from iPhone
>> -----------------------------+--------------------------------
>>       Reporter:  cheshire@…  |                Owner:  cdoyle@…
>>           Type:  request     |               Status:  assigned
>>       Priority:  minor       |            Milestone:  ietf-86
>>      Component:  printers    |           Resolution:
>>       Keywords:              |  My Current Location:
>> My MAC  Address:             |                My OS:
>> -----------------------------+--------------------------------
>>
>> Comment (by bzeeb+ietf@…):
>>
>> And to add to this, there are
>>
>> _pdl-datastream._tcp
>> _universal._sub._ipp._tcp
>>
>> PTR records pointing to the appropriate term-printer records.
> Ah! Thanks so much for your help. I get it now.
>
> What confused me is that there's no "_ipp._tcp" entry, only the subtype "_universal". Interestingly it still works fine with the iPhone. Was the "_ipp._tcp" entry just missed out by mistake, or was there some reason you deliberately did that?
>
> The intention is that if this returns a result:
>
>> % dig +short _universal._sub._ipp._tcp.meeting.ietf.org. ptr
>> term-printer._ipp._tcp.meeting.ietf.org.
> ... then this should too:
>
>> % dig +short _ipp._tcp.meeting.ietf.org. ptr
> If having that record was creating problems, then please let me know because I'd like to understand why.
>
> Stuart Cheshire
>

-- 



Colin Doyle
Senior Network Engineer
CCNA, F5 ASP/ATSP, Juniper JES

Verilan Event Services, Inc.
7327 SW Barnes Rd. #215
Portland, OR 97225


Cell: 503 810-2129
cdoyle@verilan.com
www.verilan.com


This e-mail contains proprietary information and may be confidential. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this message is strictly prohibited. If you received this message in error, please delete it immediately.

comment:7 Changed 5 years ago by cdoyle@…

Thanks. Did a bit of reading on RFC6763 and this makes a whole lot more 
sense now.

Sorry for the confusion on my part, Stuart!

Colin
On 3/13/13 6:41 PM, Stuart Cheshire wrote:
> On 13 Mar 2013, at 15:31, IETF Meeting/NOC wrote:
>
>> #605: Printing from iPhone
>> -----------------------------+--------------------------------
>>       Reporter:  cheshire@…  |                Owner:  cdoyle@…
>>           Type:  request     |               Status:  assigned
>>       Priority:  minor       |            Milestone:  ietf-86
>>      Component:  printers    |           Resolution:
>>       Keywords:              |  My Current Location:
>> My MAC  Address:             |                My OS:
>> -----------------------------+--------------------------------
>>
>> Comment (by bzeeb+ietf@…):
>>
>> And to add to this, there are
>>
>> _pdl-datastream._tcp
>> _universal._sub._ipp._tcp
>>
>> PTR records pointing to the appropriate term-printer records.
> Ah! Thanks so much for your help. I get it now.
>
> What confused me is that there's no "_ipp._tcp" entry, only the subtype "_universal". Interestingly it still works fine with the iPhone. Was the "_ipp._tcp" entry just missed out by mistake, or was there some reason you deliberately did that?
>
> The intention is that if this returns a result:
>
>> % dig +short _universal._sub._ipp._tcp.meeting.ietf.org. ptr
>> term-printer._ipp._tcp.meeting.ietf.org.
> ... then this should too:
>
>> % dig +short _ipp._tcp.meeting.ietf.org. ptr
> If having that record was creating problems, then please let me know because I'd like to understand why.
>
> Stuart Cheshire
>

-- 



Colin Doyle
Senior Network Engineer
CCNA, F5 ASP/ATSP, Juniper JES

Verilan Event Services, Inc.
7327 SW Barnes Rd. #215
Portland, OR 97225


Cell: 503 810-2129
cdoyle@verilan.com
www.verilan.com


This e-mail contains proprietary information and may be confidential. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this message is strictly prohibited. If you received this message in error, please delete it immediately.

comment:8 Changed 5 years ago by Stuart Cheshire

On 13 Mar 2013, at 16:55, Colin Doyle wrote:

> Thanks. Did a bit of reading on RFC6763 and this makes a whole lot more sense now.
> 
> Sorry for the confusion on my part, Stuart!

No need to apologize. Thanks for taking the time to help with something that wasn't really a trouble ticket.

In case you’re interested, attached below is the email I was writing.

Stuart Cheshire

--

Here’s a detailed step-by-step walkthrough of how we find the IETF Terminal Room printer, starting with DHCP, and ending with a TCP connection sending the data to the printer. When you print from your Mac or iPhone, and give no second thought to how it magically knew about the IETF Terminal Room printer, this is what it's doing under the covers.

First, let’s see what my Mac learned from the local DHCP server:

> % scutil
> > list
>   ...
>   subKey [74] = State:/Network/Service/21B5304C-C227-4932-BFCF-54B28F4CA1D2/DHCP
>   ...
> 
> > show State:/Network/Service/21B5304C-C227-4932-BFCF-54B28F4CA1D2/DHCP
> <dictionary> {
>   Option_15 : <data> 0x6d656574696e672e696574662e6f7267
>   ...
> }

Option_15 is Domain Name. What domain name?

> % echo 6d656574696e672e696574662e6f7267 0A | xxd -r -p
> meeting.ietf.org

Great. Does meeting.ietf.org recommend we look in any Wide Area Service Discovery domains?

> % dig lb._dns-sd._udp.meeting.ietf.org. ptr
> 
> ; <<>> DiG 9.6-ESV-R4-P3 <<>> lb._dns-sd._udp.meeting.ietf.org. ptr
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35624
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 4
> 
> ;; QUESTION SECTION:
> ;lb._dns-sd._udp.meeting.ietf.org. IN	PTR
> 
> ;; ANSWER SECTION:
> lb._dns-sd._udp.meeting.ietf.org. 3600 IN PTR	meeting.ietf.org.
> 
> ...
> 
> ;; Query time: 8 msec
> ;; SERVER: 130.129.5.6#53(130.129.5.6)
> ;; WHEN: Wed Mar 13 10:16:40 2013
> ;; MSG SIZE  rcvd: 188

Note, I can ask *any* DNS server this question and I get the same answer. Let’s ask Google DNS:

> % dig @8.8.8.8 lb._dns-sd._udp.meeting.ietf.org. ptr
> 
> ; <<>> DiG 9.6-ESV-R4-P3 <<>> @8.8.8.8 lb._dns-sd._udp.meeting.ietf.org. ptr
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24571
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;lb._dns-sd._udp.meeting.ietf.org. IN	PTR
> 
> ;; ANSWER SECTION:
> lb._dns-sd._udp.meeting.ietf.org. 1532 IN PTR	meeting.ietf.org.
> 
> ;; Query time: 21 msec
> ;; SERVER: 8.8.8.8#53(8.8.8.8)
> ;; WHEN: Wed Mar 13 10:18:27 2013
> ;; MSG SIZE  rcvd: 64

The DNS server I ask doesn’t have to be “on” my “local” network (whatever that means). I’m in Florida. Google DNS is I-don’t-know-where, 13 hops away, but it still gives the right answer.

> % traceroute -q 1 8.8.8.8
> traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets
>  1  rtra (130.129.80.2)  1.369 ms
>  2  75-112-170-148.net.bhntampa.com (75.112.170.148)  14.494 ms
>  3  bun2.tamp20-car1.bhn.net (71.44.3.73)  19.558 ms
>  4  hun0-0-0-0-tamp20-cbr1.bhn.net (72.31.117.156)  20.730 ms
>  5  xe-8-2-0.bar1.tampa1.level3.net (4.53.172.9)  13.052 ms
>  6  ae-5-5.ebr1.miami1.level3.net (4.69.148.213)  27.413 ms
>  7  ae-1-51.edge1.miami2.level3.net (4.69.138.75)  15.552 ms
>  8  google-inc.edge1.miami2.level3.net (4.59.240.26)  48.852 ms
>  9  209.85.253.118 (209.85.253.118)  21.118 ms
> 10  216.239.48.192 (216.239.48.192)  21.890 ms
> 11  216.239.48.192 (216.239.48.192)  23.221 ms
> 12  *
> 13  google-public-dns-a.google.com (8.8.8.8)  32.961 ms

In this case the PTR is self-referential — meeting.ietf.org is advising us to look in meeting.ietf.org, but it could easily be set up to direct us elsewhere.

But in this case it’s suggesting we look for services in meeting.ietf.org, so let’s do that:

A Mac with appropriate printer drivers installed will look for this service:

> % dig +short @8.8.8.8 _pdl-datastream._tcp.meeting.ietf.org. ptr
> term-printer._pdl-datastream._tcp.meeting.ietf.org.

There’s one printing service available here, called “term-printer”. That’s what you see when you press the “+” button in the Print & Fax Preference Pane on Mac OS X.

To actually use it, the client uses this:

> % dig +short @8.8.8.8 term-printer._pdl-datastream._tcp.meeting.ietf.org. srv
> 0 0 9100 term-printer.meeting.ietf.org.
> 
> % dig +short @8.8.8.8 term-printer.meeting.ietf.org. AAAA
> 2001:df8::48:200:74ff:fee0:6cf8

So, to use this printer, the Mac connects to [2001:df8::48:200:74ff:fee0:6cf8]:9100, and uses the installed printer driver, which speaks the appropriate vendor-specific printing protocol.

If you’re using an iPhone then you don’t have vendor-specific printer drivers; instead it uses this generic IPP-based printing service:

> % dig +short @8.8.8.8 _universal._sub._ipp._tcp.meeting.ietf.org. ptr
> term-printer._ipp._tcp.meeting.ietf.org.

There’s one IPP-based printing service available here, called “term-printer”. Same name as the pdl-datastream printing service, and same physical hardware, but different printing protocol.

To actually use it, the client uses this:

> % dig +short @8.8.8.8 term-printer._ipp._tcp.meeting.ietf.org. srv
> 0 0 631 term-printer.meeting.ietf.org.
> 
> % dig +short @8.8.8.8 term-printer.meeting.ietf.org. aaaa
> 2001:df8::48:200:74ff:fee0:6cf8

Note: Same address as before, but different port number.

To use this printer, the iPhone connects to [2001:df8::48:200:74ff:fee0:6cf8]:631, and uses IPP to print.

And that, ladies and gentlemen, is how automatic Wide Area DNS-Based Service Discovery works.

Stuart Cheshire

comment:9 Changed 5 years ago by bzeeb+ietf@…

Resolution: pending
Status: assignedclosed

I'll close this now. I have put a note into DNS to see for next meeting if we would need the _ipp._tcp record as well in addition to the ones we already have.

comment:10 Changed 5 years ago by Stuart Cheshire

Resolution: pending
Status: closedreopened
On 15 Mar 2013, at 7:14, IETF Meeting/NOC wrote:

> #605: Printing from iPhone
> -----------------------------+--------------------------------
>      Reporter:  cheshire@…  |                Owner:  cdoyle@…
>          Type:  request     |               Status:  closed
>      Priority:  minor       |            Milestone:  ietf-86
>     Component:  printers    |           Resolution:  pending
>      Keywords:              |  My Current Location:
> My MAC  Address:             |                My OS:
> -----------------------------+--------------------------------
> Changes (by bzeeb+ietf@…):
> 
> * status:  assigned => closed
> * resolution:   => pending
> 
> 
> Comment:
> 
> I'll close this now.  I have put a note into DNS to see for next meeting
> if we would need the _ipp._tcp record as well in addition to the ones we
> already have.

Thanks.

Stuart Cheshire

comment:11 Changed 5 years ago by bzeeb+ietf@…

Resolution: pending
Status: reopenedclosed

comment:12 Changed 5 weeks ago by Rick Alfvin

Milestone: ietf-86ietf-086

Milestone renamed

Note: See TracTickets for help on using tickets.