IPP on ports other than 631 not recognized

This issue was migrated from bug 5677 in our old bug tracker.

Original bug information:

Reporter: Troels Liebe Bentsen
Status: RESOLVED FIXED
Product: Wireshark
Component: GTK+ UI
OS: All
Platform: All
Version: Git

Attachments:

test.pcap: IPP post from CUPS client to MS IPP server on port 80

💬 Troels Liebe Bentsen said:

Build Information: wireshark 1.5.1 (SVN Rev 35907 from /trunk)

Copyright 1998-2011 Gerald Combs <gerald@‍wireshark.org> and contributors. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (64-bit) with GTK+ 2.22.0, with GLib 2.26.0, with libpcap 1.1.1, with libz 1.2.3.4, with POSIX capabilities (Linux), without libpcre, with SMI 0.4.8, with c-ares 1.7.3, with Lua 5.1, without Python, with GnuTLS 2.8.6, with Gcrypt 1.4.5, with MIT Kerberos, with GeoIP, with PortAudio V19-devel (built Aug 3 2010 06:06:51), without AirPcap.

Running on Linux 2.6.35-25-generic, with libpcap version 1.1.1, with libz 1.2.3.4, GnuTLS 2.8.6, Gcrypt 1.4.5.

Built using gcc 4.4.5.

Hey I'm trying to decode a IPP(Internet Printing Protocol) stream on port 80, but I'm not able to select the protocol in in the Decode As option.

I have attached the trace of a CUPS client doing a POST to a MS IPP server running on port 80.

Regards Troels

added uigtk versiondev labels

💬 Troels Liebe Bentsen said:

Created attachment 5931 IPP post from CUPS client to MS IPP server on port 80

💬 Guy Harris said:

"Decode As" currently only works at the TCP layer, and IPP doesn't run over TCP, it runs over HTTP.

This would require either

    1) extension of "Decode As" to other protocol layers

or

    2) using the Content-Type field to choose IPP (at the time we did the IPP dissector, we didn't support subdissectors of HTTP content being selected by Content-Type) - look for "application/ipp".

2) is probably the best answer here, as it'd make the right thing happen automatically.

Title changed to reflect the underlying problem.

💬 Jaap Keuter said:

Fixed in revision 35914.

💬 Guy Harris said:

Not really. It still assumes packets to port 631 are requests and other packets are responses; the HTTP dissector needs to pass more information on to subdissectors for that to work.

💬 Guy Harris said:

...or the IPP dissector needs to check the destination port against the port that matched for HTTP.

Fixed in revision 35916.

closed

mentioned in issue #18825 (closed)