Re: [Wireshark-dev] ATM over Ethernet
On 6 November 2012 20:26, Jakub Zawadzki darkjames...@darkjames.pl wrote: Hi, On Mon, Nov 05, 2012 at 12:14:31PM +, Alex Bennee wrote: We use a fairly simple ATM over Ethernet encapsulation for linking old ATM based circuits with modern Ethernet based hardware. Googling for 0x8884 I has found that it's already defined as ETH_P_ATMFATE (full name: Frame-based ATM Transport over Ethernet) Oh noes, ID clash ;-0 I'm not sure if the choice of ethertype was deliberate, it's lost in the mists of time for the atmoe driver I'm using. and there's some specification at http://www.broadband-forum.org/ftp/pub/approved-specs/af-fbatm-0139.001.pdf Is this the same protocol? It looks similar but in our case no. Although the packing is the same FATE adds some additional functionalities. If yes maybe dissector should be called FATE rather than ATMoE? I suspect a separate FATE dissector would look pretty similar except for the message handling. -- Alex, homepage: http://www.bennee.com/~alex/ http://www.half-llama.co.uk ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] ATM over Ethernet
On 6 November 2012 10:13, Alex Bennée kernel-hac...@bennee.com wrote: On 5 November 2012 18:53, Guy Harris g...@alum.mit.edu wrote: On Nov 5, 2012, at 4:14 AM, Alex Bennee kernel-hac...@bennee.com wrote: No, you need to implement a dissector for your ATM-over-Ethernet encapsulation that repeatedly calls the ATM dissector for each cell. Multiple cells encapsulated in an Ethernet packet is a characteristic of your encapsulation, not of ATM, so the code to handle that should be part of the dissector for your encapsulation, not the dissector for ATM. Ahh it makes more sense now. I've attached the re-worked patch which adds an explicit atmoe dissector which seems to work. Also how is the AAL encoding determined? Should I just register the handlers for the multiple AAL types and let the user decide? Yes. The AAL encoding is determined by whatever AAL information is in the capture file, and I suspect that is often put there by a user explicitly configuring the capturing machine. It looks like I'll have to set a preference for that then as it's only really specified by the application specific VC. I guess the real question is do I add options to the ATM decoder to select AAL based on VPI/VCI? -- Alex, homepage: http://www.bennee.com/~alex/ http://www.half-llama.co.uk 0001-Add-new-dissector-ATMoE.patch Description: Binary data ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] ATM over Ethernet
On Nov 6, 2012, at 9:47 AM, Alex Bennée kernel-hac...@bennee.com wrote: Ahh it makes more sense now. I've attached the re-worked patch which adds an explicit atmoe dissector which seems to work. Looks good. I'd use tvb_reported_length() rather than tvb_length() when calculating the number of cells. (I'd also suggest using another mechanism for providing the this is an ATM cell information, as there's also a pseudo-header for Ethernet, but, unfortunately, there *isn't* another mechanism to do that. The fact that there isn't another mechanism is, if not a bug, a serious deficiency; I'll look at fixing that, but, for now, we might as well go with the way you're doing it; if we add a new mechanism, we can revise your dissector to use it.) I guess the real question is do I add options to the ATM decoder to select AAL based on VPI/VCI? That sounds like a good idea. (At some point we might want to generalize the current notion of conversations to abstract away its orientation towards address-and-port-number endpoints, so that address-and-port-number transport-layer conversations are just one subtype, have it subsume the notion of circuits, and use them in a number of places, including ATM virtual circuits, and add support for dissectors adding arbitrary properties to conversations; that could be used to assign not only AAL types to ATM virtual circuits, but to assign higher-level encapsulation/protocol values, complete with a UI to let the user specify them.) ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] ATM over Ethernet
On Tue, Nov 6, 2012 at 12:47 PM, Alex Bennée kernel-hac...@bennee.comwrote: On 6 November 2012 10:13, Alex Bennée kernel-hac...@bennee.com wrote: On 5 November 2012 18:53, Guy Harris g...@alum.mit.edu wrote: On Nov 5, 2012, at 4:14 AM, Alex Bennee kernel-hac...@bennee.com wrote: No, you need to implement a dissector for your ATM-over-Ethernet encapsulation that repeatedly calls the ATM dissector for each cell. Multiple cells encapsulated in an Ethernet packet is a characteristic of your encapsulation, not of ATM, so the code to handle that should be part of the dissector for your encapsulation, not the dissector for ATM. Ahh it makes more sense now. I've attached the re-worked patch which adds an explicit atmoe dissector which seems to work. Just something to note - you shouldn't be calling other dissectors inside an if (tree) block. All dissectors down the stack need to be run even if tree is NULL so that conversations, expert info and other non-tree data still gets populated. The various proto_* functions all handle NULL trees and behave correctly, so the easiest way to fix this would be to simply remove the if (tree) check and leave everything else the way it is. Also, (since I'm feeling super picky today) you don't need to #include epan/prefs.h :) Cheers, Evan ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] ATM over Ethernet
Evan Huus skrev 2012-11-06 19:48: On Tue, Nov 6, 2012 at 12:47 PM, Alex Bennée kernel-hac...@bennee.com mailto:kernel-hac...@bennee.com wrote: On 6 November 2012 10:13, Alex Bennée kernel-hac...@bennee.com mailto:kernel-hac...@bennee.com wrote: On 5 November 2012 18:53, Guy Harris g...@alum.mit.edu mailto:g...@alum.mit.edu wrote: On Nov 5, 2012, at 4:14 AM, Alex Bennee kernel-hac...@bennee.com mailto:kernel-hac...@bennee.com wrote: No, you need to implement a dissector for your ATM-over-Ethernet encapsulation that repeatedly calls the ATM dissector for each cell. Multiple cells encapsulated in an Ethernet packet is a characteristic of your encapsulation, not of ATM, so the code to handle that should be part of the dissector for your encapsulation, not the dissector for ATM. Ahh it makes more sense now. I've attached the re-worked patch which adds an explicit atmoe dissector which seems to work. Just something to note - you shouldn't be calling other dissectors inside an if (tree) block. All dissectors down the stack need to be run even if tree is NULL so that conversations, expert info and other non-tree data still gets populated. The various proto_* functions all handle NULL trees and behave correctly, so the easiest way to fix this would be to simply remove the if (tree) check and leave everything else the way it is. Also, (since I'm feeling super picky today) you don't need to #include epan/prefs.h :) Cheers, Evan I've committed the ETHERTYPE_ATMOE change. Anders ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] ATM over Ethernet
Hi, On Mon, Nov 05, 2012 at 12:14:31PM +, Alex Bennee wrote: We use a fairly simple ATM over Ethernet encapsulation for linking old ATM based circuits with modern Ethernet based hardware. Googling for 0x8884 I has found that it's already defined as ETH_P_ATMFATE (full name: Frame-based ATM Transport over Ethernet) and there's some specification at http://www.broadband-forum.org/ftp/pub/approved-specs/af-fbatm-0139.001.pdf Is this the same protocol? If yes maybe dissector should be called FATE rather than ATMoE? ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] ATM over Ethernet
Hi, We use a fairly simple ATM over Ethernet encapsulation for linking old ATM based circuits with modern Ethernet based hardware. I was able to enable the packet-atm.c to decde these frames very easily (see attached) but I was looking for pointers for the next bit. Currently I can't see a way to specify treating the rest of the frame as multiple frames. Do I need to extend the ATM dissector to call itself if the remaining frame is larger than 53 bytes? Also how is the AAL encoding determined? Should I just register the handlers for the multiple AAL types and let the user decide? -- Alex, homepage: http://www.bennee.com/~alex/ http://www.half-llama.co.uk 0001-Allow-ATMoE-encapsulated-ATM-to-be-decoded-by-ATM-di.patch Description: Binary data ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
