[tcpdump-workers] C-Bus encapsulation type
Hi, I work for Clipsal (part of Schneider Electric) and have been developing a capture program and dissector for the C-Bus protocol - https://en.wikipedia.org/wiki/C-Bus_(protocol) Can we get a link layer header type assigned for this? Thanks :) -- Daniel O'Connor Senior Firmware Developer Smart Devices Asia PacificM 0403070726 Building & IT BusinessE Daniel.O'con...@schneider-electric.com 33-37 Port Wakefield Road Gepps Cross, SA, Australia ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] C-Bus encapsulation type
> On 7 Jun 2017, at 17:32, Guy Harris wrote: > > On Jun 6, 2017, at 8:51 PM, Daniel O'Connor > wrote: >> I work for Clipsal (part of Schneider Electric) and have been developing a >> capture program and dissector for the C-Bus protocol - >> https://en.wikipedia.org/wiki/C-Bus_(protocol) >> >> Can we get a link layer header type assigned for this? > > Yes, if we can get a specification for what the packets look like. :-) There's the rub the format is internal :( > Where is the format of the packets that would appear with this link-layer > header type documented? It is mostly documented at http://training.clipsal.com/downloads/OpenCBus/Serial%20Interface%20User%20Guide.pdf Although the format is slightly different (hence the internal stuff). If that's not acceptable then I can keep using user DLTs easily enough - I wasn't sure what the rules were. -- Daniel O'Connor Senior Firmware Developer Smart Devices Asia PacificM 0403070726 Building & IT BusinessE Daniel.O'con...@schneider-electric.com 33-37 Port Wakefield Road Gepps Cross, SA, Australia ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] C-Bus encapsulation type
> On 30 Jun 2017, at 03:21, Guy Harris wrote: >> Although the format is slightly different (hence the internal stuff). > > If the capture program and dissector are solely for the use of Schneider and, > possibly, its customers, and the dissector won't be open-source (which means > "not a Wireshark dissector", given that Wireshark plugins have to be GPLed, > unless the dissector is solely for use within Schneider), then a > LINKTYPE_n/DLT_USERn value would be best. I don't want to assign > LINKTYPE_/DLT_ values to formats for which there isn't sufficient > documentation for somebody to write code to parse the format (neither a > tcpdump nor a Wireshark dissector counts as "documentation"). > > If the dissector will be open-source, then there's no reason not to have a > publicly-available specification for the message format. OK fair enough. I am hoping to be able to make it more open but other people seem unreasonably paranoid about it so I'm not holding my breath :-/ -- Daniel O'Connor Senior Firmware Developer Smart Devices Asia PacificM 0403070726 Building & IT BusinessE Daniel.O'con...@schneider-electric.com 33-37 Port Wakefield Road Gepps Cross, SA, Australia ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers