[Cerowrt-devel] cerowrt-3.10.34-4 dev build released

[Cerowrt-devel] cerowrt-3.10.34-4 dev build released

[Dave Taht]

+ resync with openwrt
   they seem to be settling down...
+ Toke's ntp + dnssec stuff
+ Yet Another Patch to try and isolate the wireless hang problem
    that happens to jg every day or so and nearly no-one else.
+ Fix to babel's meshing interfaces
+ dnsmasq updated to head (seems to be stabilizing)
+ Tested for a couple hours

- I am under the impression we haven't enabled "auto" for
target and interval yet in SQM.

-There is some stuff in here I don't grok yet like this

Author: cyrus <cyrus@3c298f89-4303-0410-b956-a3cf2f4a3e73>
Date:   Tue Apr 1 18:52:09 2014 +0000

    odhcpd: add preliminary support for managed DHCPv6-PD and CER-ID





-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] cerowrt-3.10.34-4 dev build released

[Stephen Hemminger]

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

I am seeing wireless hang as well.
Mostly when multiple macbooks are active on 2.4g

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

Re: [Cerowrt-devel] cerowrt-3.10.34-4 dev build released

[Dave Taht]

On Wed, Apr 2, 2014 at 6:48 PM, Stephen Hemminger
<stephen@networkplumber.org> wrote:
> I am seeing wireless hang as well.
> Mostly when multiple macbooks are active on 2.4g

Grump. This patch is what is in 3.10.34-4. It is essentially the same as the
patch that I've been carrying in cerowrt for ages, but I dropped it
circa 3.10.28
or so as upstream had sprouted vlan and qos mapping support in addition
to the other weirdnesses in 802.11e classification therein. The vlan
mapping is just plain a bad idea, as is mapping priorities 256-, and I
don't know how to use the new qos-mapping feature...

There was some churn over wpa in the main tree that mapped it into the VO
queue recently...

So I regenerated that patch in this release.

This instead maps dscp values to the aggregateable wifi queue types:

From: Dave Taht <dave.taht@bufferbloat.net>
Date: Wed, 2 Apr 2014 12:38:53 -0700
Subject: [PATCH] wifi does not map to vlan priorities at all

obsolete "special" priority markings
get rid of vlan priorities
map unclassified dscp values to vi,be, and bk queues only

the VO queue should be as rarely used as possible.
---
 net/wireless/util.c |   85 ++++++++++++++++++++++++++++++++++++++++-----------
 1 file changed, 68 insertions(+), 17 deletions(-)

diff --git a/net/wireless/util.c b/net/wireless/util.c
index d39c371..4d1dce4 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -688,27 +688,78 @@ void ieee80211_amsdu_to_8023s(struct sk_buff
*skb, struct sk_buff_head *list,
 }
 EXPORT_SYMBOL(ieee80211_amsdu_to_8023s);

+static u8 dscp_table[] = {
+ 0, /* BE = 0x0 */
+ 0, /* Max-Reliability = 0x1 */
+ 3, /* Max-Throughput = 0x2 */
+ 0, /* 0x3 Undefined */
+ 5, /* Min-Delay = 0x4 */
+ 0, /* 0x5 Undefined */
+ 0, /* 0x6 Undefined */
+ 0, /* 0x7 Undefined */
+ 1, /* CS1 = 0x8 */
+ 0, /* 0x9 Undefined */
+ 3, /* AF11 = 0xa */
+ 0, /* 0xb Undefined */
+ 3, /* AF12 = 0xc */
+ 0, /* 0xd Undefined */
+ 3, /* AF13 = 0xe */
+ 0, /* 0xf Undefined */
+ 2, /* CS2 = 0x10 */
+ 0, /* 0x11 Undefined */
+ 3, /* AF21 = 0x12 */
+ 0, /* 0x13 Undefined */
+ 3, /* AF22 = 0x14 */
+ 0, /* 0x15 Undefined */
+ 3, /* AF23 = 0x16 */
+ 0, /* 0x17 Undefined */
+ 4, /* CS3 = 0x18 */
+ 0, /* 0x19 Undefined */
+ 3, /* AF31 = 0x1a */
+ 0, /* 0x1b Undefined */
+ 3, /* AF32 = 0x1c */
+ 0, /* 0x1d Undefined */
+ 3, /* AF33 = 0x1e */
+ 0, /* 0x1f Undefined */
+ 5, /* CS4 = 0x20 */
+ 0, /* 0x21 Undefined */
+ 5, /* AF41 = 0x22 */
+ 0, /* 0x23 Undefined */
+ 5, /* AF42 = 0x24 */
+ 0, /* 0x25 Undefined */
+ 4, /* AF43 = 0x26 */
+ 0, /* 0x27 Undefined */
+ 5, /* CS5 = 0x28 */
+ 0, /* 0x29 Undefined */
+ 0, /* 0x2a Undefined */
+ 0, /* 0x2b Undefined */
+ 4, /* VA = 0x2c */
+ 0, /* 0x2d Undefined */
+ 5, /* EF = 0x2e */
+ 0, /* 0x2f Undefined */
+ 5, /* CS6 = 0x30 */
+ 0, /* 0x31 Undefined */
+ 0, /* 0x32 Undefined */
+ 0, /* 0x33 Undefined */
+ 0, /* 0x34 Undefined */
+ 0, /* 0x35 Undefined */
+ 0, /* 0x36 Undefined */
+ 0, /* 0x37 Undefined */
+ 5, /* CS7 = 0x38 */
+ 0, /* 0x39 Undefined */
+ 0, /* 0x3a Undefined */
+ 0, /* 0x3b Undefined */
+ 0, /* 0x3c Undefined */
+ 0, /* 0x3d Undefined */
+ 0, /* 0x3e Undefined */
+ 0, /* 0x3f Undefined */
+ };
+
 /* Given a data frame determine the 802.1p/1d tag to use. */
 unsigned int cfg80211_classify8021d(struct sk_buff *skb,
     struct cfg80211_qos_map *qos_map)
 {
  unsigned int dscp;
- unsigned char vlan_priority;
-
- /* skb->priority values from 256->263 are magic values to
- * directly indicate a specific 802.1d priority.  This is used
- * to allow 802.1d priority to be passed directly in from VLAN
- * tags, etc.
- */
- if (skb->priority >= 256 && skb->priority <= 263)
- return skb->priority - 256;
-
- if (vlan_tx_tag_present(skb)) {
- vlan_priority = (vlan_tx_tag_get(skb) & VLAN_PRIO_MASK)
- >> VLAN_PRIO_SHIFT;
- if (vlan_priority > 0)
- return vlan_priority;
- }

  switch (skb->protocol) {
  case htons(ETH_P_IP):
@@ -736,7 +787,7 @@ unsigned int cfg80211_classify8021d(struct sk_buff *skb,
  }
  }

- return dscp >> 5;
+ return dscp_table[dscp>>2];
 }
 EXPORT_SYMBOL(cfg80211_classify8021d);

-- 
1.7.9.5


-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] cerowrt-3.10.34-4 dev build released

[Dave Taht]

I am actually far from convinced it is actually a wifi bug. It could
be something going wrong with routing, firewalling, nat, or something
else entirely. I have several captures of sw00 and ge00 taken after
the event occurs, and local udp, arp, and icmp and icmpv6 traffic is
working correctly. As is multicast.

The other device (sw10) stays running...

What I see in the captures I have is syn attempts from the sw00
interface do make it to the internet, and syn/ack attempts do return
through ge00, but
do not  make it through sw00. However I don't see ANY local syn
attempts in the capture I have: jg or someone needs to try a local tcp
connection to a local device or through the local router to a local
ethernet device after having it hang... (I will keep trying to
reproduce here)

tcp.flags == 0x0002

On Wed, Apr 2, 2014 at 6:48 PM, Stephen Hemminger
<stephen@networkplumber.org> wrote:
> I am seeing wireless hang as well.
> Mostly when multiple macbooks are active on 2.4g



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] cerowrt-3.10.34-4 dev build released

[David Personette]

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

http://arstechnica.com/security/2014/04/how-new-malware-is-making-the-internet-of-things-the-windows-xp-of-2014/

It's reaching tech journalism now. Could it be an attempted exploit taking
out jg's router? IE, another hacked router on his cable modem segment
scanning for other hosts to exploit.

-- 
David P.


On Wed, Apr 2, 2014 at 10:43 PM, Dave Taht <dave.taht@gmail.com> wrote:

> I am actually far from convinced it is actually a wifi bug. It could
> be something going wrong with routing, firewalling, nat, or something
> else entirely. I have several captures of sw00 and ge00 taken after
> the event occurs, and local udp, arp, and icmp and icmpv6 traffic is
> working correctly. As is multicast.
>
> The other device (sw10) stays running...
>
> What I see in the captures I have is syn attempts from the sw00
> interface do make it to the internet, and syn/ack attempts do return
> through ge00, but
> do not  make it through sw00. However I don't see ANY local syn
> attempts in the capture I have: jg or someone needs to try a local tcp
> connection to a local device or through the local router to a local
> ethernet device after having it hang... (I will keep trying to
> reproduce here)
>
> tcp.flags == 0x0002
>
> On Wed, Apr 2, 2014 at 6:48 PM, Stephen Hemminger
> <stephen@networkplumber.org> wrote:
> > I am seeing wireless hang as well.
> > Mostly when multiple macbooks are active on 2.4g
>
>
>
> --
> Dave Täht
>
> Fixing bufferbloat with cerowrt:
> http://www.teklibre.com/cerowrt/subscribe.html
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>

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

Re: [Cerowrt-devel] cerowrt-3.10.34-4 dev build released

[Jim Gettys]

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

On Wed, Apr 2, 2014 at 9:48 PM, Stephen Hemminger <
stephen@networkplumber.org> wrote:

> I am seeing wireless hang as well.
> Mostly when multiple macbooks are active on 2.4g
>
>
Also true in my house: both kids are on Macbooks.

But I've seen the problem with no-one but me (on Linux) around, so all that
says is that if the router is in use more, you see more failures.  So I'm
not sure I can draw much from this experience.
                                - Jim


> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>

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

Re: [Cerowrt-devel] cerowrt-3.10.34-4 dev build released

[Neil Shepperd]

I just flashed 3.10.34-4 to my new WNDR3800 and experienced the exact
wifi hang described by Toke Høiland-Jørgensen. But I'm on the 2.4GHz
network (with guest and babel disabled). Unfortunately I didn't think to
try tracing anything from the router side before resetting the wireless.

Syslog was filled with a lot of

DHCPDISCOVER(sw00) [MAYBE IP] [MAC ADDRESS]
DHCPOFFER(sw00) [IP] [MAC ADDRESS]

but the offers aren't being received at my laptop.

Just another data point I guess.

Neil

Re: [Cerowrt-devel] cerowrt-3.10.34-4 dev build released

[Dave Taht]

Is there a recent version that people had that was seemingly stable for
wifi that we could step back to and bisect from? Something where
you had heavy wifu use for week(s) without a problem?

(I know that until we got focused on this, and people focused on
reporting it, that maybe it was happening in releases I'd otherwise
considered to be "pretty good"... so please report in on your "best"
releases this year...)

Worst case we can step back to that kernel for a while and proceed forward
on all the other stuff. I know I crave stability at this point, and I'm
unhappy that everyone here is unhappy, too...

Regrettably since losing my lab I have not been in a position to easily
test wifi to any huge extent. I'm slowly building that up (but for example
no longer have a mac to test with)


On Thu, Apr 3, 2014 at 11:20 AM, Neil Shepperd <nshepperd@gmail.com> wrote:
> I just flashed 3.10.34-4 to my new WNDR3800 and experienced the exact
> wifi hang described by Toke Høiland-Jørgensen. But I'm on the 2.4GHz
> network (with guest and babel disabled). Unfortunately I didn't think to
> try tracing anything from the router side before resetting the wireless.

cool you disabled guest and babel. So far we've sort of ruled out
6in4 tunnelling, and syn flood protection.

Sounds like you are going to stick with -4 for a bit?

what I've been doing is mounting a usb stick, and just running continuously
on the stick

tcpdump -s 128 -i ge00 -w ge00.cap &
tcpdump -s 128 -i sw00 -w sw00.cap &

This definately hurts performance...

And it's probably time to do a tcpdump on the connected device as well.

In terms of other diags... (any suggestions?)

> Syslog was filled with a lot of
>
> DHCPDISCOVER(sw00) [MAYBE IP] [MAC ADDRESS]
> DHCPOFFER(sw00) [IP] [MAC ADDRESS]

Hmm. OK, this brings back the device driver into the equation... I
WAS seeing dhcp and arp requests "getting through" from the captures,
and it seemed like arp in particular was getting through...

>
> but the offers aren't being received at my laptop.
>
> Just another data point I guess.

Well, I'd hoped it would be a confirming one rather than one opening
up more questions.

> Neil
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] cerowrt-3.10.34-4 dev build released

[Maxim Kharlamov]

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

The last release without wifi issues was 3.8.something (I think it was
called Berlin). The whole 3.10.x branch seems to have broken wifi (will see
how 3.10.24-4 goes, it seems OK, but it's been working less than 24hours
yet).
I'm using only 2.4Ghz (5Ghz dead in the water - devices couldn't connect at
all, so I disabled it). Guest and babel disabled.


Regards,
Max


On Fri, Apr 4, 2014 at 11:36 AM, Dave Taht <dave.taht@gmail.com> wrote:

> Is there a recent version that people had that was seemingly stable for
> wifi that we could step back to and bisect from? Something where
> you had heavy wifu use for week(s) without a problem?
>
> (I know that until we got focused on this, and people focused on
> reporting it, that maybe it was happening in releases I'd otherwise
> considered to be "pretty good"... so please report in on your "best"
> releases this year...)
>
> Worst case we can step back to that kernel for a while and proceed forward
> on all the other stuff. I know I crave stability at this point, and I'm
> unhappy that everyone here is unhappy, too...
>
> Regrettably since losing my lab I have not been in a position to easily
> test wifi to any huge extent. I'm slowly building that up (but for example
> no longer have a mac to test with)
>
>
> On Thu, Apr 3, 2014 at 11:20 AM, Neil Shepperd <nshepperd@gmail.com>
> wrote:
> > I just flashed 3.10.34-4 to my new WNDR3800 and experienced the exact
> > wifi hang described by Toke Høiland-Jørgensen. But I'm on the 2.4GHz
> > network (with guest and babel disabled). Unfortunately I didn't think to
> > try tracing anything from the router side before resetting the wireless.
>
> cool you disabled guest and babel. So far we've sort of ruled out
> 6in4 tunnelling, and syn flood protection.
>
> Sounds like you are going to stick with -4 for a bit?
>
> what I've been doing is mounting a usb stick, and just running continuously
> on the stick
>
> tcpdump -s 128 -i ge00 -w ge00.cap &
> tcpdump -s 128 -i sw00 -w sw00.cap &
>
> This definately hurts performance...
>
> And it's probably time to do a tcpdump on the connected device as well.
>
> In terms of other diags... (any suggestions?)
>
> > Syslog was filled with a lot of
> >
> > DHCPDISCOVER(sw00) [MAYBE IP] [MAC ADDRESS]
> > DHCPOFFER(sw00) [IP] [MAC ADDRESS]
>
> Hmm. OK, this brings back the device driver into the equation... I
> WAS seeing dhcp and arp requests "getting through" from the captures,
> and it seemed like arp in particular was getting through...
>
> >
> > but the offers aren't being received at my laptop.
> >
> > Just another data point I guess.
>
> Well, I'd hoped it would be a confirming one rather than one opening
> up more questions.
>
> > Neil
> > _______________________________________________
> > Cerowrt-devel mailing list
> > Cerowrt-devel@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>
>
> --
> Dave Täht
>
> Fixing bufferbloat with cerowrt:
> http://www.teklibre.com/cerowrt/subscribe.html
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>

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

