24 Sep
2020
24 Sep
'20
2:58 a.m.
On 9/23/20 5:50 PM, Steffen Nurpmeso wrote:
Hello.
Hi,
Sorry for the late reply, very last summer day with
cold and rainy
days to come, and then i really turned on the TV on a non-Sunday
for the first time for long, to watch the German film "Gundermann",
which i had on my list ever since i have heard from it.
No apology necessary.
That's one of the wonderful things about email. It's their waiting for
it to be convenient for you. ;-)
This thread also gives me the feeling of being twisted
and wrapped,
.. but you know, feelings, pah.
~chuckle~
This i have never used, i do not have it installed.
But you mention
it -- what i did not understand is why it is not "simply" made a
policy that when you want to create a software bridge device, you
can create it.
Either I'm having trouble unpacking that or otherwise not understanding it.
You can create the bridge any time that you want to. (Presuming that
the kernel dependencies have been met.)
Or are you making reference to you shouldn't be able to create the
bridge if it won't work?
In the end i expect the problem to manifest in only a
few bytes
of data?
How many byte of data are you able to send from the system behind the
bridge behind the WiFi NIC that doesn't want to play nicely?
Well i never had doubts there are some technical
reasons, i just did
not know them, and there were no nice error messages nor documentation
of the problem. But given that it _does_ work for some drivers i was
also sure that the actual problem is more of a notational sort, so
to say, and then i did not understand why the creation of a software
bridge does not take appropriate steps to make this happen.
Because the behavior that I'm talking about is atypical, almost never
needed, and requires additional kernel capabilities.
There is also no good way for a system to know if the hack that I'm
talking about needs to be done or not.
Even more importantly, if this hack was automatically done, it would
mess up the most common use case for bridges or at least cause
unexpected behavior.
I could say "heck, but if ..
then it can be done".
Bridging does work with wireless in so far as the bridged frame is
handed to the wireless NIC.
It's the wireless NIC that fails to do things properly.
Is it the light switch or the light bulb's fault that the light does not
come on when there is no power to the building?
But i do not.
But in a way you did. ;-)
Well if i had the time and motivation i surely could
dive into kernel
sources and look around, and maybe even get it (done). But i have
so much to do with what other people would call livestock but i call
friends, for example, so it seems i am too old and hackneyed to get
that job done.
Fair enough. To each their own.
Chances are that your friends are there for you when the power is out.
yeah.
Yes, this is all ssh/scp communication, and that the script handles
SSH came with that veth/bridge rewrite, before everything simply had
to be typed. And so i need a name or a fixed IP in .ssh/known_hosts.
Here i have both now, without much straining.
It has to be said that Linux should really offer some kind of
setproctitle(2), more and more BSD programs use it to give sense to
ps(1) output of privilege-separated programs, and the compatibility
code using PR_SET_MM_MAP of prctl(2) after reading and parsing
/proc/self/stat is, well, immense effort.
Okay.
I'm guessing we're running / ran different versions of dhcpcd. I'm used
to one process per instance. Hence why I thought you were running
multiple instances of it. (Along with the thought that you were running
multiple network namespaces.)
No. No, that is really overkill, i am not a student
with bad body
hygiene having fun with software or something. It is annoying enough
that you ever and always again settle on a "that is a good status quo"
just to find out the next day that doing it all anew would possibly
improve the situation. No.
Indeed. If it does what you want and you're satisfied with it, the more
power to you.
That HostAP software or how it is named, doesn't
it deal with this the
right way? I seem to have read this is possible. Never tried this.
I have run HostAP. It's fairly nice and feature complete. However,
HostAP has requirements of wireless cards that play nice with things.
Even the nicest software can't realistically overcome hardware limitations.
Imho "bridge" should do this by itself
automatically.
See above. What I'm suggesting with EBTables is way beyond what bridges
should do. In fact, any bridge that does it is not behaving like a
bridge. It's behaving like something completely different.
Bridges learn who's on what side and doesn't pass something across if it
knows the destination is on the side the message is from. There's no
point in sending it across.
What I'm talking about doing is effectively the bridge lying and
claiming that everybody on the other side is the bridge.
So, no, bridges should not do what I'm pontificating automatically.
Well you could look into software like
"containers", you could read
If cgroup support, the memory controller and the pids controller
are compiled into the kernel, a mounted cgroup2 filesystem can
be used to apply memory and process-count limits to a container
as it is started. For example, the shell script
#!/bin/sh -e
echo +memory +pids >/sys/fs/cgroup/cgroup.subtree_control
mkdir /sys/fs/cgroup/mycontainer
echo $$ >/sys/fs/cgroup/mycontainer/tasks
Does this move the current running shell's PID ($$) into the mycontainer
cgroup?
echo 2G
>/sys/fs/cgroup/mycontainer/memory.high
echo 3G >/sys/fs/cgroup/mycontainer/memory.max
echo 2G >/sys/fs/cgroup/mycontainer/memory.swap.max
echo 256 >sys/fs/cgroup/mycontainer/pids.max
Setting parameters on the mycontainer cgroup.
Seems simple enough.
exec contain [...]
exec to replace the running shell with a new process while keeping the
same PID.
See linux/kernel/Documentation/cgroup-v2.txt for
detailed info
on the available controllers and configuration parameters.
I'll have to check that out.
That all seems simple enough. It's definitely in line with the way that
I do namespaces.
But most of it can be done with unshare and nsenter.
For example the
super minimal ulinux project (a bit stale) has a box script which does,
among other things
# shellcheck disable=SC2086
unshare \
--ipc \
--uts \
--pid \
--user \
--fork \
--mount \
--mount-proc \
--map-root-user \
/usr/sbin/chroot "$tmpc/root" \
/usr/bin/env -i $BOX_ENV /bin/sh -c "source /init; $*"
That all looks like typical namespace manipulation. I don't see the
relation to cgroups.
It could do nice things like
setup_tmpc() {
mkdir -p "$tmpc/root" "$tmpc/storage" "$tmpc/work"
mount -t overlay \
-o upperdir="$tmpc/storage,lowerdir=/,workdir=$tmpc/work" \
overlayfs "$tmpc/root"
I am really interested, but am too lazy to convert the scripts so
that this "distribution" (almost kernel-only) can be build without
docker etc.
Fair.
Though, I don't see any reason why you can't have a minimal version of
the distribution that you're running things on now. Thus there wouldn't
be any porting.
I personally am always astonished when i have contact
with Plan9.
I've not done anything with Plan9. Though I have been impressed by what
I've heard others say and read what they write.
I cannot really use it, i am too used to BSD/Linux,
and some things
drive me insane (network configuration etc. is so spreaded). But i
am subscribed to the MLs ever since i have been pointed to Plan9 and
always wonder when problem solutions happen to happen, how it is done.
I'm not sure what "MLs" are (is?) in this context.
--
Grant. . . .
unix || die