OpenWrt Forum Archive

Topic: WAN on 1 Gbps using RP-PPPOE DOWN!!

The content of this topic has been archived on 29 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hi,
I have a router with ramips MT7620A
Buffalo WHR-1166D specifically (On current trunk)
After ruling out some of the possibilities,
I found out that

RP-PPPOE have an issue on WAN working at 1 Gbps

Here are my tests
1. 100Mbps with DHCP on wan       OK
2. 100Mbps with PPPOE on wan      OK
3. 1 Gbps with DHCP on wan  seems OK!!!
4. 1 Gbps with PPPOE on wan   NOT OK!!!

I have tried full duplex and half duplex with ethtool but in vain

I searched some posts and also tried the following
1. override setting wan mac address with
   option macaddr '00:00:00:00:00:00'
   NOPE!!
2. Turn PPPD warning level to debug
   option pppd_options 'debug'
   (Pasted Below)
3. ethtool eth0 shows the following message

   Current message level: 0x000000ff (255)
   drv probe link timer ifdown ifup rx_err tx_err


When WAN is on 1 Gbps with DHCP
Luci shows WAN's MAC address and TX RX packets
When WAN is on 1 Gbps with PPPOE
Luci shows NO MAC address and TX RX both 0 packets!!
(Screenshot pasted below)


The interesting fact is that it only failed with
WAN on 1 Gbps using RP-PPPOE

AND According to another post

https://forum.openwrt.org/viewtopic.php?id=50648

This issue seems to be reproduced on TP-Link TL-WR1043ND v2.1
which its SoC is Qualcomm Atheros QCA9558



So, could someone verify that is it a Software Issue (RP-PPPOE)
or a Hardware Issue?
Thanks!!



MT7620A Specs:
My Buffalo WHR-1166D has ramips MT7620A
with 4 FE  &  2 RGMII
1 for CPU (switch)
&
1 for WAN (on port 5)

Which its DTS file
https://git.openwrt.org/?p=openwrt.git; … ts;hb=HEAD
seems to be correct



LOGS:


System Log (with PPPD Debug Log):

kern.info kernel: [   77.303336] mtk_soc_eth 10100000.ethernet eth0: port 5 link up (1000Mbps/Full duplex)
daemon.debug pppd[2134]: Send PPPOE Discovery V1T1 PADI session 0x0 length 4
daemon.debug pppd[2134]:  dst ff:ff:ff:ff:ff:ff  src 00:00:00:00:00:00
daemon.debug pppd[2134]:  [service-name]
daemon.debug pppd[2134]: Send PPPOE Discovery V1T1 PADI session 0x0 length 4
daemon.debug pppd[2134]:  dst ff:ff:ff:ff:ff:ff  src 00:00:00:00:00:00
daemon.debug pppd[2134]:  [service-name]
daemon.warn pppd[2134]: Timeout waiting for PADO packets
daemon.err pppd[2134]: Unable to complete PPPoE Discovery
daemon.info pppd[2134]: Exit.
daemon.notice netifd: Interface 'wan' is now down
daemon.notice netifd: Interface 'wan' is setting up now
daemon.info pppd[2195]: Plugin rp-pppoe.so loaded.
daemon.info pppd[2195]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.7
daemon.notice pppd[2195]: pppd 2.4.7 started by root, uid 0
daemon.debug pppd[2195]: Send PPPOE Discovery V1T1 PADI session 0x0 length 4
daemon.debug pppd[2195]:  dst ff:ff:ff:ff:ff:ff  src 00:00:00:00:00:00
daemon.debug pppd[2195]:  [service-name]
daemon.debug pppd[2195]: Send PPPOE Discovery V1T1 PADI session 0x0 length 4
daemon.debug pppd[2195]:  dst ff:ff:ff:ff:ff:ff  src 00:00:00:00:00:00
daemon.debug pppd[2195]:  [service-name]
daemon.debug pppd[2195]: Send PPPOE Discovery V1T1 PADI session 0x0 length 4
daemon.debug pppd[2195]:  dst ff:ff:ff:ff:ff:ff  src 00:00:00:00:00:00
daemon.debug pppd[2195]:  [service-name]
daemon.warn pppd[2195]: Timeout waiting for PADO packets
daemon.err pppd[2195]: Unable to complete PPPoE Discovery
daemon.info pppd[2195]: Exit.

Kernel Log:

mtk_soc_eth 10100000.ethernet eth0: port 5 link up (1000Mbps/Full duplex)
br-lan: port 1(eth0.1) entered disabled state
device eth0.1 left promiscuous mode
br-lan: port 1(eth0.1) entered disabled state
IPv6: ADDRCONF(NETDEV_UP): eth0.1: link is not ready
device eth0 left promiscuous mode
8021q: adding VLAN 0 to HW filter on device eth0
device eth0 entered promiscuous mode
device eth0.1 entered promiscuous mode
br-lan: port 1(eth0.1) entered forwarding state
br-lan: port 1(eth0.1) entered forwarding state
br-lan: port 1(eth0.1) entered forwarding state

Ethtool Log:

Settings for eth0:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  1000baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: No
        Speed: 1000Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 5
        Transceiver: external
        Auto-negotiation: off
        Current message level: 0x000000ff (255)
                               drv probe link timer ifdown ifup rx_err tx_err
        Link detected: yes

Screenshot when WAN on 1 Gbps using RP-PPPOE:
http://i.imgur.com/NLctDSJ.png

(Last edited by goldchang on 14 Apr 2016, 19:27)

Bug Report Ticket:
https://dev.openwrt.org/ticket/22222

TL;DR
WAN with PPPOE did not work on 1 Gbps

Did anyone managed to get PPPOE working on 1 Gbps?
on any platform (ramips, ar71xx, etc.)?

(Last edited by goldchang on 15 Apr 2016, 17:22)

goldchang wrote:

TL;DR
WAN with PPPOE did not work on 1 Gbps

Did anyone managed to get PPPOE working on 1 Gbps?
on any platform (ramips, ar71xx, etc.)?

I see similar issues, but if you set the interface to 100Mbps instead of 1000Mbps does PPPoE work for you? In my case the modem only has a 100Mbps interface towards the openwrt device and hence the negotiated wan speed is 100Mbps, but still PPPoE does not work (this is a DTAG link using the new BNG architecture)

Best Regards
        M.

Yes, PPPoE Works on 100Mbps
Strangely enough, DHCP works on 1 Gbps

Conclusion,

100Mbps with DHCP or PPPoE       OK!!!
1 Gbps with DHCP                           OK!!!
1 Gbps with PPPoE                          NOT OK!!!

So,
Did anyone managed to get PPPoE working on Gigabit Ethernet on any platform?

It looks like a Software Issue so far


Additionally,
I found some other possible tickets that might be related to this issue

https://dev.openwrt.org/ticket/12472
https://dev.openwrt.org/ticket/12181
https://dev.openwrt.org/ticket/10095
https://forum.openwrt.org/viewtopic.php?id=58368

As I can't receive PADO packets when at 1 Gbps specifically

Does anyone has the same issue?

(Last edited by goldchang on 15 Apr 2016, 20:59)

By the way,
I'm using FTTH at home
My ONU (ONT) has 1 Gbps uplink

Just curious,
Don't most providers with
DSL, ADSL, VDSL, DOCSIS modems
or
FTTx, FTTH ONUs (ONTs)
Have Gigabit Ethernet?

Or is it because
Most providers don't use PPPoE as the authentication method?

(Last edited by goldchang on 15 Apr 2016, 21:00)

Hi goldchang,

goldchang wrote:

Yes, PPPoE Works on 100Mbps
Strangely enough, DHCP works on 1 Gbps

Conclusion,

100Mbps with DHCP or PPPoE       OK!!!
1 Gbps with DHCP                           OK!!!
1 Gbps with PPPoE                          NOT OK!!!

        Interesting, thanks.

goldchang wrote:

So,
Did anyone managed to get PPPoE working on Gigabit Ethernet on any platform?

It looks like a Software Issue so far


Additionally,
I found some other possible tickets that might be related to this issue

https://dev.openwrt.org/ticket/12472
https://dev.openwrt.org/ticket/12181
https://dev.openwrt.org/ticket/10095
https://forum.openwrt.org/viewtopic.php?id=58368

As I can't receive PADO packets when at 1 Gbps specifically

Does anyone has the same issue?

I believe none of these has your failure mode "works with 100Mbps but not 1000Mpbs ethernet", but rather more mundane "if the router uses a different VLAN than the PPPoE headend communication will not happen" issues. The missing PADO can mean both the other end never receives the PADI or the other end is not happy with the details of a received PADI and simply ignores it...

