[Cerowrt-devel] how's everybody's uptime?

[Cerowrt-devel] how's everybody's uptime?

[Dave Taht]

I have thus far been delighted in the stability of 3.10.50-1, how's it
working for all of you?

In particular I am curious about how well native and hurricane
electric ipv6 support is working,
dns and mdns service, and those of you that are routing, how well, all
that is holding up?

-- 
Dave Täht

https://www.bufferbloat.net/projects/make-wifi-fast

Re: [Cerowrt-devel] how's everybody's uptime?

[Aaron Wood]

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

I'm up to 12 days at this point, but it was longer (a month?) before I did
some re-arranging of things and needed to unplug the unit.

I have an AppleTV that's wired, and all the computers are on wifi, so we
end up stressing the mdns a fair bit.  It seems solid, although all the
devices get confused about having other devices using their name, and
increment theirs (the Apple TV is up to 1344).

Everything seems to be going well, though.  But it's all still just ipv4 (I
need to deal with comcast and getting their router into bridge mode, it's
not just a modem at 192.168.100.1, it's a full blown router).

-Aaron

On Sat, Sep 27, 2014 at 10:23 AM, Dave Taht <dave.taht@gmail.com> wrote:

> I have thus far been delighted in the stability of 3.10.50-1, how's it
> working for all of you?
>
> In particular I am curious about how well native and hurricane
> electric ipv6 support is working,
> dns and mdns service, and those of you that are routing, how well, all
> that is holding up?
>
> --
> Dave Täht
>
> https://www.bufferbloat.net/projects/make-wifi-fast
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>

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

Re: [Cerowrt-devel] how's everybody's uptime?

[Jim Gettys]

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

On Sat, Sep 27, 2014 at 1:23 PM, Dave Taht <dave.taht@gmail.com> wrote:

> I have thus far been delighted in the stability of 3.10.50-1, how's it
> working for all of you?
>
> In particular I am curious about how well native and hurricane
> electric ipv6 support is working,
> dns and mdns service, and those of you that are routing, how well, all
> that is holding up?
>

​
​Uptime, 55 days (and I was the one who saw 442 most frequently)​
​ on primary router that has battery backup. Second router has was
installed some weeks ago, but a power hit took it down this morning. Third
router configured, but for no good reason not currently turned on.
​

​Native IPv6 from Comcast​

​on primary router working fine.​ Didn't bother to configure IPv6 on second
or 3rd router.


DNS & mdns are fine. Performance is good.  Life is good.
              - Jim

​


> --
> Dave Täht
>
> https://www.bufferbloat.net/projects/make-wifi-fast
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>

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

Re: [Cerowrt-devel] how's everybody's uptime?

[Valdis.Kletnieks]

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

On Sat, 27 Sep 2014 10:23:13 -0700, Dave Taht said:
> I have thus far been delighted in the stability of 3.10.50-1, how's it
> working for all of you?

I installed it when it came out, and not a blip of trouble until I
mistakenly rebooted it yesterday when I thought it had forgotten how
to rout to other subnets (I couldn't reach my Raspberry Pi which has
a wired connection from my laptop on wireless).  Turned out the *real*
culprit was our corporate VPN handing me a route for 172.16/12 and no
specific route for the other local subnets.  Comcast native IPv6 working
fine.

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

Re: [Cerowrt-devel] how's everybody's uptime?

[Rich Brown]

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

Hokey pokey! CeroWrt sez... 53d 22h 38m 21s This is great!

Everything seems to be fine. mdns, routing, low bloat, etc. I have not fired up a Hurricane Electric tunnel, but perhaps I should.

Dave: you can feel justified in taking a victory lap!

Rich

On Sep 27, 2014, at 1:23 PM, Dave Taht <dave.taht@gmail.com> wrote:

> I have thus far been delighted in the stability of 3.10.50-1, how's it
> working for all of you?
> 
> In particular I am curious about how well native and hurricane
> electric ipv6 support is working,
> dns and mdns service, and those of you that are routing, how well, all
> that is holding up?
> 
> -- 
> Dave Täht
> 
> https://www.bufferbloat.net/projects/make-wifi-fast
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]

Re: [Cerowrt-devel] how's everybody's uptime?

