On 10/12/15 12:49, Dave Taht wrote: > etags (or ctags) are friends here, as is cscope. I am in deep > gratitude to toke for supplying me a pretty good working .emacs.d set > of files for browsing code recently - I'd lost 20 years worth of > accumulated tools when my lab got stolen and don't do enough software > development today to justify sinking the time into making emacs sing > and dance anymore. That said, I don't understand 90% of all the cool > stuff he handed me... > > in the linux kernel tree, do a make TAGS. then in emacs it's esc->. to > look up a symbol. There are ton of other things in cscope that are > pretty amazing. vi has similar interfaces as do eclipse. Well I'm beginning to get the vague whiff of a rat...... In iproute2 land 'iptunnel.c' is responsible for setting 'iph.tos'. 'ip tunnel' in openwrt land returns: # ip tunnel BusyBox v1.24.1 (2015-12-10 10:25:05 GMT) multi-call binary. Usage: ip [OPTIONS] {address | route | link | rule} {COMMAND} ip [OPTIONS] OBJECT {COMMAND} where OBJECT := {address | route | link | rule} OPTIONS := { -f[amily] { inet | inet6 | link } | -o[neline] } First line gives a clue...this isn't real 'iproute2', this is busybox. And a vaguely remember something going by on the openwrt commit list about switching to 'busybox ip route' built-ins. Does busybox understand the tos flag? I can't prove it yet. But it's one of those gut feels I get...... > > On Thu, Dec 10, 2015 at 1:43 PM, Kevin Darbyshire-Bryant > wrote: >> >> On 10/12/15 12:35, Kevin Darbyshire-Bryant wrote: >>> On 10/12/15 12:22, Dave Taht wrote: >>>> On Thu, Dec 10, 2015 at 1:09 PM, Kevin Darbyshire-Bryant >>>> wrote: >>>> >>>>> the same test shows all those flows going in the best effort tin and >>>>> nothing being split out according to dscp. Things are split out >>>>> correctly with ipv4. Assuming that my installation of flent is doing >>>>> the right thing (putting dscp on its outbound ipv6 packets) and knowing >>>>> that both flent & cake handle the ipv4 version of the test correctly and >>>>> that by the time 'cake' sees my tunnel it's all ipv4 outer packets >>>>> anyway, this suggests dscp from inner ipv6 to outer ipv4 isn't taking >>>>> place, at least for 6in4 'sit' tunnels :-( >>>> Wireshark is your friend here. >>> I shall befriend it once again :-) >>>> It would not surprise me if dscp inherit had broken again, or, it was >>>> borked on decapsulation. Not a widely tested feature, that. >>> I'm only 'testing' the encapsulation side...ipv6 into router, router >>> encapsulates into ipv6, cake then sits across 'eth0' the Internet facing >>> interface and isn't classifying the flows - and I swear this used to work. > I had it working 3 years back, yes, also. > >>>> I remember making it work several years ago, remember sort of seeing >>>> the patches go upstream somewhere.... it was a long time ago. >>> Is there anyone lurking on this list, with the time, who can help me >>> with net/ipv6/sit.c? >>> >>> It looks like this is the relevant area: Need to see what >>> INET_ECN_encapsulate does (and where tos gets set) >>> >>> if (ttl == 0) >>> ttl = iph6->hop_limit; >>> tos = INET_ECN_encapsulate(tos, ipv6_get_dsfield(iph6)); >>> >>> if (ip_tunnel_encap(skb, tunnel, &protocol, &fl4) < 0) { >>> ip_rt_put(rt); >>> goto tx_error; >>> } >>> >>> skb_set_inner_ipproto(skb, IPPROTO_IPV6); >>> >>> err = iptunnel_xmit(NULL, rt, skb, fl4.saddr, fl4.daddr, >>> protocol, tos, ttl, df, >>> !net_eq(tunnel->net, dev_net(dev))); >>> iptunnel_xmit_stats(err, &dev->stats, dev->tstats); >>> return NETDEV_TX_OK; >> Ahhh....further up... >> >> if (tos == 1) >> tos = ipv6_get_dsfield(iph6); >> >> and further up still... >> >> static netdev_tx_t ipip6_tunnel_xmit(struct sk_buff *skb, >> struct net_device *dev) >> { >> struct ip_tunnel *tunnel = netdev_priv(dev); >> const struct iphdr *tiph = &tunnel->parms.iph; >> const struct ipv6hdr *iph6 = ipv6_hdr(skb); >> u8 tos = tunnel->parms.iph.tos; >> >> >> So how & who sets (or should be setting) iph.tos = 1? >> >> Rabbit hole, rabbit hole...... >> >> >> >> >> >> _______________________________________________ >> Cake mailing list >> Cake@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cake >>