-
Notifications
You must be signed in to change notification settings - Fork 303
[vslib]Add MACsec forward and filters to HostInterfaceInfo #719
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 1 commit
8b4cb33
fe58aaa
8b7f3f8
38be8ab
f98468c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,29 @@ | ||
#pragma once | ||
|
||
#include "swss/sal.h" | ||
|
||
#include <stddef.h> | ||
#include <sys/socket.h> | ||
|
||
namespace saivs | ||
{ | ||
class TrafficForwarder | ||
{ | ||
public: | ||
virtual ~TrafficForwarder() = default; | ||
|
||
protected: | ||
TrafficForwarder() = default; | ||
|
||
void add_vlan_tag( | ||
_Inout_ unsigned char *buffer, | ||
_Inout_ size_t &length, | ||
_Inout_ struct msghdr &msg) const; | ||
|
||
bool send_to( | ||
_In_ int fd, | ||
_In_ const unsigned char *buffer, | ||
_In_ size_t &length) const; | ||
|
||
}; | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -22,15 +22,18 @@ using namespace saivs; | |
|
||
MACsecForwarder::MACsecForwarder( | ||
_In_ const std::string &macsecInterfaceName, | ||
_In_ int tapfd, | ||
_In_ std::shared_ptr<HostInterfaceInfo> info): | ||
m_tapfd(tapfd), | ||
m_macsecInterfaceName(macsecInterfaceName), | ||
m_runThread(true), | ||
m_info(info) | ||
{ | ||
SWSS_LOG_ENTER(); | ||
|
||
if (m_info == nullptr) | ||
{ | ||
SWSS_LOG_THROW("The HostInterfaceInfo on the MACsec port %s is empty", m_macsecInterfaceName.c_str()); | ||
} | ||
|
||
m_macsecfd = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL)); | ||
|
||
if (m_macsecfd < 0) | ||
|
@@ -118,17 +121,17 @@ void MACsecForwarder::forward() | |
|
||
while (m_runThread) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I remember you asked this question before, sorry that I did not explain it clear. 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Agree. I add a new super class |
||
{ | ||
struct msghdr msg; | ||
struct msghdr msg; | ||
memset(&msg, 0, sizeof(struct msghdr)); | ||
|
||
struct sockaddr_storage srcAddr; | ||
|
||
struct iovec iov[1]; | ||
|
||
iov[0].iov_base = buffer; // buffer for message | ||
iov[0].iov_base = buffer; // buffer for message | ||
iov[0].iov_len = sizeof(buffer); | ||
|
||
char control[CONTROL_MESSAGE_BUFFER_SIZE]; // buffer for control messages | ||
char control[CONTROL_MESSAGE_BUFFER_SIZE]; // buffer for control messages | ||
|
||
msg.msg_name = &srcAddr; | ||
msg.msg_namelen = sizeof(srcAddr); | ||
|
@@ -183,77 +186,19 @@ void MACsecForwarder::forward() | |
continue; | ||
} | ||
|
||
struct cmsghdr *cmsg; | ||
|
||
for (cmsg = CMSG_FIRSTHDR(&msg); cmsg != NULL; cmsg = CMSG_NXTHDR(&msg, cmsg)) | ||
{ | ||
if (cmsg->cmsg_level != SOL_PACKET || cmsg->cmsg_type != PACKET_AUXDATA) | ||
continue; | ||
|
||
struct tpacket_auxdata* aux = (struct tpacket_auxdata*)CMSG_DATA(cmsg); | ||
|
||
if ((aux->tp_status & TP_STATUS_VLAN_VALID) && | ||
(aux->tp_status & TP_STATUS_VLAN_TPID_VALID)) | ||
{ | ||
SWSS_LOG_DEBUG("got vlan tci: 0x%x, vlanid: %d", aux->tp_vlan_tci, aux->tp_vlan_tci & 0xFFF); | ||
size_t length = static_cast<size_t>(size); | ||
|
||
// inject vlan tag into frame | ||
add_vlan_tag(buffer, length, msg); | ||
|
||
// for overlapping buffers | ||
memmove(buffer + 2 * MAC_ADDRESS_SIZE + VLAN_TAG_SIZE, | ||
buffer + 2 * MAC_ADDRESS_SIZE, | ||
size - (2 * MAC_ADDRESS_SIZE)); | ||
|
||
uint16_t tci = htons(aux->tp_vlan_tci); | ||
uint16_t tpid = htons(IEEE_8021Q_ETHER_TYPE); | ||
|
||
uint8_t* pvlan = (uint8_t *)(buffer + 2 * MAC_ADDRESS_SIZE); | ||
memcpy(pvlan, &tpid, sizeof(uint16_t)); | ||
memcpy(pvlan + sizeof(uint16_t), &tci, sizeof(uint16_t)); | ||
|
||
size += VLAN_TAG_SIZE; | ||
|
||
break; | ||
} | ||
} | ||
m_info->async_process_packet_for_fdb_event(buffer, length); | ||
|
||
if (m_info == nullptr) | ||
if (!send_to(m_info->m_tapfd, buffer, length)) | ||
{ | ||
SWSS_LOG_ERROR("The HostInterfaceInfo on the MACsec port %s is empty", m_macsecInterfaceName.c_str()); | ||
|
||
break; | ||
} | ||
|
||
m_info->async_process_packet_for_fdb_event(buffer, size); | ||
|
||
if (write(m_tapfd, buffer, static_cast<int>(size)) < 0) | ||
{ | ||
if (errno != ENETDOWN && errno != EIO) | ||
{ | ||
SWSS_LOG_ERROR( | ||
"failed to write to macsec device %s fd %d, errno(%d): %s", | ||
m_macsecInterfaceName.c_str(), | ||
m_macsecfd, | ||
errno, | ||
strerror(errno)); | ||
} | ||
|
||
if (errno == EBADF) | ||
{ | ||
// bad file descriptor, just end thread | ||
SWSS_LOG_ERROR( | ||
"ending thread for macsec device %s fd %d", | ||
m_macsecInterfaceName.c_str(), | ||
m_macsecfd); | ||
return; | ||
} | ||
|
||
continue; | ||
} | ||
} | ||
|
||
SWSS_LOG_NOTICE( | ||
"ending thread proc for %s", | ||
m_macsecInterfaceName.c_str()); | ||
} | ||
|
Uh oh!
There was an error while loading. Please reload this page.