Posts made by crispyoz

@Zonque The reason why you cannot ping or rsync to the Omega2 is that your Mac has no apparent route to the device. Your Mac is most likely routing everything through it's primary network connection on the 10.0.x.x network and that network has no route to the 192.168.x.x network.

The simplest method is to connect your Omega2 to the same network as your Mac, that way both devices are on the same subnet and the routing ceases to be an issue.

Alternatively you can add a route to yor Mac routing table. First find the name of the interface on Mac that is connected to the Omega2 wifi, use the ifconfig command to see the names, then from the command prompt of your Mac issue this command, replacing the interface name

route add -host 192.168.3.1 -interface <name of the interface>

@Paolo-Moro Here is the configuration files to give you a functional OpenWrt 22 wifi network.

/etc/config/network:

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fdb2:2708:4969::/48'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth0'

config interface 'lan'
        option device 'br-lan'
        option proto 'dhcp'
        option ip6assign '60'


config interface 'wwan'
        option ifname 'apcli0'
        option proto 'dhcp'
        option hostname 'o2ptest'

/etc/config/wireless:

config wifi-device 'radio0'
        option type 'mac80211'
        option path 'platform/10300000.wmac'
        option channel 'auto'
        option band '2g'
        option htmode 'HT20'
        option log_level '1'
        option disabled '0'
        option country 'AU'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid 'OpenWrt'
        option encryption 'none'
        option disabled '1'

config wifi-iface 'sta'
        option device 'radio0'
        option mode 'sta'
        option ifname 'apcli0'
        option encryption 'psk2'
        option network 'wwan'
        option led 'omega2p:blue:wifi'
        option disabled '0'
        option key '<your wifi password>'
        option ssid '<your wifi ssid>'

@stefanu Check this thread

https://community.onion.io/topic/4006/contradiction-in-omega2-device-mac-address-allocation?_=1674999572377

@stefanu The answer depends on a number of factors, if you are using the Wap Core wifi driver I have no idea, but its probably 16384.

The standard OpenWrt driver has a maximum of of 16384 but suspect you'll get some performance issues long before you hit this volume.

f you want to limit the maximum number of connections on your AP you can set it like so:

option maxassoc '5'

@Zonque As Lazar alluded to, I suspect your firmware deployment probably blew away your configuration so you should approach the device as if it were a new device and follow the docs on how to access a new device.

https://docs.onion.io/omega2-docs/connecting-to-the-omega-terminal.html#connecting-to-the-omega-terminal

@Paolo-Moro @DumTux My understanding is that Openwrt 22 firmware is considered experimental by Onion Corporation so don't expect too much. We know the Onion utils have no been portd to later versions of OpenWrt, but since Omega2 is open source, it's really up to the user base to move things forward.

I use OpenWrt 22 on some limited production devices, I recall some other users on here do also, I have to manually configure the wifi setup. Of ocurse this is done via the build system.

@Antony Take a look at this thread

https://community.onion.io/topic/4035/cloning-one-onion-to-another/5

@Amalee The permission error is becasue you are trying to execute /etc/config/samba, this is a configuration file not an executable file. Can you post the content of /etc/config/samba. Also post the results of ps command.

I assume you installed samba server using opkg install samba36-server , what other steps have you taken? By default samba listens on all interfaces, you can modify /etc/config/samba to force it to listen only on a single interface by adding the line:

option interfaces 'apcli0'

or

option interfaces '192.168.10.93'

You will also need to add firewall rules to allow access to samba ports, take a look at /etc/config/firewall and add rules for all ports:

config rule
option target 'ACCEPT'
option src 'wwan'
option proto 'udp'
option dest_port '137'
option name 'SAMBA 137'
option enabled '1'

config rule
option target 'ACCEPT'
option src 'wwan'
option proto 'udp'
option dest_port '138'
option name 'SAMBA 138'
option enabled '1'

config rule
option target 'ACCEPT'
option src 'wwan'
option proto 'tcp'
option dest_port '139'
option name 'SAMBA 139'
option enabled '1'

config rule
option target 'ACCEPT'
option src 'wwan'
option proto 'tp'
option dest_port '445'
option name 'SAMBA 445'
option enabled '1'

Probably easier to reboot then.

Before setting up the firewall rules I usually just stop the firewall and troubleshoot the issue and then setup the rules and restart the firewall.

Stopping the firewall: service firewall stop

