* [Cerowrt-devel] [Bug #442] wifi fails to transmit traffic after a few hours
@ 2014-04-05 16:33 Dave Taht
2014-04-05 22:55 ` David Personette
` (2 more replies)
0 siblings, 3 replies; 5+ messages in thread
From: Dave Taht @ 2014-04-05 16:33 UTC (permalink / raw)
To: cerowrt, cerowrt-devel
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Cerowrt-devel] [Bug #442] wifi fails to transmit traffic after a few hours 2014-04-05 16:33 [Cerowrt-devel] [Bug #442] wifi fails to transmit traffic after a few hours Dave Taht @ 2014-04-05 22:55 ` David Personette 2014-04-05 23:48 ` Chuck Anderson 2014-04-06 2:35 ` Neil Shepperd 2014-04-06 2:54 ` Valdis.Kletnieks 2 siblings, 1 reply; 5+ messages in thread From: David Personette @ 2014-04-05 22:55 UTC (permalink / raw) To: Dave Taht; +Cc: cerowrt, cerowrt-devel [-- 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 --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Cerowrt-devel] [Bug #442] wifi fails to transmit traffic after a few hours 2014-04-05 22:55 ` David Personette @ 2014-04-05 23:48 ` Chuck Anderson 0 siblings, 0 replies; 5+ messages in thread From: Chuck Anderson @ 2014-04-05 23:48 UTC (permalink / raw) To: cerowrt-devel 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.) ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Cerowrt-devel] [Bug #442] wifi fails to transmit traffic after a few hours 2014-04-05 16:33 [Cerowrt-devel] [Bug #442] wifi fails to transmit traffic after a few hours Dave Taht 2014-04-05 22:55 ` David Personette @ 2014-04-06 2:35 ` Neil Shepperd 2014-04-06 2:54 ` Valdis.Kletnieks 2 siblings, 0 replies; 5+ messages in thread From: Neil Shepperd @ 2014-04-06 2:35 UTC (permalink / raw) To: Dave Taht, cerowrt, cerowrt-devel 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Cerowrt-devel] [Bug #442] wifi fails to transmit traffic after a few hours 2014-04-05 16:33 [Cerowrt-devel] [Bug #442] wifi fails to transmit traffic after a few hours Dave Taht 2014-04-05 22:55 ` David Personette 2014-04-06 2:35 ` Neil Shepperd @ 2014-04-06 2:54 ` Valdis.Kletnieks 2 siblings, 0 replies; 5+ messages in thread From: Valdis.Kletnieks @ 2014-04-06 2:54 UTC (permalink / raw) To: Dave Taht; +Cc: cerowrt, cerowrt-devel [-- 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 --] ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2014-04-06 2:55 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-04-05 16:33 [Cerowrt-devel] [Bug #442] wifi fails to transmit traffic after a few hours Dave Taht 2014-04-05 22:55 ` David Personette 2014-04-05 23:48 ` Chuck Anderson 2014-04-06 2:35 ` Neil Shepperd 2014-04-06 2:54 ` Valdis.Kletnieks
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox