I have a silly networking question

I have a machine that is, at least at present, currently sitting on two vlans: 1 and 50

ask away, perhaps you'll get a silly answer

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

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

by "other interface" you mean "out the properly tagged vlan"?

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

well, I hope it's properly tagged

but br0.50 should ignore vlan 1

you'd hope

but it sounds like that's not the case

I mean, maybe it's stupid to have two vlans and hope that traffic between them definitely goes to the router

and I think it does the right thing if I'm, eg, talking to a vnet jail

... isn't it on your switch not sending packets on the right vlan?

okay so lessee

`ifconfig_br0="vlanfilter defuntagged 50 addm igc0 untagged 1 tagged 50"`

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

our players here being bluebell (my desktop) and raven (the server)

if I use "curl raven50:9100" on bluebell, what raven sees is:

br0.50 gets the syn packet, and then br0.1 and igc0 see the syn/ack packet, and so on

so we're going around in a little loop

bluebell > [vlan1] router [vlan50] > [vlan50/igc0] raven [vlan1/igc0] > bluebell

someone else is probably more qualified to comment

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

and yeah, perhaps the answer to "why does this stupid thing happen" is "because you're doing a stupid thing"

For now I have solved by not having the machine bridging interfaces

which is probably the sensible thing to do

Ahoi

if I have a port named foo, which relies on files from port bar, how would I mention that in the Makefile?

antranigv: Is it a build, lib or run dependency?

vkarlsen build, but its not an .so.

nor is it an executable

antranigv: bar>0:category/bar

Yeah I keep getting voc-pipes-0.1.0.m.20260124 depends on executable: voc-strutils - not found

oh wait, I didn't notice the >0

that helped

now I need to copy the files of bar into WRKSRC/build/

manual CP I guess?

antranigv: ${CP} would be more correct(tm), but is it necessary for them to be in there?

vkarlsen well, yeah, the compiler is looking for the deps.

antranigv: Doesn't it look, or can't you tell it to look for them on the system?

vkarlsen I probably can tell it to look into the system but then I have to rewrite the Makefile thats shipped with it.

antranigv: Can I have a look?

vkarlsen yes. github.com/norayr/pipes/blob/master/Makefile

will commit my whole branch of ports now, because that would give you a better picture

Looks like it will download stuff during the build phase too, which poudriere will not allow

vkarlsen yup, so I ported those too

Projects like these can be a bit tricky. I have to go to bed now, but would love to see more tomorrow

vkarlsen thank you dear.

vkarlsen reviews.freebsd.org/D54863