[Cerowrt-devel] cerowrt-3.10.34-4 dev build released
dave.taht at gmail.com
Sat Apr 5 12:02:57 EDT 2014
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.
>> 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.
Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
More information about the Cerowrt-devel