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

Dave Taht dave.taht at gmail.com
Sat Apr 5 12:15:08 EDT 2014





root at lorna-gw:~# cat /etc/openwrt_release
DISTRIB_DESCRIPTION="CeroWrt Toronto 3.10.32-9"
DISTRIB_TAINTS="no-all busybox"

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

root at 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 at gmail.com> wrote:
> On Sat, Apr 5, 2014 at 5:49 AM, Neil Shepperd <nshepperd at 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

More information about the Cerowrt-devel mailing list