Re: [Cerowrt-devel] cerowrt-3.10.34-4 dev build released

[Dave Taht]

For starters, let me suggest commenting out the multicast_rate parameter
from /etc/config/wireless and rebooting. Given an issue with dhcp
reported earlier today, that an issue with multicast.


On Thu, Apr 3, 2014 at 3:51 PM, Maxim Kharlamov <mcs@podsolnuh.biz> wrote:
> The last release without wifi issues was 3.8.something (I think it was
> called Berlin). The whole 3.10.x branch seems to have broken wifi (will see
> how 3.10.24-4 goes, it seems OK, but it's been working less than 24hours
> yet).
> I'm using only 2.4Ghz (5Ghz dead in the water - devices couldn't connect at
> all, so I disabled it). Guest and babel disabled.
>
>
> Regards,
> Max
>
>
> On Fri, Apr 4, 2014 at 11:36 AM, Dave Taht <dave.taht@gmail.com> wrote:
>>
>> Is there a recent version that people had that was seemingly stable for
>> wifi that we could step back to and bisect from? Something where
>> you had heavy wifu use for week(s) without a problem?
>>
>> (I know that until we got focused on this, and people focused on
>> reporting it, that maybe it was happening in releases I'd otherwise
>> considered to be "pretty good"... so please report in on your "best"
>> releases this year...)
>>
>> Worst case we can step back to that kernel for a while and proceed forward
>> on all the other stuff. I know I crave stability at this point, and I'm
>> unhappy that everyone here is unhappy, too...
>>
>> Regrettably since losing my lab I have not been in a position to easily
>> test wifi to any huge extent. I'm slowly building that up (but for example
>> no longer have a mac to test with)
>>
>>
>> On Thu, Apr 3, 2014 at 11:20 AM, Neil Shepperd <nshepperd@gmail.com>
>> wrote:
>> > I just flashed 3.10.34-4 to my new WNDR3800 and experienced the exact
>> > wifi hang described by Toke Høiland-Jørgensen. But I'm on the 2.4GHz
>> > network (with guest and babel disabled). Unfortunately I didn't think to
>> > try tracing anything from the router side before resetting the wireless.
>>
>> cool you disabled guest and babel. So far we've sort of ruled out
>> 6in4 tunnelling, and syn flood protection.
>>
>> Sounds like you are going to stick with -4 for a bit?
>>
>> what I've been doing is mounting a usb stick, and just running
>> continuously
>> on the stick
>>
>> tcpdump -s 128 -i ge00 -w ge00.cap &
>> tcpdump -s 128 -i sw00 -w sw00.cap &
>>
>> This definately hurts performance...
>>
>> And it's probably time to do a tcpdump on the connected device as well.
>>
>> In terms of other diags... (any suggestions?)
>>
>> > Syslog was filled with a lot of
>> >
>> > DHCPDISCOVER(sw00) [MAYBE IP] [MAC ADDRESS]
>> > DHCPOFFER(sw00) [IP] [MAC ADDRESS]
>>
>> Hmm. OK, this brings back the device driver into the equation... I
>> WAS seeing dhcp and arp requests "getting through" from the captures,
>> and it seemed like arp in particular was getting through...
>>
>> >
>> > but the offers aren't being received at my laptop.
>> >
>> > Just another data point I guess.
>>
>> Well, I'd hoped it would be a confirming one rather than one opening
>> up more questions.
>>
>> > Neil
>> > _______________________________________________
>> > Cerowrt-devel mailing list
>> > Cerowrt-devel@lists.bufferbloat.net
>> > https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>
>>
>>
>> --
>> Dave Täht
>>
>> Fixing bufferbloat with cerowrt:
>> http://www.teklibre.com/cerowrt/subscribe.html
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] cerowrt-3.10.34-4 dev build released

[Aaron Wood]

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

Up for 10 days on 3.10.32-12 (WNDR3800).  Only have 2 devices that run
2.4GHz, and it's only seen 2GB of traffic on SW00 in that time...  The 5GHz
radio has had >5GB of traffic on it in the same time.  No problems at all.

-Aaron


On Fri, Apr 4, 2014 at 12:51 AM, Maxim Kharlamov <mcs@podsolnuh.biz> wrote:

> The last release without wifi issues was 3.8.something (I think it was
> called Berlin). The whole 3.10.x branch seems to have broken wifi (will see
> how 3.10.24-4 goes, it seems OK, but it's been working less than 24hours
> yet).
> I'm using only 2.4Ghz (5Ghz dead in the water - devices couldn't connect
> at all, so I disabled it). Guest and babel disabled.
>
>
> Regards,
> Max
>
>
> On Fri, Apr 4, 2014 at 11:36 AM, Dave Taht <dave.taht@gmail.com> wrote:
>
>> Is there a recent version that people had that was seemingly stable for
>> wifi that we could step back to and bisect from? Something where
>> you had heavy wifu use for week(s) without a problem?
>>
>> (I know that until we got focused on this, and people focused on
>> reporting it, that maybe it was happening in releases I'd otherwise
>> considered to be "pretty good"... so please report in on your "best"
>> releases this year...)
>>
>> Worst case we can step back to that kernel for a while and proceed forward
>> on all the other stuff. I know I crave stability at this point, and I'm
>> unhappy that everyone here is unhappy, too...
>>
>> Regrettably since losing my lab I have not been in a position to easily
>> test wifi to any huge extent. I'm slowly building that up (but for example
>> no longer have a mac to test with)
>>
>>
>> On Thu, Apr 3, 2014 at 11:20 AM, Neil Shepperd <nshepperd@gmail.com>
>> wrote:
>> > I just flashed 3.10.34-4 to my new WNDR3800 and experienced the exact
>> > wifi hang described by Toke Høiland-Jørgensen. But I'm on the 2.4GHz
>> > network (with guest and babel disabled). Unfortunately I didn't think to
>> > try tracing anything from the router side before resetting the wireless.
>>
>> cool you disabled guest and babel. So far we've sort of ruled out
>> 6in4 tunnelling, and syn flood protection.
>>
>> Sounds like you are going to stick with -4 for a bit?
>>
>> what I've been doing is mounting a usb stick, and just running
>> continuously
>> on the stick
>>
>> tcpdump -s 128 -i ge00 -w ge00.cap &
>> tcpdump -s 128 -i sw00 -w sw00.cap &
>>
>> This definately hurts performance...
>>
>> And it's probably time to do a tcpdump on the connected device as well.
>>
>> In terms of other diags... (any suggestions?)
>>
>> > Syslog was filled with a lot of
>> >
>> > DHCPDISCOVER(sw00) [MAYBE IP] [MAC ADDRESS]
>> > DHCPOFFER(sw00) [IP] [MAC ADDRESS]
>>
>> Hmm. OK, this brings back the device driver into the equation... I
>> WAS seeing dhcp and arp requests "getting through" from the captures,
>> and it seemed like arp in particular was getting through...
>>
>> >
>> > but the offers aren't being received at my laptop.
>> >
>> > Just another data point I guess.
>>
>> Well, I'd hoped it would be a confirming one rather than one opening
>> up more questions.
>>
>> > Neil
>> > _______________________________________________
>> > Cerowrt-devel mailing list
>> > Cerowrt-devel@lists.bufferbloat.net
>> > https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>
>>
>>
>> --
>> Dave Täht
>>
>> Fixing bufferbloat with cerowrt:
>> http://www.teklibre.com/cerowrt/subscribe.html
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>
>
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>

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

