**** BEGIN LOGGING AT Wed Aug 07 02:59:58 2013
Aug 07 03:45:40 <tripolar> hi
Aug 07 03:45:53 <DonkeyHotei> lo
Aug 07 09:25:17 <russell--> blogic: fyi, remote syslog problem persists in r37734
Aug 07 09:30:59 <builder> build #311 of rb532 is complete: Failure [failed shell_12]  Build details are at http://buildbot.openwrt.org:8010/builders/rb532/builds/311
Aug 07 09:31:24 <blogic> russell--: which exact unit does it fail on ?
Aug 07 09:31:33 <blogic> i think i might just order the unit
Aug 07 09:33:57 <builder> build #311 of ppc44x is complete: Failure [failed shell_12]  Build details are at http://buildbot.openwrt.org:8010/builders/ppc44x/builds/311
Aug 07 09:40:38 <guerby> nbd, hi I noticed you fixed a mikrotik device support for openwrt https://dev.openwrt.org/ticket/13266
Aug 07 09:41:20 <guerby> nbd, do you know if Mikrotik low cost / low power RB433L board is supported by openwrt and by what version/image?
Aug 07 09:41:27 <nbd> no idea
Aug 07 09:45:34 <strasidlo> Devs! I appreaciate what you do for OpenWrt! One of my favorite operating systems. <3
Aug 07 09:48:31 <dape> best !
Aug 07 09:56:49 <guerby> nbd, ok
Aug 07 10:21:57 <KanjiMonster> guerby: routerboard support is always a bit incomplete, e.g. there is no sysupgrade (or even easy flashing)
Aug 07 10:23:04 <builder> build #325 of uml is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/uml/builds/325
Aug 07 10:34:14 <russell--> blogic, i've seen it on the buffalo wzr600dhp, also on alix2 (and possibly on wgt634u, though i'm having switch issues on it and haven't built a reliable image on it to test)
Aug 07 10:35:34 <russell--> i did *not* see the problem on ubiquiti airrouter, despite the software being identical in all relevant-seeming respects
Aug 07 10:36:03 <jow_laptop> all except the airrouter do have a switch
Aug 07 10:36:12 <jow_laptop> maybe network setup timing after all?
Aug 07 10:36:23 <russell--> alix doesn't have a switch
Aug 07 10:36:26 <jow_laptop> ah right
Aug 07 10:36:39 <jow_laptop> but it boots quite fast which exposed various races in the past already
Aug 07 10:36:51 <russell--> but i like your brainstorming ;-) /me is stumped
Aug 07 10:37:22 * russell-- assumes it is a race of some kind
Aug 07 10:37:31 <jow_laptop> I wonder if the remote log issue is reproducible in vbox or qemu
Aug 07 10:37:42 <russell--> although, just moving it later doesn't seem to help
Aug 07 10:37:58 <russell--> restarting fixes it
Aug 07 10:38:06 <russell--> restarting logread, that is
Aug 07 10:38:09 <jow_laptop> I think that the connect succeeds but is then interrupted by firewall reloads
Aug 07 10:38:15 <jow_laptop> or network reconfiguration events
Aug 07 10:38:27 <jow_laptop> did you try to disable the firewall on an affected device?
Aug 07 10:38:30 * russell-- has firewall stuff turned off
Aug 07 10:38:33 <jow_laptop> ok
Aug 07 10:40:38 <russell--> i never see a peep out of it from the next hop upstream, yet the logread process is running
Aug 07 10:41:10 <jow_laptop> did you ever check netstat -un in the broken state?
Aug 07 10:41:18 <jow_laptop> or -unp rather
Aug 07 10:42:15 <russell--> udp        0      0 192.168.80.132:38902    70.102.34.162:514       ESTABLISHED 1121/logread
Aug 07 10:42:21 <russell--> except nothing leaves
Aug 07 10:43:04 <jow_laptop> is there nat involved?
Aug 07 10:43:21 <jow_laptop> on the machine itself that is
Aug 07 10:43:24 <russell--> yes
Aug 07 10:43:35 <jow_laptop> how is it set up?
Aug 07 10:43:36 <russell--> just a regular -j MASQUERADE
Aug 07 10:43:41 <jow_laptop> inserted when?
Aug 07 10:43:50 * russell-- looks
Aug 07 10:44:58 <russell--> a custom script that is started at S45
Aug 07 10:45:47 <russell--> START=45
Aug 07 10:45:47 <russell--> start() { iptables -t nat -I POSTROUTING -o eth1 -j MASQUERADE
Aug 07 10:45:53 <russell--> ...
Aug 07 10:46:00 <jow_laptop> if you restart logging, is it still using 192.168.80.132 as local ip?
Aug 07 10:46:09 <jow_laptop> as reported by netstat -unp
Aug 07 10:46:21 <russell--> yes
Aug 07 10:46:56 <russell--> (just confirmed)
Aug 07 10:47:10 <jow_laptop> ok in the broken state right after boot, can you please grep dport=514 /proc/net/nf_conntrack
Aug 07 10:47:18 <jow_laptop> and a thing you can try
Aug 07 10:47:32 <russell--> okay, rebooting...
Aug 07 10:47:51 <jow_laptop> right after your -j MASQUERADE, issue the command below: echo f > /proc/net/nf_conntrack
Aug 07 10:48:05 <jow_laptop> that will flush any established conntrack entry
Aug 07 10:48:10 <jow_laptop> my working theory is
Aug 07 10:48:16 <jow_laptop> log is started before you setup masquerade
Aug 07 10:48:31 <jow_laptop> this causes a conntrack entry for the udp stream
Aug 07 10:48:46 <jow_laptop> once you setup masq it does not affect the udp stream because it is conntracked already
Aug 07 10:49:20 <jow_laptop> just a stab into the dark
Aug 07 10:49:28 <russell--> okay, trying..
Aug 07 10:49:33 <jow_laptop> away for lunch, bbl in 10-15 minutes
Aug 07 10:49:38 <russell--> okay
Aug 07 10:50:43 <russell--> nothing in nf_conntrack after a normal boot
Aug 07 10:57:03 <russell--> well, the remote syslog logread doesn't fire until about a second after the MASQUERADE rule fires off, according to the local syslog (via logread)
Aug 07 10:57:52 <russell--> i put in some netstat -unp's immediately before and after the MASQUERADE rule, and the logread doesn't show in either one
Aug 07 10:58:02 <russell--> but it starts right afterwards
Aug 07 10:59:29 <russell--> Wed Aug  7 03:54:35 2013 daemon.info sysinit: udp        0      0 192.168.80.132:123      50.116.55.161:123       ESTABLISHED 998/ntpclient
Aug 07 10:59:32 <russell--> Wed Aug  7 03:54:36 2013 daemon.alert logread[1118]: Logread connected to 70.102.34.162:514
Aug 07 10:59:50 <russell--> that's the one that starts but doesn't work
Aug 07 11:02:58 <jow_laptop> russell--: ok
Aug 07 11:10:48 <russell--> not to distract, but /me remembers what i was seeing on the wgt634u now.  on it, i was seeing a failure to start up the serial console shell.  but when i reinstalled procd (scp'd it to /tmp and opkg install'd it from there) it magically worked.
Aug 07 11:53:13 * russell-- thinking perhaps the problem isn't on the network side, but on subscribing to the syslog via ubus or whatever
Aug 07 11:57:13 <builder> build #295 of sibyte is complete: Failure [failed shell_12]  Build details are at http://buildbot.openwrt.org:8010/builders/sibyte/builds/295
Aug 07 12:11:51 <builder> build #344 of orion is complete: Failure [failed compile_8]  Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/344
Aug 07 13:55:07 <OpenWrt-Commits> jow r37737 trunk/include/cmake.mk * include: cmake: pass toolchain directory to default root find path as well
Aug 07 15:01:48 <Chocks> hi kiddies
Aug 07 15:01:58 <Chocks> I'm looking at avr32.  Should I be crying?
Aug 07 15:02:03 <builder> build #305 of avr32 is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/305
Aug 07 15:02:39 <Chocks> indeed
Aug 07 15:03:05 <Chocks> was hoping to run eglibc, but I see that's a no go
Aug 07 15:05:12 <KanjiMonster> perfect timing ;D
Aug 07 15:06:26 <Chocks> I think the bit that has required eglibc might not be required for this; but it makes it different to all my other platforms.  Still, I'm getting some errors with my build.  let's try again
Aug 07 15:07:29 <guerby> KanjiMonster, is it because of lack of doc or just because too few people use/spend time with openwrt on mikrotik?
Aug 07 15:07:36 <Chocks> *** Configuration avr32-openwrt-linux-uclibc not supported
Aug 07 15:08:28 <KanjiMonster> Chocks: there is no avr32 support in eglibc
Aug 07 15:08:37 * Chocks peers at musl
Aug 07 15:10:36 <Chocks> no musl support for avr32; at least not in OpenWrt
Aug 07 15:11:20 <KanjiMonster> yes, musl supportes less platforms than eglibc
Aug 07 15:11:24 <KanjiMonster> *supports
Aug 07 15:11:33 <Chocks> and uclibc build gives earlier error
Aug 07 15:11:38 <Chocks> this is trunk, so maybe something's outta sync
Aug 07 15:12:07 <KanjiMonster> guerby: it's mostly because mikrotik uses nand flash, and well nobody bothered to write a sysupgrade script for porperly updating mikrotik devices
Aug 07 15:15:20 <Chocks> perhaps one needs an nbd to comment on avr32/uclibc
Aug 07 15:15:48 <guerby> KanjiMonster, ok thx
Aug 07 15:27:36 <Chocks> moo. anyone?
Aug 07 15:27:44 <wigyori> moo
Aug 07 15:27:57 * Chocks tries AA instead of trunk
Aug 07 15:29:25 <quackquack> hambaa!
Aug 07 15:56:24 <dape> hey, there is only sysupgrade image for dlink dir 505 ?
Aug 07 15:56:56 <dape> there's nothing with factory on downloads.openwrt.org and my trunk compiled just the sysupgrade image for dir505 ..
Aug 07 15:57:16 <Chocks> aa also fails
Aug 07 15:57:22 <Chocks> *** Configuration avr32-openwrt-linux-uclibc not supported
Aug 07 15:57:24 <Chocks> when building uclibc
Aug 07 16:04:00 <dape> so.. i wonder how can i put openwrt on my dlink dir 505 then..
Aug 07 16:04:24 <wigyori> Chocks: so you cannot build an avr32 image at all with neither aa nor trunk ?
Aug 07 16:12:06 <Chocks> correct
Aug 07 16:12:13 <Chocks> seems it must have built at some time
Aug 07 16:12:45 <Chocks> I can provide a full log if need be, but this appears to be the only pertinent thing
Aug 07 16:13:04 <wigyori> yes pls - have been playing around avr32 but that was a long time ago
Aug 07 16:13:24 <Chocks> let me try one more thing
Aug 07 16:14:10 <wigyori> looks like it was fscked up recently - 37660 compiled
Aug 07 16:14:23 <wigyori> if it's a fsckup at all
Aug 07 16:20:35 <Chocks> I started with no .cofing.  It might have been the gcc I chose from a .config I took from elsewhere
Aug 07 16:21:16 * Chocks waits
Aug 07 16:32:29 <Chocks> appears you need to use gcc 4.4.7
Aug 07 17:24:41 <Chocks> /home/peter/dev/openwrt/harmony/build_dir/target-avr32_uClibc-0.9.33.2/php-5.4.17/ext/dom/node.c:847: internal compiler error: Segmentation fault
Aug 07 17:24:44 <Chocks> sweet
Aug 07 17:26:04 <zajec> KanjiMonster: hey
Aug 07 17:26:19 <zajec> KanjiMonster: i didn't expect anyone noticing me not appearing on IRC ;)
Aug 07 17:54:02 <KanjiMonster> hey zajec
Aug 07 17:55:39 <KanjiMonster> zajec: I notice everything ;)
Aug 07 18:00:50 <Chocks> hm
Aug 07 18:00:52 <Chocks> not liking this
Aug 07 18:04:31 <Chocks> it seems there's an avr32 bit added to libgcc/config.host, but lacking in later versions of GCC patches
Aug 07 18:08:02 <KanjiMonster> Chocks: might be because 4.4 is the only one having avr32 support patches ;p
Aug 07 18:08:31 <Chocks> yes, perhaps.  was going to double check before I commented further
Aug 07 18:08:43 <KanjiMonster> I think gcc 4.8 might have native support for avr32 (at least it has a "avr" target)
Aug 07 18:08:45 <Chocks> however, gcc 4.8 sources appear to have avr32 stuff in them
Aug 07 18:08:49 <Chocks> snap
Aug 07 18:09:13 <Chocks> still seems like it's missing that one bit
Aug 07 18:10:41 <Chocks> guess I have to try patching it, and see what happens
Aug 07 18:11:43 <strasidlo> KanjiMonster: is it somehow possible to get users email from openwrt trac? Someone posted patch for uclibc that solves asterisk&res_init issue, I would love to resubmit his patch correctly with his permission. I am not sure if he posted any email address, there's just his username.
Aug 07 18:14:00 <KanjiMonster> strasidlo: as trac seems to broken once again, I currently can't tell ;p
Aug 07 18:14:17 <strasidlo> it's quite often lately :)
Aug 07 18:16:38 <strasidlo> KanjiMonster: it's this - http://goo.gl/WGX7Xk and https://dev.openwrt.org/attachment/ticket/11929/560-res_init_asterisk.patch
Aug 07 18:16:59 <strasidlo> (username marko)
Aug 07 18:17:17 <KanjiMonster> trac is currently 50xing me
Aug 07 18:18:08 <KanjiMonster> strasidlo: if its only a nick, then this is only a nick ...
Aug 07 18:19:02 <KanjiMonster> the only ones with actual logins are devs
Aug 07 18:19:32 <strasidlo> so he instead of putting his email address he put his nickname there
Aug 07 18:20:00 <Chocks> damn noobs
Aug 07 18:20:35 <KanjiMonster> right
Aug 07 18:24:15 <The_Lizard> blogic: The firmware page is protected with another password, which is again checked against a SHA-1 hash.. so that will be a tough one as well...
Aug 07 18:30:20 <blogic> The_Lizard: did you get the first password ?
Aug 07 18:31:34 <The_Lizard> no, guess it is impossible
Aug 07 18:31:48 <The_Lizard> I have had it patched out...
Aug 07 18:32:09 <The_Lizard> but it would be nice if there is a non-jtag (or even non-serial) method of updating to openwrt ;)
Aug 07 18:34:23 <The_Lizard> I'm going to try to patch in a known hash, to check if there is something weird going on... (salts or something)
Aug 07 18:37:33 <Chocks> gcc/gcc/config.gcc too
Aug 07 18:38:01 <Chocks> I think this is going to be a fail.  I don't know enough about GCC internals to mess with this.  I will go back to 4.4.7 and try and -O0 that one file or package
Aug 07 18:49:01 <The_Lizard> blogic: sorry I said 'another' password, but it is the PIN code I mentioned earlier.. but I guess it is different from the serial bootloader password
Aug 07 18:59:42 <middey> The_Lizard:  on which router do you work ? Sounds like a high protected thing
Aug 07 19:04:05 <The_Lizard> arcadyan VGV7519
Aug 07 19:04:12 <The_Lizard> it is tough...
Aug 07 19:04:14 <The_Lizard> BRN-BOOT
Aug 07 19:13:54 <The_Lizard> it doesn't log anything except for its header to the serial port...
Aug 07 19:14:10 <The_Lizard> possibly I have to do a hardware mod to make the other stuff come out?
Aug 07 19:22:23 <The_Lizard> http://wiki.openwrt.org/toh/arcadyan/arv752dpw is talking about a hardware mod... is it required to get even a bit of output? or just for the additional stuff?
Aug 07 19:28:16 <soma> hi, quick question: when using proto static in network config then device and l3_device are always the same, right?
Aug 07 19:29:40 <middey> The_Lizard: the easybox 904 (procuded by Arcadyan) bootloader is also protected by a password and the bootlog shows nothing after the kernel is started ( they set the console to an not existent interface os the kenrel can't put out something) I read the wiki entry for your device and think that you maybe written that the bootloader password is 16 chars long why do you think so ?
Aug 07 19:34:14 <The_Lizard> after 16 characters it continues boot...
Aug 07 19:34:29 <MartijnVdS> might be 4 tries at a 4-char password
Aug 07 19:34:34 <MartijnVdS> or 2 tries at an 8-char one
Aug 07 19:34:45 <The_Lizard> I'm an embedded software engineer, have been digging through the disassembly....
Aug 07 19:34:56 <The_Lizard> it does show * however... for each entry
Aug 07 19:35:05 <MartijnVdS> it's some mutation of "arcadyanarcadyan"
Aug 07 19:35:11 <MartijnVdS> :P
Aug 07 19:36:20 <The_Lizard> seen something like that on another occasion?
Aug 07 19:38:44 <The_Lizard> I did see some messed-up arcadyan texts in the dumps...
Aug 07 19:39:18 <MartijnVdS> The_Lizard: I've seen several vendor passwords being similar to the vendor's name
Aug 07 19:39:38 <MartijnVdS> The_Lizard: sometimes with some substitutions ("l33t"-ified), or reversed
Aug 07 19:39:49 <The_Lizard> Interested in some brute-forcing of the known hash?
Aug 07 19:40:04 <MartijnVdS> is the type of hash known?
Aug 07 19:40:07 <The_Lizard> d05cf242701d3e6cbd5cb396c213383c3af0da3a
Aug 07 19:40:12 <The_Lizard> SHA-1
Aug 07 19:40:23 <The_Lizard> it is this, or a endian-swapped...
Aug 07 19:40:33 <The_Lizard> aabbccdd -> ddccbbaa (5 times)
Aug 07 20:12:49 <The_Lizard> A2rc9DY8N something?
Aug 07 20:13:11 <The_Lizard> looks like it is some boot parameters magic value
Aug 07 20:18:52 <strasidlo> blogic: I might have fixed x86 preinit, let me check it out again (my build server crashed because of the hot weather here). If this works, I'll send a patchset to mailing list, I hope it was not just a coincidence.
Aug 07 21:45:20 <The_Lizard> managed to patch in my own hash in the bootloaders serial menu
Aug 07 21:45:29 <The_Lizard> and it is indeed a 16-char password
Aug 07 21:48:02 <Chocks> more than one bootloader? ;p
Aug 07 22:47:05 <The_Lizard> I've added the SHA-1 from the bootloader recovery page to the wiki: B16D0EF3 DD0632DC D13D135E 2A097AE C4044C24
Aug 07 23:19:35 <swalker> you're missing a character, 39 instead of 40, from that hash
Aug 08 00:46:04 <builder> build #233 of octeon is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/octeon/builds/233
**** ENDING LOGGING AT Thu Aug 08 02:59:59 2013