Modify

Opened 11 years ago

Closed 6 years ago

Last modified 4 years ago

#947 closed defect (no_response)

WRTSL54GS has wrong WLAN and LAN MAC's (00:10:18:90:20:DB) RC6 or RC5

Reported by: breath Owned by: hauke
Priority: low Milestone: Barrier Breaker 14.07
Component: base system Version: Trunk
Keywords: Cc:

Description (last modified by mbm)

  • this will correct the wrong MAC of 00:10:18:90:20:DB of the WRTSL54GS (WLAN & LAN)

/etc/init.d/S40network OpenWrt RC6 or RC5:

#!/bin/sh
case "$1" in
  start|restart)
    ifconfig eth2 down 
    ifconfig eth2 hw ether `nvram get il0macaddr`
    ifconfig eth2 up 
    ifup lan
    ifup wan
    ifup wifi
    wifi up

    for route in $(nvram get static_route); do {
      eval "set $(echo $route | sed 's/:/ /g')"
      $DEBUG route add -net $1 netmask $2 gw $3 metric $4 dev $5
    } done
    ;;
esac

Cheers
Love OPENWRT +webif2

Attachments (0)

Change History (16)

comment:1 Changed 11 years ago by anonymous

#!/bin/sh
case "$1" in

start|restart)

ifconfig eth2 down
ifconfig eth2 hw ether nvram get il0macaddr
ifconfig eth2 up
ifup lan
ifup wan
ifup wifi
wifi up

for route in $(nvram get static_route); do {

eval "set $(echo $route | sed 's/:/ /g')"
$DEBUG route add -net $1 netmask $2 gw $3 metric $4 dev $5

} done
;;

esac

comment:2 Changed 11 years ago by mbm

  • Description modified (diff)

use trac wiki syntax when posting code (corrected in description)
if there are multiple bugs, use multiple tickets

this should be handled by S05nvram, not the networking script

comment:3 Changed 11 years ago by nbd

  • Milestone changed from 0.9/rc6 to Kamikaze

comment:4 follow-up: Changed 11 years ago by anonymous

Can you give us the change that should be made to the S05nvram file? Im having the same problem on my WRTSL54GS WR .9 but want to make the correct change.

comment:5 Changed 11 years ago by pc486

This ticket is similar to #1512. The nvram variable is already fixed by the init script, but /sbin/wifi completely ignores it and there is no way to set it in /etc/config/wireless. I've added a hack on ticket #1512 to address the config supprt.

comment:6 in reply to: ↑ 4 Changed 10 years ago by anonymous

Replying to anonymous:

Can you give us the change that should be made to the S05nvram file? Im having the same problem on my WRTSL54GS WR .9 but want to make the correct change.

I seem to be having this issue too with WR 0.9 after a software boot on a WRTSL54GS (fresh install). It boots with a gratuitous arp with the wrong MAC address (giving the eth0 MAC instead of the br0/eth2 MAC). It is useable though after a client does an arp -d *. Have not found any fix though for this except to power cycle. Anyone have a solution?

comment:7 Changed 10 years ago by kerlyn@…

For Kamikaze 7.09 (2.4) add the following lines to /etc/init.d/network
after each occurance of "/sbin/wifi/ up" (3 places):

ifconfig wl0 down
ifconfig wl0 hw ether "$(nvram get il0macaddr)"
ifconfig wl0 up

Note that "il0macaddr" is set up correctly in /etc/init.d/nvram. I hope
someone can comment on the correct way to do this at some point; I'm
guessing there's an issue with some Broadcom proprietary module that is
causing this problem (and the broken /proc/net/wl0) in the first place.

comment:8 Changed 10 years ago by anonymous

My bad. The three lines above should be added before "/sbin/wifi up" or modes other than 'ap' won't work.

comment:9 Changed 8 years ago by anonymous

Any definite fix for this ? I'm guessing that this is why I can't get my router registered in Skyhook database (the location service used by iPod Touch) - too many other devices already registered with that MAC.

Thanks,