[William Katsak]

21 days for me, in a house with two MacBooks, a Mac Pro, two iPhones, an Android, an Apple TV, and a Playstation.

-Bill

On Sep 27, 2014, at 1:23 PM, Dave Taht <dave.taht@gmail.com> wrote:

> I have thus far been delighted in the stability of 3.10.50-1, how's it
> working for all of you?
> 
> In particular I am curious about how well native and hurricane
> electric ipv6 support is working,
> dns and mdns service, and those of you that are routing, how well, all
> that is holding up?
> 
> -- 
> Dave Täht
> 
> https://www.bufferbloat.net/projects/make-wifi-fast
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] how's everybody's uptime?

[Sebastian Moeller]

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

Hi Dave, hi list,



On Sep 27, 2014, at 19:23 , Dave Taht <dave.taht@gmail.com> wrote:

> I have thus far been delighted in the stability of 3.10.50-1,

	It proved to be a “keeper” ;)?


> how's it
> working for all of you?

pretty good:

root@nacktmulle:~# uptime
 11:25:48 up 36 days,  2:16,  load average: 0.08, 0.05, 0.05
root@nacktmulle:~# 



> 
> In particular I am curious about how well native and hurricane
> electric ipv6 support is working,

	IPv6 by deutsche telekom does only supply a /64 to machines downstream of their combined router-modem, enabling ND and relaying might get IPv^ working on machines connected to cerowrt, but not in the intended way, so I did not configure it this time. Probably due to cerowrt getting a valid IPv6 address for itself but no suitable range via PD or RA (not sure which it should be ;) ) it constantly tries to get something up:

from log read:
Sun Sep 28 11:25:46 2014 daemon.notice netifd: wan6 (19537): Command failed: Unknown error
Sun Sep 28 11:25:54 2014 daemon.warn odhcpd[11168]: A default route is present but there is no public prefix on sw00 thus we don't announce a default route!
Sun Sep 28 11:27:12 2014 daemon.notice netifd: wan6 (19537): Command failed: Unknown error
Sun Sep 28 11:27:17 2014 daemon.warn odhcpd[11168]: A default route is present but there is no public prefix on gw10 thus we don't announce a default route!
Sun Sep 28 11:28:09 2014 daemon.notice netifd: wan6 (19537): Command failed: Unknown error
Sun Sep 28 11:29:03 2014 daemon.notice netifd: wan6 (19537): Command failed: Unknown error
Sun Sep 28 11:29:15 2014 daemon.warn odhcpd[11168]: A default route is present but there is no public prefix on se00 thus we don't announce a default route!

And these repeat roughly every minute…

I assume this is what makes ohcpd unhappy (these are rare, 2 in 36 days of uptime):

