Added new DLT_AUERSWALD_LOG and LINKTYPE_AUERSWALD_LOG

[fgw-auerswald]

trafficstars

Here the Pull Request as requested on mailing list.

[fgw-auerswald]

Which DLT number should we choose, I see we conflicted with another submission.

[fgw-auerswald]

Since DLT 296 was already applied for I left this one out. We are about to release another software update and would like to get away from using the DLT_USERx some time soon.

[guyharris]

In what byte order are the numeric fields? Big-endian, little-endian, or the byte order of the host writing the file?

What are names for message types 0 and 1?

Is category just a string? I assume procname, threadname, class_name or source file, and method or function name are just strings. To what do those strings correspond?

Is "process ID" a UN*X/Windows process ID? If so, for which process?

What is tgid?

What is line number?

What is sequence number?

In a type 1 message, is sip package a Session Initiation Protocol message, with src_ip, src_port, dst_ip, and dst_port being the IP address and port from which it was sent and the IP address and port to which it was sent?

[fgw-auerswald]

I updated the documentation linked in the merge request. https://github.com/Auerswald-GmbH/auerlog/blob/master/auerlog.txt

We have another release coming up soon. I would appreciate if we could switch to using the proper ID by then.

[guyharris]

The type should be 296, not 297, as that's the next available type.

[fgw-auerswald]

@guyharris 296 was applied for by FIRA_UCI https://github.com/the-tcpdump-group/libpcap/pull/1107/files I was trying to avoid another collision. So shall I take 296?

[guyharris]

@guyharris 296 was applied for by FIRA_UCI

People can give a number in a pull request, but that doesn't mean they'll get that number. In the case of that request, they don't have a publicly-available specification for the format, which is delaying the acceptance of the request.

(I've thought about providing a mechanism similar to pcapng's custom block/custom option mechanism to allow an organization with a Private Enterprise Number to manage their own provide space of link-layer header type values, so that 1) the number is permanently assigned and can be used in pcap and pcapng files without fear of collision with other vendors' numbers and 2) they don't need a public spec, because we don't "own" the value. That would be a way to handle "we want a LINKTYPE_ but we don't want to tell people how it works".)

So shall I take 296?

Yes. If, as, and when the people who want a FIRA_UCI tpe make it possible for developers to write code to read or write files with their link-layer header type without having to join their organization etc., they will get assigned whatever the next free type value is - it won't be 296, but they'll just have to deal with that.

[fxlb]

And please rebase you PR on top of the-tcpdump-group/libpcap:master. (Remove the [Merge branch 'master' into NEW_DLT_297] commit)

[fxlb]

The simpler way to update the PR to have a readable history, after updating the master branch:

git reset --hard @^
git reset --hard @^
git rebase master
git apply AUERSWALD_LOG.patch.txt
git commit -a -m "Add DLT_AUERSWALD_LOG and LINKTYPE_AUERSWALD_LOG"
git push -f

AUERSWALD_LOG.patch.txt

[infrastation]

@fgw-auerswald, now that there is a code point, could you document it here (source file, instructions)?

[fgw-auerswald]

@infrastation Will update documentation tomorrow or the day after, which will also include the link to a preliminary lua dissector for the protocol and hopefully a sample file.

[infrastation]

There is now a basic reference for the new type in the table of link-layer types, you are welcome to convert it to a better documented page as discussed.