I really loved the idea of fixup + rebase, but of course we didn't have an example here :)
So I spend half an hour to learn about git shell commands in aliases (had to learn the hardware that arguments require functions) and came up with the following.
As most have already written here, this is no suprise. These devices are made to do one job. The whole IoT thing is just cause it something that was hyped. They did try to lock down the scope _a little_. E.g. they removed the incoming RX resistor so you couldn't use the console. They disabled SSH etc. But the scope is very hackable, both in terms of the mentioned unlock ability, but also in terms of accessling Linux. The fact that this is about a RCE, is 'troublesome' but also 'meh'.
I'm mostly disappointment that the author didn't do any research. While I get the cool-factor of trying to hack the firmware from scratch, a simple search would have found the author the EEVblog [0] for starters. But i admit, it is 104 pages atm. And the biggest dissapointment, an obviously shameless plug, is that this 'reversing' of the firmware, was done more then 5 years ago [1] where I wrote scripts to extract the whole firmware automatically.
There's even rumor that the entire source code has leaked onto the internet already.
I would expect some research would have made this 'discovery' less of an 'omg there's an RCE!'
```
git clone <aports repo>.git # Only needed once obviously
cd aports
[cd <pakage subdir]
[TARGET_ARCH='x864_64']package_builder_alpine.sh [/bin/sh]
```
And that's it. The bringup-teardown of the container take a little time, so you can launch a shell instead, and call `package_builder_alpine.sh` within the shell.
The script will generate (temporary) keys if it cannot find them in the mounted volumes.
But even this can take some time, and so after running it once, to generate the keys etc, one can then just use the standard abuild tools, to make debugging faster.
In a second editor, on the local host, one can use any OS as per normal, e.g. git, vi, etc.
I agree that POSIX is needing of a few small additions;
* local keyword
* 2 or 3 variable expansion tricks (string replacement etc)
* pipefail
But with those, I think the spec isn't too bad. I've been writing (imo) high-quality (and shellcheck compliant) shell scripts for a decade, and _always_ try to be as pendantic about being posix compliant where humanly possible. Sometimes things are a _little_ harder (no sarcasm here), but it's really quite doable once you get the hang of it.
You scripts then end up being far more portable, and as stated below, MUCH easier to read. The trick is, to write readable code (which is hard enough for most people, regardless the language anyway :p)
e.g. (a very simple example), and an addition to Shrikant's post, avoid the terse double ampersant 'and' (&&) and double pipe 'or' (||) operators, in normal calls.
do
e.g.
```sh
if ! external_command; then
do something with failure
fi
```
Rather then
`external_command || do something with failure`
These can get up becoming really hard to read once they become longer, where reading a stupid "if" statement is easy to comprehend. Readability over saving number of lines.
One important hint left forgotten, always make sure the last line of your file is `exit 0` or similar. This is more a 'weak' security feature. Prevent people from appending files and executing stuff instead. Gives a known exit point.
Another addition would be to actually favor single quotes for pure strings, and use double quotes where you expect the shell to do something with your string (true for most cases, but there's plenty of strings that benefit from single quotes, and hint the reader what to expect). Also integers should never be quoted (as it would turn then into strings), which shows a 'bad' example in the trace statement, you are now comparing the strings '0' and '1' rather then the number. Best use something easier to read in that case.
One thing I will pick up from this post for sure, is the trace hint, I'm adding that to my scripts, but probably a little more tunable.
```sh
set -eu
if [ -n "${DEBUG_TRACE_SH:-}" ] && \
[ "${DEBUG_TRACE_SH:-}" != "${DEBUG_TRACE_SH#"$(basename "${0}")"}" ] || \
[ "${DEBUG_TRACE_SH:-}" = 'all' ]; then
set -x
fi
echo 'Hello World'
exit 0
```
Though I'll probably just settle for one of those keywords, I like 'all' the best atm. This would run the trace only if this special keyword is given, or if the variable contains the name of the script. I initially had `basename "${0%%.sh}"` but that makes things like `test,test1,test2` impossible, though that only helps if the extension is used ;)
While not needing be part of this list, I personally also always use functions, unless the script really is less then a handful lines, like google's bash-guide, always have a main etc.
In the end though I do disagree writing bash and bashisms. There's plenty of posts about that though; kind of like the whole C++ 'which version to use' discussion, where bash tends to be inconsistent in itself.
Also, PLC modems (at least the Qualcomm ones afaik) are SPI modules which (due to drivers) expose an Ethernet interface to Linux. The PLC utils package up commands for the MCU on these chips in Ethernet frames. This also allows things to mostly work remotely.
PLC modems require firmware and configuration. The firmware is hard to come by, Qualcomm is not sharing it with a redistributable license :(, though can be extracted from devices that do not have an EEPROM to store this firmware (the chips reference designs often have an EEPROM, but Linux can load the firmware from the filesystem quite easily (kernel does not yet do this automatically, PLC utils are needed, but that fix is just a patch away ...)
The configuration bit to the firmware also does 'initial calibration' (the chip also does a little runtime calibration) to ensure PLC communication can work, especially in noisy environments.
ISO15118, a DC/V2G/V2H/Plug-and-Charge standard for EV's (optionally) heavily relies on PLC for communication with an EVSE (charging station, Supply Equipment). It basically creates an Ethernet connection between the two, where a high-level TCP/IPv6 based protocol is then used (15118).
Just some extra data for this lesser known/obscure tech :)
First the disclaimer, very much work in progress (WIP)! Don't YET expect everything to work! 10/100Mbit is not working, SFP+ is experimental and the code base is a bit of a mess (but far better then the SDK).
The thing is, these switches can be running full-blown OpenWRT :)
First the disclaimer, very much work in progress (WIP)! Don't YET expect everything to work! 10/100Mbit is not working, SFP+ is experimental and the code base is a bit of a mess (but far better then the SDK).
Yes they do. I have an ZyXEL XGS1010-12 (unmanaged) and it also runs Linux. The switch chip must be initialized, and the realtek SDK is based on Linux.
You could do it with just an eeprom afaik, but seems to be actually more effort (and not possible on all of realtek's switch chips).
I have setup my SolarEdge system 4 years ago, (HDWave with an LCD) and never did I sign anything that stated 'must be connected to internet, or else', again not even possible with European warranty laws anyway, as the vendor has to prove that the malfunction occurred due to not being connected to the internet.
When I was doing research on inverters and the control units, I looked into a few systems. Back then, you had either string based (Sunny boy, GoodWe was what was standard offered) or per panel inverters/optimizers.
Some vendors of those setups even wanted to place an (additional) router! Maybe to ensure the wifi signal from the inverter was close, though they wanted to place it in the meetering cabinet. No way of course. Are you crazy?
The Enphase control boxes where the worst, that still stick with me today. They actually setup a VPN to their mothership, and use that to be always connected, completely unacceptable of course. Just think about it, joe schmoe gets a solar setup, happily lets it connect to the internet, and then exposes his entire home network to Enphase.
SolarEdge was the least worry some, as (after research) showed they have a USB/RS-232 and RS-485 internal port that can be used (https://github.com/jbuehl/solaredge) and I've been using that to scrap the data for years.
I do know that with the newer HDWave (without LCD) things are a bit trickier, but should still have those RS-485 connectors, as those are needed for other purposes. Of course, I don't know what software updates broke over the years.
My system has _never_ connected to the internet, and is happily humming along :)
All in all, this is completely unacceptable behavior, and I'm surprised that they keep on getting away with this. Installers think its great, they show up to give you an offer, and show how great some of their customer setups are functioning, because yes, they also keep having 'full admin' access. Insane.
While I don't agree with the tone of your post, I completely agree with the message :)
30 - 10 years ago; Yocto (and its kin) served a very specific purpose. Building super tiny Linux distributions. If you have 4MiB worth of flash (storage) there's only so much you can cram in their.
Any "modern" linux distribution might still require more then that (excluding the likes of Linux from Scratch, as that falls in into the yocto category). Being CPU bound tends not to be the major issue, storage and RAM bound however is.
Personally, I've used debian in an embedded setting which can work great, but recently I've been using Alpine Linux for embedded and if you have a bit of storage (say 32 - 64MiB SPI NOR, or just some eMMC) you are good with Alpine as well.
One other thing I think is greatly wrong with yocto, is the fact that it is super complex to do CI with it (because its one big thing) and build-times of 3.5 hours are ridiculous. Yes if I had to rebuild every single alpine package I'd probably end up with those build-times as well. But once a packages is built and vetted, just go with it (in your mirror if you will)
As for building the whole toolchain from scratch, sure, there might be exotic reasons to do that, but come on. Just stick your build environment in a container, and use that. Getting the toolchain from a "vendor" (alpine being one) is not a crime...
As I understood it, it's an ACPI configuration, more or less 'forced' by Microsoft, to ensure this cool new S0 is the default. See [0] [1] and [2]. The fix/work-around is to tell the kernel to not do that, and just use traditional S3 sleep.
Adding `mem_sleep_default=deep` to your kernel cmdline should fix it. Been doing this on my XPS13 for 3 years now and it's fine.
While I'm a huge GitLab fan since June 4th, but one thing that concerns me greatly, which hopefully will be resolved with this extra money, is the huge number of growing issues.
What's even more scary herein is, that some issues/feature request get put on the back-burner because "there's bigger problems to solve" or "more valueable features to build"
So I spend half an hour to learn about git shell commands in aliases (had to learn the hardware that arguments require functions) and came up with the following.
fixup = "!f() { git commit --fixup ${1} && GIT_SEQUENCE_EDITOR=true git rebase --autosquash --interactive --rebase-merges \"${1}~1\"; }; f"
from https://gitlab.com/olliver/dotfiles/-/blob/master/.config/gi...
Hope this helps anybody else :)