[491105.558593] CPU: 0 PID: 1330 Comm: odhcpd Not tainted 3.10.50 #2
[491105.558593] task: 838c1e68 ti: 8241e000 task.ti: 8241e000
[491105.558593] $ 0   : 00000000 00000001 0000003a 774c3440
[491105.558593] $ 4   : 00000011 7fb75808 00000040 00000000
[491105.558593] $ 8   : 00000000 7fb75840 fe800000 00000000
[491105.558593] $12   : 00000001 00000001 00000000 00000001
[491105.558593] $16   : 00402820 0000003a 7fb759a0 7740cd20
[491105.558593] $20   : 7fe8f098 00000000 00000000 00000000
[491105.558593] $24   : 00000000 77425750                  
[491105.558593] $28   : 774453a0 7fb73738 7fe8f048 0040280b
[491105.558593] Hi    : 0000003b
[491105.558593] Lo    : 000fc173
[491105.558593] epc   : 00402817 0x402817
[491105.558593]     Not tainted
[491105.558593] ra    : 0040280b 0x40280b
[491105.558593] Status: 0000fc13	USER EXL IE 
[491105.558593] Cause : 00800010
[491105.558593] BadVA : 0000003a
[491105.558593] PrId  : 00019374 (MIPS 24Kc)
[491105.558593] Modules linked in: ath9k ath9k_htc ath9k_common iptable_nat ath9k_hw ath pppoe nf_nat_ipv4 nf_conntrack_ipv4 mac80211 cfg80211 xt_u32 xt_time xt_tcpudp xt_tcpmss xt_string xt_statistic xt_state xt_recent xt_quota xt_pkttype xt_physdev xt_owner xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_helper xt_hashlimit xt_ecn xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment xt_addrtype xt_TCPMSS xt_REDIRECT xt_LOG xt_IPMARK xt_HL xt_DSCP xt_CT xt_CLASSIFY usbnet ts_kmp ts_fsm ts_bm pptp pppox ppp_async nf_nat_irc nf_nat_ftp nf_defrag_ipv4 nf_conntrack_netlink nf_conntrack_irc nf_conntrack_ftp iptable_raw iptable_mangle iptable_filter ipt_REJECT ipt_MASQUERADE ipt_ECN ip_tables crc_ccitt compat_xtables compat sch_teql sch_tbf sch_sfq sch_sfb sch_red sch_qfq sch_prio sch_pie sch_ns2_codel sch_nfq_codel sch_netem sch_htb sch_gred sch_efq_codel sch_dsmark sch_codel em_text em_nbyte em_meta em_cmp cls_basic act_police act_ipt act_skbedit act_mirred em_u32 cls_u32 cls_tcindex cls_flow cls_route cls_fw sch_hfsc sch_ingress leds_wndr3700_usb ledtrig_usbdev xt_set ip_set_list_set ip_set_hash_netport ip_set_hash_netiface ip_set_hash_net ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink sr_mod cdrom ip6t_NPT ip6t_MASQUERADE ip6table_nat nf_nat_ipv6 nf_nat ip6t_REJECT ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 pppoatm ppp_generic slhc ip_gre gre ifb nat46 sit ipip ip6_tunnel tunnel6 tunnel4 ip_tunnel vfat fat autofs4 br2684 atm nls_iso8859_2 nls_iso8859_15 nls_iso8859_13 nls_iso8859_1 nls_cp437 ipv6 authenc aead arc4 crypto_blkcipher usb_storage ohci_hcd ehci_platform ehci_hcd sd_mod scsi_mod gpio_button_hotplug ext4 crc16 jbd2 mbcache usbcore nls_base usb_common crypto_hash
[491105.558593] Process odhcpd (pid: 1330, threadinfo=8241e000, task=838c1e68, tls=774c3440)
[491105.558593] Stack : 7fb75824 7fb73758 00000000 7fb757d8 00000000 00000000 00000000 00000000
[491105.558593] 	  01ceb3a8 0001000e 00010001 19c0e94c 28924a30 5dbe0006 00060017 0018001f
[491105.558593] 	  00080002 ffff000e 00000003 000c4a30 5dbe0000 0e100000 15180004 00000002
[491105.558593] 	  00080006 00000000 0024000c 00000001 00000000 00000000 00000000 00000000
[491105.558593] 	  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[491105.558593] 	  ...
[491105.558593] Call Trace:
[491105.558593] 
[491105.558593] 
[491105.558593] Code: 1e00  0804  6500 <9a40> 720b  61d0  f123  6318  f0f0 

Also miniupnpd occasionally gets sad:

