Mac – Finding router’s WAN/External MAC address

If you want to connect your Livebox DSL modem-router to a simulated DSL signal, here are some possible problems you might need to investigate:

• A DSL modem in your home connects to a DSLAM in the phone company's central office. I'm not sure if two DSL modems can communicate with each other.

• You can't connect two phone devices with just a phone cable and communicate between them. You need something to put the correct phone line voltages on the line. You may be able to build a circuit to do this, or you might purchase a phone line simulator. (A phone line simulator will often have more features, like the ability to generate dial tone and other phone signals. Those signals wouldn't be needed for a DSL modem, but might be useful for connecting phones, answering machines, fax machines, or dial-up modems.) However, phone line simulators and circuits are mainly used with audible frequencies, I'm not sure if they'll reliably transmit high frequency DSL signals.

This is your problem:

• Apr 6 18:47:28 kernel: eth1: received packet with own address as source address

Or, rather, it is a report of such a Very Bad Thing that it trumps all other issues. With such a condition extant, it isn't unfortunate that your connection drops after 6 hours, but rather a miracle that it even works at all. (I suspect its DHCP server might be dormant until it receives its IP from the ISP's DHCP server, leading me to suspect there's a rogue server on your VLAN 2)

Your router's DHCP server appears to be answering its own DHCP REQUEST: At 1/2 DHCP Lease time, a client will attempt to renew its lease, which explains the 6 hour break-down.

I don't have any experience with your particularl router, so I can't prescribe a specific remedy, but it appears that its DHCP client is operating on the same VLAN as its DHCP server, and answering its own request; another possibility is that perhaps link-level broadcasts are somehow crossing VLANs.

The error above is a show-stopper, really. This situation ought to never, ever happen. Were it not confined to DHCP packets, such a loop condition can cripple a switch, when the offending ethernet frames are cloned and re-transmitted, eventually saturating the switching fabric. Note that it is not an IP level error, but a MAC/Layer 2 error.

I hope this helps...