**** BEGIN LOGGING AT Thu Nov 19 02:59:58 2015
Nov 19 07:25:23 <builder> build #148 of cobalt is complete: Failure [failed shell_10]  Build details are at http://buildbot.openwrt.org:8010/builders/cobalt/builds/148
Nov 19 07:28:01 <builder> build #148 of cns21xx is complete: Failure [failed shell_10]  Build details are at http://buildbot.openwrt.org:8010/builders/cns21xx/builds/148
Nov 19 07:30:54 <builder> build #148 of orion is complete: Failure [failed shell_10]  Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/148
Nov 19 08:02:19 <OpenWrt-Commits> luka r47513 trunk/target/linux/ (7 files) * imx6: refresh patches
Nov 19 08:28:42 <builder> build #146 of pxa is complete: Failure [failed shell_10]  Build details are at http://buildbot.openwrt.org:8010/builders/pxa/builds/146
Nov 19 09:49:51 <builder> build #133 of x86 is complete: Failure [failed shell_14]  Build details are at http://buildbot.openwrt.org:8010/builders/x86/builds/133
Nov 19 09:56:22 <txomon> I think I already asked this, but I don't remember the answer... uhttpd + ws?
Nov 19 09:57:32 <builder> build #135 of ar71xx.nand is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx.nand/builds/135
Nov 19 09:57:40 <karlp> wise sorcerers?
Nov 19 10:03:52 <jow_laptop> white space?
Nov 19 10:04:00 <jow_laptop> wall street?
Nov 19 10:06:22 <nbd> my crystal ball says: websockets
Nov 19 10:07:30 <karlp> nbd: don't spoil the fun, that was my guess too, just felt the question was needlessly terse :)
Nov 19 10:07:39 <nbd> i agree
Nov 19 10:08:11 <nbd> and wise sorcerers might want to use websockets too sometimes
Nov 19 10:08:31 <nbd> with magic javascript incantations
Nov 19 10:08:58 <jow_laptop> the websocket protocol looks annoying
Nov 19 10:09:41 <karlp> txomon: if you _were_ asking about websockets, I use mosquitto for it, not uhttpd...
Nov 19 10:09:44 <jow_laptop> Patches welcome though, or maybe nbd wants to chime in ;)
Nov 19 10:09:54 <karlp> but I already had the mqtt broker available....
Nov 19 10:10:12 <karlp> it's more likely to be ubus that wants to provide websocket support than uhttpd I'd imagine?
Nov 19 10:10:14 <nbd> i think a websocket api that connects to an ubus service using ubus fd passing might be interesting
Nov 19 10:10:14 <jow_laptop> maybe it makes sense to support connection upgrading in uhttpd with a handoff to some other service then
Nov 19 10:10:34 <jow_laptop> but some totally httpd-unrelated protocol? not sure
Nov 19 10:10:43 <jow_laptop> *http-unrealted protocol in uhttpd
Nov 19 10:14:23 <cyrusff> *sigh* webpeople and their latest hypes: rest, websockets, server-side javascript, wonder what the next strange idea will be
Nov 19 10:14:31 <jow_laptop> https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers
Nov 19 10:14:40 <jow_laptop> looking here and still nto clear on some key concepts
Nov 19 10:15:55 <nbd> while the protocol is somewhat quirky, i do like the concept of being able to stream data from the server side to the client with support for bidirectional communication and without constant useless extra http requests
Nov 19 10:16:17 <cyrusff> nbd: yeah that protocol is called tcp ;)
Nov 19 10:16:55 <nbd> well, allowing the browser to do arbitrary tcp would be a huge security risk
Nov 19 10:17:08 <cyrusff> in what way?
Nov 19 10:17:15 <nbd> it could poke services
Nov 19 10:17:20 <jow_laptop> some questions which aren't clear to me from skimming the doc a few times
Nov 19 10:17:21 <nbd> send spam mail via hosts that also have open port 25
Nov 19 10:17:27 <jow_laptop> a) what port is it using?
Nov 19 10:17:36 <nbd> if it allows other ip addresses, it could poke around in an internal network on a server's request
Nov 19 10:17:56 <jow_laptop> b) is it handshaking the tcp^Wws connection with http to switch to some binary protocol then?
Nov 19 10:18:17 <jow_laptop> c) this Sec-WebSocket-Key, is it the 32bit xor secret used for "encrypting" frames?
Nov 19 10:19:02 <cyrusff> nbd: i mean its the same issue with XSRF
Nov 19 10:19:28 <jow_laptop> apparently the framing supports fragmentation and reassembly, this looks like a headache to securely implement
Nov 19 10:19:40 <cyrusff> sure that limits me to "HTTP" in some way, but also works with arbitrary ports and destinations
Nov 19 10:19:43 <jow_laptop> I mean doable ofc, but annoying and certainly not simple
Nov 19 10:19:45 <builder> build #144 of ppc40x is complete: Failure [failed shell_10]  Build details are at http://buildbot.openwrt.org:8010/builders/ppc40x/builds/144
Nov 19 10:20:20 <nbd> cyrusff: but with XSRF at least it's contained to one protocol where people are expected to take care of request security via tokens and stuff anyway
Nov 19 10:20:25 <cyrusff> jow_laptop: i think its multiplexed with the standard http-port it seems and that sec-websocket-key is just elaborate "Do you speak WS?" - "Yes I do"
Nov 19 10:20:33 <nbd> with arbitrary TCP that doesn't work
Nov 19 10:20:34 <jow_laptop> so I could imagine uhttpd being a proxy of some sort, maybe even performing the handshake but not sure if the actual binary ws communication should be done by it
Nov 19 10:20:49 <nbd> jow_laptop: i agree, it should be a separate daemon
Nov 19 10:21:05 <nbd> or a plugin
Nov 19 10:21:24 <nbd> plugin would be more efficient since it would get rid of one extra data copy layer
Nov 19 10:21:29 <jow_laptop> simpyl speaking I'd want that to be a different uloop()
Nov 19 10:21:41 <cyrusff> pass fds
Nov 19 10:22:09 <cyrusff> nbd: okay granted, let's say using HTTP as handshake has its merits, however that still doesn't really warrant a framing-protocol on top of TCP and what not
Nov 19 10:22:19 <nbd> the way it's designed right now, uhttpd cannot easily pass its http connection fd to another process
Nov 19 10:22:20 <cyrusff> and XOR "Encryption"
Nov 19 10:22:40 <cyrusff> nbd: i guess TLS would be tricky
Nov 19 10:22:50 <nbd> yeah
Nov 19 10:23:16 <nbd> even non-TLS is tricky
Nov 19 10:23:20 <nbd> because data is buffered
Nov 19 10:23:20 <cyrusff> i guess you could do awkward splice() and pipe combinations to get it near zero-copy
Nov 19 10:39:09 <karlp> libwebsockets is already packaged for openwrt, fwiw, and in use
Nov 19 10:42:58 <builder> build #147 of imx6 is complete: Failure [failed compile_4]  Build details are at http://buildbot.openwrt.org:8010/builders/imx6/builds/147
Nov 19 10:43:41 <risk> websockets are going to be die-ing off in favor of http2 .. not a good long term bet
Nov 19 10:44:03 <risk> on the other hand http2 is not that well understood by people
Nov 19 10:44:42 <karlp> http2 is like ipv6, great idea, eventually. maybe. sort of, hopefully.
Nov 19 10:44:48 <karlp> websockets solves those problems now.
Nov 19 10:44:49 <risk> also, .. what's wrong with just poking a server on the lan twice a second if that "poking" doesn't require forking stuff or sending tons of syscalls
Nov 19 10:44:55 <jow_laptop> http 2 is an even larger clusterfuck :)
Nov 19 10:45:32 <risk> oh, I know, let's use quic /joke
Nov 19 10:45:41 <jow_laptop> just a rebranded spdy to begin with
Nov 19 10:45:43 <karlp> risk: don't question the user, give them more tools for shooting off their feet or maybe making something cool.
Nov 19 10:46:31 <risk> karlp: if you make it work it'll be considered :)
Nov 19 10:48:19 <jow_laptop> karlp: hm, the ucrrent libwebsockets ipk is ~33K that alone is larger than uhttpd and all its optional plugins :(
Nov 19 10:48:20 <risk> but seriously, having a small ubus like message buffer where messages have a sequence and a ttl, with a few messages in ram, that the browser can pick up over plain http sounds good enough for me, I don't think it'd matter much if changing the ip appears to take 50ms or 250ms or 1s
Nov 19 10:48:56 <jow_laptop> there's probably potential for shrinking it though
Nov 19 10:49:25 <karlp> risk: make what work?
Nov 19 10:49:51 <risk> websocket based ui
Nov 19 10:49:58 <karlp> jow_laptop: yeah, uhttpd doesn't support DELETE either, there's a reason it's small ;)
Nov 19 10:50:18 <jow_laptop> yes but adding DELETE wouldn't be 33K
Nov 19 10:50:23 <karlp> risk: I've already got a websockets based ui, I'm the maintainer of the libwebsockets package ;)
Nov 19 10:50:30 <karlp> jow_laptop: I know, cheap shot sorry :)
Nov 19 10:50:35 <karlp> 33k is nothing! look at openssl!
Nov 19 10:50:56 <risk> karlp: you have a websockets based luci?
Nov 19 10:50:57 <jow_laptop> openssl? even jquery is larger!
Nov 19 10:51:17 <karlp> risk: why would I need to replace luci? it doesn't have bits that need websockets.
Nov 19 10:51:34 <karlp> I'm not trying to replace everything with websockets just because.
Nov 19 10:51:34 <jow_laptop> karlp: anyhow, do you need delete and put support? I can certainly add stubs so that at least cgi handler can implement them
Nov 19 10:51:52 <jow_laptop> I already added HEAD because it was needed by CORS
Nov 19 10:52:10 <karlp> jow_laptop: passing them to the handler would be nice, but I'm currently using the X-HTTP-Method-Override you added for me
Nov 19 10:52:39 <karlp> works fine, just occasionally forget and press the "delete" button in a rest client instead of post and a header.
Nov 19 10:52:55 <risk> oh sorry, I thought you wanted to build uhttpd with it .. so you could have uhttpd serve through luci stuff using websockets .., my bad
Nov 19 10:52:58 <cyrusff> what's the point of adding DELETE?
Nov 19 10:53:03 <karlp> risk: no, that's txomon.
Nov 19 10:53:09 <cyrusff> i mean you don't really want to remote-delete files right?
Nov 19 10:53:13 <karlp> cyrusff: for your favourite REST ;)
Nov 19 10:53:33 <cyrusff> okay, I'm rephrasing. what's the point of REST over say, JSON-RPC
Nov 19 10:53:33 <jow_laptop> cyrusff: right, for building REST apis
Nov 19 10:53:42 <karlp> I want to delete some files, yes.  and "deleteing" portions of uci configs.
Nov 19 10:53:42 <jow_laptop> cyrusff: less framing
Nov 19 10:54:02 <karlp> also json rpc is all rpc and not documents and urls :)
Nov 19 10:54:09 <karlp> gross and old fashioned ;)
Nov 19 10:54:29 <karlp> (and of course, totally functional and well documented, unlike most rest apis)
Nov 19 10:54:48 <cyrusff> its funny, because people probably said the reverse about using DELETE etc. over RPCs a few years ago
Nov 19 10:54:48 <jow_laptop> stop being sarcastic ;)
Nov 19 10:55:00 <cyrusff> ;)
Nov 19 10:55:29 <cyrusff> remember webdav? :P
Nov 19 10:55:34 <karlp> yup,
Nov 19 10:55:45 <karlp> OPTIONS?! what are those?! no my webserver doens't support them!
Nov 19 10:55:48 <risk> well, fwiw there's http://json-schema.org/ .. not the same as json rpc, but might help with plain old json post requests
Nov 19 10:55:52 <jow_laptop> cyrusff: its still a little while yet but soon the web people will complete the full circle
Nov 19 10:56:08 <karlp> risk: yeah, I've got a RAML 0.8 document for our api and it uses json schema
Nov 19 10:56:17 <jow_laptop> I mean with websockets they're on the way to reinvent tcp
Nov 19 10:56:28 <cyrusff> jow_laptop: so after REST we then have CBOR-RPC? ;)
Nov 19 10:56:39 <karlp> jow_laptop: no, they just want to use tcp, but are in a constrained environment.
Nov 19 10:57:01 <karlp> they all know this stuff exists, thye just can't use it from a browser client.
Nov 19 10:57:17 <karlp> and network security people insisted they couldn't have anything at all except an outbound 80/443,
Nov 19 10:57:25 <jow_laptop> karlp: you can run a linux in a javascript vm, let it talk to the outside using websockets and then finally install your favorite network software within it
Nov 19 10:57:29 <risk> karlp: sarcasm on raml doc, or link?
Nov 19 10:57:51 <karlp> it's for aour own devices, but yeah, hang on,
Nov 19 10:58:27 <jow_laptop> yeah I get the idea that they needs some tcp-like thing doable from the browser which must not be unrestricted tcp
Nov 19 10:58:35 <karlp> http://paste.fedoraproject.org/292241/44793068/
Nov 19 10:58:44 <jow_laptop> but wouldn't something simple like the existing CONNECT used by http proxy work?
Nov 19 10:58:51 <karlp> that's what websockets does.
Nov 19 10:58:56 <jow_laptop> why a new framing, new security concept, new subprotocols
Nov 19 10:59:17 <karlp> connect by itself is still just a single request.
Nov 19 10:59:32 <karlp> you're not solving the bi-dir comms, you still need the old long polling/crap
Nov 19 10:59:33 <jow_laptop> just CONNECT, in js you get a handle with read callbacks and write methods
Nov 19 10:59:44 <jow_laptop> if stuff is binary it gets exposed as typed char array
Nov 19 11:00:02 <cyrusff> yeah, why not just treat the socket as a plain old TCP-sockets after you have handshaked the HTTP "Upgrade"
Nov 19 11:00:24 <karlp> yeah, and I think socket.io stuff provided a nice api on that.
Nov 19 11:00:41 <cyrusff> websockets is just one of those typical 10x overengineered IETF protocols
Nov 19 11:00:56 <jow_laptop> so the handshaking of websockets is okay, but the rest looks awkward, especially the frame formatz
Nov 19 11:00:59 <jow_laptop> -z
Nov 19 11:01:00 <karlp> I don't know why websockets put more in, but I believe it was for being able to hve different protocols available from the same endpoint.
Nov 19 11:01:22 <karlp> and as a user, I don't have to care an aweful lot about it, it "just works" these days.
Nov 19 11:01:50 <karlp> having it all available on the same endpoint came again from the network security guys blocking everything and the CORS/xsrf hellholes
Nov 19 11:01:57 <jow_laptop> true but what kind of argument is that in a development channel :)
Nov 19 11:02:16 <jow_laptop> its not about what works from a user pov, but how hard it is to implement
Nov 19 11:02:47 <cyrusff> yay for awkward framing and XOR "encrpytion" on top of TCP because you are too lazy to open a second socket
Nov 19 11:02:50 <risk> karlp: do you treat raml as idl, and/or "transpile" it into client/server stubs, or is it just for documentation purposes?
Nov 19 11:02:52 <karlp> heh, I'm just a user ;)
Nov 19 11:03:15 <karlp> risk: I just use it for documentaiton and to make me think about it more formally, but you can "transpile" them.
Nov 19 11:03:37 <karlp> I've never been particularly happy with transpiling things, bad expererinces from wsdl and xsd
Nov 19 11:03:54 <risk> karlp: yeah, but I'd imagine every single js framework or tool has their own philosophy on how to send web requests
Nov 19 11:04:05 <karlp> I only have a js client anyway though, so I don't see much use for transpiling (neat word)
Nov 19 11:04:17 <karlp> but if you're writing java or C# or blah clients then I guess it's more appealing
Nov 19 11:04:37 <risk> also to generate server code
Nov 19 11:04:44 <jow_laptop> I recently had a lot of fun with SOAP, WSDL and PHP
Nov 19 11:04:59 <karlp> yeah, well, I can't imagine anyeon'e written a raml server generator that makes luci controllers....
Nov 19 11:05:03 <karlp> so that's by hand too...
Nov 19 11:05:18 <risk> karlp: yeah, but maybe something exists for lua
Nov 19 11:05:26 <jow_laptop> hey, single page apps is the future, who needs servers
Nov 19 11:05:32 <risk> and cgi has been around the block for long enough
Nov 19 11:05:33 <jow_laptop> thats what the cloud is for
Nov 19 11:05:49 <risk> (not that I like cgi)
Nov 19 11:05:54 <risk> funny you mention that
Nov 19 11:06:02 <karlp> risk: maybe, they tend to be expeting luvit or similar, luci's not really the same thing there.
Nov 19 11:06:32 <karlp> where'd txomon go anyway? dropped his bomb and left?
Nov 19 11:06:34 <jow_laptop> the onyl nice thing about cgi is that it is damn simple
Nov 19 11:06:43 <plntyk> some servers are nice but recently they are only working with ipv6 because NAT/ipv4 with old stuff is not that nice
Nov 19 11:07:30 <risk> jow_laptop: I've actually thought about that, making web ui optional, to save flash
Nov 19 11:07:32 <jow_laptop> karlp: he's scared now :)
Nov 19 11:07:51 <risk> jow_laptop: but having http with endpoints that work
Nov 19 11:08:01 <jow_laptop> risk: it did a proof of concept with luci2 a while ago, works practically ootb and needed like three lines of frontend code change
Nov 19 11:08:27 <jow_laptop> you just copy your /www to some online server and extend the login form with a third field for the router host address
Nov 19 11:08:38 <risk> yeah, something like that
Nov 19 11:08:47 <risk> but it's not really handy for a router
Nov 19 11:09:04 <karlp> just need http access to the device then.  those damn network "securitay" engineers will get in the wya of that quick smart
Nov 19 11:09:07 <jow_laptop> the existing ubus-http-json-rpc (can we find a new acronym for that?) already supports all needed functionality
Nov 19 11:09:10 <risk> and then there's the version mess
Nov 19 11:09:17 <jow_laptop> the only missing bit, CORS, has been added a while back
Nov 19 11:09:50 <karlp> jow_laptop: I actually considered trying to do my stuff as a json-rpc end, but I found it too much unknown.
Nov 19 11:09:58 <plntyk> UTOC (1st, 2nd,3rd, last letter)
Nov 19 11:10:00 <karlp> I knew how to make controllers in lua and could follow things there,
Nov 19 11:10:17 <karlp> making a uhttpd json rpc backend was just dark depths with no lights.
Nov 19 11:11:08 <jow_laptop> I actually added a CGI-like facility to rpcd so that you can write rpc procedures in shell script, or any other language
Nov 19 11:13:47 <karlp> guess I just couldn't find it then :)
Nov 19 11:14:22 <jow_laptop> https://wiki.openwrt.org/doc/techref/rpcd
Nov 19 11:19:35 <karlp> heh, nice and old.  must have overlooked it while trying to sort out uhttpd-json-rpc vs ubus vs rpcd and the different things plugged into ubus.
Nov 19 11:20:22 <karlp> that probably would have been potentially easier to run locally too. running uhttpd with luci locally has never worked well, though I've not tried in a while
Nov 19 11:51:22 <OpenWrt-Commits> cyrus r47514 trunk/package/network/services/odhcpd/Makefile * odhcpd: correctly handle netlink congestion case
Nov 19 11:56:02 <OpenWrt-Commits> cyrus r47515 branches/chaos_calmer/package/network/services/odhcpd/Makefile * odhcpd: backport trunk fixes
Nov 19 12:15:48 <txomon> karlp: Sorry I needed a nap, I was really tired
Nov 19 12:16:26 <txomon> I have been f***** android for past 72 hours
Nov 19 12:16:32 <txomon> I mean of course, fantastic
Nov 19 12:17:28 <txomon> I was thinking on listening to events
Nov 19 12:17:39 <txomon> and yes, it was for ubus
Nov 19 12:17:45 * txomon is reading the conversation meanwhile
Nov 19 12:29:56 <txomon> so yeah, the only thing I really need is to listen to ubus notifications
Nov 19 12:30:02 <txomon> through http
Nov 19 12:30:12 <builder> build #147 of oxnas is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/oxnas/builds/147
Nov 19 12:30:20 <txomon> rpc won't work that way, although we would have something like AJAX, but ... xD
Nov 19 12:31:15 <txomon> my idea was to support sockets on httpd-mod-ubus
Nov 19 12:31:27 <cyrusff> jsonrpc supports notifications protocol-wise
Nov 19 12:31:43 <cyrusff> so it could be implemented using polling probably
Nov 19 12:31:52 <jow_laptop> well any kind of active listening on the client side does not map well to http
Nov 19 12:32:12 <jow_laptop> one end has to poll and the other end needs to queue
Nov 19 12:32:30 <txomon> yeah, but I wanted to get rid of the polling, moreover if it exists a better way to do it...
Nov 19 12:32:57 <txomon> s,better,"better",
Nov 19 12:33:25 <jow_laptop> right now there is no websocket ubus transport implemented
Nov 19 12:34:03 <cyrusff> jow_laptop: you would need some sort of queueing anyway, since you would need to actively subscribe
Nov 19 12:34:10 <cyrusff> via ubus
Nov 19 12:34:28 <cyrusff> or well you'd need some sort of per-client state at least
Nov 19 12:34:39 <txomon> cyrusff: of course, you have to even maintain the connection
Nov 19 12:34:58 <txomon> my idea would be to provide WS for just the ubus endpoint
Nov 19 12:36:00 <txomon> I dunno how is uhttpd done inside and how much does ubus mod do, but maybe if we support just a few basics of the WS protocol is assumable
Nov 19 12:36:02 <cyrusff> my point is, the rpcd would need to subscribe on the client's behalf anyway
Nov 19 12:36:06 <jow_laptop> anbody with ncm protocol experiene here?
Nov 19 12:36:26 <txomon> cyrusff: why would rpcd need to subscribe on the client's behalf?
Nov 19 12:36:36 <jow_laptop> got a bug report for luci which boils down to `ifstatus network-with-ncm` not reporting any ip address
Nov 19 12:37:32 <cyrusff> jow_laptop: maybe it boils down to the use of subprotocols
Nov 19 12:37:44 <cyrusff> so that its really ifstatus network-with-ncm_4 or so
Nov 19 12:37:59 <txomon> my idea was to maintain the same protocol, jsonrpc2 but with serialized
Nov 19 12:38:01 <cyrusff> txomon: because you don't get ubus events which you arent't subscribed to
Nov 19 12:38:18 <cyrusff> and rpcd is just another ubus-client in that sense
Nov 19 12:38:21 <txomon> cyrusff: for sure the ubus mod should need to be updated to allow subscription
Nov 19 12:39:16 <karlp> repalce ubus with mosquitto? ;)
Nov 19 12:39:33 * karlp ducks...
Nov 19 12:39:39 <cyrusff> karlp: nah i guess we can do better and find even more bloated protocols
Nov 19 12:40:01 <cyrusff> something with XML over SOAP or so
Nov 19 12:40:09 <txomon> the three modifications I see is: 1) uhttpd to support WS handshake 2) uhttpd-mod-ubus to support WS protocol 2) uhttpd-mod-ubus to allow subscription
Nov 19 12:40:12 <karlp> cyrusff: mqtt is just binary with topics for pub/sub...
Nov 19 12:40:25 <karlp> just like ubus, only... not proprietary openwrt...
Nov 19 12:40:43 <cyrusff> ah think i confused it with something else then
Nov 19 12:41:02 <karlp> mqtt doesn't say anything at all about the messages
Nov 19 12:41:07 <jow_laptop> cyrusff: subprotcols? please not
Nov 19 12:42:07 <txomon> anyway, I just want to be able to subscribe to ubus from a remote client
Nov 19 12:42:33 <cyrusff> txomon: sounds like overkill
Nov 19 12:42:46 <cyrusff> to do WS just for the subscription bits
Nov 19 12:43:02 <txomon> cyrusff: without polling. I need to be able to get rid of any polling
Nov 19 12:43:34 <txomon> if you want responsive workflows, you need it to be as fast as possible
Nov 19 12:43:44 <jow_laptop> just poll faster :D
Nov 19 12:43:56 <cyrusff> well how does WS get rid of polling?
Nov 19 12:44:02 <cyrusff> its tcp so it will at least poll on that layer
Nov 19 12:44:31 <cyrusff> all that it does is save you a few bytes for the http request
Nov 19 12:44:43 <jow_laptop> well I suppose txomon means the tradition window.setInterval / window.setTimeout poll loop
Nov 19 12:44:46 <cyrusff> jow_laptop: many of the 3g/4g protocols just setup an L2
Nov 19 12:44:58 <jow_laptop> cyrusff: well devstatus has the ip and ifstatus not
Nov 19 12:44:58 <cyrusff> and then spawn a subprotocol to run dhcp and dhcpv6 over it
Nov 19 12:45:14 <cyrusff> can you get a network interface dump?
Nov 19 12:45:23 <cyrusff> then we know whats going on
Nov 19 12:45:26 <jow_laptop> I changed luci to ifstatus recently and of course everything broke
Nov 19 12:45:34 <jow_laptop> I requested a dump, yes
Nov 19 12:46:02 <jow_laptop> whenever I seriously try to move away from getifaddrs, uci state vars to ubus, I notice stuff not working :)
Nov 19 12:46:16 <txomon> jow_laptop: yeah, that's what I want to avoid, anyway, while learning android I am doing a ubus rpc interface for android
Nov 19 12:46:44 <txomon> and I realized you can't really replicate ubus there...
Nov 19 12:46:49 <jow_laptop> txomon: the simplest intermeidate solution would be a long polling implementation
Nov 19 12:47:20 <txomon> jow_laptop: and the best to allow server->client communication?
Nov 19 12:47:27 <txomon> using http
Nov 19 12:47:30 <jow_laptop> long polling
Nov 19 12:48:13 <cyrusff> jow_laptop: basically "ubus call network.interface dump" and aggregate all information with matching l3_devices
Nov 19 12:49:07 <jow_laptop> cyrusff: yeah thats exactly what I did not want to do anymore
Nov 19 12:49:15 <jow_laptop> hence moving to ifstatus
Nov 19 12:49:36 <jow_laptop> simple usecase: having a wan with dhcp and some @wan alias with static ipaddr
Nov 19 12:50:11 <jow_laptop> I don't want wan to have both ips displayed next to it. I want wan to display the dhcp ip and the alias interface to display its static ip
Nov 19 12:50:17 <karlp> txomon: you could probably write a pretty trivial ubus<->mqtt bridge actually.  havne't played with the auth stuff much though, but they both offer pub/sub, so just susbcribe to * on ubus and repost to mqtt, and listen to * on mqtt and repost to ubus?
Nov 19 12:52:05 <jow_laptop> cyrusff: can we add an initiator property to those subiface so we at least know what they relate to?
Nov 19 12:52:34 <jow_laptop> without grouping by l3device because then we'd mix logically separate networks
Nov 19 13:03:50 <cyrusff> hmm is the original "ifname" exported?
Nov 19 13:03:59 <cyrusff> because then you could simply parse @foo
Nov 19 13:04:09 <cyrusff> and see what parent a subinterface belongs to
Nov 19 13:05:39 <cyrusff> but i guess we could also export a "virtual" flag in addition
Nov 19 13:10:25 <cyrusff> http://git.openwrt.org/?p=project/netifd.git;a=commitdiff;h=48c0fbee548206058c399a73a80178cdcfec3fc7
Nov 19 13:11:20 <cyrusff> dynamic=false: interface is in config, dynamic=true: interface is virtual and is deleted once it goes down for any reason
Nov 19 13:19:39 <txomon> karlp: my idea was to use the same transport as the rest of ubus really...
Nov 19 13:20:43 <txomon> but yeah for the moment, and until they approve me using the ubus backend like I am, I will stick to the long polling option
Nov 19 14:45:18 <OpenWrt-Commits> wigyori r47516 trunk/package/boot/uboot-sunxi/patches/002-add-lamobo-r1.diff * packages: uboot-sunxi: update Lamobo R1 patch
Nov 19 15:24:00 <builder> build #147 of realview is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/realview/builds/147
Nov 19 15:46:37 <wubblepuff> rmilecki, hi. I was send by hacking gluon to you because you might be interessted in something b43 related. here is a dmesg for you pastebin.com/Crr59XfY
Nov 19 15:53:21 <wubblepuff> rmilecki, notice "[    0.264000] ssb: WARNING: Invalid SPROM CRC (corrupt SPROM)"
Nov 19 16:11:05 <builder> build #128 of avr32 is complete: Failure [failed shell_10]  Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/128
Nov 19 18:31:55 <rmilecki> wubblepuff: nothing extraordinary i can see there
Nov 19 18:32:12 <rmilecki> wubblepuff: this is SPROM-less PCIe card, so it doesn't containt SPROM
Nov 19 18:32:16 <rmilecki> SPROM should be provided by platform
Nov 19 18:32:23 <rmilecki> it seems bcm63xx doesn't provide it
Nov 19 18:37:25 <builder> build #132 of xburst is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/xburst/builds/132
Nov 19 19:19:31 <builder> build #128 of mxs is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/mxs/builds/128
Nov 19 19:28:59 <jow_laptop> cyrusff: thanks but thats only marginally useful - something like parent=wan6 or section=wan6 would be helpful
Nov 19 19:29:39 <cyrusff> jow_laptop: reiterating here: isn't that saved in ifname?
Nov 19 19:29:56 <cyrusff> or does netifd use the resolved ifname instead of providing say @wan6
Nov 19 19:29:58 <cyrusff> ?
Nov 19 19:30:04 <cyrusff> in the ubus output
Nov 19 19:30:32 <jow_laptop> but how can I differentiate a virtual iface from two configured ifaces sharing the smae l3device?
Nov 19 19:30:54 <jow_laptop> even if I group by l3device
Nov 19 19:31:09 <cyrusff> no, thats not what i mean
Nov 19 19:31:33 <cyrusff> so a virtual interface is just an interface that doesn't exist in config and is forgotten when it goes down
Nov 19 19:31:52 <cyrusff> a subprotocol is usually just a combination of virtual interface and ifname=@parent
Nov 19 19:32:15 <cyrusff> so once we export the originally configured ifname (e.g. @parent) you could replicate the relations
Nov 19 19:32:23 <cyrusff> so questions was: do we already do that?
Nov 19 19:32:31 <jow_laptop> not sure if we really could
Nov 19 19:32:48 <jow_laptop> what if two interfaces share the same device and each spawn virtual subifaces
Nov 19 19:32:55 <jow_laptop> how to group them?
Nov 19 19:33:34 <cyrusff> okay let's say: name=wan,ifname=eth0,proto=dhcp and name=wan6,ifname=eth0,proto=dhcpv6
Nov 19 19:33:58 <cyrusff> wan has wan_6,ifname=@wan,proto=6rd and wan6 has wan6_4,ifname=@wan6,proto=dslite
Nov 19 19:34:15 <cyrusff> as subinterface respectively
Nov 19 19:34:28 <cyrusff> so their ifname is different
Nov 19 19:34:44 <jow_laptop> in the interface dump the l3_devices are resolved
Nov 19 19:34:48 <jow_laptop> e.g. wwan0
Nov 19 19:35:01 <cyrusff> yeah, my question was: is the l2_device exported?
Nov 19 19:35:11 <cyrusff> l3_device you cannot use anyway
Nov 19 19:35:21 <cyrusff> since for a tunnel the l3_device of the subinterface would be different
Nov 19 19:35:29 <jow_laptop> l2 is exported and resolved as well
Nov 19 19:35:44 <cyrusff> okay, so we need to export the unresolved l2
Nov 19 19:35:56 <jow_laptop> but separately
Nov 19 19:36:15 <jow_laptop> don't need unresolved stuff in ubus just to painfully solve it myself
Nov 19 19:36:32 <cyrusff> sure
Nov 19 19:36:41 <cyrusff> so guess we want parent=wan
Nov 19 19:36:56 <jow_laptop> yeah, preferably something that can be directly used for uci queries
Nov 19 19:37:09 <cyrusff> uci is problematic
Nov 19 19:37:10 <jow_laptop> i.e. section=wan
Nov 19 19:37:20 <cyrusff> since subinterfaces can have subinterfaces
Nov 19 19:37:37 <jow_laptop> I only care about the initial originator, if there's one
Nov 19 19:37:55 <jow_laptop> and sub-sub-ifaces would still have section=<whatever triggered the chain>
Nov 19 19:38:06 <cyrusff> well the parent of a sub-sub is the sub-
Nov 19 19:38:06 <OpenWrt-Commits> hauke r47517 trunk/package/firmware/ath10k-firmware/Makefile * ath10k-firmware: fix patch of firmware
Nov 19 19:38:19 <jow_laptop> hence not parent=... but section=...
Nov 19 19:38:22 <jow_laptop> would make it clear
Nov 19 19:38:48 <jow_laptop> i.e. t get rid of / shutdown sub-sub-foo, delete section foo
Nov 19 19:39:09 <wubblepuff> rmilecki, so sprom warning is no issue then? it's just wifi doesn't seem to connect to anything. is it a gluon bug? spw303v wifi doesn't work in openwrt. I added the "fallback_sprom" entry from homehub2a patch to spw303v patch. after that b43 module loads, with that warning though,
Nov 19 19:40:00 <cyrusff> jow_laptop: well the "dynamic"-flag aside there is no difference between an @wan interface that is explicitly written in the config
Nov 19 19:40:15 <cyrusff> or one that was spawned as a virtual subinterface by a protocol handler
Nov 19 19:40:47 <jow_laptop> well my use case is:
Nov 19 19:41:09 <jow_laptop> uci foreach "network", "interface"
Nov 19 19:41:30 <jow_laptop> ubus call network.interface status [interface name] -> report ipv4-address
Nov 19 19:41:43 <jow_laptop> that fails for any proto ncm interface
Nov 19 19:42:06 <jow_laptop> and by merely grouping by device I might report addresses belonging to a forein uci section
Nov 19 19:42:15 <jow_laptop> which I do not want
Nov 19 19:42:23 <jow_laptop> so how to solve?
Nov 19 19:42:25 <cyrusff> problem with that is that there may be something in the future which just creates a virtual interface out of a daemon
Nov 19 19:42:35 <jow_laptop> thats fine, then it has no config
Nov 19 19:42:56 <cyrusff> so you don't care about that
Nov 19 19:43:11 <wubblepuff> rmilecki, also it seem openwrt/gluon doesn't get a mac adress for wifi (ff:ff:ff...)
Nov 19 19:43:18 <jow_laptop> what I care about is that interconnected interfaces can be related to each other
Nov 19 19:43:25 <cyrusff> wubblepuff: what is a gluon?
Nov 19 19:43:35 <jow_laptop> cyrusff: freifunk openwrt fork
Nov 19 19:44:02 <cyrusff> ah, fancy name
Nov 19 19:44:12 <cyrusff> anyway
Nov 19 19:44:15 <wubblepuff> cyrusff, https://github.com/freifunk-gluon/gluon
Nov 19 19:44:15 <jow_laptop> cyrusff: either those sub-hierarchies need to point to some unique id to group them (e.g. uci section name), or have a simple .parent property chain so I can group them
Nov 19 19:44:55 <cyrusff> yeah, that parent property should be doable
Nov 19 19:44:56 <jow_laptop> so I were to report that proto=ncm iface, I would merge the states of all other ifaces having .parent = <this-ncm-iface>
Nov 19 19:45:03 <jow_laptop> +if
Nov 19 19:45:56 <jow_laptop> even better would be a childs = [ ... ] on the parent but that is probably harder to implement and not worth it
Nov 19 19:46:36 <jow_laptop> I guess the parent has no knowledge at all of potential sub-ifaces
Nov 19 19:47:12 <jow_laptop> that virtual flag should be kept anyway, this allows easy exclusion of non-config interfaces
Nov 19 19:53:44 <cyrusff> i think children might even be easier
Nov 19 19:53:58 <jow_laptop> great
Nov 19 19:54:00 <cyrusff> based on device_users
Nov 19 19:54:10 <jow_laptop> because in practise the childs of a given interest are of more interest than the parent
Nov 19 19:54:18 <jow_laptop> especially if the parent itself carries no ip config
Nov 19 19:54:26 <jow_laptop> *of a given interface
Nov 19 20:51:13 <OpenWrt-Commits> hauke r47518 packages/utils/sane-backends * sane-backends: moved to github
Nov 19 20:51:34 <OpenWrt-Commits> hauke r47519 packages/utils/canutils * canutils: moved to github
Nov 19 20:52:01 <OpenWrt-Commits> hauke r47520 packages/utils/bandwidthd * bandwidthd: moved to github
Nov 19 20:52:41 <OpenWrt-Commits> hauke r47521 packages/net/reaver * reaver: moved to github
Nov 19 20:53:05 <OpenWrt-Commits> hauke r47522 packages/net/nbd * nbd: moved to github
Nov 19 20:53:29 <OpenWrt-Commits> hauke r47523 packages/net/htpdate * htpdate: moved to github
Nov 19 20:53:49 <OpenWrt-Commits> hauke r47524 packages/net/chrony * chrony: moved to github
Nov 19 20:54:27 <OpenWrt-Commits> hauke r47525 packages/net/chaosvpn * chaosvpn: moved to github
Nov 19 20:54:47 <OpenWrt-Commits> hauke r47526 packages/net/atftp * atftp: moved to github
Nov 19 20:55:07 <OpenWrt-Commits> hauke r47527 packages/libs/libgee * libgee: moved to github
Nov 19 20:55:25 <OpenWrt-Commits> hauke r47528 packages/lang/tcl * tcl: moved to github
Nov 19 20:56:18 <OpenWrt-Commits> hauke r47529 packages/lang/python-crypto * python-crypto: moved to github
Nov 19 20:57:30 <rmilecki> wubblepuff: i have no idea about bcm63xx fallback, gluon, homehub2a & spw303v
Nov 19 20:57:44 <rmilecki> wubblepuff: there should be SPROM fallback implementation filling all important fields in SPROM struct
Nov 19 20:57:51 <rmilecki> e.g. MAC address, boardflags, etc.
Nov 19 20:59:05 <rmilecki> wubblepuff: http://lxr.free-electrons.com/source/arch/mips/bcm47xx/sprom.c?v=4.2 this is how bcm47xx handles this
Nov 19 20:59:11 <rmilecki> on bcm47xx there is NVRAM
Nov 19 20:59:19 <rmilecki> so we query NVRAM & put data in SPROM struct
Nov 19 20:59:29 <rmilecki> wubblepuff: you may ask KanjiMonster for some help
Nov 19 21:00:31 <KanjiMonster> on bcm63xx there is no sprom data in nvram, so we have to hardcode it
Nov 19 21:01:30 <wubblepuff> basically I'm missing something
Nov 19 21:02:22 <wubblepuff> rmilecki, thanks
Nov 19 21:03:32 <wubblepuff> KanjiMonster, is there something I could provide like logs for this?
Nov 19 21:07:16 <builder> build #127 of kirkwood is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/kirkwood/builds/127
Nov 19 21:10:30 <OpenWrt-Commits> hauke r47530 packages/net/gpsd * gpsd: moved to github
Nov 19 21:51:28 <OpenWrt-Commits> nbd r47531 trunk/package/system/ubus/Makefile
Nov 19 21:51:28 <OpenWrt-Commits> ubus: update to the latest version, adds support for monitoring system bus traffic
Nov 19 22:02:56 <builder> build #130 of ar7 is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/ar7/builds/130
Nov 19 22:18:03 <builder> build #119 of mpc83xx is complete: Failure [failed shell_10]  Build details are at http://buildbot.openwrt.org:8010/builders/mpc83xx/builds/119
Nov 20 00:36:18 <builder> build #115 of mpc52xx is complete: Failure [failed shell_10]  Build details are at http://buildbot.openwrt.org:8010/builders/mpc52xx/builds/115
**** ENDING LOGGING AT Fri Nov 20 02:59:58 2015