Re: [Cerowrt-devel] [Bloat] Ubiquiti Launches a Speed Test Network

[Pete Heist <pete@heistp.net>]

> On Sep 7, 2019, at 1:12 AM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> 
>>>> From irtt help client:
>>>> --fill=fill    fill payload with given data (default none)
>>>>              none: leave payload as all zeroes
>>>>              rand: use random bytes from Go's math.rand
>>>>              pattern:XX: use repeating pattern of hex (default 69727474)
>>>> --fill-one     fill only once and repeat for all packets
>>>> --sfill=fill   request server fill (default not specified)
>>>>              see options for --fill
>>>>              server must support and allow this fill with --allow-fills
>>> 
>>> As above, we're doing --fill=rand today.
>> 
>> 	Sama as above, but maybe Pete could be convinced to do the read back of the first X bytes automatically.
> 
> Certainly not opposed to adding this support to Flent if it materialises
> in irtt :)

Coming into this late so haven’t parsed the full request, but irtt sends the requested DSCP value passed in via --dscp to the server during the handshake. It would be possible, though not very intuitive, to pull this out of the initial request packet, which contains type/value pairs encoded with varint style encoding: https://developers.google.com/protocol-buffers/docs/encoding.

The format of the request is “documented” in code in the bytes() method in params.go. Visually, the DSCP value is often the value 0x08, close to the end of the initial packet, following by the DSCP value as a signed varint. (Clearly, it would have made more sense if I’d just sent that as an unsigned byte instead of using a varint, let alone a signed one, but I just leaned on the binary package’s varint support, such as it is, so one has to grok this: https://developers.google.com/protocol-buffers/docs/encoding#signed-integers. I’ve added it to irtt’s todo list to clean this up before 1.0, which will mean a protocol version bump).

One unfortunate thing is that if the goal is to verify that DSCP values have not been modified along the way (without a pcap), afaik the receiver has no way of obtaining the received DSCP value in user space without opening up a raw socket and parsing the IP packet in full (requiring root). But, figuring it out from packet dumps would be possible. If I ever get around to adding irtt support to scetrace (https://github.com/heistp/scetrace), I could detect and count changes to dscp values there, though that’s a ways off at the moment.

Knowing all this, are there any simple changes I can make to get you what you need?