> On 21 Mar 2019, at 06:20, Ni, Hongjun <hongjun...@intel.com> wrote: > > Hi Raj, > > I think you may check the Ethernet type, if it is PPPoE packet, then MAC > check will be skipped. > > Thanks, > Hongjun > > -----Original Message----- > From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Raj > Sent: Wednesday, March 20, 2019 9:48 PM > To: vpp-dev <vpp-dev@lists.fd.io> > Cc: alp.ars...@xflowresearch.com; Ni, Hongjun <hongjun...@intel.com> > Subject: Re: [vpp-dev] Status of PPPoE Plugin > > I commented out the offending parts and now PPPoE is working fine. > > diff --git a/src/vnet/ethernet/node.c b/src/vnet/ethernet/node.c index > 53d5b4eb0..7c5f673e0 100755 > --- a/src/vnet/ethernet/node.c > +++ b/src/vnet/ethernet/node.c > @@ -429,14 +429,14 @@ ethernet_input_inline (vlib_main_t * vm, > } > else > { > + /*if (!ethernet_address_cast (e0->dst_address) && > (hi->hw_address != 0) && > !eth_mac_equal ((u8 *) e0, hi->hw_address)) > error0 = ETHERNET_ERROR_L3_MAC_MISMATCH; > if (!ethernet_address_cast (e1->dst_address) && > (hi->hw_address != 0) && > !eth_mac_equal ((u8 *) e1, hi->hw_address)) > + error1 = ETHERNET_ERROR_L3_MAC_MISMATCH;*/ > vlib_buffer_advance (b0, sizeof (ethernet_header_t)); > determine_next_node (em, variant, 0, type0, b0, > &error0, &next0); @@ -653,10 +653,10 @@ > ethernet_input_inline (vlib_main_t * vm, > } > else > { > + /*if (!ethernet_address_cast (e0->dst_address) && > (hi->hw_address != 0) && > !eth_mac_equal ((u8 *) e0, hi->hw_address)) > + error0 = ETHERNET_ERROR_L3_MAC_MISMATCH;*/ > vlib_buffer_advance (b0, sizeof (ethernet_header_t)); > determine_next_node (em, variant, 0, type0, b0, > &error0, &next0); > > I am sure this is not a patch which will be accepted upstream.
I would say: for sure not. > I am not sure how to _correctly_ fix this, so that it will be accepted by > upstream. If some pointers are given I can submit a patch to get PPPoE > working correctly again in VPP. This is typical case of “shotgun wedding” between control plane and dataplane over the TAP interface. RFC2516 Section 4. clearly says: The DESTINATION_ADDR field contains either a unicast Ethernet destination address, or the Ethernet broadcast address (0xffffffff). For Discovery packets, the value is either a unicast or broadcast address as defined in the Discovery section. For PPP session traffic, this field MUST contain the peer's unicast address as determined from the Discovery stage. The SOURCE_ADDR field MUST contains the Ethernet MAC address of the source device. So right thing to do here is to make sure that both control and session packets are using single mac address, preferably MAC address of the VPP interface where session traffic is received.
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12600): https://lists.fd.io/g/vpp-dev/message/12600 Mute This Topic: https://lists.fd.io/mt/28791570/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
