[tcpdump-workers] Request for new LINKTYPE_* code LINKTYPE_AUERSWALD_LOG
--- Begin Message --- Dear tcpdump developers, We would like to request a dedicated LINKTYPE_* / DLT_* code. Auerswald is a major German telecommunications equipment manufacturer. We have implemented the option to capture (combined) network traffic and logging information as pcap/pcapng in our soon to be released new product line. For development, we so far have used LINKTYPE_USER0 and would like to change this to a proper code before the commercial release. We also plan to publicly release the dissector and would like to make sure both can be released with a proper code from the get go. The dissector we currently use is however only in lua. Our preferred name would be LINKTYPE_AUERSWALD_LOG If anyone is interested we can provide further information. Best regards Frank Gorgas-Waller Software Architect Auerswald Gesellschaft für Datensysteme mbH Vor den Grashöfen 1 38162 Cremlingen Germany Registered at AG Braunschweig HRB 7499 Management board: Dipl.-Ing. Gerhard Auerswald Dipl.-Kfm. (FH) Christian Auerswald --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Request for new LINKTYPE_* code LINKTYPE_AUERSWALD_LOG
--- Begin Message --- > Ideally, you would have a document somewhere that would describe your capture > format. We might want to review the format. I would be able to > I would note that if you are just adding logging, and you just want to use > pcapng, that you might store your ethernet captures as normal EN10B, and your > logging in a new LINKTYPE_, which was specific to your log format. > In pcapng, you can mix different LINKTYPEs, in a single file. > (But, not in pcap, which is/was a major reason pcapng was designed) This is exactly what we do, beside of one exception. Our log format does contain a "content ID" to allow for future updates and different structures to be transportet within the same format. One of the content types we have specified is SIP packages. Since SIP is frequently encrypted and we do not want to break the encryption of the customer we insert decrypted SIP messages as a separate element to allow for better debugging of encrypted connections. Since we did not find a suitable LINKTYPE_ for the information we have available when logging, we decided to include these as a internal content ID which however is mapped to SIP > Then you can ideally follow: > > https://github.com/the-tcpdump-group/libpcap/blob/master/doc/DLT_ALLOCATE_HOWTO.md > send a pull request. We are happy to do so as soon as the dissector is uploaded to github as well. We plan to release the dissector on github as soon as we have the ID to update the code with the proper ID. The dissector contains some documentation already, beside that we can release the C structs that define the format elements. Since we plan to potentially include more elements in the future, we decided to use a format where we can just assign a new internal content ID for each update to the structures. Best regards Frank Gorgas-Waller --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Request for new LINKTYPE_* code LINKTYPE_AUERSWALD_LOG
--- Begin Message --- > Ideally, you would have a document somewhere that would describe your capture > format. We might want to review the format. I would be able to > I would note that if you are just adding logging, and you just want to use > pcapng, that you might store your ethernet captures as normal EN10B, and your > logging in a new LINKTYPE_, which was specific to your log format. > In pcapng, you can mix different LINKTYPEs, in a single file. > (But, not in pcap, which is/was a major reason pcapng was designed) This is exactly what we do, beside of one exception: Our log format does contain a "content ID" to allow for future updates and different structures to be transportet within the same format. One of the content types we have specified is SIP packages. Since SIP is frequently encrypted and we do not want to break the encryption of the customer we insert decrypted SIP messages as a separate element to allow for better debugging of encrypted connections. Since we did not find a suitable LINKTYPE_ for the information we have available when logging, we decided to include these as a internal content ID which however is mapped to SIP with the information available to allow for further processing. > Then you can ideally follow: > > https://github.com/the-tcpdump-group/libpcap/blob/master/doc/DLT_ALLOCATE_HOWTO.md > send a pull request. We are happy to do so as soon as the dissector is uploaded to github as well. We plan to release the dissector on github as soon as we have the ID to update the code with the proper ID. The dissector contains some documentation already, beside that we can release the C structs that define the format elements. Since we plan to potentially include more elements in the future, we decided to use a format where we can just assign a new internal content ID for each update to the structures. Best regards Frank Gorgas-Waller --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Request for new LINKTYPE_* code LINKTYPE_AUERSWALD_LOG
--- Begin Message ---
Hi,
We currently use this code in our lua dissector to display (decoded) SIP
messages.
-- offsets will change with the new LINKTYPE
if (buf(148,2):uint() == MSG_TYPE_SIP) then
sadd("src_ip",0,16)
sadd("src_port",16,2,"uint")
sadd("dst_ip", 18,16)
sadd("dst_port",34,2,"uint")
Dissector.get("sip"):call(buf(msg_start, msg_len):tvb(), pinfo, subtree)
return
end
We could theoretically use a different LINKTYPE_ that would just contain the
same SIP information, however it would cause major changes for us, due to the
way logging is realized in our systems.
We had to adapt a legacy logging interface that does not allow us to put those
packages into a different LINKLAYER_ without some major redesign, for which I
do not see any time in the near future.
The pcapng interface we provide only combines network traffic with that one
logging stream.
Best regards
Frank Gorgas-Waller
Von: Anders Broman
Gesendet: Donnerstag, 4. Februar 2021 10:32:51
An: Michael Richardson; develo...@auerswald.de
Cc: tcpdump-workers@lists.tcpdump.org
Betreff: Re: [tcpdump-workers] Request for new LINKTYPE_* code
LINKTYPE_AUERSWALD_LOG
Hi,
You should perhaps take a look at the exported plus link type and wireshark
sources. It may be doing similar things. New tags could be added.
Regards
Anders
Hämta Outlook för Android<https://aka.ms/ghei36>
________________
From: tcpdump-workers on behalf of
developer--- via tcpdump-workers
Sent: Thursday, February 4, 2021 10:25:07 AM
To: Michael Richardson
Cc: tcpdump-workers@lists.tcpdump.org
Subject: Re: [tcpdump-workers] Request for new LINKTYPE_* code
LINKTYPE_AUERSWALD_LOG
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://protect2.fireeye.com/v1/url?k=6834631a-37af5a37-68342381-8692dc8284cb-36a161c5fa71f9bb&q=1&e=1c2aa5de-a64f-4983-9bfb-41b294d0b43c&u=https%3A%2F%2Flists.sandelman.ca%2Fmailman%2Flistinfo%2Ftcpdump-workers
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Request for new LINKTYPE_* code LINKTYPE_AUERSWALD_LOG
--- Begin Message ---
Sorry for the delay in responding, I had to look thru the code to make sure all
the information is accurate.
I looked into the option to change in particular the msg_type 1 (decoded SIP
message),
but for the short term, using export_pdu is not an option because of the
changes required.
The current implementation for the LINKTYPE_AUERSWALD_LOG uses the following
format:
Each package starts with a message header followed by the payload and a 0 byte.
The message header currently has a fixed width of 150 bytes.
For the future the length of the header might change based on the msg_type.
(This will allow for less waste compared to the fix length)
Whenever the content structure of the message or length of header is changed
a new msg_type will be used.
/* Literals for displaying level are
local level_tab = {
[0] = "Off",
[1] = "Error",
[2] = "Warning",
[3] = "Info",
[4] = "Debug",
[5] = "EDebug"
}
*/
// The Offset in comments is just for convenience for writing wireshark
dissectors
struct message_hdr {
uint16_t msg_type; // Offset 0
uint32_t level; // Offset 2
char category[32]; // Offset 6
union { // New Offsetbase 38
struct {// if msg_type == 0
int32_t pid; // Offset 38
int32_t tgid;// Offset 42
char procname[16];// Offset 46
char threadname[16]; // Offset 62
char class_name[32]; // Offset 78
char method[32]; // Offset 110
uint32_t lineno; // Offset 142
uint32_t seqno; // Offset 146
};
struct {// if msg_type == 1
char src_ip[16]; // Offset 38
uint16_t src_port;// Offset 54
char dst_ip[16]; // Offset 56
uint16_t dst_port;// Offset 72
};
};
} __attribute__((packed));// Total 150
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] DLT_AUERSWALD_LOG and LINKTYPE_AUERSWALD_LOG
--- Begin Message --- What are the steps to finalize registering the DLT and LINKTYPE. We are about to release another major release of our software and would like to stop using USER0. Conflicts have been resolved and review was requested quite a while ago. As far as I can see the merge request is waiting for approval by guyharris. https://github.com/the-tcpdump-group/libpcap/pull/995 Thanks in advance Frank Gorgas-Waller --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
