PPP on TP-Link router?

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

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

--
Regards,
Quân

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

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         <[email protected]>

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         <[email protected]>

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.

Regards,
Quân

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

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         <[email protected]>