[Cerowrt-devel] [Bug #442] wifi fails to transmit traffic after a few hours

[Cerowrt-devel] [Bug #442] wifi fails to transmit traffic after a few hours

[Dave Taht]

The  above  subject line and cc  will  get this conversation  into
the bug  tracker.


---------- Forwarded message ----------
From: Dave Taht <dave.taht@gmail.com>
Date: Sat, Apr 5, 2014 at 9:15 AM
Subject: Re: [Cerowrt-devel] cerowrt-3.10.34-4 dev build released
To: Neil Shepperd <nshepperd@gmail.com>
Cc: "cerowrt-devel@lists.bufferbloat.net" <cerowrt-devel@lists.bufferbloat.net>


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


-- 
Dave Täht

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

Re: [Cerowrt-devel] [Bug #442] wifi fails to transmit traffic after a few hours

[David Personette]

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

I assume that you wanted other people to report their status? Working here:

root@outpost:~# cat /etc/openwrt_release
DISTRIB_ID="CeroWrt"
DISTRIB_RELEASE="3.10.34-4"
DISTRIB_REVISION="r40361"
DISTRIB_CODENAME="toronto"
DISTRIB_TARGET="ar71xx/generic"
DISTRIB_DESCRIPTION="CeroWrt Toronto 3.10.34-4"
DISTRIB_TAINTS="no-all busybox"

root@outpost:~# uptime
 22:52:44 up 2 days, 11:16,  load average: 0.00, 0.01, 0.04

root@outpost:~# egrep -i "country|channel|htmode" /etc/config/wireless
    option channel  11
    option htmode    HT40-
    option channel  36
    option htmode    HT40+

-- 
David P.



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

> The  above  subject line and cc  will  get this conversation  into
> the bug  tracker.
>
>
> ---------- Forwarded message ----------
> From: Dave Taht <dave.taht@gmail.com>
> Date: Sat, Apr 5, 2014 at 9:15 AM
> Subject: Re: [Cerowrt-devel] cerowrt-3.10.34-4 dev build released
> To: Neil Shepperd <nshepperd@gmail.com>
> Cc: "cerowrt-devel@lists.bufferbloat.net" <
> cerowrt-devel@lists.bufferbloat.net>
>
>
> 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
>
>
> --
> 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: 7527 bytes --]

Re: [Cerowrt-devel] [Bug #442] wifi fails to transmit traffic after a few hours

[Chuck Anderson]

No problems here in the last couple hours with 3.10.36-1.  I only have
one client associated at 2.4 GHz.  I watched a bunch of Youtube videos
without problems.  I got my HE IPv6 tunnel configured and working
(still no native IPv6 AFAICT on Comcast in the Boston 'burbs).

Should I be using dnsmasq-dhcpv6 or is odhcpd the appropriate default?
I'm confused about the choices/terminology of various DHCP server and
client options in CeroWRT.  I believe my clients are just using SLAAC,
but eventually I would like to use DHCPv6 (if required) and get
dual-stack DDNS working as part of the solution to the following
problem.

One of the biggest reasons I haven't moved my entire LAN over to
CeroWRT yet is that I'm currently using DHCP IP reservations in
NetGear's firmwware and hostnames via manually distributed /etc/hosts
files to communicate with my various devices.  It is a big pain to
have to set up new IP reservations in CeroWRT and /etc/hosts with the
new 172.30.42 IP block, and then worry about having to switch
everything back to the old 192.168 network if it breaks.

 1473 root      1172 S    /usr/sbin/odhcpd
22447 root      1400 S    udhcpc -p /var/run/udhcpc-ge00.pid -s /lib/netifd/dhcp.script -f -t 0 -i ge00 -C
22723 root       820 S    odhcp6c -s /lib/netifd/dhcpv6.script -P60 ge00
1473 root      1172 S    /usr/sbin/odhcpd
 1793 root      1376 S    /usr/sbin/pimd -f
 1857 nobody    2128 S    avahi-daemon: running [cerowrt-2.local]
 1922 root      1172 S    /usr/sbin/babeld -D -I /var/run/babeld.pid -L /dev/null -C interface se00 -C interface sw00 -C interface sw10 -C interface 
 1995 root      1120 S    /usr/sbin/ahcpd -i /var/lib/ahcp-unique-id -L /var/log/ahcpd.log -c /var/etc/ahcpd.conf gw01 gw11
 2046 root       800 S    /sbin/rngd -f -r /dev/urandom -W 4000 -t 30
 2059 root      1404 S    /usr/sbin/ntpd -n -S /usr/sbin/ntpd_record_stratum -l -p 0.openwrt.pool.ntp.org -p 1.openwrt.pool.ntp.org -p 2.openwrt.pool
 2070 root      1180 S    /usr/sbin/polipo -c /var/etc/polipo.conf
12660 nobody    2840 S    /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf -k --dnssec-no-timecheck
12666 root      2832 S    /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf -k --dnssec-no-timecheck
22217 root      1520 S    /sbin/netifd
22447 root      1400 S    udhcpc -p /var/run/udhcpc-ge00.pid -s /lib/netifd/dhcp.script -f -t 0 -i ge00 -C
22723 root       820 S    odhcp6c -s /lib/netifd/dhcpv6.script -P60 ge00
22947 root      1560 S    /usr/sbin/hostapd -P /var/run/wifi-phy0.pid -B /var/run/hostapd-phy0.conf
22970 root      1552 S    /usr/sbin/hostapd -P /var/run/wifi-phy1.pid -B /var/run/hostapd-phy1.conf

root@cerowrt:~# cat /etc/openwrt_release 
DISTRIB_ID="CeroWrt"
DISTRIB_RELEASE="3.10.36-1"
DISTRIB_REVISION="r40387"
DISTRIB_CODENAME="toronto"
DISTRIB_TARGET="ar71xx/generic"
DISTRIB_DESCRIPTION="CeroWrt Toronto 3.10.36-1"
DISTRIB_TAINTS="no-all busybox"
root@cerowrt:~# uptime
 19:30:59 up  2:33,  load average: 0.00, 0.01, 0.04
root@cerowrt:~# egrep -i "country|channel|htmode" /etc/config/wireless  
		option channel '11'
		option country 'US'
		option channel '36'
		option country 'US'
root@cerowrt:~# 

On Sat, Apr 05, 2014 at 06:55:33PM -0400, David Personette wrote:
> I assume that you wanted other people to report their status? Working here:
> 
> root@outpost:~# cat /etc/openwrt_release
> DISTRIB_ID="CeroWrt"
> DISTRIB_RELEASE="3.10.34-4"
> DISTRIB_REVISION="r40361"
> DISTRIB_CODENAME="toronto"
> DISTRIB_TARGET="ar71xx/generic"
> DISTRIB_DESCRIPTION="CeroWrt Toronto 3.10.34-4"
> DISTRIB_TAINTS="no-all busybox"
> 
> root@outpost:~# uptime
>  22:52:44 up 2 days, 11:16,  load average: 0.00, 0.01, 0.04
> 
> root@outpost:~# egrep -i "country|channel|htmode" /etc/config/wireless
>     option channel  11
>     option htmode    HT40-
>     option channel  36
>     option htmode    HT40+
> 
> -- 
> David P.
> 
> 
> 
> On Sat, Apr 5, 2014 at 12:33 PM, Dave Taht <dave.taht@gmail.com> wrote:
> 
> > The  above  subject line and cc  will  get this conversation  into
> > the bug  tracker.
> >
> >
> > ---------- Forwarded message ----------
> > From: Dave Taht <dave.taht@gmail.com>
> > Date: Sat, Apr 5, 2014 at 9:15 AM
> > Subject: Re: [Cerowrt-devel] cerowrt-3.10.34-4 dev build released
> > To: Neil Shepperd <nshepperd@gmail.com>
> > Cc: "cerowrt-devel@lists.bufferbloat.net" <
> > cerowrt-devel@lists.bufferbloat.net>
> >
> >
> > 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.)

Re: [Cerowrt-devel] [Bug #442] wifi fails to transmit traffic after a few hours

[Neil Shepperd]

Experiencing the bug every few days:

root@cerowrt:~# cat /etc/openwrt_release
DISTRIB_ID="CeroWrt"
DISTRIB_RELEASE="3.10.34-4"
DISTRIB_REVISION="r40361"
DISTRIB_CODENAME="toronto"
DISTRIB_TARGET="ar71xx/generic"
DISTRIB_DESCRIPTION="CeroWrt Toronto 3.10.34-4"
DISTRIB_TAINTS="no-all busybox"

root@cerowrt:~# uptime
 12:22:42 up 1 day, 18:37,  load average: 0.04, 0.04, 0.05

root@cerowrt:~# egrep -i "country|channel|htmode" /etc/config/wireless
        option htmode 'HT20'
        option country 'AU'
        option channel 'auto'
        option htmode 'HT20'
        option country 'AU'
        option channel 'auto'

>> It_would_be_nice_to_see_10sec_of_these_captures_before_and_after.

Uploaded at http://zlkj.in/files/wireshark/. I filtered the captures in
wireshark for frame.time > "April 5, 2014 20:40:44" which is about 10
seconds before the bug. wlan0.cap is the capture from my laptop. ppp.cap
is from the pppoe connection on ge00.

>> 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

I can ssh in and access the admin interface if I connect my laptop by an
ethernet cable. But during the failure, I can't access the admin
interface or the internet over sw00. After resetting sw00 by admin
interface on se00, I can connect over the wireless again.

>> if_you_are_not_using_babel_disable_it.It_makes_a_lot_of_updates
>> to_the_routing_table.that_might_be_malfunctioning..

I thought I disabled babel, but I'm still seeing babel packets in the
capture, so I guess disabling the "babel" networks on both radios in the
wifi tab is not enough.

Re: [Cerowrt-devel] [Bug #442] wifi fails to transmit traffic after a few hours

[Valdis.Kletnieks]

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

On Sat, 05 Apr 2014 09:33:45 -0700, Dave Taht said:
> The  above  subject line and cc  will  get this conversation  into
> the bug  tracker.

I've never managed to have the wifi lock up on my 3800.

root@bogon-gateway-1:~# cat /etc/openwrt_release
DISTRIB_ID="CeroWrt"
DISTRIB_RELEASE="3.10.36-1"
DISTRIB_REVISION="r40387"
DISTRIB_CODENAME="toronto"
DISTRIB_TARGET="ar71xx/generic"
DISTRIB_DESCRIPTION="CeroWrt Toronto 3.10.36-1"
DISTRIB_TAINTS="no-all busybox"
root@bogon-gateway-1:~# uptime
 20:53:11 up  3:05,  load average: 0.16, 0.30, 0.39
root@bogon-gateway-1:~#  egrep -i "country|channel|htmode" /etc/config/wireless
        option channel '11'
        option country 'US'
        option channel '36'
        option country 'US'

(Upstream to comcast is a nominal 10mbit down/2 mbit up)

root@bogon-gateway-1:~# sh ./betterspeedtest.sh -H netperf6.richb-hanover.com
Testing against netperf6.richb-hanover.com while pinging gstatic.com (60 seconds in each direction)
.............................................................
 Download:  7.66 Mbps
  Latency: (in msec, 61 pings, 0.00% packet loss)
      Min: 16.824 
    10pct: 20.281 
   Median: 24.838 
      Avg: 25.469 
    90pct: 30.937 
      Max: 37.476
.............................................................
   Upload:  2.21 Mbps
  Latency: (in msec, 61 pings, 0.00% packet loss)
      Min: 19.125 
    10pct: 21.770 
   Median: 26.363 
      Avg: 26.392 
    90pct: 30.478 
      Max: 34.852
root@bogon-gateway-1:~# sh ./betterspeedtest.sh -H netperf.richb-hanover.com
Testing against netperf.richb-hanover.com while pinging gstatic.com (60 seconds in each direction)
............................................................
 Download:  8.09 Mbps
  Latency: (in msec, 61 pings, 0.00% packet loss)
      Min: 17.153 
    10pct: 20.290 
   Median: 24.304 
      Avg: 24.855 
    90pct: 29.817 
      Max: 40.293
.............................................................
   Upload:  2.24 Mbps
  Latency: (in msec, 61 pings, 0.00% packet loss)
      Min: 21.306 
    10pct: 23.127 
   Median: 25.968 
      Avg: 26.374 
    90pct: 30.681 
      Max: 33.517


[-- Attachment #2: Type: application/pgp-signature, Size: 848 bytes --]