[2309796.523437] CPU: 0 PID: 5358 Comm: miniupnpd Not tainted 3.10.50 #2
[2309796.523437] task: 8284afc8 ti: 8119e000 task.ti: 8119e000
[2309796.523437] $ 0   : 00000000 00000001 000001dd 7734a440
[2309796.523437] $ 4   : 00000011 7fe07a68 7fe07cd0 00000000
[2309796.523437] $ 8   : 00000000 5e7ffffa a221b7b9 5c220800
[2309796.523437] $12   : 4f544944 2e55504e 00000000 00000000
[2309796.523437] $16   : 000001dd 000001dd 7fe084b0 77295d20
[2309796.523437] $20   : 7fb17c10 00000000 00000000 00000000
[2309796.523437] $24   : 00000000 772a39d0                  
[2309796.523437] $28   : 772ce3a0 7fe079a0 7fb17960 0040a283
[2309796.523437] Hi    : 00000012
[2309796.523437] Lo    : 003fdd15
[2309796.523437] epc   : 0040a28f 0x40a28f
[2309796.523437]     Not tainted
[2309796.523437] ra    : 0040a283 0x40a283
[2309796.523437] Status: 0000fc13	USER EXL IE 
[2309796.523437] Cause : 00800010
[2309796.523437] BadVA : 000001dd
[2309796.523437] PrId  : 00019374 (MIPS 24Kc)
[2309796.523437] Modules linked in: ath9k ath9k_htc ath9k_common iptable_nat ath9k_hw ath pppoe nf_nat_ipv4 nf_conntrack_ipv4 mac80211 cfg80211 xt_u32 xt_time xt_tcpudp xt_tcpmss xt_string xt_statistic xt_state xt_recent xt_quota xt_pkttype xt_physdev xt_owner xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_helper xt_hashlimit xt_ecn xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment xt_addrtype xt_TCPMSS xt_REDIRECT xt_LOG xt_IPMARK xt_HL xt_DSCP xt_CT xt_CLASSIFY usbnet ts_kmp ts_fsm ts_bm pptp pppox ppp_async nf_nat_irc nf_nat_ftp nf_defrag_ipv4 nf_conntrack_netlink nf_conntrack_irc nf_conntrack_ftp iptable_raw iptable_mangle iptable_filter ipt_REJECT ipt_MASQUERADE ipt_ECN ip_tables crc_ccitt compat_xtables compat sch_teql sch_tbf sch_sfq sch_sfb sch_red sch_qfq sch_prio sch_pie sch_ns2_codel sch_nfq_codel sch_netem sch_htb sch_gred sch_efq_codel sch_dsmark sch_codel em_text em_nbyte em_meta em_cmp cls_basic act_police act_ipt act_skbedit act_mirred em_u32 cls_u32 cls_tcindex cls_flow cls_route cls_fw sch_hfsc sch_ingress leds_wndr3700_usb ledtrig_usbdev xt_set ip_set_list_set ip_set_hash_netport ip_set_hash_netiface ip_set_hash_net ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink sr_mod cdrom ip6t_NPT ip6t_MASQUERADE ip6table_nat nf_nat_ipv6 nf_nat ip6t_REJECT ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 pppoatm ppp_generic slhc ip_gre gre ifb nat46 sit ipip ip6_tunnel tunnel6 tunnel4 ip_tunnel vfat fat autofs4 br2684 atm nls_iso8859_2 nls_iso8859_15 nls_iso8859_13 nls_iso8859_1 nls_cp437 ipv6 authenc aead arc4 crypto_blkcipher usb_storage ohci_hcd ehci_platform ehci_hcd sd_mod scsi_mod gpio_button_hotplug ext4 crc16 jbd2 mbcache usbcore nls_base usb_common crypto_hash
[2309796.523437] Process miniupnpd (pid: 5358, threadinfo=8119e000, task=8284afc8, tls=7734a440)
[2309796.523437] Stack : 7fe07c45 7fe07a68 7fe07a68 7fe07c68 00000000 7fe07cb0 00000010 00000000
[2309796.523437] 	  00000000 00000000 7fb17960 0040a2cd 00000000 363a3134 00000001 000001dd
[2309796.523437] 	  00000011 0040a3a5 00000011 7fe07a68 000001dd 00000000 7fe07cb0 00000010
[2309796.523437] 	  00000000 00000000 7fe07a24 00000008 00000000 00407a3b 7fe07bf0 772b2b3f
[2309796.523437] 	  00000001 00410c9c 7fe07cb0 00000010 007c50dc 00001388 00411368 7fe07d30
[2309796.523437] 	  ...
[2309796.523437] Call Trace:
[2309796.523437] 
[2309796.523437] 
[2309796.523437] Code: 1e00  06cc  6500 <9a40> 720b  6008  7204  6750  6172 

But this does not seem to affect the usability of cerowrt much. So overall I am very happy ;)


Now, I have performed a few netperf-wrapper tests recently and it seems there is something in my system that screws up latency under load roughly every minute (see attached image). Until recemty I believed these to be caused by my MacBooks wireless access, but the attached image is from a test win se00 (also no soft-irq spikes visible on top running on cerowrt). I begin to wonder whether these might be caused by ohcpd’s repeated search for a useable IPv6 link, but I digress.










> dns and mdns service, and those of you that are routing, how well, all
> that is holding up?

	Nothing to report as I have not consciously tested those…

