PPP on TP-Link router?

PPP on TP-Link router?

[Nguyễn Hồng Quân]

Hello
I install OpenWrt to Tp-link 940N router, which is based on SoC: Atheros
AR7240 rev 2.
I tried to establish PPPoE connection but not successfully.
Sometimes pppd failed due to timeout after sending config-request,
sometimes failed due to "Couldn't rename ppp1 to pppoe-wan".

How can I do to solve this?

-- 
Regards,
Quân

Y!IM: ng_hquan_vn
GTalk: ng.hong.quan

Re: PPP on TP-Link router?

[Nguyễn Hồng Quân]

Here is my log:
http://paste.ubuntu.com/1561429/

On Wed 23 Jan 2013 08:52:30 AM ICT, Nguyễn Hồng Quân wrote:
> Hello
> I install OpenWrt to Tp-link 940N router, which is based on SoC: Atheros
> AR7240 rev 2.
> I tried to establish PPPoE connection but not successfully.
> Sometimes pppd failed due to timeout after sending config-request,
> sometimes failed due to "Couldn't rename ppp1 to pppoe-wan".
>
> How can I do to solve this?
>

--
Regards,
Quân

Y!IM: ng_hquan_vn
GTalk: ng.hong.quan

Re: PPP on TP-Link router?

[James Carlson]

On 01/22/13 21:23, Nguyễn Hồng Quân wrote:
> Here is my log:
> http://paste.ubuntu.com/1561429/

The logs show what appears to be a low-level communications problem.
We're receiving fine, but the peer cannot receive the messages we're
sending.

If you're able to get diagnostic information out of the peer, you may be
able to find out what is going wrong, but I think it's more likely that
a problem like this will require a dedicated external Ethernet analyzer
to figure out whether or not your system is sending correctly-formed
messages.

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

Re: PPP on TP-Link router?

[James Carlson]

On 01/23/13 10:51, terry white wrote:
> ... ciao:
> 
>     please excuse the my prior post.
>   
>     i was in the process of deciding, if asking whether a 'tcpdump' of the 
> exiting interface, worth consideration.  and then ...

It couldn't hurt.  But it'll probably show the same thing that the logs
are showing, which is that you're sending and receiving just fine, but
the peer can't hear you.  (The only other thing I think it could reveal
would be that your system is sending malformed packets due to a bug, but
I think that's unlikely given that [a] other people have used this
software successfully and [b] you are receiving data from the peer so at
least something works.)

At that point, you have to determine where your packets are being
dropped.  tcpdump won't show you whether the bits actually make it out
on the wire; it only can show what was scheduled for transmission in the
local driver.  An external packet sniffer could show whether you're
sending viable packets.  Other possible sources of information would be
error counters in the peer's Ethernet driver and any of the
switches/bridges that may stand between your system and the peer.

In any event, it's a very difficult sort of failure to debug unless
you've got the right tools and administrative access.

Perhaps a different angle of attack would help.  Is there some other
system that is able to talk to this peer?  Does Windows or a Mac or
something else talk to it successfully?  If so, then getting a packet
capture with wireshark (or similar) and comparing the sessions in detail
between the working one and the failing one would be quite interesting.

A fair possibility here (based on my sad experiences with PPPoE) is that
the peer is flaking out because one of the optional PPPoE attributes
that it believes to be "necessary" was omitted by your system, and a
mere configuration change will fix the problem.  PPPoE is like that.

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

Re: PPP on TP-Link router?

[Nguyễn Hồng Quân]

Hello,

Now the problem is gone. Seems that the ISP refused my router, based on
unknown criteria.
The criteria is unknown because:
- Not really MAC address restriction: I have another D-Link router with
OpenWrt and different MAC: Connect OK.
- We clone MAC from old router (which is TP-Link 741 with stock
firmware, has been set up since I used ISP's service) to new TP-Link 940
with OpenWrt installed: Timeout is gone, but failed to authenticate.
- I revert 940 to stock firmware without cloning MAC: Cannot connect.
- Revert 940 to stock firmware and clone MAC: Connect OK.
- Reflash that 940 to OpenWrt and clone MAC: Connect OK.

Don't know why flashed TP-Link need MAC clone, but D-Link needn't.


On 01/23/2013 07:25 PM, James Carlson wrote:
> On 01/22/13 21:23, Nguyễn Hồng Quân wrote:
>> Here is my log:
>> http://paste.ubuntu.com/1561429/
> The logs show what appears to be a low-level communications problem.
> We're receiving fine, but the peer cannot receive the messages we're
> sending.
>
> If you're able to get diagnostic information out of the peer, you may be
> able to find out what is going wrong, but I think it's more likely that
> a problem like this will require a dedicated external Ethernet analyzer
> to figure out whether or not your system is sending correctly-formed
> messages.
>

-- 
Regards,
Quân

Y!IM: ng_hquan_vn
GTalk: ng.hong.quan

Re: PPP on TP-Link router?

[James Carlson]

On 01/23/13 23:57, Nguyễn Hồng Quân wrote:
> Hello,
> 
> Now the problem is gone. Seems that the ISP refused my router, based on
> unknown criteria.
> The criteria is unknown because:
> - Not really MAC address restriction: I have another D-Link router with
> OpenWrt and different MAC: Connect OK.
> - We clone MAC from old router (which is TP-Link 741 with stock
> firmware, has been set up since I used ISP's service) to new TP-Link 940
> with OpenWrt installed: Timeout is gone, but failed to authenticate.
> - I revert 940 to stock firmware without cloning MAC: Cannot connect.
> - Revert 940 to stock firmware and clone MAC: Connect OK.
> - Reflash that 940 to OpenWrt and clone MAC: Connect OK.
> 
> Don't know why flashed TP-Link need MAC clone, but D-Link needn't.

Tracking MAC addresses as a means to do "authentication" (or "policy
enforcement") is pretty common among ISPs using PPPoE.  My guess would
be that you tripped over something odd in the enforcement mechanism.

I think it's still possible that the ISP is looking for some PPPoE
option or behavior to determine whether you're "compliant" with their
rules.  One possibility would be that they expect to see a PADT at the
end of a session, and if they don't see it, you can't start another
session with a different MAC address until some other event (such as a
timeout) occurs.

In any event, good to hear that it's working now.  If it happens again,
though, you'll probably want to talk to your ISP, or go shopping for a
different one.  (With luck, one that doesn't use PPPoE ...)

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>