Re: [tcpdump-workers] DLT request for SDLC (BITBUS)
Hi Guy, thank you for your response. I think my request was a bit misleading and wrong formulated. I told you we are working on a BITBUS tracer which in reality is a SDLC tracer that can trace BITBUS too. >> Is there a way to use the SDLC dissector as a DLT already? > No, and if you were to do so, you probably wouldn't like the results, unless you're using SNA on the BITBUS links. > >> If not we would request a DLT for SDLC communication on which we would base our BITBUS lua dissector plugin. > > You should, instead, get LINKTYPE_BITBUS/DLT_BITBUS. I don't think thats what we want as we have raw SDLC frames coming from our usb tracer and need to display them too. We want to feed the data directly into Wireshark with an extcap component and don't want to go the detour over ethernet packets. The payload data should not be interpreted by default (we would write a lua bitbus dissector for that). Would this route be possible with a DLT like LINKTYPE_SDLC/DLT_RAWSDLC ? Best regards Freundliche Grüße Paul Becker ELZET 80 Mikrocomputer GmbH & Co. KG Theaterplatz 9 D-52062 Aachen Germany Tel. +49-241-4016580 Fax +49-241-48480 email: bec...@elzet80.de Please visit our web-site at http://www.elzet80.com ELZET =8 0= I USt.Id. : DE 117 662 038 Handelsregister Aachen Abt. A, Nr. 8044 Komplementär & Geschäftsführung: Giesler & Danne Bet. u. Verw. GmbH Handelsregister Aachen Abt. B, Nr. 17317 Geschäftsführer Walter L. Giesler Am 16.01.2017 um 19:12 schrieb Guy Harris: On Jan 16, 2017, at 4:06 AM, Becker (ELZET80) wrote: we are currently working on an USB tracer which captures messages from BITBUS connected devices. BITBUS is based on the SDLC protocol by IBM (see: https://en.wikipedia.org/wiki/Synchronous_Data_Link_Control) Several protocols, including HDLC, LAPB, IEEE 802.2, etc. are, directly or indirectly, "based on the SDLC protocol". However... We have already seen that there is a SDLC dissector implemented in Wireshark ...the SDLC dissector is intended to dissect IBM's SDLC, and assumes that the payload of an Information frame is SNA. According to http://www.bitbus.org/dnl/BITBUS%20Interconnect%20Specification.PDF 1) "The BITBUS interconnect does not (and is not intended to) maintain strict SDLC compatibility" and 2) what's described by section 5.0 "MESSAGE PROTOCOL SPECIFICATION" isn't SNA. So we should not treat the BITBUS data link layer as SDLC, but as Yet Another SDLC-Based Protocol. but as we are getting our data from our tracer tool there is no ethernet layer here. Is there a way to use the SDLC dissector as a DLT already? No, and if you were to do so, you probably wouldn't like the results, unless you're using SNA on the BITBUS links. If not we would request a DLT for SDLC communication on which we would base our BITBUS lua dissector plugin. You should, instead, get LINKTYPE_BITBUS/DLT_BITBUS. Would those packets begin with the Address field of the BITBUS header, followed by the Control field, followed by the Information, with the Flag fields not included. and with bit-stuffing removed? Would they include the FCS, or not? ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] DLT_request
yes, used endianness is always big endian. before version 1.2 of gencp standard, exist the possibility to define a protocol endianness - but this is removed with version 1.2! so all endianness of protocol data of cameralink interface should also be big endian. the protocol transports read and write memory request between host (pc with frame grabber) and a camera. the data in this requests can be little and big endian in mixed manner ! but this is defined in the next layer the SFNC standards of the xml description files of the camera. what do you mean - makes it sense to define a DLT_request for the CameraLink Protocol ? Best Regards Rene Weber Geschäftsführer: Dr. Albert Schmidt· Dr. Oliver Vietze Sitz der Gesellschaft: Radeberg Amtsgericht Dresden: HRB 15379 Ust. ID: DE 189714583 -Ursprüngliche Nachricht- Von: Guy Harris [mailto:g...@alum.mit.edu] Gesendet: Freitag, 13. Januar 2017 21:21 An: Weber René Cc: tcpdump-workers@lists.tcpdump.org Betreff: Re: [tcpdump-workers] DLT_request On Jan 13, 2017, at 6:49 AM, Weber René wrote: > On Jan 11, 2017, at 11:42 PM, Weber René wrote: > >>> We working at software for industrial cameras which are supported by the >>> cameralink standard. We use Wireshark to monitor the control interface. We >>> have implemented a solution similar like the u3v dissector and uses link >>> type DLT_USER0. The cameralink interface is basically a serial interface >>> like rs232 uart. > >> So this is for GenCP over a serial port, rather than GenCP-over-UDP? > > I don't know a GenCP-over-UDP - where can I find some information about this? OK, they mentioned UDP here: http://www.emva.org/wp-content/uploads/GenICam_GenCP_1.2.pdf but they didn't really mention it as a transport. >> So do the packets in such a pcap or pcapng file start with the serial prefix >> described in section 1.5 "Serial Prefix", followed by the common command >> data described in section 4.3 "Common Command Data", followed by the >> specific command data for the command in question (section 1.6 "Serial >> Postfix" says there's no postfix for serial ports)? > > correct. U3V in opposite to cameralink has a different prefix and a different > endian order. So the GenCP-over-serial endianness is big-endian, as per Appendix 1. Serial Port Implementations This section specializes the generic protocol for the use over a serial link. 1.1. Byteorder For devices communicating over a serial link the byte order of bootstrap registers and protocol fields is big-endian. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] DLT request for SDLC (BITBUS)
On Jan 17, 2017, at 5:25 AM, Becker (ELZET80) wrote:
> I think my request was a bit misleading and wrong formulated. I told you we
> are working on a BITBUS tracer which in reality is a SDLC tracer that can
> trace BITBUS too.
So by "tracer" do you mean that it actually dissects and displays packets, or
do you mean it captures packets and feeds them to Wireshark or some other
program to dissect?
>>> Is there a way to use the SDLC dissector as a DLT already?
>> No, and if you were to do so, you probably wouldn't like the results, unless
>> you're using SNA on the BITBUS links.
>>
>>> If not we would request a DLT for SDLC communication on which we would base
>>> our BITBUS lua dissector plugin.
>>
>> You should, instead, get LINKTYPE_BITBUS/DLT_BITBUS.
>
> I don't think thats what we want as we have raw SDLC frames coming from our
> usb tracer and need to display them too.
So what's a "raw SDLC frame"? An SNA packet using SDLC as the link-layer?
> We want to feed the data directly into Wireshark with an extcap component and
> don't want to go the detour over ethernet packets.
> The payload data should not be interpreted by default (we would write a lua
> bitbus dissector for that).
So are these BITBUS packets, SNA packets, or both?
("SDLC" isn't "any protocol with an address field and an SDLC-like control
field"; that definition would include HDLC, LAPB, LAPD, BITBUS, etc..)
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
