https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292759
Zhenlei Huang <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|Affects Only Me |Affects Some People
Status|New |In Progress
Assignee|[email protected] |[email protected]
--- Comment #16 from Zhenlei Huang <[email protected]> ---
(In reply to vova from comment #15)
> Not sure what you ment under "a new kind of **promiscuous mode**"
Current promiscuous mode reads, the NIC accepts any packets it receives. That
is to say, any frames, tagged or not, destined for us or not, or event bad
frames ( wrong CRCs, em(4) has a knob for that ) should be passed in. That
implies `allmulti` and `-vlanhwfilter`.
"a new kind of **promiscuous mode**" or "a new type of **promiscuous mode**",
shall be `allunicast` if I name it. It hints the driver whether the unicast
frames not destined for us should be accepted or dropped.
> I am not sure, dimention is already here as "vlanfilter",
> thinking if these two dimentions are intersecting:
> -promisc ->> filters out non mine frames (these that as in ether dst not my address)
> parametrized by: my MAC(s) when ON
> clearly required to be OFF for bridge functioning, as it forwards packates
> vlanhwfilter ->> filters out VLANs I am not interested in
> parametrized by: my VLAN(s)
> for bridge it is fine to be either ON or OFF as far as VLAN(s) are propagated
> for me sounds more logical not connect one to another.
If we have `allunicast` mode, then bridge(4) can benefits it from putting
member interface into `allunicast` and `allmulti` mode, while not loosing the
capability to let member interfaces do vlan filtering when `vlanhwfilter` is
available.
I'm sure how many people will be interested with that idea. I can prototype it
on if_em(4) when I have spare time. Are you willing to test it ?
BTW, I'd like to give your credentials since you have tested the patch to fix
setting the promisc mode of if_em(4). Does `[email protected]` looks good to you, or
you are willing to use the real name?
--
You are receiving this mail because:
You are the assignee for the bug.
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.