Subject: [ipwave] BSM messages Packet Capture DB

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 14 Dec 2018 06:10:27 +0000

Folks - We are looking for a database (PCAP) of SAE 2735 BSM messages. We realize most of the university folks are using the standard simulators to generate these packets, but we are looking for packet traces from a real trial. With simulators, we cannot model all the subtle variations of parameters in the messages, or at least it won't be trivial, hence looking for some good set of database. Greatly appreciate any pointers.

Sri

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 14 Dec 2018 10:45:12 +0100

For American format (WSMP, BSM, etc.; not ETSI CAM) there's a lowres 
photo of a secured WSMP packet from a trial in NYC in America.  There is 
also that MessageParser test URL at itsforge.

(I suppose there is a reason for this image to be lowres, but that 
reason can not be confidentiality of proprietary technology, nor address 
privacy risks)

Le 14/12/2018 à 07:10, Inline image 1Sri Gundavelli (sgundave) a écrit :
> Folks – We are looking for a database (PCAP) of SAE 2735 BSM messages. 
> We realize most of the university folks are using the standard 
> simulators to generate these packets, but we are looking for packet 
> traces from a real trial. With simulators, we cannot model all the 
> subtle variations of parameters in the messages, or at least it won’t 
> be trivial, hence looking for some good set of database. Greatly 
> appreciate any pointers.
>
>
> Sri
>
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its

Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB-implementations
From: William Whyte <[email-masked]>
To: Alexandre Petrescu <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Fri, 2 Mar 2018 12:02:24 -0500

US implementations use QoSData with everything -- although it's not
required by 802.11-OCB, as we discussed earlier, it *is* required for a
"WAVE device", which all US devices are.

Here's a Wireshark image from a contact showing the QoSData field:

Cheers,

William

On Fri, Mar 2, 2018 at 11:28 AM, Alexandre Petrescu <
[email-masked]> wrote:

>
>
> Le 02/03/2018 à 17:16, William Whyte a écrit :
>
>> I've confirmed that the US implementations use QoSData, just to close
>> that loop.
>>
>
> Thanks.  It's QoSData with IP, right?
>
> Alex
>
>
>> Cheers,
>>
>> William
>>
>>
>> On Thu, Mar 1, 2018 at 11:05 AM, Alexandre Petrescu <
>> [email-masked] <mailto:[email-masked]>>
>> wrote:
>>
>>     William,
>>
>>     Le 01/03/2018 à 16:59, William Whyte a écrit :
>>
>>           > I propose we rename 'OCB' into 'IP-OCB' in the draft.
>>
>>           > 'IP-OCB' is an OCB mode that can be transport IP packets
>>         with .11 Data
>>
>>           > headers or with .11 QoS Data headers.
>>
>>         If it’s over OCB, then it needs to use QoSData. If you’re doing
>>         Data, you’re not conformant to OCB. There can’t be an OCB mode
>>         that transports packets with .11 Data, because OCB by definition
>>         uses QoSData. If the draft implies that you can do
>>         non-conformant OCB, that’s a serious defect in the draft.
>>
>>         Some implementations may not yet have implemented this, but
>>         that’s on those developers.
>>
>>
>>     For one second, allow me the benefit of the doubt about
>>     specifications that may not be implemented.
>>
>>     I would like to know whether there is an implementation of IP over
>>     OCB with QoSData headers?  Packet dump is sufficient, or any other
>>     kind of statement.
>>
>>     I agree with you that many times it is good to write specification
>>     first and implementation after.
>>
>>     Alex
>>
>>
>>         Cheers,
>>
>>         William
>>
>>         Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986
>>         <https://go.microsoft.com/fwlink/?LinkId=550986>> for Windows 10
>>
>>         *From: *Alexandre Petrescu <mailto:[email-masked]
>>         <mailto:[email-masked]>>
>>         *Sent: *Thursday, March 1, 2018 10:54 AM
>>         *To: *William Whyte <mailto:[email-masked]
>>         <mailto:[email-masked]>>; [email-masked]
>>         <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>         *Subject: *Re: [ipwave] 802.11 Data vs 802.11 QoS Data in
>>         IPv6-over-802.11-OCB-implementations
>>
>>
>>         Le 01/03/2018 à 16:50, William Whyte a écrit :
>>
>>           >  >> (there are some packet dumps with IP packets transported
>>         with .11 Data
>>
>>           >
>>
>>           > headers in OCB mode at 5.9GHz, e.g. attached).
>>
>>           >
>>
>>           > My understanding is OCB mode requires QoSData, so those
>>         packets aren’t
>>
>>           > conformant to the standard.
>>
>>         I propose we rename 'OCB' into 'IP-OCB' in the draft.
>>
>>         'IP-OCB' is an OCB mode that can be transport IP packets with
>>         .11 Data
>>
>>         headers or with .11 QoS Data headers.
>>
>>         Alex
>>
>>           >
>>
>>           > Cheers,
>>
>>           >
>>
>>           > William
>>
>>           >
>>
>>           > Sent from Mail
>>         <https://go.microsoft.com/fwlink/?LinkId=550986
>>         <https://go.microsoft.com/fwlink/?LinkId=550986>> for
>>
>>           > Windows 10
>>
>>           >
>>
>>           > *From: *Alexandre Petrescu
>>         <mailto:[email-masked]
>>         <mailto:[email-masked]>>
>>
>>           > *Sent: *Thursday, March 1, 2018 10:48 AM
>>
>>           > *To: [email-masked] <mailto:[email-masked]>
>>         <mailto:[email-masked] <mailto:[email-masked]>>
>>
>>           > *Subject: *Re: [ipwave] 802.11 Data vs 802.11 QoS Data in
>>
>>           > IPv6-over-802.11-OCB -implementations
>>
>>           >
>>
>>           > In a private discussion, this question came up:
>>
>>           >
>>
>>           > Is there a packet dump showing an IP packet transported with
>>         .11 QoSData
>>
>>           >
>>
>>           > headers in OCB mode at 5.9GHz.
>>
>>           >
>>
>>           > (there are some packet dumps with IP packets transported
>>         with .11 Data
>>
>>           >
>>
>>           > headers in OCB mode at 5.9GHz, e.g. attached).
>>
>>           >
>>
>>           > Alex
>>
>>           >
>>
>>           > Le 01/03/2018 à 15:32, Alexandre Petrescu a écrit :
>>
>>           >
>>
>>           >  > I received some feedback from programmer.
>>
>>           >
>>
>>           >  >
>>
>>           >
>>
>>           >  > Le 28/02/2018 à 23:48, Abdussalam Baryun a écrit :
>>
>>           >
>>
>>           >  > [...]
>>
>>           >
>>
>>           >  >> ieee802.11ocb protocol is already implemented/tested and
>>         it is
>>
>>           >
>>
>>           >  >> interoperable, but what is the problem, sorry maybe I
>>         did not follow
>>
>>           >
>>
>>           >  >> the discussion well,
>>
>>           >
>>
>>           >  >
>>
>>           >
>>
>>           >  > Here is the QoS problem for IP over 802.11 OCB in
>>         implementations.
>>
>>           >
>>
>>           >  >
>>
>>           >
>>
>>           >  > In short, in open source on linux, we dont know how to
>>         send IP packets
>>
>>           >
>>
>>           >  > transported as 802.11 QoSData, all IP packets are
>>         transported as 802.11
>>
>>           >
>>
>>           >  > Data instead.
>>
>>           >
>>
>>           >  >
>>
>>           >
>>
>>           >  > - if you ping -Q at 5.9GHz in OCB mode, the DSCP fields
>>         do get
>>
>>           >
>>
>>           >  >    set properly in IP headers of Echorequest, but there
>>         is no .11 QoSData
>>
>>           >
>>
>>           >  >    headers in packets.  Normally, one expects the QoSData
>>         headers to be
>>
>>           >
>>
>>           >  >    present there when the DSCP (an IP field) is set.
>>
>>           >
>>
>>           >  >
>>
>>           >
>>
>>           >  > - if you want to modify kernel, and force always to use
>>         QoSData headers
>>
>>           >
>>
>>           >  >    on WiFi, including OCB at 5.9GHz, there is a
>>         net/mac80211/tx.c file
>>
>>           >
>>
>>           >  >    with a flag called wme_sta that you could set to
>>         true.  But take care
>>
>>           >
>>
>>           >  >    that the C comments there say that it's not normal to
>>         use QoSData
>>
>>           >
>>
>>           >  >    headers in OCB mode, because a terminal sending
>>         QoSData has no
>>
>>           >
>>
>>           >  >    guarantee that receivers also use QoSData (the
>>         negotiation of QoS
>>
>>           >
>>
>>           >  >    capabilities are absent in OCB).
>>
>>           >
>>
>>           >  >
>>
>>           >
>>
>>           >  > As you can see, this can be long to try and fix.
>>
>>           >
>>
>>           >  >
>>
>>           >
>>
>>           >  > Until then I will propose to set QoS aside from
>>         IP-over-OCB at this time.
>>
>>           >
>>
>>           >  >
>>
>>           >
>>
>>           >  > Alex
>>
>>           >
>>
>>           >  >
>>
>>           >
>>
>>           >  > _______________________________________________
>>
>>           >
>>
>>           >  > its mailing list
>>
>>           >
>>
>>           >  > [email-masked] <mailto:[email-masked]>
>>
>>           >
>>
>>           >  > https://www.ietf.org/mailman/listinfo/its
>>         <https://www.ietf.org/mailman/listinfo/its>
>>
>>           >
>>
>>
>>
>>
>> --
>>
>>
>> PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS:
>> [email-masked] <mailto:[email-masked]>
>>
>

