On 1/2/12 3:18 PM, Cezary Jackiewicz wrote:
> Dnia 2012-01-02, o godz. 14:42:34
> Philip Prindeville <[email protected]> napisał(a):
>
>> I'm pretty sure this isn't what you want!
>>
>> % grep 0x02 /usr/include/netinet/ip.h
>> #define IPTOS_ECN_ECT0 0x02
>> #define IPTOS_LOWCOST 0x02
>> %
>>
>>
>> Read the comments in /usr/include/netinet/ip.h and consider that the
>> original RFC-791 markings were retired 14 years ago.
>>
>> Sending IPTOS_LOWCOST will have some *very* unfortunate effects if you go
>> through an ECN-aware router!
>
> Transmission defines 'lowcost' as 0x10 (line 266 in
> libtransmission/session.c).
>
> #define IPTOS_LOWDELAY 0x10
>
> in /usr/include/netinet/ip.h
>
>
This app is broken. Looking at /usr/include/netinet/ip.h:
#define IPTOS_LOWDELAY 0x10
#define IPTOS_THROUGHPUT 0x08
#define IPTOS_RELIABILITY 0x04
#define IPTOS_LOWCOST 0x02
versus session.c:
if( !evutil_ascii_strcasecmp( str, "lowcost" ) )
return 0x10;
if( !evutil_ascii_strcasecmp( str, "mincost" ) )
return 0x10;
if( !evutil_ascii_strcasecmp( str, "throughput" ) )
return 0x08;
if( !evutil_ascii_strcasecmp( str, "reliability" ) )
return 0x04;
if( !evutil_ascii_strcasecmp( str, "lowdelay" ) )
return 0x02;
The first and last if tests are wrong.
It should be:
if( !evutil_ascii_strcasecmp( str, "lowdelay" ) )
return 0x10;
if( !evutil_ascii_strcasecmp( str, "throughput" ) )
return 0x08;
if( !evutil_ascii_strcasecmp( str, "reliability" ) )
return 0x04;
if( !evutil_ascii_strcasecmp( str, "lowcost" ) ||
!evutil_ascii_strcasecmp( str, "mincost" ) )
return 0x02;
In any case, the fields 0x01 and 0x02 were deprecated 14 years ago so the last
'if' shouldn't even be there.
Citing RFC 2474:
4. Historical Codepoint Definitions and PHB Requirements
The DS field will have a limited backwards compatibility with current
practice, as described in this section. Backwards compatibility is
addressed in two ways. First, there are per-hop behaviors that are
already in widespread use (e.g., those satisfying the IPv4 Precedence
queueing requirements specified in [RFC1812]), and we wish to permit
their continued use in DS-compliant nodes. In addition, there are
some codepoints that correspond to historical use of the IP
Precedence field and we reserve these codepoints to map to PHBs that
meet the general requirements specified in Sec. 4.2.2.2, though the
specific differentiated services PHBs mapped to by those codepoints
MAY have additional specifications.
No attempt is made to maintain backwards compatibility with the "DTR"
or TOS bits of the IPv4 TOS octet, as defined in [RFC791].
and RFC 2481:
5. Explicit Congestion Notification in IP
[...]
Bits 6 and 7 in the IPv4 TOS octet are designated as the ECN field.
Bit 6 is designated as the ECT bit, and bit 7 is designated as the CE
bit. The IPv4 TOS octet corresponds to the Traffic Class octet in
IPv6. The definitions for the IPv4 TOS octet [RFC791] and the IPv6
Traffic Class octet are intended to be superseded by the DS
(Differentiated Services) Field [DIFFSERV]. Bits 6 and 7 are listed
in [DIFFSERV] as Currently Unused. Section 19 gives a brief history
of the TOS octet.
Because of the unstable history of the TOS octet, the use of the ECN
field as specified in this document cannot be guaranteed to be
backwards compatible with all past uses of these two bits. The
potential dangers of this lack of backwards compatibility are
discussed in Section 19.
[...]
19. Historical definitions for the IPv4 TOS octet
RFC 791 [RFC791] defined the ToS (Type of Service) octet in the IP
header. In RFC 791, bits 6 and 7 of the ToS octet are listed as
"Reserved for Future Use", and are shown set to zero. The first two
fields of the ToS octet were defined as the Precedence and Type of
Service (TOS) fields.
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | TOS | 0 | 0 | RFC 791
+-----+-----+-----+-----+-----+-----+-----+-----+
RFC 1122 included bits 6 and 7 in the TOS field, though it did not
discuss any specific use for those two bits:
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | TOS | RFC 1122
+-----+-----+-----+-----+-----+-----+-----+-----+
The IPv4 TOS octet was redefined in RFC 1349 [RFC1349] as follows:
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | TOS | MBZ | RFC 1349
+-----+-----+-----+-----+-----+-----+-----+-----+
Bit 6 in the TOS field was defined in RFC 1349 for "Minimize Monetary
Cost". In addition to the Precedence and Type of Service (TOS)
fields, the last field, MBZ (for "must be zero") was defined as
currently unused. RFC 1349 stated that "The originator of a datagram
sets [the MBZ] field to zero (unless participating in an Internet
protocol experiment which makes use of that bit)."
[...]
The damage that could be done in an ECN-capable environment by a
non-ECN-capable end-node transmitting packets with the ECT bit set
has been discussed in Section 9 on "Non-compliance by the End Nodes".
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