Best Regards
	Sebastiam

> 
> -- 
> Dave Täht
> 
> https://www.bufferbloat.net/projects/make-wifi-fast
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel


[-- Attachment #2.1: Type: text/html, Size: 13031 bytes --]

[-- Attachment #2.2: latency_spikes_roughly_every_60sec.png --]
[-- Type: image/png, Size: 23046 bytes --]

Re: [Cerowrt-devel] how's everybody's uptime?

[Neil Shepperd]

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

Hi

News is not so good from me:- I experienced bug 442-like symptoms about a week ago (but my housemate reset the router before I could confirm). But at least that was the only incident. Apart from that, miniupnpd has crashed a few times too in the last week, leaving core files in /tmp. Loading them in gdb from crosstool-ng told me not much except "segfault"; I'm not really sure how to set up a debugging environment properly or generate a miniupnpd with debugging symbols. I speculate that this is related to weird xbone behaviour with nat-pmp (the xbox likes to duplicate packets).

Also  noticed the 2.4GHz network isn't coming up automatically on boot now; I thought someone posted a message about this in the list earlier but I can't find it now.

Neil

On 28/09/14 03:23, Dave Taht wrote:
> I have thus far been delighted in the stability of 3.10.50-1, how's it
> working for all of you?
> 
> In particular I am curious about how well native and hurricane
> electric ipv6 support is working,
> dns and mdns service, and those of you that are routing, how well, all
> that is holding up?
> 


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

Re: [Cerowrt-devel] how's everybody's uptime?

[Toke Høiland-Jørgensen]

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

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

> I have thus far been delighted in the stability of 3.10.50-1, how's it
> working for all of you?

Very good. Two main gateways running tunnelled IPv6 and authoritative
DNS; one with unencrypted wifi and no guest network, another with
Freeradius and 802.11i authentication on the encrypted network. Both
running without issue (other than what I've caused myself by tinkering)
for ~50 days.

Also, the second box distributes routes to a secondary router over
babel, which is also very stable; including automatic failover when the
wireless bridge between the buildings fails (which again mostly happens
when I tinker with it...). Bridging the wifi interfaces to a secondary
router with VLAN interconnect between the two routes also works well.

All in all, very happy with the stability of this release and quite
impressed with the feature set. Big thumbs up! :)

-Toke

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

Re: [Cerowrt-devel] how's everybody's uptime?

[Dave Taht]

Could y'all check your instruction traps?

Also check for space on flash periodically. Hopefully we're not
writing flash anywhere, either.

I note that once upon a time we had a dhcpv6 bug that only struck
every 55 days, and if we get past that point,
we're finally in stable territory...

... except for all the little bugs like pim that have cropped up.


On Sun, Sep 28, 2014 at 5:22 AM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> Dave Taht <dave.taht@gmail.com> writes:
>
>> I have thus far been delighted in the stability of 3.10.50-1, how's it
>> working for all of you?
>
> Very good. Two main gateways running tunnelled IPv6 and authoritative
> DNS; one with unencrypted wifi and no guest network, another with
> Freeradius and 802.11i authentication on the encrypted network. Both
> running without issue (other than what I've caused myself by tinkering)
> for ~50 days.
>
> Also, the second box distributes routes to a secondary router over
> babel, which is also very stable; including automatic failover when the
> wireless bridge between the buildings fails (which again mostly happens
> when I tinker with it...). Bridging the wifi interfaces to a secondary
> router with VLAN interconnect between the two routes also works well.
>
> All in all, very happy with the stability of this release and quite
> impressed with the feature set. Big thumbs up! :)
>
> -Toke



-- 
Dave Täht

https://www.bufferbloat.net/projects/make-wifi-fast

Re: [Cerowrt-devel] how's everybody's uptime?

[Keith Duthie]

I'm not using ipv6 (annoyingly my ISP doesn't support it yet) so I
can't say anything about that, but I've got uptime of 57 days. I do
have a lot of "Failed to send to ff02::1%sw00 (Operation not
permitted)" in my logs from odhcpd, which is interesting given that
the sw00 interface is actually disabled in my config.

