The last Snapshot for which VLANs are working is pfSense-CE-memstick-2.7.0-DEVELOPMENT-amd64-20220314-1916

NRgia

For me the last snapshot for which VLANs traffic is working is pfSense-CE-memstick-2.7.0-DEVELOPMENT-amd64-20220314-1916.

Any other Snapshots to which I update to will lose traffic to tagged VLANs, only the management interface will pass traffic.

I did not notice any errors, in system logs, or any other rules errors.

If I downgrade to pfSense-CE-memstick-2.7.0-DEVELOPMENT-amd64-20220314-1916, the traffic is restored again.

As an example:
For a interface named ix0 we have 2 VLANs
ix0.10 and ix0.20
The traffic is passing only for ix0 interface for snaphots greater than pfSense-CE-memstick-2.7.0-DEVELOPMENT-amd64-20220314-1916.

Packages installed:
pfBlockerNg
Avahi
Suricata (disabled in snapshots greater than pfSense-CE-memstick-2.7.0-DEVELOPMENT-amd64-20220314-1916, to exclude incompatibility).

netblues

Just upgraded to
2.7.0.a.20220321.2208
with tagged vlans
I don't see any issues., at least regarding vlans.

jimp

There was an upstream sync with the latest FreeBSD 12 stable code after that snapshot, so it's possible something changed there.

I can't reproduce any problems here, however. I'm passing traffic just fine on tagged VLANs using ix on the most recent snapshots.

NRgia

@jimp said in The last Snapshot for which VLANs are working is pfSense-CE-memstick-2.7.0-DEVELOPMENT-amd64-20220314-1916:

There was an upstream sync with the latest FreeBSD 12 stable code after that snapshot, so it's possible something changed there.

I can't reproduce any problems here, however. I'm passing traffic just fine on tagged VLANs using ix on the most recent snapshots.

Thank you @jimp and @netblues for investigating.

That was what I wanted to ask next, maybe some code from BSD upstream was synced, and that's why it doesn't pass traffic anymore?

Can you compare the "diff" for ix driver, or anything related to it on current snapshot vs pfSense-CE-memstick-2.7.0-DEVELOPMENT-amd64-20220314-1916 one ?

I also looked over some commits from 8 days ago. There are some related to iflib interface through which all drivers works now and the fixes are for Intel drivers and how VLAN tagging is handled.
I will give you 2 examples:

https://github.com/pfsense/FreeBSD-src/commit/9c762cc125c0c2dae9fbf49cc526bb97c14b54a4

and

https://github.com/pfsense/FreeBSD-src/commit/33c120d56634d5855a3f43c962ac38fade610943

@netblues are you using a NIC, also with ix driver?
Thanks

netblues

@nrgia Unfortunately, its a realtek.

NRgia

I tried to install a few more future snapshots for a few days and in the end I gave up having the same result, and no feedback.

Looking over the commits I saw one from yesterday that caught my attention. It was a code revert

https://github.com/pfsense/FreeBSD-src/commit/7921c9ba64960c29a63a96619e6d0ea0732db5bd

Then I waited for the next build to be available and I updated from:

pfSense-CE-memstick-2.7.0-DEVELOPMENT-amd64-20220314-1916 to pfSense-CE-memstick-2.7.0-DEVELOPMENT-amd64-20220326-0600

I don't know if it's related with the above commit or not, but now the VLANs traffic returned to normal.

IMHO I find it pointless to test a devel version if nobody gives you feedback, and you keep testing in blind hoping and praying it will get fixed...it seems I got lucky.

I mean, don't get me wrong, I could very well stay on the Stable version and not testing and all will be good, but what I have expected is to get some feedback when something breaks and it is reported. In short what was the root cause for this?
Thank you

netblues

@nrgia IMHO Since 2.7 is in rather early development stages, it's not always easy to keep pace of alpha testing.

As the project will reach beta status, testing will be much much more useful.
For now is ok to see new things as they get merged.
If something doesn't work don't always expect feedback.

Just my 2c.

NRgia

@netblues said in The last Snapshot for which VLANs are working is pfSense-CE-memstick-2.7.0-DEVELOPMENT-amd64-20220314-1916:

@nrgia IMHO Since 2.7 is in rather early development stages, it's not always easy to keep pace of alpha testing.

As the project will reach beta status, testing will be much much more useful.
For now is ok to see new things as they get merged.
If something doesn't work don't always expect feedback.

Just my 2c.

I am always open to debate and discussions.
So what you are suggesting is to postpone testing until later stages of the software?

This is wrong and I will explain why, and you don't have to take my word on it, there were other boards that defined some testing principles, they are applicable in any software development lifecycle.

Did you heard of the 7 testing principles?
Did you heard about the 3rd one? It's called "Early testing"

You can read more about them here:
https://astqb.org/istqb-foundation-level-seven-testing-principles/
and here:
https://istqbfoundation.blogspot.com/p/12-what-is-testing-k2.html under LO-1.2.2 section

In short, testing early is always better than testing later.
I will conclude with a question for you, if you are a developer, what will be more easier for you, to debug 10.000 lines of codes later, or 1.000 lines of code early?

And if I may ask, for which audience are these snapshots targeted to? To a selected few, or to anyone who is willing to test?

netblues

I'm not saying that testing is not needed. On the contrary.
What I'm saying is that the dev team definitely has its own mechanisms to test.

Having said that, reading about an issue in a public forum is one thing, responding to it is another.

Especially when something is hard to replicate, or is a corner situation.
Since you (and I) most probably didn't sign up to a tester's program I hardly expect anyone to respond to our findings unless there is a reason to. And that's at his own discretion.

NRgia

@netblues said in The last Snapshot for which VLANs are working is pfSense-CE-memstick-2.7.0-DEVELOPMENT-amd64-20220314-1916:

I'm not saying that testing is not needed. On the contrary.
What I'm saying is that the dev team definitely has its own mechanisms to test.

Having said that, reading about an issue in a public forum is one thing, responding to it is another.

Especially when something is hard to replicate, or is a corner situation.
Since you (and I) most probably didn't sign up to a tester's program I hardly expect anyone to respond to our findings unless there is a reason to. And that's at his own discretion.

I was guiding by Open Source principles here:
https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution

Anyone can contribute, you don't have to be on the "Schindler's list" or something. In order to raise an issue, you first discuss about it, have feedback about it, decide if it's a defect or not, otherwise you risk opening a Redmine issue that will be pushed back forever.

And most importantly abide by community ways of working. So I can understand if in this stage, help from general audience is not needed.