Re: [Cerowrt-devel] cerowrt-3.10.34-4 dev build released

[Aaron Wood]

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

On Fri, Apr 4, 2014 at 12:56 AM, Aaron Wood <woody77@gmail.com> wrote:

> Up for 10 days on 3.10.32-12 (WNDR3800).  Only have 2 devices that run
> 2.4GHz, and it's only seen 2GB of traffic on SW00 in that time...  The 5GHz
> radio has had >5GB of traffic on it in the same time.  No problems at all.
>

And I also have both 2.4 and 5GHz babel and guest SSIDs all turned off.

-Aaron

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

Re: [Cerowrt-devel] cerowrt-3.10.34-4 dev build released

[Dave Taht]

On Thu, Apr 3, 2014 at 3:57 PM, Aaron Wood <woody77@gmail.com> wrote:
> On Fri, Apr 4, 2014 at 12:56 AM, Aaron Wood <woody77@gmail.com> wrote:
>>
>> Up for 10 days on 3.10.32-12 (WNDR3800).  Only have 2 devices that run
>> 2.4GHz, and it's only seen 2GB of traffic on SW00 in that time...  The 5GHz
>> radio has had >5GB of traffic on it in the same time.  No problems at all.
>
>
> And I also have both 2.4 and 5GHz babel and guest SSIDs all turned off.
>
> -Aaron

Your clients are?

So far there seems to be a significant trend towards osx being an issue...


-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] cerowrt-3.10.34-4 dev build released

[Maxim Kharlamov]

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

Clients: two android devices (Google Nexus 5 and SGS3), one Arch Linux
laptop, iPad, MacBook Pro (from time to time).


Regards,
Max


On Fri, Apr 4, 2014 at 11:58 AM, Dave Taht <dave.taht@gmail.com> wrote:

> On Thu, Apr 3, 2014 at 3:57 PM, Aaron Wood <woody77@gmail.com> wrote:
> > On Fri, Apr 4, 2014 at 12:56 AM, Aaron Wood <woody77@gmail.com> wrote:
> >>
> >> Up for 10 days on 3.10.32-12 (WNDR3800).  Only have 2 devices that run
> >> 2.4GHz, and it's only seen 2GB of traffic on SW00 in that time...  The
> 5GHz
> >> radio has had >5GB of traffic on it in the same time.  No problems at
> all.
> >
> >
> > And I also have both 2.4 and 5GHz babel and guest SSIDs all turned off.
> >
> > -Aaron
>
> Your clients are?
>
> So far there seems to be a significant trend towards osx being an issue...
>
>
> --
> Dave Täht
>
> Fixing bufferbloat with cerowrt:
> http://www.teklibre.com/cerowrt/subscribe.html
>

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

Re: [Cerowrt-devel] cerowrt-3.10.34-4 dev build released

[David Personette]

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

I have an OSX laptop on 5ghz, a Linux desktop and server via ethernet,
Linux Laptop via 5gz, Roku via 5gz, Nexus 7 via 5gz, and misc other
devices... I didn't get my total bandwidth on 3.10.32-12, 3.10.34-1, but
I've done 3.3GB down 0.9GB up since flashing 3.10.34-4. I've had no
problems on any of those builds. It's been rock solid for me. I work from
home two days a week (Tues and Thurs), wireless connection via my work OSX
laptop. Since the 3.10.x series, I've noticed that WiFi has been noticeably
faster. If there is a roll-back of the kernel, would it be possible to have
a fork still with the latest kernel too... otherwise how will it be known
when the issue is fixed, sorry to be a PitA.

-- 
David P.



On Thu, Apr 3, 2014 at 7:01 PM, Maxim Kharlamov <mcs@podsolnuh.biz> wrote:

> Clients: two android devices (Google Nexus 5 and SGS3), one Arch Linux
> laptop, iPad, MacBook Pro (from time to time).
>
>
> Regards,
> Max
>
>
> On Fri, Apr 4, 2014 at 11:58 AM, Dave Taht <dave.taht@gmail.com> wrote:
>
>> On Thu, Apr 3, 2014 at 3:57 PM, Aaron Wood <woody77@gmail.com> wrote:
>> > On Fri, Apr 4, 2014 at 12:56 AM, Aaron Wood <woody77@gmail.com> wrote:
>> >>
>> >> Up for 10 days on 3.10.32-12 (WNDR3800).  Only have 2 devices that run
>> >> 2.4GHz, and it's only seen 2GB of traffic on SW00 in that time...  The
>> 5GHz
>> >> radio has had >5GB of traffic on it in the same time.  No problems at
>> all.
>> >
>> >
>> > And I also have both 2.4 and 5GHz babel and guest SSIDs all turned off.
>> >
>> > -Aaron
>>
>> Your clients are?
>>
>> So far there seems to be a significant trend towards osx being an issue...
>>
>>
>> --
>> Dave Täht
>>
>> Fixing bufferbloat with cerowrt:
>> http://www.teklibre.com/cerowrt/subscribe.html
>>
>
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>

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

Re: [Cerowrt-devel] cerowrt-3.10.34-4 dev build released

[Aaron Wood]

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

On Fri, Apr 4, 2014 at 12:58 AM, Dave Taht <dave.taht@gmail.com> wrote:

> On Thu, Apr 3, 2014 at 3:57 PM, Aaron Wood <woody77@gmail.com> wrote:
> > On Fri, Apr 4, 2014 at 12:56 AM, Aaron Wood <woody77@gmail.com> wrote:
> >>
> >> Up for 10 days on 3.10.32-12 (WNDR3800).  Only have 2 devices that run
> >> 2.4GHz, and it's only seen 2GB of traffic on SW00 in that time...  The
> 5GHz
> >> radio has had >5GB of traffic on it in the same time.  No problems at
> all.
> >
> >
> > And I also have both 2.4 and 5GHz babel and guest SSIDs all turned off.
> >
> > -Aaron
>
> Your clients are?
>
> So far there seems to be a significant trend towards osx being an issue...


