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?
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
uci set wireless.@wifi-iface.ssid=Omega-XXXX
uci commit wireless
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
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/mtd2will 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
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):
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 email@example.com, 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-ifacessid='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.