comment:10 Changed 8 years ago by thepeople

  • Milestone changed from Kamikaze to Kamikaze Bugs Paradize
  • Priority changed from high to low
  • Version set to Kamikaze trunk

comment:11 Changed 8 years ago by koitsu

I can provide full details of the problem that's going on here. It's haunted me for a very long time with OpenWRT-based firmwares on WRTSL54GS units, and it's very easy to reproduce. I want people to focus on the fact that all of this is with a pure wired-based network; yes wireless is configured, but all the clients I've seen this happen on (FreeBSD, Windows, Linux) are wired.

Let's take the following WRTSL54GS device and MAC address configuration. This is out of the box, specifically on Kamikaze 8.09.2, r18961:

eth0 = 00:14:BF:E5:37:C6 (LAN network, Ethernet)
eth1 = 00:14:BF:E5:37:C7 (WAN network, Ethernet)
wl0 = 00:10:18:90:20:DB (WLAN network, 802.11)
br-lan = 00:10:18:90:20:DB (bridged network)

nvram il0macaddr = 00:14:bf:e5:37:c8 (I have no idea what this is)
nvram et0macaddr = 00:14:BF:E5:37:C6

IPv4 configuration:

eth0 = <unbound>
eth1 = WAN IP address obtained from ISP

wl0 = <unbound>

br-lan = 192.168.1.1

The clients on the wired LAN are able to talk to 192.168.1.1 when ARP-wise the MAC address seen is 00:10:18:90:20:db. This is absolutely 100% fact.

Now, reboot the WRTSL54GS, and while that's happening run from a box "ping 192.168.1.1". There are short periods of time where packet loss occurs, then things recover, then things break, then recover for a couple packets, then flat out break indefinitely.

I'll note that when the first recovery happens, the ICMP response packets have a TTL of 100 on them. I believe this is the TFTP/CFE stage kicking in, since normally Linux uses a TTL of 64. During the next recovery phase (only lasting a few packets), the TTLs are once again 64.

Once things are indefinitely broken, doing "arp -a" on the machine where the ping was run from shows that the MAC associated with 192.168.1.1 is 00:14:bf:e5:37:c6.

Fixing it is as simple as doing "arp -d 192.168.1.1" on each client and voila, things work again. However, having to do this on every client is absolutely unacceptable.

I'll note that the open-source Tomato firmware *does not* have this problem. So it's been solved/worked around there somehow.

I'm more than happy to send a developer a fresh WRTSL54GS unit if they wish to work on this.

comment:12 Changed 8 years ago by koitsu

Wow, thanks "Wikiformatting", you completely buggered my follow-up! Let's try this again. Oh wait, now Akismet thinks what I'm about to post is somehow spam! This ticketing system is awesome.

WRTSL54GS device and MAC address configuration, on Kamikaze 8.09.2, r18961:

  eth0 = 00:14:BF:E5:37:C6 (LAN network, Ethernet)
  eth1 = 00:14:BF:E5:37:C7 (WAN network, Ethernet)
   wl0 = 00:10:18:90:20:DB (WLAN network, 802.11)
br-lan = 00:10:18:90:20:DB (bridged network)

nvram il0macaddr = 00:14:bf:e5:37:c8 (I have no idea what this is)
nvram et0macaddr = 00:14:BF:E5:37:C6

IPv4 configuration:

  eth0 = <unbound>
  eth1 = WAN IP address obtained from ISP
   wl0 = <unbound>
br-lan = 192.168.1.1

comment:13 Changed 7 years ago by kaloz

  • Milestone changed from Kamikaze Bugs Paradise to Attitude Adjustment (trunk)
  • Owner changed from developers to hauke
  • Status changed from new to assigned
  • Version changed from Kamikaze trunk to Trunk

comment:14 Changed 7 years ago by hauke

Does this problem still exist with recent trunk?

What value does "et1macaddr" have in the nvram?

The mac address from il0macaddr is used for the wlan interface if the value in et1macaddr is not a valid mac address.

comment:15 Changed 6 years ago by hauke

  • Resolution set to no_response
  • Status changed from assigned to closed

Reopen this if the issue is still there.

comment:16 Changed 4 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.