No sign of instruction traps, but my use is relatively light and is
only ipv4, so I'm probably not a good yard-stick for that. Flash usage
is still looking good, with 95% free.

All in all, it's looking at least as stable as most commercial
routers. Not that that's necessarily a high bar ;-)

Regards,
Keith

On Wed, Oct 1, 2014 at 6:20 PM, Dave Taht <dave.taht@gmail.com> wrote:
> Could y'all check your instruction traps?
>
> Also check for space on flash periodically. Hopefully we're not
> writing flash anywhere, either.
>
> I note that once upon a time we had a dhcpv6 bug that only struck
> every 55 days, and if we get past that point,
> we're finally in stable territory...
>
> ... except for all the little bugs like pim that have cropped up.
>
>
> On Sun, Sep 28, 2014 at 5:22 AM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>> Dave Taht <dave.taht@gmail.com> writes:
>>
>>> I have thus far been delighted in the stability of 3.10.50-1, how's it
>>> working for all of you?
>>
>> Very good. Two main gateways running tunnelled IPv6 and authoritative
>> DNS; one with unencrypted wifi and no guest network, another with
>> Freeradius and 802.11i authentication on the encrypted network. Both
>> running without issue (other than what I've caused myself by tinkering)
>> for ~50 days.
>>
>> Also, the second box distributes routes to a secondary router over
>> babel, which is also very stable; including automatic failover when the
>> wireless bridge between the buildings fails (which again mostly happens
>> when I tinker with it...). Bridging the wifi interfaces to a secondary
>> router with VLAN interconnect between the two routes also works well.
>>
>> All in all, very happy with the stability of this release and quite
>> impressed with the feature set. Big thumbs up! :)
>>
>> -Toke
>
>
>
> --
> Dave Täht
>
> https://www.bufferbloat.net/projects/make-wifi-fast
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] how's everybody's uptime?

[Richard Weait]

On Sat, Sep 27, 2014 at 1:23 PM, Dave Taht <dave.taht@gmail.com> wrote:
> I have thus far been delighted in the stability of 3.10.50-1, how's it
> working for all of you?

I have to confess that I'm still using. 3.10.41-1 on two devices.
up 30 days on one
and 39 days on the other

Re: [Cerowrt-devel] how's everybody's uptime?

[leetminiwheat]

3.10.50-1 uptime/stability report:

using as primary gw router for a few months now. primary net usage:
gaming, and routing net to cable TV boxes via FiOS provided MoCA
router as secondary router.

# uptime
 10:11:56 up 20 days, 20:09,  load average: 0.00, 0.02, 0.04

nothing strange in dmesg or logread. (though logread only goes back so far.)

memory usage in htop seems consistent between 27MB and 28MB, no memory leaks.

sw00/sw10 WiFi performance has been good on both fronts for 2.4ghz and
5ghz. I run a WiFi hotspot on gw00. no sign of bug 443

had to reboot before this due to SQM bug, bandwidth limiting stopped
working on guest ingress presumably due to many SQM restarts and/or
wifi channel fiddling. Also recall odhcpd going out of control with
CPU usage about 2 months ago or something. still have to figure out
some way to limit max connections for guests so they can't saturate my
network even with badnwidth limiting, firewall packages seem to lack
support for what I'd need. I have 6 IFB interfaces right now though,
any way to clean these up?

mdns responder (avahi-daemon) seems to be working with iPhone to
Windows 8.1, though iPhone needs to be rebooted for WiFi sync to work
every darn time. Unsure if iPhone bug or Windows bug or avahi bug.
seems to advertise all services fine when I checked from a linux box.

not using ipv6, though @ge00 and odhcpd is enabled still. GW10 and
babel disabled. gw00 guest/bandwidth limited, and ge00 limited just
below ISP cap. all fq_codel.

Other additional packages I run:
-OpenSSH client for socks5 proxy ssh session to a remote server w/
screen for lower latency gaming tunnel. (se00)
-Miau for IRC bouncer.
-dnscrypt-proxy server running locally to fetch encrypted dns requests
and serve locally 127.0.0.1:2053 to dnsmasq working great. I wish this
package would get pushed upstream, I think it's more secure than
DNSSEC. or possibly a combination of the two would be best. (still
unsure how to setup DNSSEC properly).

