From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 0D8B321F1B8 for ; Fri, 15 Nov 2013 04:36:01 -0800 (PST) Received: from u-080-c233.eap.uni-tuebingen.de ([134.2.80.233]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MRXzM-1WA0e61bK4-00ScJK for ; Fri, 15 Nov 2013 13:35:58 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sebastian Moeller In-Reply-To: Date: Fri, 15 Nov 2013 13:35:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56442F41-68E0-495A-B6B3-87AC2910EBED@gmail.com> <47AA0EBF-0886-444B-9A04-EB23105A8A3B@gmx.de> <51BF9432-6FC2-4A14-B147-13F1E779CA93@gmail.com> <876F5928-D2F3-417D-8927-21AE2C5CC136@gmail.com> <1327805F-3961-40F0-BB90-07997E9E1CC4@gmx.de> <9ABE8A7D-DEB1-459A-8068-2B7719728D5F@gmail.com> To: Sebastian Moeller X-Mailer: Apple Mail (2.1510) X-Provags-ID: V03:K0:mAIImBvO6nXFNB6Fa3LoqyQYsqWSZvA+/5f4uxBbOERQJZokOqF 3ykaNsSMchyIsgSXTALPgo5LChQrehEJ5egSGXxNOr96nVNiOHp1bdGwmnPYBZmAfOdPkfl 3yHSvyQ7gTuu7deVyiOsEwk+jFoLzaVYj3NFJeXJsoRvslo1pTUwix/np8S0tOjyyokevUT ZifmlH97JmFCZZp4R/SmA== Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] CeroWrt 3.10.18-1 Field Report X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 12:36:02 -0000 Hi All, small update, I have a hunch that comment 3 of = https://dev.openwrt.org/ticket/13958 might be relevant for us: > additional 2cents: turns out i had mount-utils installed, whose = /usr/bin/mount had different output than the busybox one. this broke the = function rootfs_type() in /lib/upgrade/common.sh, causing the sysupgrade = script to switch something unswitchable... indeed we have a binary in /usr/bin/mount and: export PATH=3D/usr/bin:/usr/sbin:/bin:/sbin in /etc/profile So, it might be enough to replace the following in = /lib/upgrade/commons.sh rootfs_type() { mount | awk '($3 ~ /^\/$/) && ($5 !~ /rootfs/) { print $5 }' } with rootfs_type() { busy box mount | awk '($3 ~ /^\/$/) && ($5 !~ /rootfs/) { print = $5 }' } to get sys upgrade to work again.=20 But I have not tested that (and most likely will not be able to do so = before next week); yet I wanted to document this potential fix for the = greater public... Best Regards Sebastian On Nov 13, 2013, at 00:11 , Sebastian Moeller wrote: > Hi All, >=20 > it turns out that not being able/willing to read can make you do busy = work. It seems I forgot to add "firmware" as device to my mtd = invocation=85 I guess I would never have tried the GUI if I had gotten = the mtd command right the first time :) >=20 >=20 > best > Sebastian >=20 >=20 > On Nov 13, 2013, at 00:06 , Sebastian Moeller = wrote: >=20 >> Hi Richard, hi Dave, hi list, >>=20 >> so I could not resist the lure of 3.10.18-1 and upgraded my = 3.10.11-2.; which turned out to be slightly more involved than I had = expected. >>=20 >> 1) SYSUPGRADE >> root@nacktmulle:/# sysupgrade -d 60 -n = /home/persistent/cerowrts/3.10.18-1/openwrt-ar71xx-generic-wndr3700v2-squa= shfs-sysupgrade.bin >>=20 >> killall: watchdog: no process killed >> Sending TERM to remaining processes ... netifd dynamic_dns_upd sleep = minissdpd lighttpd crond lighttpd pimd snmpd xinetd dbus-daemon dnsmasq = zebra babeld watchquagga smbd nmbd avahi-daemon ahcpd rngd ntpd ubusd = askfirst=20 >> Sending KILL to remaining processes ... ubusd askfirst=20 >> Switching to ramdisk... >> mount: /proc is not a block device >> umount: /tmp/root: not mounted >> Failed to switch over to ramfs. Please reboot. >>=20 >> Rebooting still returned me back to 3.10.11-2 >>=20 >> 2) MTD >> root@nacktmulle:/tmp# mtd -r write /tmp/firmware.img=20 >> Usage: mtd [ ...] [ ...] = [:...] >>=20 >> The device is in the format of mtdX (eg: mtd4) or its label. >> mtd recognizes these commands: >> unlock unlock the device >> refresh refresh mtd partition >> erase erase all data on device >> write |- write (use - for stdin) to = device >> jffs2write append to the jffs2 partition on = the device >> fixtrx fix the checksum in a trx header on = first boot >> Following options are available: >> -q quiet mode (once: no [w] on writing, >> twice: no status messages) >> -n write without first erasing the blocks >> -r reboot after successful command >> -f force write without trx checks >> -e erase before executing the = command >> -d directory for jffs2write, defaults to = "tmp" >> -j integrate into jffs2 data when = writing an image >> -p write beginning at partition offset >> -o offset offset of the image header in the = partition(for fixtrx) >> -F [:[:]][,...] >> alter the fis partition table to create = new partitions replacing >> the partitions provided as argument to = the write command >> (only valid together with the write = command) >>=20 >> Example: To write linux.trx to mtd4 labeled as linux and reboot = afterwards >> mtd -r write linux.trx linux >>=20 >> Still no upgrade performed, but at least it is clearer why, my = command was incomplete=85 BUT I seem to recall that it was exactly this = command that actually allowed me to install 3.10.11-2 in the first = place, weird. >>=20 >> 3) LUCI = (http://gw.home.lan:81/cgi-bin/luci/;stok=3D19113c7f25269daca52ed92ef4d4b8= 02/admin/system/flashops/) >> I disabled the Keep Settings checkbox, uploaded the image (after = making sure /tmp had enough space) followed the "flash image=85" link e = voila, 3.10.18-1 up and running in no time >>=20 >> I have no idea what the GUI actually does differently from calling = sysupgrade on the command line. >>=20 >>=20 >> So the upshot is Juergen Botz is right and the GUI seems to work, at = least if one does not keep the old configuration. (And for that problem = I followed caves advice and just saved /overlay before upgrading, so I = could see the old configuration files and compare.) >>=20 >> Since I am using cerowrt as secondary router I have no input on the = PPPoE issues=85. >>=20 >> best >> Sebastian >>=20 >>=20 >>=20 >>=20 >> On Nov 12, 2013, at 22:17 , Sebastian Moeller = wrote: >>=20 >>> Hi Richard, >>>=20 >>>=20 >>> On Nov 12, 2013, at 18:26 , Richard E. Brown = wrote: >>>=20 >>>>> On Nov 12, 2013, at 4:11 AM, Sebastian Moeller = wrote: >>>>>=20 >>>>>>> - Had to enable and set AQM parameters, since they=92re saved = differently from the QoS settings in the 3.7.5-2 firmware. Set = parameters to ~ 90% of link speeds=20 >>>>>>=20 >>>>>> Just curious, did you specify overhead and encapsulation? >>>>=20 >>>> No, I simply used the defaults on that page. >>>=20 >>> Ah, you might want to try setting the link layer adaptation = mechanism to tc_stab, the link layer to adls or atm and the overhead to = 40 (or look at http://ace-host.stuart.id.au/russell/files/tc/tc-atm/ to = figure out the fixed per packet overhead of your link). This should = allow you to specify a larger percentage of your link rate as shaped = rate=85 But see the attached screenshot of my AQM tab >>>=20 >>>=20 >>> >>>=20 >>>>=20 >>>>>>> - The kernel.log shows lots of the stack traces below: 2-5 per = second on a long-term basis.=20 >>>>>>=20 >>>>>> These look quite weird, the error is a slow patch warning from = hfsc_schedule_watchdog . But, hfsc is the queuing discipline used by = stock OpenWrt, cerowrt , so far, has only used HTB (last I checked was = cerowrt 3.10.11-3). So my guess is that you were running the default QOS = system instead (or worse in addition) to cerowrt's. It would be great to = see the output of: >>>>>> tc -d qdisc ; tc -s class show dev ifb0 ; tc -s class show dev = ge00 >>>>>> to check what is up with the AQM system... >>>>>>=20 >>>>>> Did you by any change use the QOS tab in 3.7.5-2 instead of = running AQM or simple_qos.sh from rc.local/ifup? If so did you direct = sys upgrade to keep the old configuration files? >>>>=20 >>>> Yes, I was using QoS in 3.7.5-2, and I kept the old configuration = files (so I didn=92t have to re-enter credentials for my DSL link, etc.) = I guess it seems likely that I may have been running *both* (!) >>>=20 >>> Probably just QOS, as I think both QOS and AQM start out by = tearing down all discs=85 but the hfsc error should not affect AQM since = it uses HTB. >>>=20 >>>>=20 >>>> Would a better upgrade path be to start with 3.7.5-2, then disable = the QoS, then flash with 3.10.18-1? (My intuition tells me that this = would remove the QoS settings from the loop=85) >>>=20 >>> Mhhh, I guess that should work. >>>>=20 >>>> It=92s pretty easy to re-flash with 3.10.18-1 and run the tc = commands. If disabling QoS makes sense, then after I do the =92tc=92 = experiment, I=92ll re-flash with 3.7.5-2, turn off QoS, then reflash to = 3.10.18-1. >>>=20 >>> This should not fix your PPPoE issues though=85 so maybe it is = not the best time to switch=85 >>>=20 >>>> But it=92ll have to wait =92til dark so no one else is using it. = :-) >>>=20 >>> Hihi, same issue on my side :) No "playing" with the network = while my wife is using it=20 >>>=20 >>> Best >>> Sebastian >>>=20 >>>=20 >>>>=20 >>>> Rich >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> Cerowrt-devel mailing list >>> Cerowrt-devel@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/cerowrt-devel >>=20 >> --=20 >> Sandra, Okko, Joris, & Sebastian Moeller >> Telefon: +49 7071 96 49 783, +49 7071 96 49 784, +49 7071 96 49 785 >> GSM: +49-1577-190 31 41 >> GSM: +49-1517-00 70 355 >>=20 >> Moltkestrasse 6 >> 72072 Tuebingen >> Deutschland >>=20 >=20