Thanks Damjan. Will look into it and find some way to resolve it. Thanks, Hongjun
From: Damjan Marion [mailto:dmar...@me.com] Sent: Friday, March 22, 2019 3:41 PM To: Ni, Hongjun <hongjun...@intel.com> Cc: l...@cisco.com; vpp-dev@lists.fd.io Subject: Re: [vpp-dev] Status of PPPoE Plugin On 22 Mar 2019, at 07:34, Ni, Hongjun <hongjun...@intel.com<mailto: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<https://tools.ietf.org/html/rfc2516#section-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> [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<mailto:dmar...@me.com>; Ni, Hongjun <hongjun...@intel.com<mailto:hongjun...@intel.com>> Cc: vpp-dev@lists.fd.io<mailto: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<mailto:vpp-dev@lists.fd.io> <vpp-dev@lists.fd.io<mailto: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<mailto:hongjun...@intel.com>> Cc: vpp-dev@lists.fd.io<mailto: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<mailto: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> > [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<mailto:vpp-dev@lists.fd.io>> > Cc: alp.ars...@xflowresearch.com<mailto:alp.ars...@xflowresearch.com>; Ni, > Hongjun <hongjun...@intel.com<mailto: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<mailto:vpp-dev+ow...@lists.fd.io> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [l...@cisco.com<mailto:l...@cisco.com>] -=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12617): https://lists.fd.io/g/vpp-dev/message/12617 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] -=-=-=-=-=-=-=-=-=-=-=-
