2014-10-27 GnuCash IRC logs
00:23:14 *** benjamin-agaric has quit IRC
00:48:35 *** fell_ has quit IRC
02:12:51 *** MechtiIde has joined #gnucash
02:48:08 *** GabrieleV_ has joined #gnucash
02:48:46 *** GabrieleV has quit IRC
02:48:46 *** GabrieleV_ is now known as GabrieleV
03:13:31 *** O01eg has quit IRC
03:25:15 <Simon> the guile auto-compile output goes to stderr... which is not appropriate
03:30:32 *** aqua___ has joined #gnucash
03:34:19 *** wol has joined #gnucash
03:58:11 *** cartsoftware has joined #gnucash
04:26:02 *** cartsoftware1 has joined #gnucash
04:26:02 *** cartsoftware has quit IRC
04:48:49 *** wol has quit IRC
04:48:51 *** wol has joined #gnucash
04:59:35 *** aqua___ has quit IRC
05:23:27 *** wol has quit IRC
05:28:38 *** ErKa has quit IRC
06:27:22 *** aqua___ has joined #gnucash
06:39:30 *** Jimraehl1 has left #gnucash
06:43:06 *** cartsoftware1 has quit IRC
06:43:48 *** cartsoftware has joined #gnucash
06:47:50 *** Jimraehl1 has joined #gnucash
06:48:13 *** gjanssens has joined #gnucash
06:48:13 *** gncbot sets mode: +o gjanssens
06:55:54 *** aqua___ has quit IRC
07:05:33 *** fell_ has joined #gnucash
07:05:33 *** gncbot sets mode: +o fell_
07:16:16 *** benjamin-agaric has joined #gnucash
07:41:04 *** AndreeeCZ__ has joined #gnucash
07:42:19 *** andy has quit IRC
07:50:13 *** andy has joined #gnucash
07:55:25 *** MechtiIde has quit IRC
08:06:01 *** cartsoftware has quit IRC
08:08:23 *** cartsoftware has joined #gnucash
08:29:44 *** aqua___ has joined #gnucash
08:31:51 <warlord> Simon: I dont think we really have any way to control that.
08:33:12 *** GabrieleV_ has joined #gnucash
08:33:13 *** GabrieleV has quit IRC
08:33:13 *** GabrieleV_ is now known as GabrieleV
08:34:42 *** Gbarr has joined #gnucash
08:44:43 *** aqua___ has quit IRC
08:49:38 *** AndreeeCZ_ has joined #gnucash
08:56:09 *** cartsoftware has quit IRC
08:57:47 *** cartsoftware has joined #gnucash
08:58:56 *** AndreeeCZ__ has quit IRC
09:13:17 *** Jeff999 has joined #gnucash
09:15:33 *** AndreeeCZ_ has quit IRC
09:19:01 *** benjamin-agaric has quit IRC
09:24:17 *** wol has joined #gnucash
09:26:00 *** wol has quit IRC
09:44:38 *** lmat has joined #gnucash
09:45:37 *** MechtiIde has joined #gnucash
09:49:04 *** benjamin-agaric has joined #gnucash
09:53:22 *** Gbarr has quit IRC
09:53:53 *** himaxx has joined #gnucash
10:01:50 *** Gbarr has joined #gnucash
10:42:03 *** benjamin-agaric has quit IRC
11:09:43 *** wol has joined #gnucash
11:45:52 *** O01eg has joined #gnucash
11:46:33 *** ErKa has joined #gnucash
11:51:04 *** lmat has quit IRC
11:58:25 <gjanssens> warlord: "singe-issue voters" vs "single-issue-software-users" - what does that mean ?
12:01:55 <warlord> There's a concept here in the US of a "single issue voter"
12:03:55 <warlord> Basically it's someone who votes purely on the basis of a single issue. "I want lower taxes", so they'll vote for someone who will restrict everything else so long as they say they will lower taxes, any other issue be damned.
12:04:22 <gjanssens> Ok, got it
12:04:46 <gjanssens> We do have indeed several "not-yet-users like that as well...
12:05:19 <warlord> In this case it was a user who only cared about a single feature: saving check payee addresses. Nothing else seems to matter except that one feature.
12:06:27 <gjanssens> Heh, there's always that "one last issue preventing them from switching"...
12:06:51 <warlord> yep
12:13:26 *** jralls has quit IRC
12:13:48 *** jralls has joined #gnucash
12:13:48 *** gncbot sets mode: +o jralls
12:22:45 <jralls> I went to the GSoC reunion over the weekend and several people told me that they'd used GnuCash briefly but decided that they weren't compulsive enough to keep going. One switched to Ledger for reasons he couldn't articulate well enough for me to understand, the rest just quit tracking their money at all.
12:24:53 <warlord> Well, we can't force people to keep track of their own finances..
12:27:11 <jralls> ;-)
12:28:48 *** wol has quit IRC
12:42:12 *** lmat has joined #gnucash
12:44:18 <gjanssens> :)
12:44:53 <gjanssens> jralls: I tried to install the nightly build to test your webkit work but the installer freezes while installing a fedora png :(
12:45:24 <gjanssens> I'm not sure the problem is with the installer though as I had a similar problem last week with one of my own builds
12:45:43 <gjanssens> On that build I reran dist.sh and that fixed it
12:45:53 <gjanssens> I haven't done that yet for the nightly
12:46:17 <jralls> A fedora png? Must be from Webkit share.
12:46:27 <gjanssens> I suppose so.
12:47:05 <gjanssens> My own build didn't fail on the fedora png, but on another one (there was no fedore png just yet)
12:47:06 <jralls> I doubt that we need those, they're probably for the sample browser. I can take them out of the binary tarball.
12:47:43 <gjanssens> That's fine. However the installer shouldn't freeze on it
12:48:06 <jralls> The tag build I ran yesterday failed because the upgraded gnutls that webkit needs didn't include libgcrypt, which gwen needs. Working on that now.
12:48:34 <jralls> I've got enough time today to test properly before trying another tag build.
12:50:07 <jralls> Sligtht change of subject: I take it that Win32 is still using Guile 1.8 because you couldn't get 2.0 to build on Win32. What problems did you have?
12:53:37 <gjanssens> There were several.
12:54:13 <gjanssens> You can find a summary by reading my mail conversation on mingw-user
12:54:16 <gjanssens> http://sourceforge.net/p/mingw/mailman/mingw-users/thread/16994493.5VZvzMHYWc%40legolas.kobaltwit.lan/#msg32809708
12:55:25 <gjanssens> The end conclusion is that guile 2 needs several patches that are not integrated yet
12:55:51 <gjanssens> And libunistring which is shipped with mingw needs patching as well
12:56:14 <gjanssens> I briefly ran an experiment using EZWinPorts' version of Guile 2
12:56:54 <gjanssens> That worked but didn't solve codepage issues I was looking at then
12:57:14 <gjanssens> And finally I ran out of time so I never continued
12:57:41 <gjanssens> Switching to EZWinports's version is fairly easy though
12:58:10 <gjanssens> And that version is built with a recent gcc so should be ABI compatible
12:58:58 <jralls> Codepage issues are the bane of Win32. Python has similar troubles. Does Guile have a way to override the lies that Win32 tells it about what encoding to use?
12:59:39 <jralls> We basically want to force UTF8 for everything except filesystem access, which should be UTF16.
13:04:53 <gjanssens> I don't know really
13:05:09 <gjanssens> And I'm afraid none of the guile devs knows either
13:05:54 <gjanssens> They're not really Windows minded and that's putting it mildly
13:06:24 <gjanssens> On the other hand guile does have a set-locale command
13:06:41 <gjanssens> Which works exactly like set_locale in C
13:06:59 <jralls> Isn't that because it just calls the C one?
13:07:08 <gjanssens> Heh, probably...
13:07:14 <gjanssens> Never occured to me :)
13:08:11 <gjanssens> BTW: I haven't gotten a sensible response about how guile handles ABI changes and pre-compiled files
13:08:30 <gjanssens> Seems that's also something not part of the guile mindset
13:08:41 <gjanssens> They heavily promote autocompilation
13:09:10 <gjanssens> But IMO that doesn't work well for distributions
13:09:45 <gjanssens> And even the scm files/modules that ship with guile itself are pre-compiled
13:11:46 <jralls> Really? In the source tarballs? Or they're compiled when you make guile, so that they wind up in the rpm or whatever?
13:12:43 <jralls> If the latter we can do the same with the GC scheme modules.
13:15:35 <jralls> Though maybe we should do a Guile version check at startup to protect against the distro upgrading guile without rebuilding the GC pacakge.
13:17:02 *** aqua___ has joined #gnucash
13:23:58 <warlord> jralls: you mean from like 2.x to 2.x+1 or do you mean from 2.x.y to 2.x.y+1?
13:24:54 <jralls> Unfortunately I'm afraid we'll have to check y+1 since Geert thinks that ABI is a foreign concept to the Guile team.
13:25:09 <gjanssens> jralls: they're compiled when you make guile
13:25:28 <gjanssens> And re ABI
13:25:54 <gjanssens> Guile 2 is the first version that compiles scm files
13:26:00 <gjanssens> So it's pretty new
13:26:46 <gjanssens> They haven't had to deal with this yet
13:27:36 <gjanssens> How is this dealt with in the python world ?
13:28:37 <jralls> That would mean that they're a bunch of noobs, and I'm pretty sure that's not true at least of Andy Wingo. I think it's more likely that they saw an opportunity for a speedup and didn't pause to carefully think through the implications before releasing it.
13:30:22 <jralls> I don't know, but I've never had a problem with Python like the Fedora bug.
13:32:15 *** fell__ has joined #gnucash
13:32:15 *** gncbot sets mode: +o fell__
13:34:17 *** MechtiIde has quit IRC
13:34:50 <jralls> But I'm confused on that bug how the .go files from the previous version being in the user cache interfered with a new version of GC if we were preventing Guile from loading them by specifying the .scm file.
13:38:15 <gjanssens> Heh, welcome to guile :)
13:39:24 <jralls> Makes me wonder if Guile is dependable enough to rely on going forward.
13:39:30 <gjanssens> By using the .scm extension in load-from-path pre-compiled files are never found
13:39:44 <gjanssens> So it always resorts to its autocompilation mechanism
13:40:00 <gjanssens> But that mechanism also caches its compiled files
13:40:12 *** fell_ has quit IRC
13:40:21 <gjanssens> And these compiled files *will* be found on the next autocompilation attempt
13:41:00 <gjanssens> The .scm extension bug only affects the code path looking for suitable files on the %load-compiled-path
13:41:42 <gjanssens> Since we never did self-compile our scheme files, these autocompiled files were still there from the last gnucash run
13:42:00 <gjanssens> And will be found again after the new gnucash rpm is installed
13:42:44 <gjanssens> And as rpm honours build dates of the files it installs, the newly installed scheme files *can* appear to be older than the cached autocompiled files
13:43:17 <gjanssens> I poked to guile devs again on the compatibility issue
13:43:35 <gjanssens> Here's the answer: they *think* guile 2
13:43:41 <gjanssens> (oops)
13:44:14 <gjanssens> they *think* guile 2.2 will resort to autocompilation if it encounters a *.go file compiled by guile 2.0
13:44:16 <jralls> So removing the extension when calling load-from-path lets Guile find .go files which were built during make, and are packaged in the rpm.
13:44:32 <gjanssens> exactly
13:44:56 <gjanssens> I have opened a bug report against guile for this inconsistent behaviour (to which the guile devs agreed)
13:45:24 <gjanssens> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18835
13:45:50 <gjanssens> Well they acknowledged it to be a bug on irc, not the bug itself yet...
13:46:38 <jralls> We're not in a position to be throwing rocks about timely response to bug reports...
13:47:05 <gjanssens> :D I wasn't throwing rocks
13:47:16 <gjanssens> Just clarifying my own statements
13:48:06 <gjanssens> And re ABI compatibility they added this in the context of distributions as well:
13:48:30 <gjanssens> Assume fedora releases a gnucash package built against guile 2 (with self-compiled scm files)
13:48:48 <gjanssens> (guile 2.0 that is)
13:49:16 <gjanssens> and then fedora updates to guile 2.2, it should re-release gnucash to ship the updated *.go files
13:49:41 <gjanssens> I wonder how such a dependency would get encoded in the rpm spec...
13:50:20 <gjanssens> Probably "requires: guile = 2.0" instead of "requires: guile >= 2.0"
13:51:01 <jralls> Yes. Now what about built with 2.0.11 and upgrades to 2.0.13?
13:54:38 <warlord> You can make an RPM that depends on the exact version of guile.
13:55:20 <gjanssens> Yes. It will be up to the maintainers to remember doing so.
13:55:32 <warlord> or even the exact version of another package. Although usually that's only used for internal dependencies (i.e., when you break apart a package) but you can use similar features to make the rpm depend on the exact version it was built against.
13:57:00 <jralls> I was actually wondering what the Guile devs say about .go files built with 2.0.11 when the user upgrades to 2.0.13.
13:59:33 <gjanssens> I have asked the question, no answer yet.
14:11:04 *** AndreeeCZ_ has joined #gnucash
14:13:28 <gjanssens> Answer: ABI changes only happen on major releases (like 2.0 to 2.2)
14:13:55 *** wol has joined #gnucash
14:14:15 *** GabrieleV_ has joined #gnucash
14:14:17 <jralls> Ah, so they are paying attention to ABI. That's good news.
14:14:21 *** GabrieleV has quit IRC
14:14:21 *** GabrieleV_ is now known as GabrieleV
14:14:30 <gjanssens> And mark_weaver helpfully added that if C code is involved an application is tied to one version of guile anyway
14:14:52 <gjanssens> So when guile 2.2 comes out, fedora would have to recompile gnucash anyway to be compatible with it
14:15:05 <gjanssens> One thing less to worry about :)
14:15:08 <gjanssens> Pfew
14:22:23 <warlord> good news
14:54:20 *** wol has quit IRC
14:58:57 *** lwells has joined #gnucash
15:31:33 *** lwells has quit IRC
15:42:08 *** lmat has quit IRC
16:05:57 <Simon> warlord: raise it as a bug against Guile?
16:06:50 *** AndreeeCZ_ has quit IRC
16:11:08 *** StuM has quit IRC
16:16:18 *** aqua___ has quit IRC
16:19:04 <warlord> Simon: yep
16:23:48 <Simon> and it seems to do nothing if a price actually fails to update
16:23:53 <Simon> exit code 0 and no stderr output
16:46:36 *** jralls has quit IRC
16:47:30 *** jralls has joined #gnucash
16:47:31 *** gncbot sets mode: +o jralls
16:53:26 <gjanssens> OT: I'm struggling with configuring static routes on my vm server
16:53:48 <gjanssens> Can I ask about it here ?
17:16:46 <warlord> gjanssens: sure, although I'm going to be AFK for a while.
17:17:26 <gjanssens> Ok we'll see where we get
17:17:36 <gjanssens> Have a look at this routing table: http://paste.kde.org/puaysyp6j
17:18:19 <gjanssens> The server has one nic (eth0) with ip address *.151
17:18:32 <gjanssens> The gateway is *.129
17:18:56 <warlord> what's the network mask? I don't see any "network" address for the interface.
17:19:03 <gjanssens> Then I have a xen guest set up which should listen on *.156
17:19:11 <warlord> e.g., one would expect to see something like:
17:19:16 <gjanssens> The network mask is /32
17:19:33 <warlord> a /32 is a single host. You can't have multiple hosts on a /32.
17:19:43 <warlord> You need at smallest a /30
17:19:47 <gjanssens> This is a single IP assigned by my hosting provider
17:20:02 <warlord> You cannot route a /32
17:20:08 <gjanssens> Where do you see multiple hosts on /32 ?
17:20:17 <warlord> You dont
17:20:20 <warlord> A /32 is a single host
17:20:23 <warlord> non-routed
17:20:27 <warlord> it's a "host address"
17:20:31 <warlord> you cannot route to/from that.
17:20:35 <warlord> it's an end address.
17:20:37 <gjanssens> Ok which address your you taking about ?
17:20:45 <warlord> the network
17:20:57 <warlord> I would expect to see something like:
17:21:14 <warlord> 176.9.23.0/24 dev eth0 ....
17:21:27 <warlord> (run ip route on your current system to see what I mean)
17:22:42 <gjanssens> For the record I'm following these guidelines from the hosting provider:
17:22:44 <gjanssens> http://wiki.hetzner.de/index.php/Netzkonfiguration_CentOS/en#Additional_IP_addresses_.28virtualization.29
17:23:59 <gjanssens> So how do you say "this host is reachable via that route" ?
17:24:16 <gjanssens> Because effectively I can't reach the *.156 address
17:24:46 <gjanssens> When I ping it (from my workstation), I see the ping appears on the server's eth0
17:25:02 <gjanssens> But from there it vanishes
17:25:13 <gjanssens> It never appears on br0
17:28:02 <gjanssens> However when logged in into the server over ssh, I can from there ssh to the *.156 guest
17:28:24 <gjanssens> So locally on the server that route definition seems to work
17:30:08 <gjanssens> Also I don't see why you can't route to/from a host
17:30:27 <gjanssens> The man page or "route" suggests you can:
17:31:22 <gjanssens> Route manipulates the kernel’s IP routing tables. Its primary use is to set up static routes to specific *hosts* or networks via an interface after it has been configured with the ifcon-fig(8) program.
17:31:30 <gjanssens> (emphasis mine)
17:35:09 *** aqua___ has joined #gnucash
17:38:01 *** jralls has quit IRC
17:38:33 *** jralls has joined #gnucash
17:38:34 *** gncbot sets mode: +o jralls
17:45:15 <jralls> gjanssens: 176.9.23.129 is your ISP's router. 176.9.23.156 is your computer's connection to the outside world. You need a separate local network to connect your VMs to. The VM software should provide that for you, along with an IP for your actual computer.
17:46:15 <gjanssens> jralls: no 176.9.23.156 is the ip address for the vm, 176.9.23.151 is the host's ip
17:46:51 <gjanssens> the separate local network is a selfconfigured bridge (br0)
17:47:04 <gjanssens> The vm is connected to this bridge
17:47:17 <gjanssens> And traffic between the host (server) and the guest is working fine
17:47:18 <jralls> You can't do that. 176.9/16 belongs to your ISP, and 176.9.23.156 belongs to another customer.
17:47:55 <gjanssens> Eh no, I got two ip addresses: 176.9.23.151 and 176.9.23.156 assigned directly to me
17:48:13 <gjanssens> And that's actually all ipv4 addresses I have
17:48:59 <gjanssens> The idea is to set up a routed configuration, where the vm is using a public ip address
17:49:11 <jralls> Ah. Usually you only get one, and you're expected to run a NAT router between the outside and inside.
17:50:15 <gjanssens> NAT routing is one of three supported methods in xen
17:50:22 <gjanssens> The other two are bridged and routed
17:51:14 <gjanssens> Unfortunately I can't use the (much easier) bridged mode because that would mean I can't set up ipv6 according to the hetzner wiki page
17:52:23 <jralls> OK, so you're using routed. That routing table should be set up in Xen, IIRC.
17:53:07 <gjanssens> Not anymore. As of xen 4.1 the admin is allowed to set up the routing by himself and as of 4.2 he's even required to do so
17:53:41 <gjanssens> And frankly it doesn't look like the issue is with xen
17:54:24 <gjanssens> When I ping from a remote host, the icmp-request packets appear on the external interface, but not on the bridge
17:56:48 <gjanssens> The bridge is something purely host side. So my routing should be able to forward the ping packets from the external to the bridge at least
17:57:12 <gjanssens> If not to the guest then I'd have to go search the xen configuration
17:57:45 <gjanssens> Or is that already a false assumption ?
17:58:22 <jralls> Try changing line 3 to 176.9.23.1/24 dev eth0 proto kernel scope link src 176.9.23.151
18:00:01 <jralls> No, wait, that won't work either.
18:00:08 <warlord> gjanssens: I think you need to set up bridge mode.
18:00:26 <jralls> I thought he did have bridge mode set up.
18:00:27 <gjanssens> Which means I can't ipv6 :(
18:00:39 <warlord> probably, in this config.
18:00:47 <gjanssens> I did indeed, I'm now trying to convert to routed
18:00:55 <warlord> Did it work in bridge mode?
18:01:00 <gjanssens> Yes
18:01:04 <gjanssens> But not ipv6
18:01:07 <warlord> I wouldn't expect it to work in route mode because you don't actually have a network to route
18:01:18 <warlord> Why not? Each host would have its own IPv6 address.
18:01:32 <gjanssens> I tried, it didn't work
18:02:14 <gjanssens> And the note at the end of the hetzner wiki page predicted this as well:
18:02:16 <gjanssens> NOTICE: In this configuration the use of IPv6 is limited. The IPv6 subnet can be routed via Hetzner Robot to either the main IP address or ONE of the additional IP addresses. (or more precisely: to the IPv6 link local address, that is generated from the MAC address)
18:02:58 <gjanssens> So either the host gets ipv6 or one guest
18:03:05 <gjanssens> At least that's how I read it
18:03:40 <gjanssens> warlord: did you read my quote from the route utility which suggests you can define routes to individual hosts as well ?
18:04:02 <warlord> gjanssens: yes, however you would need the support of your ISP to route that way
18:04:16 <jralls> gjanssens: Have you looked at http://wiki.xenproject.org/wiki/Xen_Networking#Setting_up_routing_on_the_host and http://wiki.xenproject.org/wiki/Vif-route
18:04:28 <warlord> ah, so its a vm limitation.
18:04:39 <warlord> that's different.. (about v6)
18:05:15 <jralls> gjanssesns: The kernel routing table doesn't know about the VM unless Xen's router is told about it.
18:06:56 <gjanssens> warlord: it looks like the ISP does route that way
18:07:27 <gjanssens> I'm explicitly told to route to the single host, not a network
18:08:11 <warlord> What network technology are you using? I have no idea how the ISP is routing you two unique and non-connected single IP Addresses and would expect them to talk to each other without going through their upstream router..
18:08:44 <gjanssens> jralls: I don't understand that last sentence
18:08:57 <gjanssens> my kernel routing table knows about eth0 and br0
18:09:13 <gjanssens> and it knows that *.156 can be reached via br0
18:09:42 <gjanssens> So when it receives a packet on eth0 for *.156, shouldn't it just push it out to br0 ?
18:09:56 <gjanssens> I don't see it appear on br0
18:10:27 <gjanssens> The vm's vif is added to this bridge by the way, so it would also pick up this packet IUC
18:11:20 <jralls> gjanssens: You've told the kernel routing table that it -- that kernel, that single host -- has two interfaces, eth0 and br0, over which it can send and receive traffic. For itself. Not for any other host. Anything coming in on either of them it assumes is for itself, not for another host, virtual or otherwise.
18:12:21 <gjanssens> I have set net.ipv4.ip_forward = 1
18:13:31 <gjanssens> I thought that was all that is necessary to have the kernel pass traffic along if it is not for itself ?
18:13:38 <jralls> But it thinks that both 156 and 151 are itself.
18:13:46 <gjanssens> warlord: what do you mean with "network technology" ?
18:13:54 <jralls> One for each IP.
18:14:30 <gjanssens> jralls: I don't read it that way
18:14:51 <gjanssens> *.129 is my isp's gateway
18:15:12 <jralls> OK, but I'm not reading. I have 20+ years of experience with this stuff.
18:15:35 <gjanssens> :)
18:16:03 <jralls> Yes, 129 is a router, controlling probably a /28 subnet of the ISP's total space.
18:16:28 <gjanssens> Then the obvious question is, what should the routing table look like such that it understands *.156 is something it should pass along on br0 ?
18:17:20 <gjanssens> And anything else not meant for *.151 should be passed to *.129 ?
18:18:09 *** aqua___ has quit IRC
18:18:38 <jralls> br0 needs to have a different IP on a different subnet from 151. Give me a moment to write it out in binary...
18:20:23 <gjanssens> Sure
18:23:25 *** StuM has joined #gnucash
18:25:18 <jralls> OK, so you can pretend that there are two networks, ..144/28 and ..156/28. You'll need to set those netmasks; use route rather than ip route, it's easier to figure out what you're doing. Assign something other than 156 to br0, say 158. In route you set the netmask with the network bits, so it will be 255.255.255.251.
18:28:01 <jralls> route add -net 176.9.23.156 netmask 255.255.255.251 dev br0
18:30:54 <gjanssens> That one brings up the usage of route
18:31:50 <gjanssens> "bogus networkmask"
18:33:29 <gjanssens> (should be 240 I presume)
18:34:31 <Simon> uhh
18:34:50 <Simon> you should probably be adding a route to .129/32 and then adding a default route via .129
18:35:07 <Simon> if you invent /28s like that you may be unable to reach those IPs
18:35:33 <Simon> you can add as many explicit /32 routes as you need
18:36:13 <Simon> it should then work if you just have the guest in the bridge
18:36:18 <jralls> Yeah, bet it says "bogus netmask" at the top of the message. Duh. 251 isn't a power of 2.
18:36:36 <Simon> btw, watch out for linux's stupid default setting for net.bridge.bridge-nf-call-iptables
18:36:50 <gjanssens> The route to .129 is there. It's line 2 in http://paste.kde.org/puaysyp6j
18:37:01 <Simon> it causes all bridged traffic to be run through iptables, and you might be dropping all the packets in your firewall rules
18:37:20 <gjanssens> That may be it Simon
18:37:28 <gjanssens> I read something along those lines
18:37:47 <jralls> Simon: He's trying to get routed, not bridged.
18:37:55 <Simon> it may go through the FORWARD table, I'm not sure (I've disabled that setting since it first appeared)
18:38:01 <Simon> you can't route it
18:38:05 <jralls> gjanssens: I tried 240, got bogus netmask again.
18:38:12 <Simon> I don't think you are the gateway for .156
18:38:25 <Simon> the network you're on is expecting you to respond to arp queries for .156
18:38:47 <Simon> so either you run it with proxy arp or you just bridge the guest onto the same ethernet network as the host
18:40:52 <Simon> that hetzner page doesn't make much sense
18:41:16 <Simon> it has the host adding a route to the guest via br0 (eth0)...
18:41:42 <Simon> oh, eth0 isn't in the bridge
18:42:00 <gjanssens> I think hetzner is trying to do some hybrid configuration
18:42:15 <gjanssens> a bridge to tie all the vm's vifs together
18:42:32 <gjanssens> And then routing from the plain external interfact to/from that bridge
18:42:36 <Simon> have you actually configured any part of the hetzner system to tell it which mode you want to use?
18:42:55 <gjanssens> So a there is a bridge involved
18:43:01 <Simon> you always need at least one bridge because that's the standard way of dealing with VMs
18:43:18 <Simon> when the VM network interface comes up it is added to the bridge
18:44:09 <gjanssens> What do you mean with configuring the hetzner system to tell which mode I want to use ?
18:45:29 <Simon> when the router wants to send traffic to an IP, there are 2 options:
18:45:45 <Simon> 1) perform an ARP request over Ethernet to find the MAC that has that IP
18:46:11 <Simon> 2) perform an ARP request over Ethernet to find the MAC of a gateway IP (i.e. the host)
18:46:23 <Simon> it then sends the packet to that MAC address
18:46:49 <Simon> so either it is expecting to find the guest's IP on that network, or to find the host's IP and then route via it
18:47:24 <Simon> see "As this makes the MAC addresses of the guest system visible from the outside, a virtual MAC address needs to be requested for each single IP address via the Hetzner Robot and assigned to the guest NIC." which you presumably need to do for option 1)
18:48:42 <gjanssens> I have requested a virtual mac address, and set that for the vm
18:48:54 <gjanssens> I have also enabled proxy arp on eth0
18:49:07 <Simon> as for the actual configuration of routes on your host/guest, it looks like every IP should be added as a /32, the gateway should be added as a /32 route followed by a default route via the gateway
18:49:15 <Simon> gjanssens: you don't want both of those
18:49:35 <Simon> gjanssens: either the guest is expected to respond for its IP (<@gjanssens> I have requested a virtual mac address, and set that for the vm)
18:49:47 <Simon> gjanssens: or the host is expected to respond for the guest's IP (<@gjanssens> I have also enabled proxy arp on eth0)
18:49:59 <gjanssens> Simon, I had tried both ways
18:50:07 <gjanssens> With and without proxy arp
18:50:13 <Simon> right, but don't set them both up at the same time
18:50:15 <gjanssens> Originally it was without and still not working
18:50:28 <gjanssens> Ok, I'll disable proxy arp again
18:50:56 <Simon> I'd go back to whichever configuration allowed you to see a ping
18:51:18 <gjanssens> Oh, it was disabled again already
18:52:08 <gjanssens> In this configuration I see a ping from an external host appear on eth0 (external nic), but it never reaches br0 (the bridge holding the vm)
18:52:18 <Simon> ("the gateway should be added as a /32 route followed by a default route via the gateway" is something that a lot of linux distributions handle very very badly)
18:52:33 <Simon> gjanssens: check what the destination MAC address is (tcpdump -e)
18:53:58 <gjanssens> The destination mac address is 00:50:56:00:4d:99
18:54:11 <gjanssens> Which is the virtual mac address assigned to my vm
18:54:50 <gjanssens> arp -a gives
18:54:53 <Simon> ok, so you are either not allowing the traffic because of sysctl/iptables/ebtables
18:55:01 <gjanssens> static.156.23.9.176.clients.your-server.de (176.9.23.156) at 00:50:56:00:4d:99 [ether] on br0
18:55:08 <Simon> oh1
18:55:10 <Simon> oh!*
18:55:16 <Simon> eth0 isn't in br0
18:55:37 <gjanssens> No, because I need routed networking
18:55:43 <Simon> I don't understand how it got the MAC of the VM
18:56:06 <Simon> although it shouldn't matter for routing because I don't think linux will care
18:56:29 <Simon> you need to have net.ipv4.ip_forward=1, net.ipv6.conf.eth0.forwarding=1 and net.ipv6.conf.br0.forwarding=1
18:56:52 <Simon> and net.bridge.bridge-nf-call-iptables=0, net.bridge.bridge-nf-call-ip6tables=0 because they cause more harm than anything else
18:57:20 <Simon> er, net.ipv4.conf.eth0.forwarding=1 and net.ipv4.conf.br0.forwarding=1
18:58:02 <Simon> actually, net.ipv6.conf.all.forwarding=1
18:58:09 *** jralls is now known as jralls_afk
18:58:23 <Simon> they really made some of this complicated regarding how "all" works: http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/proc-sys-net-ipv6..html
18:59:15 <gjanssens> I'm currently still focussing on getting ipv4 working, so my ipv6 rules may not be complete
18:59:45 <gjanssens> I have just added the two additional conf.<nic>.forwarding rules as I didn't have those yet
18:59:53 <gjanssens> But still no dice
19:00:30 *** Gbarr has quit IRC
19:01:06 <Simon> I'd usually just set *.forwarding=1 and manage it with explicit iptables FORWARD rules
19:01:14 <Simon> oh!
19:01:24 <Simon> you're getting traffic to a MAC address that isn't yours,
19:01:32 <Simon> so the interface will need to be in promiscuous mode
19:01:33 <gjanssens> arp -na gives
19:01:42 <gjanssens> ? (176.9.23.156) at 00:50:56:00:4d:99 [ether] on br0
19:01:56 <gjanssens> That question mark may be significant as well ?
19:02:05 <Simon> that's probably an rdns failure
19:02:13 <Simon> whenever you run tcpdump, run it with -p
19:02:24 <Simon> otherwise you're putting the interface into promiscuous mode and affecting the behaviour
19:03:10 <Simon> however you're going to need it to be in promiscuous mode all the time if the traffic arrives at eth0 with the VM's MAC
19:03:52 <gjanssens> with -p I no longer see the ping packets on eth0
19:03:55 <Simon> which means you actually want to remove the "virtual MAC address" at hetzner, and enable proxy arp
19:04:02 <Simon> right - because the traffic is going to the VM's MAC
19:04:20 <gjanssens> Let me try...
19:04:22 <Simon> if you're going for a routed configuration I'd get that sorted
19:04:33 <Simon> because running in promiscuous mode all the time is an ugly hack
19:05:11 <Simon> I don't know how often the router will refresh its arp cache
19:05:38 <Simon> so it could continue to try to use the VM's MAC for a while
19:06:53 * Simon goes to bed
19:07:47 <gjanssens> That was it !
19:07:56 <gjanssens> It works now.
19:07:59 <gjanssens> Thanks a lot
19:08:00 <Simon> what did you change?
19:08:10 <Simon> is it using the host's MAC now?
19:08:18 <gjanssens> Enabled proxy arp, disabled virtual mac
19:08:22 <Simon> ok
19:08:22 <gjanssens> Yes
19:08:29 * gjanssens goes to bed as well
19:08:37 <gjanssens> Tomorrow I can look at ipv6
19:08:45 <gjanssens> Night all and thanks for the help
19:09:10 *** gjanssens has quit IRC
19:23:58 *** jralls_afk has quit IRC
19:24:57 *** jralls_afk has joined #gnucash
19:43:25 *** jralls_afk has quit IRC
19:44:08 *** jralls_afk has joined #gnucash
19:48:10 *** ErKa has quit IRC
20:05:41 *** jralls_afk has quit IRC
20:06:46 *** jralls_afk has joined #gnucash
20:49:08 *** AndreeeCZ has joined #gnucash
21:31:50 *** andy has quit IRC
21:54:48 *** andy has joined #gnucash
22:06:58 *** jralls_afk has quit IRC
22:07:28 *** jralls_afk has joined #gnucash
22:17:32 *** puck has quit IRC
22:21:03 *** puck has joined #gnucash
22:27:44 *** jralls_afk has quit IRC
22:28:43 *** jralls_afk has joined #gnucash
23:18:49 *** AndreeeCZ has quit IRC
23:23:49 *** StuM has quit IRC
23:44:52 *** GabrieleV_ has joined #gnucash
23:44:56 *** GabrieleV has quit IRC
23:44:56 *** GabrieleV_ is now known as GabrieleV