Re: [tcpdump-workers] Request for new LINKTYPE_* code LINKTYPE_AUERSWALD_LOG

2021-02-04 Thread Guy Harris via tcpdump-workers
--- Begin Message ---
On Feb 4, 2021, at 3:41 AM, developer--- via tcpdump-workers 
 wrote:

> 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

In other words, the format of packets is:

IPv6 source address - 16 octets
source port - 2 octets
IPv6 destination address - 16 octets
destination port - 16 octets
SIP packet
--- 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

2021-02-04 Thread developer--- via tcpdump-workers
--- 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


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

Re: [tcpdump-workers] Request for new LINKTYPE_* code LINKTYPE_AUERSWALD_LOG

2021-02-04 Thread Anders Broman via tcpdump-workers
--- Begin Message ---
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


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

Re: [tcpdump-workers] Request for new LINKTYPE_* code LINKTYPE_AUERSWALD_LOG

2021-02-04 Thread developer--- via tcpdump-workers
--- 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

2021-02-04 Thread developer--- via tcpdump-workers
--- 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