iOS 7 (a pair of iPhone 4's).  Everything that supports 5GHz is using 5GHz.

-Aaron

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

Re: [Cerowrt-devel] cerowrt-3.10.34-4 dev build released

[Toke Høiland-Jørgensen]

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

Dave Taht <dave.taht@gmail.com> writes:

> Is there a recent version that people had that was seemingly stable for
> wifi that we could step back to and bisect from? Something where
> you had heavy wifu use for week(s) without a problem?

FWIW I haven't seen the issue I had again. Am currently at just under 6
days of uptime, and ~14 gigs transferred out the 5ghz wifi with no
issues. Still on the same build (derived 3.10.32-12) that I had the
problem with before...

Will upgrade to HEAD over the weekend.

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [Cerowrt-devel] cerowrt-3.10.34-4 dev build released

[Neil Shepperd]

> Sounds like you are going to stick with -4 for a bit?

Actually, this is the first time I've tried cerowrt on a router. But
yeah, I'll stick with the current version unless you come out with a new
patch to try.

> what I've been doing is mounting a usb stick, and just running continuously
> on the stick
> 
> tcpdump -s 128 -i ge00 -w ge00.cap &
> tcpdump -s 128 -i sw00 -w sw00.cap &
> 
> This definately hurts performance...
> 
> And it's probably time to do a tcpdump on the connected device as well.
> 

Update: I did this, and experienced the hang again. A first look at the
tcpdump output on sw00 shows a sudden reduction in traffic at 20:40:54,
so I assume that's probably the time of the event. After that, I see
many DHCP and ARP requests arriving, but no responses leaving the interface.

In fact, I don't see anything leaving except, oddly, some DNS responses
(which are indeed received by my laptop). I also see some EAPOL stuff on
both the router and laptop at roughly the same time, so I guess that's
getting through, but I don't know the direction.

I think next time I'll try with -Pin/-Pout to separate incoming and
outgoing packets properly...

> Hmm. OK, this brings back the device driver into the equation... I
> WAS seeing dhcp and arp requests "getting through" from the captures,
> and it seemed like arp in particular was getting through...

So I guess this is only half right? What I see in syslog is dnsmasq
saying it has sent a packet, but it doesn't make it onto the interface.
Apart from DNS packets, so I don't know what to make of that.

Neil

Re: [Cerowrt-devel] cerowrt-3.10.34-4 dev build released

[Dave Taht]

On Sat, Apr 5, 2014 at 5:49 AM, Neil Shepperd <nshepperd@gmail.com> wrote:
>> Sounds like you are going to stick with -4 for a bit?
>
> Actually, this is the first time I've tried cerowrt on a router. But
> yeah, I'll stick with the current version unless you come out with a new
> patch to try.

Thx. I am hoping this is the *last* priority 1 bug cerowrt has.

but_fixing_it_is_going_to_be_pita.

I_confess_to_"embedded_fatigue".

>> what I've been doing is mounting a usb stick, and just running continuously
>> on the stick
>>
>> tcpdump -s 128 -i ge00 -w ge00.cap &
>> tcpdump -s 128 -i sw00 -w sw00.cap &
>>
>> This definately hurts performance...
>>
>> And it's probably time to do a tcpdump on the connected device as well.
>>
>
> Update: I did this, and experienced the hang again. A first look at the
> tcpdump output on sw00 shows a sudden reduction in traffic at 20:40:54,
> so I assume that's probably the time of the event. After that, I see
> many DHCP and ARP requests arriving, but no responses leaving the interface.

It_would_be_nice_to_see_10sec_of_these_captures_before_and_after.

>
> In fact, I don't see anything leaving except, oddly, some DNS responses
> (which are indeed received by my laptop). I also see some EAPOL stuff on
> both the router and laptop at roughly the same time, so I guess that's
> getting through, but I don't know the direction.
>
> I think next time I'll try with -Pin/-Pout to separate incoming and
> outgoing packets properly...

Tis easier_to_sort_in_wireshark_against_one_capture,IMHO.

I_have_been_looking_for_failed_syn_attempts_and_retries_as_a_key_indicator
that_something_Bad_happened.

>> Hmm. OK, this brings back the device driver into the equation... I
>> WAS seeing dhcp and arp requests "getting through" from the captures,
>> and it seemed like arp in particular was getting through...
>
> So I guess this is only half right? What I see in syslog is dnsmasq
> saying it has sent a packet, but it doesn't make it onto the interface.
> Apart from DNS packets, so I don't know what to make of that.

It_is_possible_there_are_a_variety_of_failure_modes.

I_am_not_entirely_convinced_this_is_actually_a_wifi_specific_failure.

can_you_try_ssh_to_the_router_during_a_failure,and/or_accessing
the_web_admin_interface?and/or_trying_to

if_you_are_not_using_babel_disable_it.It_makes_a_lot_of_updates
to_the_routing_table.that_might_be_malfunctioning..

(I_really_need_a_keyboard_that_recovers_from_damp_weather.)

> Neil



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] cerowrt-3.10.34-4 dev build released

[Dave Taht]

In_trying_to_sort_out_the_differences_between_the_people
working_wifi_for_long_periods,vs_those_without...

I_am_curious_if_your_country
code_is_set,and_what_it_is_set_to,and_your_wifi_channel_set

It_is_long_past_time_we_start_up_a_formal_bug_for_this,
but_I'll_wait_for_my_spacebar.

In_a_known_pretty_good_case:

root@lorna-gw:~# cat /etc/openwrt_release
DISTRIB_ID="CeroWrt"
DISTRIB_RELEASE="3.10.32-9"
DISTRIB_REVISION="r39917"
DISTRIB_CODENAME="toronto"
DISTRIB_TARGET="ar71xx/generic"
DISTRIB_DESCRIPTION="CeroWrt Toronto 3.10.32-9"
DISTRIB_TAINTS="no-all busybox"

root@lorna-gw:~# uptime
 16:07:37 up 21 days, 21:35,  load average: 0.00, 0.01, 0.04

root@lorna-gw:~# egrep -i "country|channel|htmode" /etc/config/wireless
    option channel  11
    option htmode    HT20
    option channel '44'
    option htmode    HT40+
    option country 'US'


On Sat, Apr 5, 2014 at 9:02 AM, Dave Taht <dave.taht@gmail.com> wrote:
> On Sat, Apr 5, 2014 at 5:49 AM, Neil Shepperd <nshepperd@gmail.com> wrote:
>>> Sounds like you are going to stick with -4 for a bit?
>>
>> Actually, this is the first time I've tried cerowrt on a router. But
>> yeah, I'll stick with the current version unless you come out with a new
>> patch to try.
>
> Thx. I am hoping this is the *last* priority 1 bug cerowrt has.
>
> but_fixing_it_is_going_to_be_pita.
>
> I_confess_to_"embedded_fatigue".
>
>>> what I've been doing is mounting a usb stick, and just running continuously
>>> on the stick
>>>
>>> tcpdump -s 128 -i ge00 -w ge00.cap &
>>> tcpdump -s 128 -i sw00 -w sw00.cap &
>>>
>>> This definately hurts performance...
>>>
>>> And it's probably time to do a tcpdump on the connected device as well.
>>>
>>
>> Update: I did this, and experienced the hang again. A first look at the
>> tcpdump output on sw00 shows a sudden reduction in traffic at 20:40:54,
>> so I assume that's probably the time of the event. After that, I see
>> many DHCP and ARP requests arriving, but no responses leaving the interface.
>
> It_would_be_nice_to_see_10sec_of_these_captures_before_and_after.
>
>>
>> In fact, I don't see anything leaving except, oddly, some DNS responses
>> (which are indeed received by my laptop). I also see some EAPOL stuff on
>> both the router and laptop at roughly the same time, so I guess that's
>> getting through, but I don't know the direction.
>>
>> I think next time I'll try with -Pin/-Pout to separate incoming and
>> outgoing packets properly...
>
> Tis easier_to_sort_in_wireshark_against_one_capture,IMHO.
>
> I_have_been_looking_for_failed_syn_attempts_and_retries_as_a_key_indicator
> that_something_Bad_happened.
>
>>> Hmm. OK, this brings back the device driver into the equation... I
>>> WAS seeing dhcp and arp requests "getting through" from the captures,
>>> and it seemed like arp in particular was getting through...
>>
>> So I guess this is only half right? What I see in syslog is dnsmasq
>> saying it has sent a packet, but it doesn't make it onto the interface.
>> Apart from DNS packets, so I don't know what to make of that.
>
> It_is_possible_there_are_a_variety_of_failure_modes.
>
> I_am_not_entirely_convinced_this_is_actually_a_wifi_specific_failure.
>
> can_you_try_ssh_to_the_router_during_a_failure,and/or_accessing
> the_web_admin_interface?and/or_trying_to
>
> if_you_are_not_using_babel_disable_it.It_makes_a_lot_of_updates
> to_the_routing_table.that_might_be_malfunctioning..
>
> (I_really_need_a_keyboard_that_recovers_from_damp_weather.)
>
>> Neil
>
>
>
> --
> Dave Täht
>
> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] cerowrt-3.10.34-4 dev build released

