We have upgraded the community system as part of the upgrade a password reset is required for all users before login in.

Update set my MAC address to 0000



  • I was having trouble updating the firmware on my Omega 2+ (kept getting 404 error), so I performed a factory reset (NOT RECOMMENDED). Ever since that the graphical OS through the browser does not load. Basically kind of bricked the Omega 2+. I just get a directory when I load 192.168.3.1.

    With some difficulty I figured out how to upgrade firmware through ssh, but as soon as I upgraded to omega2p-v0.1.9-b152.bin the MAC address changed to 0000

    Anyone know how I can unbrick it and restore the MAC address?

    Thanks,

    Mike



  • I reset the Omega a couple more times and finally got the browser GOS to work, but the MAC address is still 0000



  • @Michael-Boddy I have a screenshot with my Omega stuck on 0000.

    Just edit /etc/config/wireless



  • I tried:

    uci set wireless.@wifi-iface[0].ssid=Omega-XXXX
    uci commit wireless
    /etc/init.d/wireless restart

    but the last command did not work. Got the error -ash /etc/init.d/wireless: not found
    Know the proper syntax for this?
    At this stage the wireless adapter must be reset to save the changes, so the above "solution" does not work

    I did manage to fix it using:

    wifisetup -ap edit -ssid Omega-XXXX

    Which automatically resets the wifi adapter, and is much easier.

    Thanks for the help

    Mike



  • I'm not sure how Onion is doing it, but typically on an MT7688 system the MAC address is stored in the 3rd mtd partition (counting from zero). Perhaps someone with hardware in hand can provide the specifics.

    hexdump -C /dev/mtd2 will typically show a mix of data, with the MAC address early in it. However, various flash mishaps could leave that either all 0's or more likely all 1's (0xff). This is relatively fixable given a model of what it should be and an ability to get into U-Boot or boot a Linux image that doesn't lock this partition.

    While the above is true, the issue is now believed to be elsewhere - likely the stored MAC address is fine, the problem seems to be with its readout or application.

    A MAC address actually has 6 octets - ie, 00:00:00:00:00:00 would be a zeroed (invalid) MAC address. To see what your operating MAC address is, you can use the ifconfig command. Typically if the MAC address actually were read from flash as zero, something would object and invent a random one that is slightly nonzero.

    The SSID is really distinct from the MAC address, however often part of the MAC address is used to create a locally unique SSID. Trying to change the SSID in uci may or may not succeed for that goal, but it won't propagate back to a change of the MAC address.



  • With my "MAC" set back as C449 the hexdump shows (note the C449 in coluns 10 and 11):
    0_1486234199472_Omega0000.JPG



  • I just noticed that when I ssh into the Omegas I can no longer do it using ssh root@Omega-XXXX, I must use ssh root@192.168.3.1, and my command prompt is root@Omega-OOOO:~#

    In short you're right and I have not fixed my MAC address, I've just aliased it

    Its really wierd because when I use

    uci show wireless

    the information is

    wireless.@wifi-iface[0]ssid='Omega-XXXX' (Where XXXX is what set the MAC to)



  • @Michael-Boddy You only set the SSID, you didn't fix the hostname. The hostname is specified in /etc/config/system



  • @WereCatf I can edit that, but the /etc/init.d/wireless restart command does not work, so the config won't be saved



  • OK, so it actually did work... was no need to restart wireless- just re-booted Omaga



  • Had the same problem after sysupgradeing to firmware image 1.9 b1.52

    Since I was able to connect via ssh I just changed the SSID
    and in the consoles the Name



  • Starting to sound like another bug for Onion to fix.



  • If one wants to get to the bottom of it, old and new factory images can be extracted via tricky application of squashfs tools (and maybe dd and whatever compression tool, I forget) and the various startup scripts and programs diffed directly.

    Or you can poke around on the running system (or two side by side?) and see what is changed.

    Of course checking any changes in the public repo would be worthwhile, but unclear if whatever is causing the issue made it there. My initial sense after looking at it is that the upstream change WereCatf mentioned would not apply to this hardware, but not 100% sure of that. It would not be at all surprising if the issue does turn to to be a similarly tiny detail breaking some part of the automated process.


Log in to reply
 

Looks like your connection to Community was lost, please wait while we try to reconnect.