> On 22 Mar 2019, at 07:34, Ni, Hongjun <hongjun...@intel.com> wrote: > > Hi John, > > For first PADI packet, its destination MAC is broadcast address. > Not sure it is accepted by ethernet-input node?
Sure it does, otherwise arp, dhcp, ... will not work. > Do we need special process to handle it? > 5.1 The PPPoE Active Discovery Initiation (PADI) packet > > > The Host sends the PADI packet with the DESTINATION_ADDR set to the > broadcast address. The CODE field is set to 0x09 and the SESSION_ID > MUST be set to 0x0000. > > Thanks, > Hongjun > > From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of John Lo > (loj) via Lists.Fd.Io > Sent: Thursday, March 21, 2019 11:34 PM > To: dmar...@me.com; Ni, Hongjun <hongjun...@intel.com> > Cc: vpp-dev@lists.fd.io > Subject: Re: [vpp-dev] Status of PPPoE Plugin > > Thanks for citing the PPPoE RFC 2516, Damjan. The RFC goes on to describe > how to resolve the MAC address for PPPoE sessions in Section 5 in discovery > stage. As such, there is really no “L2 mode” for PPPoE sessions mentioned in > my previous reply in this thread. The root cause of the problem was MAC > address resolution for PPPoE sessions. -John > > From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Damjan Marion > via Lists.Fd.Io > Sent: Thursday, March 21, 2019 11:08 AM > To: Ni, Hongjun <hongjun...@intel.com> > Cc: vpp-dev@lists.fd.io > Subject: Re: [vpp-dev] Status of PPPoE Plugin > > > > > 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/675294 > Group Owner: vpp-dev+ow...@lists.fd.io > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [l...@cisco.com] > -=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12612): https://lists.fd.io/g/vpp-dev/message/12612 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] -=-=-=-=-=-=-=-=-=-=-=-
