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

[Sebastian Moeller <moeller0@gmx.de>]

[-- Attachment #1: Type: text/plain, Size: 3454 bytes --]

Hi Pete,

If the PayPal ad of an irtt packet would contain the requested DSCP as ascci string (maybe starting with a string like "DSCP: 46: 101110 (EF)" in the first few bytes of the payload would make confirming bleaching/remapping from packetdumps relatively convenient, say just by looking at a packet in Wireshark and comparing the IP headers DSCP value with the string in the payload. Sure that is not automated, but would be great in at least allowing to test for bleaching in the packets received from a irtt server....

But, as much as I would like that feature, I believe the total audience will be quite small....

Best Regards
        Sebastian

On September 7, 2019 1:33:48 PM GMT+02:00, Pete Heist <pete@heistp.net> wrote:
>
>> 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?

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[-- Attachment #2: Type: text/html, Size: 4377 bytes --]