Re: [Bugme-new] [Bug 39252] New: [r8169] PPPoE connections don't work if a custom MAC address is assigned

Re: [Bugme-new] [Bug 39252] New: [r8169] PPPoE connections don't work if a custom MAC address is assigned

[Andrew Morton]

(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

On Tue, 12 Jul 2011 22:51:16 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=39252
> 
>            Summary: [r8169] PPPoE connections don't work if a custom MAC
>                     address is assigned
>            Product: Drivers
>            Version: 2.5
>     Kernel Version: 3.0
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: Network
>         AssignedTo: drivers_network@kernel-bugs.osdl.org
>         ReportedBy: t.artem@mailcity.com
>         Regression: No
> 
> 
> Description of problem: if I assign a custom MAC address to my onboard NIC,
> then I cannot establish PPPoE connections, and even `pppoe -A` command doesn't
> return any PPPoE access concentrators.
> 
> 
> Version-Release number of selected component (if applicable): r8169 2.3LK-NAPI
> 
> 
> How reproducible: always
> 
> 
> Steps to Reproduce:
> 1. Boot
> 2. ifconfig eth0 hw ether MACADDRESS
> 3. Try to establish PPPoE connection using eth0
> 
> Actual results: PPPoE connection cannot be established, no network packets
> return
> 
> 
> Expected results: PPPoE connections working
> 
> 
> Additional info: if I put eth0 in the promiscuous mode, then PPPoE starts
> working.
> 
> Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express
> Gigabit Ethernet controller (rev 06)
>         Subsystem: ASUSTeK Computer Inc. Device 8432
>         Flags: bus master, fast devsel, latency 0, IRQ 47
>         I/O ports at e000 [size=256]
>         Memory at d0004000 (64-bit, prefetchable) [size=4K]
>         Memory at d0000000 (64-bit, prefetchable) [size=16K]
>         Capabilities: [40] Power Management version 3
>         Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
>         Capabilities: [70] Express Endpoint, MSI 01
>         Capabilities: [b0] MSI-X: Enable- Count=4 Masked-
>         Capabilities: [d0] Vital Product Data
>         Capabilities: [100] Advanced Error Reporting
>         Capabilities: [140] Virtual Channel
>         Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00
>         Kernel driver in use: r8169
>         Kernel modules: r8169
> 

Re: [Bugme-new] [Bug 39252] New: [r8169] PPPoE connections don't work if a custom MAC address is assigned

[David Miller]

From: Andrew Morton <akpm@linux-foundation.org>
Date: Wed, 13 Jul 2011 16:13:45 -0700

>> https://bugzilla.kernel.org/show_bug.cgi?id=39252
>> 
>>            Summary: [r8169] PPPoE connections don't work if a custom MAC
>>                     address is assigned
 ...
>> Description of problem: if I assign a custom MAC address to my onboard NIC,
>> then I cannot establish PPPoE connections, and even `pppoe -A` command doesn't
>> return any PPPoE access concentrators.

Since you seem to be creating your PPPoE connections _after_ changing
the MAC, the following shouldn't matter, but for the cases where
PPPoE connections already exist we do need this kind of change.

Again, I don't expect this to fix the bug, and I believe that it's
some r8169 specific issue.  Although, it might.

--------------------
pppoe: Must flush connections when MAC address changes too.

Kernel bugzilla: 39252

Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/pppoe.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/net/pppoe.c b/drivers/net/pppoe.c
index 718879b..bc9a4bb 100644
--- a/drivers/net/pppoe.c
+++ b/drivers/net/pppoe.c
@@ -348,8 +348,9 @@ static int pppoe_device_event(struct notifier_block *this,
 
 	/* Only look at sockets that are using this specific device. */
 	switch (event) {
+	case NETDEV_CHANGEADDR:
 	case NETDEV_CHANGEMTU:
-		/* A change in mtu is a bad thing, requiring
+		/* A change in mtu or address is a bad thing, requiring
 		 * LCP re-negotiation.
 		 */
 
-- 
1.7.6