**** BEGIN LOGGING AT Tue Dec 01 02:59:58 2009
Dec 01 08:52:26 <Lalloso> {Nico} good morning
Dec 01 13:47:17 <rtz> [florian]: you here?
Dec 01 13:48:01 <[florian]> rtz: yes
Dec 01 13:48:53 <danitool> my usb audio sounds choppy, and i don't know if it is the kernel 2.6 or the music player :(
Dec 01 13:49:13 <rtz> [florian]: mtd partition setup doesn't work, but I can't figure out what's wrong
Dec 01 13:49:18 <rtz> let me create a log
Dec 01 13:52:23 <rtz> [florian]: http://openwrt.pastebin.com/m5145c2a2
Dec 01 13:53:00 <rtz> [florian]: the sitecom code in platform.c is called and the partition table looks good, but something afterwards goes wrong
Dec 01 13:53:31 <rtz> [florian]: any pointer where I could start looking would be really helpful
Dec 01 13:53:37 <rtz> because I'm out of ideas
Dec 01 14:02:00 <[florian]> rtz: it did not create partitions, make sure you have CONFIG_MTD_PARTITIONS set
Dec 01 14:15:03 <Lalloso> {Nico}: you here?
Dec 01 14:15:18 <Lalloso> if {Nico}  or some other developer change anything to the Makefiles of a package
Dec 01 14:15:25 <Lalloso> for example net/freeswitch
Dec 01 14:15:49 <Lalloso> do i need feeds update -a to get thos changes?
Dec 01 14:15:58 <Lalloso> or is enough to do svn up on the openwrt trunk
Dec 01 14:16:02 <Lalloso> ?
Dec 01 14:16:16 <Lalloso> i would like to understand how the svn update and the feeds update are related one to the other
Dec 01 14:26:04 <jow_laptop> Lalloso: svn up will just update your openwrt checkout
Dec 01 14:26:20 <jow_laptop> the package stuff is in a separate checkout so you need to use ./scripts/feeds update
Dec 01 14:26:46 <Lalloso> so if i do an svn co
Dec 01 14:26:58 <Lalloso> than an svn switch to an internal repository of mine
Dec 01 14:27:08 <Lalloso> that's like creating an unofficial local openwrt branch
Dec 01 14:27:13 <jow_laptop> yes
Dec 01 14:27:20 <Lalloso> will feeds update continue to work pointing to the internet?
Dec 01 14:27:49 <Lalloso> i can't lose all the important patches {Nico} is doing to the build system until they are well finalized
Dec 01 14:29:13 <Lalloso> but in the meanwhile i need to work on a specific revision of the openwrt trunk as i can't write on official openwrt repository (i'm far from having the necessary skills to acquire such a privilege)
Dec 01 15:15:44 <Lalloso> svn co is returning 405 Method not allow?
Dec 01 15:15:49 <Lalloso> just to me ?
Dec 01 15:16:34 <jow_laptop> you're using the wrong protocol (https:// instead of svn://)
Dec 01 16:16:39 <Lalloso> you are right sorry jow_laptop
Dec 01 16:50:06 <rtz> [florian]: ping
Dec 01 16:52:23 <[florian]> rtz: pong
Dec 01 16:52:57 <rtz> [florian]: it still doesn't work
Dec 01 16:53:06 <rtz> and config_mtd_partitions is set
Dec 01 16:53:21 <[florian]> rtz: ok, I actually did not write that code so I guess sn9 did something wrong
Dec 01 16:53:33 <[florian]> rtz: could you send me the bootlog of your original firmware?
Dec 01 16:53:57 <rtz> [florian]: yes, one moment
Dec 01 16:54:17 <rtz> [florian]: but it did work with the patch he send me
Dec 01 16:54:41 <rtz> [florian]: I'm not sure, if there are differences to the stuff in svn, but they can't be big
Dec 01 16:54:42 <[florian]> rtz: could you send me the patch he sent you?
Dec 01 16:54:56 <rtz> [florian]: don't have it anymore :/
Dec 01 16:55:01 <[florian]> rtz: ah
Dec 01 17:08:12 <rtz> [florian]: http://openwrt.pastebin.com/m531dcef6
Dec 01 17:12:47 <[florian]> rtz: thanks, actually this it not very useful since they do not seem to do something standard with the mtd subsystem
Dec 01 17:13:53 <rtz> [florian]: I know
Dec 01 17:14:03 <rtz> [florian]: they use a special mtd driver
Dec 01 17:14:28 <rtz> [florian]: but I carefully checked the layout in platform.c
Dec 01 17:14:48 <rtz> [florian]: it's basically correct
Dec 01 17:16:43 <rtz> let me try something
Dec 01 17:29:13 <rtz> [florian]: there is a line ROOT_DEV = 0; in platform.c
Dec 01 17:29:25 <rtz> [florian]: should it be set to something?
Dec 01 17:34:10 <[florian]> rtz: preferably let it unset
Dec 01 18:06:38 <tmonjalo> nbd: Have you ever tested madwifi with adhoc + ap ?
Dec 01 18:08:17 <nbd> no
Dec 01 18:08:22 <nbd> not recently
Dec 01 18:08:33 <nbd> which is why i asked the question on the list
Dec 01 18:12:50 <rtz> [florian]: how does the kernel decide what to use as rootfs, if ROOT_DEV is 0 and not root= option is given on the commandline?
Dec 01 21:35:45 <cshore> ping xMff
Dec 01 21:36:48 <xMff> pong cshore
Dec 01 22:17:43 <CIA-92> jow * r18616 /packages/net/iptraf/ (Makefile patches/005-atheros.patch): [packages] iptraf: add patch to make iptraf recognize athX interfaces - thanks Jose Monteiro! (#6248)
Dec 01 22:31:12 <CIA-92> jow * r18617 /trunk/package/firewall/ (Makefile files/uci_firewall.sh):
Dec 01 22:31:12 <CIA-92> [package] firewall: initialize dest_port with src_dport if omitted in redirect sections to narrow
Dec 01 22:31:12 <CIA-92> down corresponding forward rules to the actual target ports - thanks Niels Boehm! (#6249)
Dec 01 22:36:19 <xMff> ping swalker
Dec 01 22:42:22 <cshore1> ping xMff
Dec 01 22:42:36 <xMff> pong cshore1
Dec 01 22:42:55 <cshore1> Hi....Marc was saying you wanted me to UCI the PPTP stuff I did?
Dec 01 22:43:18 <xMff> cshore1: yes because I've seen you had hardcoded stuff in there
Dec 01 22:43:33 <cshore1> yeah, it was a quick hack
Dec 01 22:43:39 <xMff> :)
Dec 01 22:43:55 <cshore1> but now that I know it works I can UCI it
Dec 01 22:44:10 <cshore1> part of it's in dnsmasq
Dec 01 22:44:24 <xMff> you mean the nameserver stuff?
Dec 01 22:44:29 <cshore1> yeah
Dec 01 22:44:45 <xMff> use /tmp/resolv.conf.auto + killall -HUP dnsmasq
Dec 01 22:45:21 <xMff> this should work imo
Dec 01 22:46:24 <xMff> and in the init script you don't need both boot() + start() if they're identical, common boot() is implemented as boot() { start; }
Dec 01 22:46:26 <cshore1> well what I did is split DNS....queries go to standard DNS unless they're the vpn domain, and I exclude the vpn server and a couple of other public servers from going through the VPN dns (using internet instead)
Dec 01 22:46:37 <cshore1> ah, ok
Dec 01 22:47:10 <cshore1> it requires the -S paramater of dnsmasq
Dec 01 22:47:18 <cshore1> which currently isn't UCI'd
Dec 01 22:47:23 <xMff> it is
Dec 01 22:47:29 <cshore1> is it?
Dec 01 22:47:32 <cshore1> I didn't see it
Dec 01 22:47:45 <xMff> yep, list server in config dnsmasq
Dec 01 22:48:26 <xMff> list server '/example.org/1.2.3.4'
Dec 01 22:48:27 <xMff> list server '/foobar.com/5.6.7.8'
Dec 01 22:48:56 <cshore1> hmmm....okay so I don't need that then
Dec 01 22:48:58 <xMff> but I have no good idea how to inject that at runtime
Dec 01 22:50:01 <cshore1> hmmmm.....well I just have it hardcoded atm anyway
Dec 01 22:50:24 <cshore1> is it in LuCI ?
Dec 01 22:50:35 <xMff> I think so
Dec 01 22:51:38 <xMff> ah the server stuff is not provided by the pptp vpn but site specific
Dec 01 22:51:45 <cshore1> that's right
Dec 01 22:52:09 <xMff> then its okay to put it into uci or dnsmasq.conf and wrap the whole process into a wizzard or something
Dec 01 22:52:17 <cshore1> it's the local router that determins the dnsmasq
Dec 01 22:52:18 <cshore1> right
Dec 01 22:52:28 <cshore1> based on the ISP
Dec 01 22:52:44 <cshore1> and the domain names you just have to know
Dec 01 22:52:52 <xMff> yep
Dec 01 22:53:21 <cshore1> (i.e. the VPN server name so that it's available even before PPTP is active else you can't connect, and get disconnected if you are connected)
Dec 01 22:53:48 <cshore1> or if the internal IP is different than the one you need for the connection (that's what happened to me)
Dec 01 22:53:59 <xMff> so you basically decoupled your pptp "implementation" from the actual network config and made it a standalone service... did you check how well it works together with e.g. pppoe?
Dec 01 22:54:47 <xMff> yeah the pptp is more a second stage protocol (after acquiring normal ip connectivity) and the uci network config for it is a bit weird
Dec 01 22:55:13 <xMff> there's an "option ipproto" in the original stuff to specify the underlying protocol
Dec 01 22:55:20 <cshore1> actually it uses the /etc/config/network and just automatically calls it after dnsmasq is up
Dec 01 22:55:34 <xMff> e.g. static + pptp or dhcp + pptp
Dec 01 22:55:46 <cshore1> because when the network is first brought up it can connect due to lack of dns
Dec 01 22:55:54 <cshore1> can't I mean
Dec 01 22:56:10 <xMff> yep
Dec 01 22:56:36 <xMff> I think it should be more treated like openvpn and not as an interface protocol
Dec 01 22:56:45 <cshore1> it uses ifup right now
Dec 01 22:56:53 <cshore1> hmmm...makes sense
Dec 01 22:57:01 <cshore1> I don't know how OpenVPN is done
Dec 01 22:57:17 <xMff> was just an example, it is done differently
Dec 01 22:57:23 <xMff> erm separately I mean
Dec 01 22:57:33 <xMff> regardless of the underlying network config
Dec 01 22:57:38 <cshore1> right
Dec 01 22:58:38 <cshore1> so basically you'd suggest moving it out of /etc/config/network?
Dec 01 22:58:54 <cshore1> and the Interfaces LuCI pages?
Dec 01 22:59:04 <xMff> yes imo it would make the whole thing easier
Dec 01 22:59:38 <xMff> too
Dec 01 23:00:29 <xMff> on the other hand pptp depends on pppd so it would be wise to reuse the stuff from ppp/pppoe/pppoa
Dec 01 23:01:21 <xMff> process control. pid file handling and stuff like that
Dec 01 23:01:27 <cshore1> right
Dec 01 23:02:02 <xMff> yet the proto pptp + ipproto dhcp notation is weird
Dec 01 23:02:25 <xMff> maybe it should be similar to how it is done for wpa, e.g. proto pptp+dhcp
Dec 01 23:03:14 <xMff> so first setup_interface() is called for the underlying proto and then the pptp client is spawned
Dec 01 23:03:54 <xMff> you said connecting fails due to not-yet-available dns, doesn't the pptp client tries to reconnect?
Dec 01 23:05:46 <cshore1> it wasn't....it complained couldn't resolve
Dec 01 23:05:57 <cshore1> and that was the only message
Dec 01 23:06:27 <xMff> I see, maybe we should consider patching it then, or look whether there is an option for continuous retrues
Dec 01 23:06:29 <xMff> *retries
Dec 01 23:06:44 <cshore1> once it succeeds it does retry
Dec 01 23:06:50 <xMff> hmm
Dec 01 23:06:52 <cshore1> or if dns fails to find an address
Dec 01 23:07:04 <cshore1> but when there is no dnsmasq it doesn't like it
Dec 01 23:07:12 <xMff> ah so the problem was that the server was not available at all
Dec 01 23:07:16 <cshore1> right
Dec 01 23:07:18 <xMff> no resolver
Dec 01 23:07:23 <cshore1> right
Dec 01 23:08:22 <xMff> hm
Dec 01 23:08:34 <cshore1> is there a way to have a resolver, even one that just says not found, before the interfaces are brought up/
Dec 01 23:09:12 <xMff> unlikely since not even lo is configured until shortly before pptp is brought up
Dec 01 23:09:16 <cshore1> right
Dec 01 23:10:04 <xMff> I think pptp should be patched to handle the missing dns gracefully
Dec 01 23:10:23 <xMff> or pppd, not sure which one is responsible here exactly
Dec 01 23:10:58 <xMff> do you have the exact message from logread?
Dec 01 23:11:06 <cshore1> not handy, no
Dec 01 23:11:11 <xMff> k
Dec 01 23:12:07 <cshore1> I it's pptp that does that connection....
Dec 01 23:12:08 <xMff> ok, so to summarize: the init script you did is for bringing up pptp a second time
Dec 01 23:12:13 <cshore1> right
Dec 01 23:13:27 <cshore1> and there are bunch of pppd options that are needed that aren't currently in LuCI/UCI
Dec 01 23:13:40 <xMff> can you compile a list of them?
Dec 01 23:13:44 <cshore1> sure
Dec 01 23:14:18 <xMff> I tried to document the current openwrt stuff here: https://wiki.openwrt.org/doc/uci/network#protocol.pptp.point-to-point.tunneling.protocol
Dec 01 23:15:04 <cshore1> persist
Dec 01 23:15:04 <cshore1> +mppe required,stateless
Dec 01 23:15:04 <cshore1> refuse-eap
Dec 01 23:15:04 <cshore1> refuse-pap
Dec 01 23:15:04 <cshore1> refuse-chap
Dec 01 23:15:04 <cshore1> refuse-mschap
Dec 01 23:15:06 <cshore1> lcp-echo-failure 0
Dec 01 23:17:17 <xMff> persist is passed to pppd if "demand" is empty
Dec 01 23:17:24 <cshore1> ah, ok
Dec 01 23:17:48 <cshore1> some sites will need eap (i.e. no refuse-eap)
Dec 01 23:18:12 <xMff> lcp-echo-failure can be specified by the "keepalive" option
Dec 01 23:18:18 <cshore1> lcp-echo-failure isn't required by PPTP per say but the site I use
Dec 01 23:18:19 <cshore1> ok
Dec 01 23:19:24 <xMff> option demand "3 5"  -> lcp-echo-interval=3, lcp-echo-failure=5
Dec 01 23:19:51 <xMff> erm wrong
Dec 01 23:19:59 <xMff> option keepalive "3 5"
Dec 01 23:20:13 <cshore1> config 'interface' 'vertical'
Dec 01 23:20:13 <cshore1>         option 'proto' 'pptp'
Dec 01 23:20:13 <cshore1>         option 'server' 'scvpn.vertical.com'
Dec 01 23:20:13 <cshore1>         option 'username' 'username'
Dec 01 23:20:13 <cshore1>         option 'password' 'password'
Dec 01 23:20:14 <cshore1>         option 'defaultroute' '0'
Dec 01 23:20:16 <cshore1>         option 'peerdns' '0'
Dec 01 23:20:18 <cshore1>         option 'mtu' '1352'
Dec 01 23:20:20 <cshore1>         option 'ifname' 'ppp1'
Dec 01 23:20:22 <cshore1>         option 'pppd_options' 'persist +mppe required,stateless refuse-eap refu
Dec 01 23:20:24 <cshore1> se-pap refuse-chap refuse-mschap lcp-echo-failure 0'
Dec 01 23:21:38 <cshore1> that's what I ended up with
Dec 01 23:22:17 <cshore1> using the LuCI Interfaces interface
Dec 01 23:23:08 <xMff> I see
Dec 01 23:24:13 <cshore1> then you ifup vertical
Dec 01 23:26:00 <cshore1> Marc was suggesting doing it kind of like WLAN...in /etc/config/network, but a separate LuCI interface
Dec 01 23:27:33 <xMff> yes
Dec 01 23:28:32 <xMff> I think we'll make it a task, as the other stuff atm
Dec 01 23:28:53 <cshore1> is that an NIU thing?
Dec 01 23:29:01 <xMff> yes
Dec 01 23:29:01 <cshore1> I haven't looked at it yet
Dec 01 23:29:50 <cshore1> so for the init.d script, do you instead want to patch pptp to deal gracefully with no resolver?
Dec 01 23:30:00 <cshore1> that's the only thing that's really needed
Dec 01 23:30:00 <xMff> yes, this is the plan
Dec 01 23:30:22 <cshore1> the dnsmasq stuff is because I didn't find the -S stuff in LuCI
Dec 01 23:30:35 <xMff> ok, I see
Dec 01 23:30:46 <xMff> the dnsmasq stuff needs rework anyway
Dec 01 23:32:32 <cshore1> so is there anything you want to me to at this point?
Dec 01 23:34:10 <cshore1> oh, yeah I also added a route in ip-up.d
Dec 01 23:35:05 <xMff> routes can be specified with uci as well
Dec 01 23:35:17 <xMff> https://wiki.openwrt.org/doc/uci/network#ipv4.routes
Dec 01 23:35:41 <cshore1> but I did mine dynamically based on the IP of the PPP connection
Dec 01 23:36:01 <cshore1> or interface
Dec 01 23:36:07 <cshore1> since it changes
Dec 01 23:36:19 <xMff> ah
Dec 01 23:36:22 <xMff> hm, was it a netroute?
Dec 01 23:36:28 <cshore1> yes
Dec 01 23:36:50 <xMff> the interface stuff should be no issue since the "uci routes" are brought up by hotplug and referenced by logical ifname
Dec 01 23:37:03 <cshore1> if [ "$VR_NET" = "192.168.1" ]; then
Dec 01 23:37:04 <cshore1>         route add -net 192.168.1.0 netmask 255.255.255.0 gw $PPP_REMOTE
Dec 01 23:37:04 <cshore1> fi
Dec 01 23:37:30 <xMff> ah ok
Dec 01 23:38:38 <xMff> hmm, hard to do that in a generic way
Dec 01 23:39:05 <xMff> no wait
Dec 01 23:39:27 <xMff> if you ommit the gateway option in uci route sections, the gateway is taken from the referenced interface
Dec 01 23:40:01 <cshore1> would you dev pppX?
Dec 01 23:40:41 <xMff> http://openwrt.pastebin.com/m6e1fdd78
Dec 01 23:40:59 <xMff> this should do the trick with both gw X and dev Y
Dec 01 23:41:49 <cshore1> ok
Dec 01 23:42:09 <cshore1> just a sec; I'm going to try converting to a proper UCI'd PPTP
Dec 01 23:43:56 <cshore1> ok, I just checked.  The -S stuff is definitely not in the version of LuCI I have on my router (but it's r17550)
Dec 01 23:44:07 <xMff> btw, was the error you seen in pptp something like "gethostbyname 'foo': name server error"
Dec 01 23:44:35 <cshore1> I'm sorry I don't remember; give me a sec and I'll tell you
Dec 01 23:51:44 <cshore> Ok, it looks like the second pptp isn't needed I disabled it and left everthing else and rebooted and it worked fine
Dec 01 23:52:54 <cshore> oh wait
Dec 01 23:53:00 <cshore> disable didn't work
Dec 01 23:53:20 <cshore> it crated an Spptp entry so I didn't notice it
Dec 01 23:58:07 <cshore> Nope
Dec 01 23:58:17 <cshore> It doesn't have any messages at all
Dec 01 23:58:22 <cshore> it probably isn't dns
Dec 02 00:36:32 <cshore> ping xMff
**** ENDING LOGGING AT Wed Dec 02 02:59:57 2009