On Wed, Oct 1, 2014 at 8:37 AM, Richard Weait <richard@weait.com> wrote:
> On Sat, Sep 27, 2014 at 1:23 PM, Dave Taht <dave.taht@gmail.com> wrote:
>> I have thus far been delighted in the stability of 3.10.50-1, how's it
>> working for all of you?
>
> I have to confess that I'm still using. 3.10.41-1 on two devices.
> up 30 days on one
> and 39 days on the other
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] how's everybody's uptime?

[Aaron Wood]

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

Uptime:   21:30:42 up 40 days, 12:17,  load average: 0.11, 0.13, 0.08
no traps

It's running native IPv6 (Comcast), now that I have the Comcast Wifi unit
running in bridge mode.  Everything seems just fine.

df -h:
Filesystem                Size      Used Available Use% Mounted on
rootfs                   14.4M     10.7M      3.7M  74% /
/dev/root                14.4M     10.7M      3.7M  74% /
tmpfs                    61.6M      1.1M     60.6M   2% /tmp
tmpfs                   512.0K         0    512.0K   0% /dev

-Aaron

On Tue, Sep 30, 2014 at 10:20 PM, Dave Taht <dave.taht@gmail.com> wrote:

> Could y'all check your instruction traps?
>
> Also check for space on flash periodically. Hopefully we're not
> writing flash anywhere, either.
>
> I note that once upon a time we had a dhcpv6 bug that only struck
> every 55 days, and if we get past that point,
> we're finally in stable territory...
>
> ... except for all the little bugs like pim that have cropped up.
>
>
> On Sun, Sep 28, 2014 at 5:22 AM, Toke Høiland-Jørgensen <toke@toke.dk>
> wrote:
> > Dave Taht <dave.taht@gmail.com> writes:
> >
> >> I have thus far been delighted in the stability of 3.10.50-1, how's it
> >> working for all of you?
> >
> > Very good. Two main gateways running tunnelled IPv6 and authoritative
> > DNS; one with unencrypted wifi and no guest network, another with
> > Freeradius and 802.11i authentication on the encrypted network. Both
> > running without issue (other than what I've caused myself by tinkering)
> > for ~50 days.
> >
> > Also, the second box distributes routes to a secondary router over
> > babel, which is also very stable; including automatic failover when the
> > wireless bridge between the buildings fails (which again mostly happens
> > when I tinker with it...). Bridging the wifi interfaces to a secondary
> > router with VLAN interconnect between the two routes also works well.
> >
> > All in all, very happy with the stability of this release and quite
> > impressed with the feature set. Big thumbs up! :)
> >
> > -Toke
>
>
>
> --
> Dave Täht
>
> https://www.bufferbloat.net/projects/make-wifi-fast
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>

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

Re: [Cerowrt-devel] how's everybody's uptime?

[Sebastian Moeller]

Hi leetminiwheat (nice handle by the way ;) )
On Nov 6, 2014, at 16:45 , leetminiwheat <LeetMiniWheat@gmail.com> wrote:

> 3.10.50-1 uptime/stability report:
> 
> using as primary gw router for a few months now. primary net usage:
> gaming, and routing net to cable TV boxes via FiOS provided MoCA
> router as secondary router.
> 
> # uptime
> 10:11:56 up 20 days, 20:09,  load average: 0.00, 0.02, 0.04
> 
> nothing strange in dmesg or logread. (though logread only goes back so far.)
> 
> memory usage in htop seems consistent between 27MB and 28MB, no memory leaks.
> 
> sw00/sw10 WiFi performance has been good on both fronts for 2.4ghz and
> 5ghz. I run a WiFi hotspot on gw00. no sign of bug 443
> 
> had to reboot before this due to SQM bug, bandwidth limiting stopped
> working on guest ingress presumably due to many SQM restarts and/or
> wifi channel fiddling. Also recall odhcpd going out of control with
> CPU usage about 2 months ago or something. still have to figure out
> some way to limit max connections for guests so they can't saturate my
> network even with badnwidth limiting, firewall packages seem to lack
> support for what I'd need. I have 6 IFB interfaces right now though,
> any way to clean these up?

Maybe the following will work (repave $CUR_IFB with the IFB you want to get rid of)
	tc qdisc del dev $CUR_IFB root
