[cups.general] ipp/port#, how does one determine # without actually printing?

[wtautz]

Kurt Pfeifle wrote:
> wtautz <wtautz at cs.uwaterloo.ca> wrote (Friday 28 July 2006 17:07):
>
>   
>>> However, that one HP 4000 I found nearby did not support IPP at
>>> all:
>>>
>>>    ./ipptest -v ipp://10.162.4.65:631/ipp get-printer-attributes.test
>>>    Unable to connect to 10.162.4.65 on port 631 - Connection refused
>>>
>>>   
>>>       
>> Perhaps it has to be turned on.
>>     
>
> I know. But that's a different issue.  :-)
>
> The point I was trying to make was that "ipptest" can be used to 
> query IPP printers about their supported attributes & get a fairly 
> reliable feedback about their supported device URIs. And if they 
> refuse connection, their IPP support is disabled or non-existent
> altogether  :-)
>   
Yes, I understood :-) Nice tool. Perhaps it could be included
in the public cups binary distributions.

>
>   
>> Nmap helps.  
>>     
>
> No. If you mean to test if port 631 is open... it won't be open if
> the printer has its IPP support disbled by the admin.
>   
Yes, I meant for testing to see if the printer had it enabled. If
not I would check to see if it could be turned on. Btw,
filtered ports isn't a good thing...

> You could use nmap to poke a printer and probe ports like 515, 631
> and 9100 (and even some more -- some vendors put their AppSocket
> support behind other ports than 9100) to see if they are open; but
> it will only be a first indication. 
>
> If port 631 is open, suggesting IPP is supported, you still do not
> know the "printer-uri-supported" attribute.
>
>
>   
>> Of course one can connect via web 
>> browser.
>> Perhaps the tests you mention are independent of it being enabled.
>>     
>
>   
I should have made clear that this is one way to enable it.
Thanks again for the extensive discussion. Extremely
enlightening not just for me but others I'm sure!

walter