[asterisk-dev] Skinny protocol messages with recent Cisco phones-

[Dan Austin]

I don't have wireshark, so I am open to suggestions.
My sniffer is reporting it as 'extra bytes'.  At least
one of structures in the current code is using :

uint32_t space;

To generate 4 bytes of padding, so I extended the concept.
I have a patch that I am cleaning up right now, and I
can/will open a bug with it attached.

My 7940 is still functional after these changes, so the
older phones do not care if the packet is padded, but the
new ones choke if it is not.  Based on that observation, I
would tend to think that this approach is valid not only
for trunk, but also branches/1.4 since the code tries to
support the new devices.

An alternate approach is to duplicate all of the structures
and have versions for old and new phones and make the general
code aware of the difference so we send old style packets
to legacy models and the new style for the current models (yuck).

Dan

-----Original Message-----
From: asterisk-dev-bounces at lists.digium.com [mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Jason Parker
Sent: Tuesday, June 05, 2007 11:51 AM
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] Skinny protocol messages with recent Cisco phones-


----- "Dan Austin" <Dan_Austin at Phoenix.com> wrote:
> I wrote:
> > Traces of the following message types with 79X1 phones
> > would be handy:
> 
> > 82		start tone
> > 83		Stop tone
> > 85		Set ringer message
> > 9A		Clear display message
> > 106		Close receive channel
> > 111		Call state message
> 
> > I am also looking into:
> > RECEIVED UNKNOWN MESSAGE TYPE:  c
> > RECEIVED UNKNOWN MESSAGE TYPE:  9 (I think this is a line request)
> 
> OK, I managed to get a proper protocol decoder added to my
> closed-source sniffer.  It looks like the new phones are
> much pickier about the response packets.
> 
> 1st up, the line_stat_res_message structure:
> Current:
>         uint32_t lineNumber;
>         char lineDirNumber[24];
>         char lineDisplayName[42];
>         uint32_t space;
> 
> Problem:
> 	Packet captures against CCM show that lineDisplayName
> should be [24], and that 60 bytes of packet padding is 
> needed/used.
> 
> Working:
>         uint32_t lineNumber;
>         char lineDirNumber[24];
>         char lineDisplayName[24];
>         uint32_t space[15];
> 
> So now the device registers and collects all of the 
> proper settings.  The phone still does not work, throwing
> errors for each of the response messages listed above.
> I suspect that the same root cause applies, so I'll study
> the CCM captures.
> 
> These changes DO NOT appear to break the older phones.
> 
> Dan
> 

Looks about right, but it would probably be more like 3x char[4] (or a char[8] and a char[4]..) and a uint32_t

What does wireshark say it should be?

-- 
Jason Parker
Digium

_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev