18:19:42 I have a silly networking question 18:20:06 I have a machine that is, at least at present, currently sitting on two vlans: 1 and 50 18:20:07 ask away, perhaps you'll get a silly answer 18:21:00 if a machine on vlan 50 happens to try to talk to the interface on br0.1, or a machine on vlan 1 happens to talk to something on br0.50, the return packet comes out the other interface 18:21:23 basically it notices that it's got a direct way to talk to the other network segment and just pops the packet out on that path 18:22:06 by "other interface" you mean "out the properly tagged vlan"? 18:22:18 so, my question is: is the problem that I'm doing something daft, or is there a way to tell freebsd to use the appropriate interface 18:22:29 well, I hope it's properly tagged 18:22:55 but br0.50 should ignore vlan 1 18:23:52 you'd hope 18:24:01 but it sounds like that's not the case 18:24:31 I mean, maybe it's stupid to have two vlans and hope that traffic between them definitely goes to the router 18:24:57 and I think it does the right thing if I'm, eg, talking to a vnet jail 18:27:33 ... isn't it on your switch not sending packets on the right vlan? 18:27:58 okay so lessee 18:28:03 `ifconfig_br0="vlanfilter defuntagged 50 addm igc0 untagged 1 tagged 50"` 18:28:36 so we've got `igc0` is the real interface, `br0.1` and `br0.50` being the interfaces for the machine itself on the same bridge 18:29:46 our players here being bluebell (my desktop) and raven (the server) 18:30:13 if I use "curl raven50:9100" on bluebell, what raven sees is: 18:31:01 br0.50 gets the syn packet, and then br0.1 and igc0 see the syn/ack packet, and so on 18:31:08 so we're going around in a little loop 18:31:58 bluebell > [vlan1] router [vlan50] > [vlan50/igc0] raven [vlan1/igc0] > bluebell 18:33:18 someone else is probably more qualified to comment 18:34:10 basically I think raven is quite happy to _route_ a packet correctly, but if it _originates_ a packet it notices that it can just dump a packet for the subnet on vlan1 directly into vlan1 18:34:33 and yeah, perhaps the answer to "why does this stupid thing happen" is "because you're doing a stupid thing" 19:46:08 For now I have solved by not having the machine bridging interfaces 19:46:21 which is probably the sensible thing to do 20:28:20 Ahoi 21:07:28 if I have a port named foo, which relies on files from port bar, how would I mention that in the Makefile? 21:08:50 antranigv: Is it a build, lib or run dependency? 21:09:05 vkarlsen build, but its not an .so. 21:10:21 nor is it an executable 21:10:22 antranigv: bar>0:category/bar 21:13:08 Yeah I keep getting voc-pipes-0.1.0.m.20260124 depends on executable: voc-strutils - not found 21:16:00 oh wait, I didn't notice the >0 21:16:01 that helped 21:16:21 now I need to copy the files of bar into WRKSRC/build/ 21:16:26 manual CP I guess? 22:40:10 antranigv: ${CP} would be more correct(tm), but is it necessary for them to be in there? 22:44:08 vkarlsen well, yeah, the compiler is looking for the deps. 22:53:06 antranigv: Doesn't it look, or can't you tell it to look for them on the system? 22:53:43 vkarlsen I probably can tell it to look into the system but then I have to rewrite the Makefile thats shipped with it. 22:54:17 antranigv: Can I have a look? 22:54:43 vkarlsen yes. https://github.com/norayr/pipes/blob/master/Makefile 22:55:06 will commit my whole branch of ports now, because that would give you a better picture 22:57:27 Looks like it will download stuff during the build phase too, which poudriere will not allow 22:58:03 vkarlsen yup, so I ported those too 22:59:07 Projects like these can be a bit tricky. I have to go to bed now, but would love to see more tomorrow 23:00:14 vkarlsen thank you dear. 23:15:30 vkarlsen https://reviews.freebsd.org/D54863