-- 

PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS:
[email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 17 Dec 2018 13:25:14 +0100

Sri,

For BSM I dont know.

For CAM I do have some captures from trials where I am involved.  I can 
send them to person.  I do not put on email list because too many, and 
dont know  how to classify on a single email.  These are things that 
should be put on a web site with some readme file.

I do not worry too much about privacy of these captures because many of 
them are captured on public roads where anyone can capture.  It is 
called 'war driving'.  Google does it routinely.

(it's like taking photos of monuments - anyone can - even if some 
worrisome person may worry about the kind of monument).

Alex

Le 14/12/2018 à 07:10, Sri Gundavelli (sgundave) a écrit :
> subtle variations of parameters in the messages, or at least it won’t be 
> trivial, hence looking for some good set of database. Greatly appreciate 
> any pointers.
> 
> 
> Sri
>

---

From: "Chris Metz (chmetz)" <[email-masked]>
Date: Mon, 17 Dec 2018 16:15:49 +0000

Slightly higher wireshark screenshot using, if I recall correctly, MessageParser data. I recall efforts to locate pcap data but to no avail.

-cm

From: its <[email-masked]> on behalf of Alexandre Petrescu <[email-masked]>
Date: Friday, December 14, 2018 at 1:45 AM
To: "Sri Gundavelli (sgundave)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [ipwave] BSM messages Packet Capture DB

For American format (WSMP, BSM, etc.; not ETSI CAM) there's a lowres photo of a secured WSMP packet from a trial in NYC in America.  There is also that MessageParser test URL at itsforge.

(I suppose there is a reason for this image to be lowres, but that reason can not be confidentiality of proprietary technology, nor address privacy risks)

Le 14/12/2018 à 07:10, [nline image 1] Sri Gundavelli (sgundave) a écrit :
Folks – We are looking for a database (PCAP) of SAE 2735 BSM messages. We realize most of the university folks are using the standard simulators to generate these packets, but we are looking for packet traces from a real trial. With simulators, we cannot model all the subtle variations of parameters in the messages, or at least it won’t be trivial, hence looking for some good set of database. Greatly appreciate any pointers.

Sri

its mailing list

[email-masked]<mailto:[email-masked]>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 17 Dec 2018 19:23:06 +0100

the direct location of pcap of MessageParser zip file is 
https://www.itsforge.net/media/kunena/attachments/478/MessageParserTest.zip

that url is pointed to by this discussion url
https://www.itsforge.net/index.php/community/discussion-forum/cv-dsrc-message-parser/44-test-files?start=0

That zip file is 3.8M

Le 17/12/2018 à 17:15, Chris Metz (chmetz) a écrit :
> Slightly higher wireshark screenshot using, if I recall correctly, 
> MessageParser data. I recall efforts to locate pcap data but to no avail.
> 
> -cm
> 
> *From: *its <[email-masked]> on behalf of Alexandre Petrescu 
> <[email-masked]>
> *Date: *Friday, December 14, 2018 at 1:45 AM
> *To: *"Sri Gundavelli (sgundave)" <[email-masked]>, "[email-masked]" 
> <[email-masked]>
> *Subject: *Re: [ipwave] BSM messages Packet Capture DB
> 
> Le 14/12/2018 à 07:10, nline image 1Sri Gundavelli (sgundave) a écrit :
> 
>     Folks – We are looking for a database (PCAP) of SAE 2735 BSM
>     messages. We realize most of the university folks are using the
>     standard simulators to generate these packets, but we are looking
>     for packet traces from a real trial. With simulators, we cannot
>     model all the subtle variations of parameters in the messages, or at
>     least it won’t be trivial, hence looking for some good set of
>     database. Greatly appreciate any pointers.
> 
>     Sri
> 
> 
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 17 Dec 2018 19:39:30 +0100

Sri,

To test interoperability of BSM message the best way is indeed to get 
captures from somebody else and feed it to your decoder, and vice-versa.

Until that is possible (someone to provide you pcaps), there are a few 
things which could be small steps with the ASN1 Playground tool.

- decide between J2735 version 2009 (free at the date of issue)
   or J2735 2016 (paying).
- if 2009 then use the freely available grammar .asn file from ASN1
   Playground.
- if 2016: buy the 2016 .asn file (cca 100USD) and upload it to ASN1
   Playground ('Schema' - 'Upload .asn file').  It seems for private use.
- Compile schema and Encode/Decode on ASN1 Playground.

That helps a little bit to make sure that your own Encoder/Decoder works 
a little bit like somebody else's Encoder/Decoder, starting presumably 
from the same grammar .asn file.

That's the best thing one could do at this time for BSM messages.

There's no better way to ensure interop of BSM.

If it were me, I would use the 2009 J2735 for BSM messages, find a 
partner, put these BSMs on XER so they're clear, and send on UDP on IPv6 
across Internet.

Alex

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 19 Dec 2018 15:15:26 +0000

Hi Alex,

Thanks!

We are reasonably sure our decoders in a good shape, but what we are
looking for different data sets (from real trials); specially the BSM sent
on channel 272, and others messages from RSU¹s on other channels. This is
not just for testing parser, but for understanding the mobility patterns
..etc.

We do have 2016 paying ASN files and so we are good there. Also, thanks to
John Kenney, he clarified about 2009 and so we are ignoring that version
as there is not much foot print.

Sri

On 12/17/18, 10:39 AM, "its on behalf of Alexandre Petrescu"
<[email-masked] on behalf of [email-masked]> wrote:

>> Folks  We are looking for a database (PCAP) of SAE 2735 BSM messages.
>> subtle variations of parameters in the messages, or at least it won¹t
>>be

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 19 Dec 2018 18:25:18 +0000

Yep ..typo ..

On 12/19/18, 10:23 AM, "Dick Roy" <[email-masked]> wrote:

>FYI ... it's channel 172, not 272. And if you are still seeing LPD LLC
>headers, that's wrong!
>
>RR
>
>-----Original Message-----
>From: its [mailto:[email-masked]] On Behalf Of Sri Gundavelli
>(sgundave)
>Sent: Wednesday, December 19, 2018 7:15 AM
>To: Alexandre Petrescu; [email-masked]
>...etc.