followed by:
	ip link delete ${CUR_IFB} type ifb
Hopefully that should do the trick. I am curious which SQM you are using stock from cerowrt 3.10.50-1 or an updated version? We tried to fix the spurious IFB generation and should be in much better shape now, only leaking IFBs if either run.sh or stop.sh do not execute fully. I would love independent confirmation that the fixes actually work… 

> 
> mdns responder (avahi-daemon) seems to be working with iPhone to
> Windows 8.1, though iPhone needs to be rebooted for WiFi sync to work
> every darn time. Unsure if iPhone bug or Windows bug or avahi bug.
> seems to advertise all services fine when I checked from a linux box.
> 
> not using ipv6, though @ge00 and odhcpd is enabled still. GW10 and
> babel disabled. gw00 guest/bandwidth limited, and ge00 limited just
> below ISP cap. all fq_codel.

	How well does that work in practice? (Can you effectively shape to more than 60Mbps combined over all directions and interfaces concurrently?)

Best Regards
	Sebastian

> 
> Other additional packages I run:
> -OpenSSH client for socks5 proxy ssh session to a remote server w/
> screen for lower latency gaming tunnel. (se00)
> -Miau for IRC bouncer.
> -dnscrypt-proxy server running locally to fetch encrypted dns requests
> and serve locally 127.0.0.1:2053 to dnsmasq working great. I wish this
> package would get pushed upstream, I think it's more secure than
> DNSSEC. or possibly a combination of the two would be best. (still
> unsure how to setup DNSSEC properly).
> 
> On Wed, Oct 1, 2014 at 8:37 AM, Richard Weait <richard@weait.com> wrote:
>> On Sat, Sep 27, 2014 at 1:23 PM, Dave Taht <dave.taht@gmail.com> wrote:
>>> I have thus far been delighted in the stability of 3.10.50-1, how's it
>>> working for all of you?
>> 
>> I have to confess that I'm still using. 3.10.41-1 on two devices.
>> up 30 days on one
>> and 39 days on the other
>> _______________________________________________
>> 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

Re: [Cerowrt-devel] how's everybody's uptime?

[Luke Hamburg]

root@r1:~# uptime
 13:20:41 up 363 days,  3:27,  load average: 0.04, 0.02, 0.04



I haven't touched my Cero for months (just noticed I'm 2 days shy of a full year!) and the last reboot was only due to a power failure.  This is on a wndr3800. I admit I'm using quite an old version but "if it ain't broke" :) 

Re: [Cerowrt-devel] how's everybody's uptime?

[Sebastian Moeller]

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


On Sep 28, 2014, at 11:45 , Sebastian Moeller <moeller0@gmx.de> wrote:
[…]
> 
> 
> Now, I have performed a few netperf-wrapper tests recently and it seems there is something in my system that screws up latency under load roughly every minute (see attached image). Until recemty I believed these to be caused by my MacBooks wireless access, but the attached image is from a test win se00 (also no soft-irq spikes visible on top running on cerowrt). I begin to wonder whether these might be caused by ohcpd’s repeated search for a useable IPv6 link, but I digress.
> 
> 
> 

	This is not going to be too interesting, but for some closure I want to document the information about this issue (especially since cerowrt is completely innocent, and I want to avoid spoiling its reputation with another device’s issues)
	So I figured that one out; it was the 2.4GHz wifi on my ISP’s modem-router (speed port w723v type A, avoid if possible); which was a) running without associated stations as an emergency fallback in case I screwed up cerowrt, and b) was actually wedging itself hard after 1 to 48 hours of operation in that it did not allow any station to connect. And in the wedged state it completely wiped out this modem-router’s wan throughput. Since this router was shared between my wired and wireless tests (after all this is the device talking DSL ;) ) it affected all my tests. Since I disabled that devices WLAN completely, the latency spikes are gone (actually now I have periodic spikes, but these are of much smaller magnitude and much less urgent to solve).\\\

Best Regards
	Sebastian
	

[-- Attachment #2.1: Type: text/html, Size: 2315 bytes --]

[-- Attachment #2.2: latency_spikes_roughly_every_60sec.png --]
[-- Type: image/png, Size: 23046 bytes --]