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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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" <[EMAIL PROTECTED]> 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
_______________________________________________ --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
