Bug 6237 - Duplicate MAC address for bridged ethernet device
: Duplicate MAC address for bridged ethernet device
Status: RESOLVED INVALID
Product: SB 2/3
Classification: Unclassified
Component: Wireless
: 81
: PC Windows XP
: P2 normal with 1 vote (vote)
: ---
Assigned To: Unassigned bug - please assign me!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-26 18:18 UTC by Russ Panneton
Modified: 2009-09-08 09:12 UTC (History)
1 user (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Russ Panneton 2007-11-26 18:18:53 UTC
I have a Directv HR20 DVR connected to the SB3's bridged ethernet port.  The SB3 reports its MAC address for both itself and the HR20 behind it.  This seems to prevent the DHCP server in my router from assigning a dynamic IP address to the HR20.  All networking activity appears normal but the duplicate MAC address in my router's LAN tables makes me nervous.  Router is a Buffalo WHR-HP-G54 running DD-WRT V24 rc5.  SB3 firmware version is 81.
Comment 1 Russ Panneton 2007-11-26 18:23:02 UTC
Dunno if this could be related to bug #5523 since I am using WPA2-AES wireless encryption, which works perfectly for me.
Comment 2 William Faulk 2007-12-10 10:52:58 UTC
I am using WPA2-AES and have the same duplicated MAC address problem.
Comment 3 Blackketter Dean 2007-12-27 12:29:14 UTC
802.11 bridges show multiple devices on the network as a single MAC address.  Squeezebox is doing the right  thing here.  This should be transparent to DHCP, but I suspect that either your DVR or your DHCP server is getting confused.  As a workaround, try using a static address on one of the devices.

Comment 4 William Faulk 2007-12-27 13:05:40 UTC
DHCP assigns addresses based on MAC address.  If the DHCP server gets two requests from the same MAC address, it will send the same IP address.  Not to mention it makes it impossible to assign a fixed DHCP address to both systems.

If this is the way 802.11 is intended to work, then I don't want you to break the spec, obviously.  Do you have any reference for that assertion, though?  I tried to find something before I commented on the bug report.