ipcop pppoe

Mark Smith xorp at 020602005a5b40404e4440475758417a.nosense.org
Tue Apr 19 06:55:43 CST 2005

Hi Raymond,

On Tue, 19 Apr 2005 08:31:04 +0200
Raymond Orchison <raymondo at unibase.co.za> wrote:

> Hi All,
> I'm having a problem getting my pppeo interface to connect to my adsl
> modem.
> I have two nic'.s eth0 has an ip, eth1 has an ip, my
> adsl modem is attached to eth1 and has an ip of
> I have setup my pppeo interface in ipcop with my username and password
> but it won't connect. In /var/log/messages all I get is:
> pppd started
> pppd using channel 23
> pppd using interface ppp0
> pppd Connect: ppp0 <--> /dev/pts/1
> ppppd sent [LCP ConfReq id=0x1 <mru 1492> < magic 0xa09624d3>]
> pppoe Timeout waiting for PADO packets

PADx packets are PPPOE packets. There is what the PPPoE RFC says about a PADO (RFC2516)

"5.2 The PPPoE Active Discovery Offer (PADO) packet

   When the Access Concentrator receives a PADI that it can serve, it
   replies by sending a PADO packet. ..."

Which means that you've either got your pppoe configured to use the
wrong ethernet interface (should be eth1 based on what your ADSL modem
is attached to), or the upstream Access Concentrator is not responding
at the moment. If the AC isn't responding, typically that means it's a
telco fault, and the only thing you can do is ring their support line.

However, I've had some issues on occasion where, for some reason, the AC
won't respond, possibly due to the PPP session not closing down
properly. These problems seem to resolve themselves after quite a long

It seems these "lockouts" are tied to the MAC address of the ethernet
card being used for the ADSL modem. I've found that changing the MAC
address on the ethernet card I'm using with my ADSL modem seems to fix
the problem straight away. Changing the MAC address of a card is fairly
easy. You can use the ifconfig or "iproute2" ip command. I prefer the
latter. For example, as root, 

[root at ubu] > ip link show dev eth1
8: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:a0:cc:a2:6e:4d brd ff:ff:ff:ff:ff:ff
[root at ubu] > ip link set dev eth1 down
[root at ubu] > ip link set dev eth1 address 02:00:00:00:00:01
[root at ubu] > ip link set dev eth1 up  
[root at ubu] > ip link show dev eth1
8: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 02:00:00:00:00:01 brd ff:ff:ff:ff:ff:ff
[root at ubu] >

You'd then restart your PPPoE session.

Note that if you want to restore the original MAC address, you'll either
have to note it down, unload and reload the NIC driver, or reboot the

Switching on the 0x02 bit in the first octet is a good idea - it
indicates that the address is a locally assigned one, and therefore
shouldn't collide with any manufacturer assigned MAC addresses.
Colliding MAC addresses can be a big pain to find, so they are
well and truly worth avoiding. In particular, because these MAC
addresses need to unique over the footprint of the AC (eg, your
neighbour, the people up the street etc), it is also important to try to
ensure that the locally assigned MAC address is unlikely to collide with
any other locally assigned MAC addresses. Actually, that makes my
example one BAD, as using 00:00:00:00:01 would be somewhat probable for
somebody assigning a local address. Pick something much more random for
the last 5 octets of the MAC address. 5 octets from /dev/urandom would
be good. eg

[mark at ubu] > od -A n -t x1 -N 5 /dev/urandom
 d5 bf 0f 6b 38
[mark at ubu] >

Also make sure you don't switch on the 0x01 bit in the first octet. That
represents multicast destination addresses, which make no sense for
source MAC addresses (actually, that's not quite correct, that bit is
used to indicate the packet carries a source route when using token
ring), and when used for destination MAC addresses, will typically be
flooded out all ports of the layer 2 device forwarding them, eg an
ethernet switch, or possibly the AC. For example, using
03(0x02+0x01):00:00:00:00:01 would be very BAD!



    The Internet's nature is peer to peer.

More information about the linuxsa mailing list