[vslib]Add MACsec forward and filters to HostInterfaceInfo #719
Conversation
Pterosaur
force-pushed
the
add_macsec_forward_and_filters_to_hostinterfaceinfo
branch
from
301e633 to
e974c85
Compare
Pterosaur
changed the title
Pterosaur
force-pushed
the
add_macsec_forward_and_filters_to_hostinterfaceinfo
branch
from
e974c85 to
7df69f3
Compare
Signed-off-by: Ze Gan <[email protected]>
Pterosaur
force-pushed
the
add_macsec_forward_and_filters_to_hostinterfaceinfo
branch
from
7df69f3 to
8b4cb33
Compare
| @@ -112,6 +118,25 @@ void MACsecForwarder::forward() | |||
|
|
|||
| while (m_runThread) | |||
There was a problem hiding this comment.
why you need separate thread in macsec ? there is already thread thats deals with packet processing, why not tap into that ?
There was a problem hiding this comment.
we already have 2 threads per port that transfer the data, and you are having some another thread for the path that is already processing data, this seems a waist of resources
There was a problem hiding this comment.
I remember you asked this question before, sorry that I did not explain it clear.
I think we need three threads in current design. The previous two are for forwarding data between tap and veth, and the new one is for forwarding the plaintext data from macsec to tap.
Meanwhile, all encrypted data on the thread 2 will be dropped by the macsec ingress filter. Because linux kernel will help us to forward the encrypted data.
All plaintext data, except EAPOL traffic, from tap interface will be captured by the MACsec egress filter that forwards to the macsec device for encryption.
Who will help us to forward the plaintext data from macsec device? I believe it should be thread 3.
There was a problem hiding this comment.
so mu understanding here is now like this: we have regular traffic, and encrypted traffic coming to the same interface then based on something (dont know what it is) you can distinguish which one is which, and for encrypted traffic you are sending this traffic to separate created socket that will decrypt this traffic inside kernel and then you can read that socket (or other one?) to get planetext traffic, process it, block or forward, maybe generate fdb notification, and then forward back encrypted traffic (re-encrypted if some filters are applied that modify pakcket) to the existing tap device?
if this is the case, both encrypted and plain text traffic come to the single tap interface, and right now this traffic is processing 1 by 1 packet in order that they arrived, with your async solution there is possibility that arrived packets will be reordered, and this is probably whats not happening in real hardware, but thats my guess. Anyway in this case i think you should block for processing in the pipeline.
if my understanding here is wrong, please setup a call meeting with me, we can talk and share on teams. I'm in CET timezone and available from 11am to 10pm everyday
There was a problem hiding this comment.
basically this MACsecForwarder::forward() is exactly the same as HostInterfaceInfo::veth2tap_fun, but not having this filter option, and just uses different FD, but other processes are the same, i think this could be somehow unified, but maybe not this PR
There was a problem hiding this comment.
Agree. I add a new super class TrafficForwarder. Maybe we can leverage it to refactor this part in the another PR.
| @@ -112,6 +118,25 @@ void MACsecForwarder::forward() | |||
|
|
|||
| while (m_runThread) | |||
There was a problem hiding this comment.
so mu understanding here is now like this: we have regular traffic, and encrypted traffic coming to the same interface then based on something (dont know what it is) you can distinguish which one is which, and for encrypted traffic you are sending this traffic to separate created socket that will decrypt this traffic inside kernel and then you can read that socket (or other one?) to get planetext traffic, process it, block or forward, maybe generate fdb notification, and then forward back encrypted traffic (re-encrypted if some filters are applied that modify pakcket) to the existing tap device?
if this is the case, both encrypted and plain text traffic come to the single tap interface, and right now this traffic is processing 1 by 1 packet in order that they arrived, with your async solution there is possibility that arrived packets will be reordered, and this is probably whats not happening in real hardware, but thats my guess. Anyway in this case i think you should block for processing in the pipeline.
if my understanding here is wrong, please setup a call meeting with me, we can talk and share on teams. I'm in CET timezone and available from 11am to 10pm everyday
vslib/src/MACsecForwarder.cpp
Outdated
| break; | ||
| } | ||
|
|
||
| m_info->async_process_packet_for_fdb_event(buffer, size); | ||
|
|
||
| if (write(m_tapfd, buffer, static_cast<int>(size)) < 0) |
There was a problem hiding this comment.
this also seems like a HostInterfaceInfo::veth2tap_fun end of the function, so this is also could be moved to a common function?
vslib/src/MACsecManager.cpp
Outdated
| @@ -579,7 +579,7 @@ bool MACsecManager::add_macsec_forwarder( | |||
|
|
|||
| auto &manager = itr->second; | |||
|
|
|||
| manager.m_forwarder = std::make_shared<MACsecForwarder>(macsecInterface, manager.m_info->m_tapfd); | |||
| manager.m_forwarder = std::make_shared<MACsecForwarder>(macsecInterface, manager.m_info->m_tapfd, manager.m_info); | |||
There was a problem hiding this comment.
manager.m_info->m_tapfd in not necessary parameter, remove; you are already passing manager.m_info inside, so you can internally use that m_tapfd, and also m_tapfd should be private, did you change visibility of that item ?
vslib/src/MACsecForwarder.cpp
Outdated
| } | ||
| } | ||
|
|
||
| if (m_info == nullptr) |
There was a problem hiding this comment.
i think this should be checked on the constructor and throw if empty
Signed-off-by: Ze Gan <[email protected]>
Signed-off-by: Ze Gan <[email protected]>
Pterosaur
force-pushed
the
add_macsec_forward_and_filters_to_hostinterfaceinfo
branch
from
15536e0 to
8b7f3f8
Compare
Signed-off-by: Ze Gan <[email protected]>
Signed-off-by: Ze Gan <[email protected]>
|
retest vs please |
…#719) Add MACsec filter before VLAN Tag and FDB event processing. Refer: MACsec in VLAN-aware Bridges
Add MACsec filter before VLAN Tag and FDB event processing.
Refer: MACsec in VLAN-aware Bridges
Signed-off-by: Ze Gan [email protected]