[Török Edwin]

Hi,

On 04/03/2014 04:17 AM, Dave Taht wrote:> + resync with openwrt
>    they seem to be settling down...
> + Toke's ntp + dnssec stuff
> + Yet Another Patch to try and isolate the wireless hang problem
>     that happens to jg every day or so and nearly no-one else.
> + Fix to babel's meshing interfaces
> + dnsmasq updated to head (seems to be stabilizing)
> + Tested for a couple hours

Just upgraded to 3.10.34-4, works great!

On 03/21/2014 07:47 PM, Dave Taht wrote:
> + This is the first release with toke's bcp38 code installed (and
> enabled by default). I am hoping people simply don't even notice it's
> there... (it's off the firewall web page)

I just tested BCP38, but it looks like it doesn't filter anything with PPPoE.
My outgoing interface is actually called pppoe-ge00, so adding filter rules on ge00 doesn't have any impact.

I hacked the script to set the interface name for iptables to pppoe-ge00 (not for uci, cause uci
doesn't have an enabled=1 for pppoe):
                setup_ipset
+               interface=pppoe-ge00
                setup_iptables "$interface"

Any idea how to fix this properly without hardcoding the interface name?

With this hack the bcp38 filtering works (10.0.0.1 is the P-t-P address on pppoe-ge00):
# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
ping: sendto: Operation not permitted

# ipset list
Name: bcp38-ipv4
Type: hash:net
Revision: 4
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 8856
References: 2
Members:
127.0.0.0/8
192.0.2.0/24
203.0.113.0/24
0.0.0.0/8
192.168.0.0/16
198.51.100.0/24
169.254.0.0/16
10.0.0.0/8
10.0.0.1 nomatch
172.16.0.0/12
240.0.0.0/4


FWIW this is how my /etc/config/network entry looks like for PPPoE:
config interface 'ge00'
        option ifname 'ge00'
        option _orig_ifname 'ge00'
        option _orig_bridge 'false'
        option proto 'pppoe'
        option username '<user>'
        option password '<pass>'
        option ipv6 '1'

Best regards,
--Edwin

Re: [Cerowrt-devel] cerowrt-3.10.34-4 dev build released

[Dave Taht]

On Sat, Apr 5, 2014 at 1:34 AM, Török Edwin <edwin+ml-cerowrt@etorok.net> wrote:
> Hi,
>
> On 04/03/2014 04:17 AM, Dave Taht wrote:> + resync with openwrt
>>    they seem to be settling down...
>> + Toke's ntp + dnssec stuff
>> + Yet Another Patch to try and isolate the wireless hang problem
>>     that happens to jg every day or so and nearly no-one else.
>> + Fix to babel's meshing interfaces
>> + dnsmasq updated to head (seems to be stabilizing)
>> + Tested for a couple hours
>
> Just upgraded to 3.10.34-4, works great!
>
> On 03/21/2014 07:47 PM, Dave Taht wrote:
>> + This is the first release with toke's bcp38 code installed (and
>> enabled by default). I am hoping people simply don't even notice it's
>> there... (it's off the firewall web page)
>
> I just tested BCP38, but it looks like it doesn't filter anything with PPPoE.
> My outgoing interface is actually called pppoe-ge00, so adding filter rules on ge00 doesn't have any impact.
>
> I hacked the script to set the interface name for iptables to pppoe-ge00 (not for uci, cause uci
> doesn't have an enabled=1 for pppoe):
>                 setup_ipset
> +               interface=pppoe-ge00
>                 setup_iptables "$interface"
>
> Any idea how to fix this properly without hardcoding the interface name?
>
> With this hack the bcp38 filtering works (10.0.0.1 is the P-t-P address on pppoe-ge00):
> # ping 192.168.1.1
> PING 192.168.1.1 (192.168.1.1): 56 data bytes
> ping: sendto: Operation not permitted
>
> # ipset list
> Name: bcp38-ipv4
> Type: hash:net
> Revision: 4
> Header: family inet hashsize 1024 maxelem 65536
> Size in memory: 8856
> References: 2
> Members:
> 127.0.0.0/8
> 192.0.2.0/24
> 203.0.113.0/24
> 0.0.0.0/8
> 192.168.0.0/16
> 198.51.100.0/24
> 169.254.0.0/16
> 10.0.0.0/8
> 10.0.0.1 nomatch
> 172.16.0.0/12
> 240.0.0.0/4
>
>
> FWIW this is how my /etc/config/network entry looks like for PPPoE:
> config interface 'ge00'
>         option ifname 'ge00'
>         option _orig_ifname 'ge00'
>         option _orig_bridge 'false'
>         option proto 'pppoe'
>         option username '<user>'
>         option password '<pass>'
>         option ipv6 '1'
>
> Best regards,
> --Edwin
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

I_have_no_spacebar_this_morning_(too_damp).

One_thought_had_been_to_hook_it_into_the_wan_firewall_chains.

another_would_be_to_more_deeply_inspect_the_interface_definition
and_"do_the_right_thing"_against_various_protos.

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] cerowrt-3.10.34-4 dev build released

[Török Edwin]

On 04/05/2014 06:53 PM, Dave Taht wrote:
> On Sat, Apr 5, 2014 at 1:34 AM, Török Edwin <edwin+ml-cerowrt@etorok.net> wrote:
>> I hacked the script to set the interface name for iptables to pppoe-ge00 (not for uci, cause uci
>> doesn't have an enabled=1 for pppoe):
>>                 setup_ipset
>> +               interface=pppoe-ge00
>>                 setup_iptables "$interface"
>>
>> Any idea how to fix this properly without hardcoding the interface name?
> 
> I_have_no_spacebar_this_morning_(too_damp).
> 
> One_thought_had_been_to_hook_it_into_the_wan_firewall_chains.
> 
> another_would_be_to_more_deeply_inspect_the_interface_definition
> and_"do_the_right_thing"_against_various_protos.
> 

Does this affect sqm-scripts too?
It only sets QoS classification on ge00, not pppoe-ge00. By the time the packets reach ge00, do they still have the QoS bits set?

Best regards,
--Edwin

Re: [Cerowrt-devel] cerowrt-3.10.34-4 dev build released

[Toke Høiland-Jørgensen]

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

Török Edwin <edwin+ml-cerowrt@etorok.net> writes:

> I hacked the script to set the interface name for iptables to pppoe-ge00 (not for uci, cause uci
> doesn't have an enabled=1 for pppoe):
>                 setup_ipset
> +               interface=pppoe-ge00
>                 setup_iptables "$interface"
>
> Any idea how to fix this properly without hardcoding the interface
> name?

Editing the config file by hand should be sufficient rather than having
to edit the script (it's in /etc/config/bcp38).

The interface selection box in the GUI does not show pppoe-ge00 as an
option?

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [Cerowrt-devel] cerowrt-3.10.34-4 dev build released

[Török Edwin]

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

On 04/07/2014 05:45 PM, Toke Høiland-Jørgensen wrote:
> Török Edwin <edwin+ml-cerowrt@etorok.net> writes:
> 
>> I hacked the script to set the interface name for iptables to pppoe-ge00 (not for uci, cause uci
>> doesn't have an enabled=1 for pppoe):
>>                 setup_ipset
>> +               interface=pppoe-ge00
>>                 setup_iptables "$interface"
>>
>> Any idea how to fix this properly without hardcoding the interface
>> name?
> 
> Editing the config file by hand should be sufficient rather than having
> to edit the script (it's in /etc/config/bcp38).

Thanks, that worked (both for /etc/config/bcp38 and /etc/config/sqm).
The netperf streams seem to be better separated with pppoe-ge00.png

> 
> The interface selection box in the GUI does not show pppoe-ge00 as an
> option?

It shows only @ge00, ge00, and se00, and selecting the @ge00 doesn't help.

Best regardsm
--Edwin

[-- Attachment #2: ge00.png --]
[-- Type: image/png, Size: 228610 bytes --]

[-- Attachment #3: pppoe-ge00.png --]
[-- Type: image/png, Size: 206067 bytes --]

Re: [Cerowrt-devel] cerowrt-3.10.34-4 dev build released

[Toke Høiland-Jørgensen]

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

Török Edwin <edwin+ml-cerowrt@etorok.net> writes:

> Thanks, that worked (both for /etc/config/bcp38 and /etc/config/sqm).
> The netperf streams seem to be better separated with pppoe-ge00.png

Great!

> It shows only @ge00, ge00, and se00, and selecting the @ge00 doesn't
> help.

Hmm, probably need to find another way to extract the available
interface names, then. Or just hook into the firewall zones.

Will give it a shot when next I have the time for a hacking spree :)

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [Cerowrt-devel] cerowrt-3.10.34-4 dev build released

[Dave Taht]

On Mon, Apr 7, 2014 at 8:27 AM, Török Edwin <edwin+ml-cerowrt@etorok.net> wrote:
> On 04/07/2014 05:45 PM, Toke Høiland-Jørgensen wrote:
>> Török Edwin <edwin+ml-cerowrt@etorok.net> writes:
>>
>>> I hacked the script to set the interface name for iptables to pppoe-ge00 (not for uci, cause uci
>>> doesn't have an enabled=1 for pppoe):
>>>                 setup_ipset
>>> +               interface=pppoe-ge00
>>>                 setup_iptables "$interface"
>>>
>>> Any idea how to fix this properly without hardcoding the interface
>>> name?
>>
>> Editing the config file by hand should be sufficient rather than having
>> to edit the script (it's in /etc/config/bcp38).
>
> Thanks, that worked (both for /etc/config/bcp38 and /etc/config/sqm).
> The netperf streams seem to be better separated with pppoe-ge00.png

Um, er, I actually found the differences between these two graphs
quite puzzling, as the fq_codel tc filter is supposed to be able to
decode ppp frames and access the 5 tuple including the diffserv bits,
which seems to be happening in the sqm-over-ppp case but not the
sqm-over-normal-ethernet-with-encap-traffic case.

It may be that the iptables rules don't work right on encapsulated
traffic. :grump:

Did you use simple.qos in both cases?

It might be easier to see a difference in performance if you use a
closer server like demo.tohojo.dk.

This is the relevant bit from net/core/flow_dissector.c

        case __constant_htons(ETH_P_PPP_SES): {
                struct {
                        struct pppoe_hdr hdr;
                        __be16 proto;
                } *hdr, _hdr;
                hdr = skb_header_pointer(skb, nhoff, sizeof(_hdr), &_hdr);
                if (!hdr)
                        return false;
                proto = hdr->proto;
                nhoff += PPPOE_SES_HLEN;
                switch (proto) {
                case __constant_htons(PPP_IP):
                        goto ip;
                case __constant_htons(PPP_IPV6):
                        goto ipv6;
                default:
                        return false;
                }
        }

>
>>
>> The interface selection box in the GUI does not show pppoe-ge00 as an
>> option?
>
> It shows only @ge00, ge00, and se00, and selecting the @ge00 doesn't help.
>
> Best regardsm
> --Edwin
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>



-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article

Re: [Cerowrt-devel] cerowrt-3.10.34-4 dev build released

[Török Edwin]

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

On 04/07/2014 08:58 PM, Dave Taht wrote:
> On Mon, Apr 7, 2014 at 8:27 AM, Török Edwin <edwin+ml-cerowrt@etorok.net> wrote:
>> On 04/07/2014 05:45 PM, Toke Høiland-Jørgensen wrote:
>>> Török Edwin <edwin+ml-cerowrt@etorok.net> writes:
>>>
>>>> I hacked the script to set the interface name for iptables to pppoe-ge00 (not for uci, cause uci
>>>> doesn't have an enabled=1 for pppoe):
>>>>                 setup_ipset
>>>> +               interface=pppoe-ge00
>>>>                 setup_iptables "$interface"
>>>>
>>>> Any idea how to fix this properly without hardcoding the interface
>>>> name?
>>>
>>> Editing the config file by hand should be sufficient rather than having
>>> to edit the script (it's in /etc/config/bcp38).
>>
>> Thanks, that worked (both for /etc/config/bcp38 and /etc/config/sqm).
>> The netperf streams seem to be better separated with pppoe-ge00.png
> 
> Um, er, I actually found the differences between these two graphs
> quite puzzling, as the fq_codel tc filter is supposed to be able to
> decode ppp frames and access the 5 tuple including the diffserv bits,
> which seems to be happening in the sqm-over-ppp case but not the
> sqm-over-normal-ethernet-with-encap-traffic case.
> 
> It may be that the iptables rules don't work right on encapsulated
> traffic. :grump:
> 
> Did you use simple.qos in both cases?

Yes, and I've run this prior to running /usr/lib/sqm/run.sh to clear the old rules:

IFACE=pppoe-ge00 /usr/lib/sqm/stop.sh
IFACE=ge00 /usr/lib/sqm/stop.sh
vi /etc/config/sqm (change the interface line)
/usr/lib/sqm/run.sh
... run netperf-wrapper again

> 
> It might be easier to see a difference in performance if you use a
> closer server like demo.tohojo.dk.

Attached, the graphs are closer now, but so are the flows, is classification even working there?
Maybe I just have too much bandwidth there and not creating a bottleneck properly.

I tried using 1/10 of bandwidth, see _10th.png. The difference is much sharper, and pppoe-ge00_10th.png seems to be working, while ge00_!oth not.

> 
> This is the relevant bit from net/core/flow_dissector.c
> 
>         case __constant_htons(ETH_P_PPP_SES): {
>                 struct {
>                         struct pppoe_hdr hdr;
>                         __be16 proto;
>                 } *hdr, _hdr;
>                 hdr = skb_header_pointer(skb, nhoff, sizeof(_hdr), &_hdr);
>                 if (!hdr)
>                         return false;
>                 proto = hdr->proto;
>                 nhoff += PPPOE_SES_HLEN;
>                 switch (proto) {
>                 case __constant_htons(PPP_IP):
>                         goto ip;
>                 case __constant_htons(PPP_IPV6):
>                         goto ipv6;
>                 default:
>                         return false;
>                 }
>         }
> 

TBH I don't know how PPPoE is actually implemented, who does the encapsulation? The kernel or the user-space daemon?
Would a packet capture on ge00/pppoe-ge00 help while running something that sets QoS bits (I'm guessing SSH would be good for that)?

Thanks,
--Edwin

[-- Attachment #2: ge00.png --]
[-- Type: image/png, Size: 257302 bytes --]

[-- Attachment #3: pppoe-ge00.png --]
[-- Type: image/png, Size: 255549 bytes --]

[-- Attachment #4: ge00_10th.png --]
[-- Type: image/png, Size: 234196 bytes --]

[-- Attachment #5: pppoe-ge00_10th.png --]
[-- Type: image/png, Size: 216757 bytes --]

Re: [Cerowrt-devel] cerowrt-3.10.34-4 dev build released

[Jim Reisert AD1C]

Not the cleanest upgrade, for me at least.  It went something like this:

After doing a sysupgrade from 3.10.32-12, Windows file sharing across
the subnets was no longer working.  Referring to:

http://www.bufferbloat.net/projects/cerowrt/wiki/Sharing_Windows_Files_from_wired_to_wireless

I noticed that /etc/samba/smb.conf.template had been restored back to
its default.  I made the changes, rebooted a number of times, etc. but
still count not get samba working.

So I tried a "sysupgrade" back to 3.10.32-12, but same results.

I did a clean install of 3.10.34-4. with the same results.

I did a clean install of 3.10.32-12 with the same results.

I then ran across this correspondence between Dave and I from about a month ago:

"After installing Samba, we could not see the remote Windows file
  shares over the network, except by using the TCP/IP v4 numerical
   address. Suspecting it was a WINS problem, I changed the setting on
  both my network adapters (local and remote):

  <network adapter> | Properties
  Click on TCP/IPv4 and then on Properties
  Clicked Advanced button at the bottom, then go to the WINS tab

  I had "Enable NetBIOS over TCP/IP" checked on both computers. I
  changed this to the Default setting (use NetBIOS setting from the DHCP
  server).  After another reboot, the Windows networking was working by
  name."

My Windows network settings hadn't changed, so there was nothing to do here.

Bottom l line, I can access the wired network server from the wireless
machine by numerical IP address only, no longer by WINS address.

I did not try re-flashing all the way back to 3.10.26-7, the version
onto which I had originally made samba run (before upgrading to
3.10.32-9 etc.)

At this point I'm tempted to leave well enough alone, as I've already
re-configured the one application that talks to the network drive to
use the numerical IP address.


-- 
Jim Reisert AD1C, <jjreisert@alum.mit.edu>, http://www.ad1c.us

Re: [Cerowrt-devel] cerowrt-3.10.34-4 dev build released

[Dave Taht]

It would have helped to have a backup. As best I recall we'd had to
add 3 lines to the smb.conf.template file, notably

wins support = yes


On Sat, Apr 5, 2014 at 12:11 PM, Jim Reisert AD1C
<jjreisert@alum.mit.edu> wrote:
> Not the cleanest upgrade, for me at least.  It went something like this:
>
> After doing a sysupgrade from 3.10.32-12, Windows file sharing across
> the subnets was no longer working.  Referring to:
>
> http://www.bufferbloat.net/projects/cerowrt/wiki/Sharing_Windows_Files_from_wired_to_wireless
>
> I noticed that /etc/samba/smb.conf.template had been restored back to
> its default.  I made the changes, rebooted a number of times, etc. but
> still count not get samba working.
>
> So I tried a "sysupgrade" back to 3.10.32-12, but same results.
>
> I did a clean install of 3.10.34-4. with the same results.
>
> I did a clean install of 3.10.32-12 with the same results.
>
> I then ran across this correspondence between Dave and I from about a month ago:
>
> "After installing Samba, we could not see the remote Windows file
>   shares over the network, except by using the TCP/IP v4 numerical
>    address. Suspecting it was a WINS problem, I changed the setting on
>   both my network adapters (local and remote):
>
>   <network adapter> | Properties
>   Click on TCP/IPv4 and then on Properties
>   Clicked Advanced button at the bottom, then go to the WINS tab
>
>   I had "Enable NetBIOS over TCP/IP" checked on both computers. I
>   changed this to the Default setting (use NetBIOS setting from the DHCP
>   server).  After another reboot, the Windows networking was working by
>   name."
>
> My Windows network settings hadn't changed, so there was nothing to do here.
>
> Bottom l line, I can access the wired network server from the wireless
> machine by numerical IP address only, no longer by WINS address.
>
> I did not try re-flashing all the way back to 3.10.26-7, the version
> onto which I had originally made samba run (before upgrading to
> 3.10.32-9 etc.)
>
> At this point I'm tempted to leave well enough alone, as I've already
> re-configured the one application that talks to the network drive to
> use the numerical IP address.
>
>
> --
> Jim Reisert AD1C, <jjreisert@alum.mit.edu>, http://www.ad1c.us



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] cerowrt-3.10.34-4 dev build released

[Jim Reisert AD1C]

On Sat, Apr 5, 2014 at 1:26 PM, Dave Taht <dave.taht@gmail.com> wrote:

> It would have helped to have a backup.

Yup, hindsight is 50/50 [sic]

> As best I recall we'd had to add 3 lines to the smb.conf.template file, notably
>
> wins support = yes

Yup, did that.  Not working this time around.

Maybe I'll play around some more tomorrow.

-- 
Jim Reisert AD1C, <jjreisert@alum.mit.edu>, http://www.ad1c.us

Re: [Cerowrt-devel] cerowrt-3.10.34-4 dev build released

[Robert Bradley]

[-- Attachment #1.1: Type: text/plain, Size: 1193 bytes --]

On 06/04/2014 01:15, Jim Reisert AD1C wrote:
> On Sat, Apr 5, 2014 at 1:26 PM, Dave Taht <dave.taht@gmail.com> wrote:
>
>> It would have helped to have a backup.
> Yup, hindsight is 50/50 [sic]
>
>> As best I recall we'd had to add 3 lines to the smb.conf.template file, notably
>>
>> wins support = yes
> Yup, did that.  Not working this time around.
>
> Maybe I'll play around some more tomorrow.
>

I noticed last time that Samba tends to bind to localhost only on
CeroWRT, since no interface is set in /etc/config/samba.  For the
moment, you need to add "list interface <interface>" lines to
/etc/config/samba manually:

uci add_list samba.@samba[0].interface=se00
uci add_list samba.@samba[0].interface=sw00
uci add_list samba.@samba[0].interface=sw10
uci commit samba && /etc/init.d/samba restart

This limits Samba to the non-guest interfaces.  I think you should be
able to add interfaces from the GUI too but that seems to be missing
from CeroWRT and OpenWRT.  The attached patch adds it back in (cd /;
patch -p1 to apply it) to  and seems to work fine despite the Wiki at
http://wiki.openwrt.org/doc/uci/samba stating otherwise.

-- 
Robert Bradley


[-- Attachment #1.2: samba.patch --]
[-- Type: text/plain, Size: 810 bytes --]

--- rom/usr/lib/lua/luci/model/cbi/samba.lua
+++ overlay/usr/lib/lua/luci/model/cbi/samba.lua
@@ -28,6 +28,15 @@
         translate("Allow system users to reach their home directories via " ..
                 "network shares"))
 
+net = s:taboption("general", Value, "interface", translate("Served interfaces"))
+net.template = "cbi/network_netlist"
+net.widget   = "checkbox"
+net.nocreate = true
+
+function net.cfgvalue(self, section)
+        return m.uci:get("samba", section, "interfaces")
+                end
+
 tmpl = s:taboption("template", Value, "_tmpl",
 	translate("Edit the template that is used for generating the samba configuration."), 
 	translate("This is the content of the file '/etc/samba/smb.conf.template' from which your samba configuration will be generated. " ..

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]