Let us know what steps you have taken and how you are trying to access your omega samba device, using a MAC/Windows/*nix??

@Andrew-Doherty I just tested the link:

@Andrew-Doherty The firmware releases for the original Omega are available here: http://repo.onion.io/omega/images/

@huntc This runs the /sbin/firstboot script which performs jffs2reset which erases the overlay partition. The overlay partition contains the packages you install etc

@Amalee welcome back

I'm not aware of any such video however the steps look well written so perhaps you can elaborate on which steps you have completed, any specific probems you are experiencing or if you require any additional clarifications that would assist you.

@nsmith I'll explain it like this. If I switich on the device and manually set the date and time to July 2nd, 2022 11:22:30 and leave the device running, it will keep the correct time with no need for any network/internet access, so at 15:25;12 on July 2nd 2022 I check the time and find the date and time to be correct. Then I switch the device off.

On July 2nd 15:55:12 I switch the device back on. What will the date and time be? The answer is not as you might expect, it is not July 2nd 15:55:12. This is because the device stores the date and time in volatile RAM, so when the power is removed this is lost. When the device starts up it attempts to correct the date and time using a script /etc/init.d/sysfixtime which looks for the latest timestamp on files in /etc, of course if none of these files have changed in months then this doesn't help much. You could run a cron job that touches a file in /etc every X number of minutes/hours, but again if your device is switched off for day you'll still lose a day on the clock. Also touching files in /etc too frequently is not a great idea as it increases wear on the RAM.

If your requirement is to simply track the duration of something regardless of whether the date and time are correct you can still do this. For example when your app starts up it might check the date and time (even if it is not correct), then later it could check date & time again and calculate the time difference between these two checks, just not the actual date and time.

I hope that helps.

@magge Sorry missed that. We really need more information on your software's interaction with the file system. JFFS is a very robust system, Omega2 file system corruption such as you are describing is not something I have ever seen outside of a hardware design issue, and I don't recall any similar reports to your experience. My guess is that there is something in your code causing the issue and you've simply been lucky not to have experienced the issue on other hardware (I recall you mentioned your software was on another device).

To remove hardware from the equation, I'd install your software on a stock power dock with Omega2+. Since we don't know what additional hardware your custom PCB includes, or exactly how your software interacts with the device, I can only offer an opinion on how I would proceed if faced with a similar issue.

Honestly, I don't think the issue is the Omega2, your issue is simpy too reproducable not to have been experienced by those of us who have 100s or 1000s of Omega2 in production for years. So we're here to assist you in working thourgh the issue until the light bulb moment arrives

@magge If you don't use upx do you have the same issue?

@huntc This is an image of an Omega2S+ with the lid taken off, you can clearly see the flash chip so it's not hard to access..

@MK From the FAQ "The Omega2S is guaranteed to be available until January 2025".

Take a look at this link in relation to MIPS and Omega2

https://community.onion.io/topic/4462/mips-architecture-end-of-support/2?_=1673014342782

@nsmith If your device doesn't have access to an external time source, then it really has no way of of nkowing how long it has been switched off.

You don't necessarily need internet access to connect to an NTP server, most corporate networks provide them internally.

If your device has no network acccess, then you're going to need something to keep track of time when your Omega is switched off then you'll need a time source to correct the Omega time when it restarts. Just google for RTC and you'll find a pile of designs to incoruporate into your design. As an alterntive solution, the device boots up and runs a script to connect to wifi, updates the time from NTP server then shuts down the wifi. A bit of a hack.

@nsmith As @luz was explaining, messing with u-boot is not really setting up a chain of trust, u-boot just bootstraps the device, once it's running then it accessies flash. If I desperately wanted to look at your firmware and u-boot was nobbled, I'd just open the lid, reflow the O2S and remove the flash chip then install it in a O2S that had an un-noblled u-boot.

A hardeware engineer would probably just breadboard the thing and access the flash that way.

As @luz said, it depends on what your security requirements are.

30 years ago I was engaged by an embassy to troubleshoot their core consular communications system. It was in a bullet proof glass enclosure and I was ony permitted to enter the room with 2 guards toting shotguns who stood so close to me I could smell their lunch. I assumed they would shoot me if I did anything that looked suspicious, but I wasn't sure they had the expertise to know if I was doing anythig suspicion.

The only client I ever "inappropriately" copied software from was a max security military installation that took 2 hours to pass through security to get in to do a 30 minutes job, then another hour to pass back out of security, where they checked every floppy dist I had on me. Fortunatley they didnt know what an optical disk was and had no way read it if they did know what it was. I could now be writing this from inside guantanamo

The point is that security is relative, you need to assess the risk, the skills of your adversary and the cost and effort of mitigation.

@luz I made my point badly, I was in agreement with you. I think huntc mentioned in a previous post he was using RUST so perhaps the plethora of decompilers is seen as a risk.

I'm a big believer is round pegs in round holes and square pegs in square holes. Omega2 was not designed to be a super secure platform. If my firmware has gold embedded in it, I'll hire a couple of pinketons or use a platform that supports TPM et al.

I miss the days of obfuscation competitions.