Best Regards
        M.

Agree
As my ISP does not restrict MAC Address or VLAN ID
I would narrow down to these two tickets

https://dev.openwrt.org/ticket/12472
https://forum.openwrt.org/viewtopic.php?id=58368


Additionally,

Bug Report Ticket:
https://dev.openwrt.org/ticket/22222


Someone reported the same situation as I did
Will investigate further


By the way,
Your Deutsche Telekom uplink which uses BNG architecture
is the same as Mine
Which is equivelent to BRAS

Also,
Did you resolved your issue?


My link has already negotiated at 1 Gbps
But will fail only if using PPPoE

Maybe using tcpdump to capture PADI & PADO packets
Can show what's really going wrong

Hi Goldchang,

goldchang wrote:

Agree
As my ISP does not restrict MAC Address or VLAN ID
I would narrow down to these two tickets

https://dev.openwrt.org/ticket/12472

        I believe the "missing" PADT should only extend the time it takes for a new PPP connection to be established, the pppoe-server first needs to time-out the old connection unless a proper PADT was sent to disconnect/hang-up the session, but the symptom should be long duration required for a PPPoE connection to establish after a unscheduled pppoe connection loss.

        This seems to be VLAN related, no?

goldchang wrote:

Additionally,

Bug Report Ticket:
https://dev.openwrt.org/ticket/22222


Someone reported the same situation as I did
Will investigate further


By the way,
Your Deutsche Telekom uplink which uses BNG architecture
is the same as Mine
Which is equivelent to BRAS

        Well in this acronym soup equivalence depends on the level of detail one looks at wink in DTAGs case (are you on a DTAG network too?) there was/is a switch from redback/ericsson or cisco to juniper, and a new method to establish line-identities (why they still use PPPoE at all beats me, this are 8 byte per packet I would rather use for my data.)

goldchang wrote:

Also,
Did you resolved your issue?

        Unfortunately not, I guess I should try over-night again to rule out excessive long ppp connection time outs...

goldchang wrote:

My link has already negotiated at 1 Gbps
But will fail only if using PPPoE

Maybe using tcpdump to capture PADI & PADO packets
Can show what's really going wrong

Well in my case I never see a PADO on the wire to my openwrt's PADIs at all, so I am sure something is wrong, but what exactly I can not see...

Best Regards
        M.

Currently having a busy week
Let me make a quick reply first
I'll make another full reply ASAP


I agree with your comments
Will dig further into this issue from a different perspective


By the way,
I saw your other post that
the router you currently have issue with is
Buffalo WZR-HP-AG300H

I also have a Buffalo router that is on ar71xx platform, too smile
I have
Buffalo WHR-HP-G300N

Just to let you know,
I will try to help you out on your issue, too smile

(Last edited by goldchang on 19 Apr 2016, 01:47)

Hi goldchang,

goldchang wrote:

Currently having a busy week
Let me make a quick reply first
I'll make another full reply ASAP


I agree with your comments
Will dig further into this issue from a different perspective


By the way,
I saw your other post that
the router you currently have issue with is
Buffalo WZR-HP-AG300H

        I was only responding to that post, myself I run openwrtt on a netgear wndr3700v2 (ar71xx platform), but the issues are with the ISP supplied modem router "sppedport w723v type A" which is made by huawei for Deutsche Telekom. My current theory is that this modem never adorned pppoe-passthough with VLAN-tags at all and that the older BRAS system Telekom used was permissive of that while the recent BNG system really really requires VLAN7-tags... The wndr3700 beautifully tags outgoing packets if configured thusly, but the modem will not accept tagged packets on its lan side... (yeah I should get a better modem...)

goldchang wrote:

I also have a Buffalo router that is on ar71xx platform, too smile
I have
Buffalo WHR-HP-G300N

Just to let you know,
I will try to help you out on your issue, too smile

I am always happy to receive help wink so thank you very much for your offer.

Best Regards
        M.

Guys, I am having same problem with latest stable release on Linksys WRT 1900 ACS and Vigor 120 modem.. Drops seems to be frequently - every hour on my WAN interface (WAN interface configured as eth0.5 - yep VLAN). Any fix, hack around to solve this problem?

The discussion might have continued from here.