Neighbor11111112 has quit [Quit: Neighbor11111112]
Redfoxmoon has quit [Ping timeout: 260 seconds]
samantaz_ has joined #openwrt-devel
samantaz has quit [Ping timeout: 246 seconds]
SpaceRat has quit [Read error: Connection reset by peer]
SpaceRat has joined #openwrt-devel
brn has joined #openwrt-devel
fredrikhl has quit [Remote host closed the connection]
brn has quit [Ping timeout: 246 seconds]
hbug has joined #openwrt-devel
tobleminer-tSYS has quit [Quit: AS4242423214]
hbug___ has quit [Ping timeout: 240 seconds]
tobleminer-tSYS has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
jow has quit [Ping timeout: 256 seconds]
jow has joined #openwrt-devel
MichaelOF has quit [Quit: Konversation terminated!]
mangix has quit [Ping timeout: 272 seconds]
_whitelogger has joined #openwrt-devel
mangix has joined #openwrt-devel
mangix has quit [Read error: Connection reset by peer]
mangix has joined #openwrt-devel
black_ant has quit [Ping timeout: 265 seconds]
Redfoxmoon has joined #openwrt-devel
Guest88073 is now known as lep-delete
lep-delete is now known as Guest88073
Guest88073 is now known as lep-delete
lep-delete is now known as Guest88073
greearb has quit [Remote host closed the connection]
greearb has joined #openwrt-devel
Borromini has joined #openwrt-devel
MarioH_ has joined #openwrt-devel
MarioH- has joined #openwrt-devel
ds_shadof has quit [Read error: Connection reset by peer]
MarioH has quit [Ping timeout: 272 seconds]
ds_shadof has joined #openwrt-devel
MarioH has joined #openwrt-devel
MarioH| has joined #openwrt-devel
MarioH^ has joined #openwrt-devel
MarioH- has quit [Ping timeout: 240 seconds]
MarioH_ has quit [Ping timeout: 256 seconds]
MarioH- has joined #openwrt-devel
MarioH| has quit [Ping timeout: 240 seconds]
Guest88073 has quit [Read error: Connection reset by peer]
MarioH has quit [Ping timeout: 272 seconds]
lep-delete has joined #openwrt-devel
MarioH^ has quit [Ping timeout: 260 seconds]
MarioH has joined #openwrt-devel
lep-delete is now known as Guest88073
MarioH| has joined #openwrt-devel
gch9812131 has joined #openwrt-devel
philipp64|work has joined #openwrt-devel
MarioH- has quit [Ping timeout: 260 seconds]
gch981213 has quit [Ping timeout: 264 seconds]
gch9812131 is now known as gch981213
MarioH has quit [Ping timeout: 260 seconds]
MarioH has joined #openwrt-devel
MarioH| has quit [Ping timeout: 258 seconds]
MarioH- has joined #openwrt-devel
MarioH| has joined #openwrt-devel
MarioH has quit [Ping timeout: 256 seconds]
MarioH- has quit [Ping timeout: 258 seconds]
MarioH_ has joined #openwrt-devel
MarioH- has joined #openwrt-devel
dedeckeh has joined #openwrt-devel
MarioH| has quit [Ping timeout: 265 seconds]
MarioH has joined #openwrt-devel
MarioH| has joined #openwrt-devel
MarioH_ has quit [Ping timeout: 258 seconds]
MarioH- has quit [Ping timeout: 260 seconds]
MarioH- has joined #openwrt-devel
MarioH| has quit [Ping timeout: 272 seconds]
MarioH has quit [Ping timeout: 272 seconds]
MarioH has joined #openwrt-devel
MarioH| has joined #openwrt-devel
MarioH- has quit [Ping timeout: 260 seconds]
MarioH_ has joined #openwrt-devel
MarioH^ has joined #openwrt-devel
MarioH has quit [Ping timeout: 240 seconds]
MarioH| has quit [Ping timeout: 264 seconds]
gch9812133 has joined #openwrt-devel
Nick_Lowe has joined #openwrt-devel
MarioH has joined #openwrt-devel
gch981213 has quit [Read error: Connection reset by peer]
gch9812133 is now known as gch981213
MarioH| has joined #openwrt-devel
MarioH_ has quit [Ping timeout: 264 seconds]
MarioH^ has quit [Ping timeout: 256 seconds]
MarioH| has quit [Ping timeout: 240 seconds]
MarioH has quit [Ping timeout: 260 seconds]
MarioH has joined #openwrt-devel
MarioH_ has joined #openwrt-devel
MarioH| has joined #openwrt-devel
ivanich has joined #openwrt-devel
MarioH has quit [Ping timeout: 258 seconds]
MarioH- has joined #openwrt-devel
MarioH_ has quit [Ping timeout: 256 seconds]
MarioH| has quit [Ping timeout: 260 seconds]
MarioH_ has joined #openwrt-devel
MarioH- has quit [Ping timeout: 256 seconds]
MarioH has joined #openwrt-devel
MarioH- has joined #openwrt-devel
MarioH_ has quit [Ping timeout: 265 seconds]
MarioH_ has joined #openwrt-devel
MarioH has quit [Ping timeout: 256 seconds]
MarioH has joined #openwrt-devel
MarioH- has quit [Ping timeout: 264 seconds]
MarioH| has joined #openwrt-devel
MarioH- has joined #openwrt-devel
MarioH^ has joined #openwrt-devel
gch9812137 has joined #openwrt-devel
gch981213 has quit [Read error: Connection reset by peer]
gch9812137 is now known as gch981213
MarioH_ has quit [Ping timeout: 240 seconds]
MarioH has quit [Ping timeout: 260 seconds]
MarioH| has quit [Ping timeout: 256 seconds]
MarioH^ has quit [Ping timeout: 240 seconds]
MarioH- has quit [Ping timeout: 256 seconds]
<grift>
aparcar[m]: fstools seems to have been merged so i guess a selinux-policy version bump may be in order. how do you (or how do you want me) to go about that?
MarioH has joined #openwrt-devel
MarioH_ has joined #openwrt-devel
<grift>
i dont have release tar balls and i believe gitweb doesnt play nice?
dedeckeh has quit [Remote host closed the connection]
MarioH| has joined #openwrt-devel
MarioH^ has joined #openwrt-devel
<grift>
would be nice if i am not the only one overseeing version bumps anyone , i suppose, should be able to bump any time one feels like theres some worthwhile fixes
MarioH has quit [Ping timeout: 264 seconds]
MarioH_ has quit [Ping timeout: 272 seconds]
MarioH has joined #openwrt-devel
<grift>
maybe i should just move the project to github
MarioH_ has joined #openwrt-devel
Ycarus has joined #openwrt-devel
MarioH| has quit [Ping timeout: 240 seconds]
MarioH^ has quit [Ping timeout: 260 seconds]
MarioH- has joined #openwrt-devel
MarioH| has joined #openwrt-devel
MarioH has quit [Ping timeout: 260 seconds]
MarioH_ has quit [Ping timeout: 265 seconds]
MarioH has joined #openwrt-devel
MarioH_ has joined #openwrt-devel
aszeszo has joined #openwrt-devel
MarioH| has quit [Ping timeout: 260 seconds]
MarioH- has quit [Ping timeout: 260 seconds]
brn has joined #openwrt-devel
MarioH| has joined #openwrt-devel
MarioH has quit [Ping timeout: 256 seconds]
<damex>
have anyone had a success with new synology boxes? placed an order for ds620slim and gonna try to put openwrt on it (there is no regular bios per se)
<damex>
i will be 'fine' if i can't run my software on it since there is no other hardware available on market with similar formfactor and capabilities
<Borromini>
i think i have an atom tablet here (hand me down). runs android, can run linux in theory, but the bootloader has been stripped so much it doesn't support the necessary calls or whatnot.
danitool has joined #openwrt-devel
<Borromini>
damex: ok. i'm looking at the helios64 myself for home server replacement.
<damex>
well, they let you run anything on top their DSM (linux + opkg + docker + virtualization + whatever)
<damex>
Borromini: it is pretty big :(
<damex>
i am restricted space-wise
<damex>
ds620slim is 6x 2.5 inch drives + sodimm ddr3 memory expansion (16gb ram?)
<damex>
and is 3.2L without power brick
<Borromini>
ok
<damex>
not sure how big helios64 is but it is >14L
<damex>
and it is without power brick
<damex>
although it is lovely to get dual 2.5Gbe :p
<Borromini>
:P
rsalvaterra has joined #openwrt-devel
<Borromini>
it's single, one gbit and one 2,5 i think
<Borromini>
and the 2,5 GbE is over USB 3 apparently
brn has quit [Remote host closed the connection]
<rsalvaterra>
'morns! :)
<Borromini>
hey rsalvaterra
brn has joined #openwrt-devel
<damex>
oh yeah, seems like 1x2.5gbe and 1x1gbe
<damex>
they plan to restrict ecc memory options to 1gb or something like that
<damex>
currently it is 4gb
<Borromini>
damex: i suppose the soldered 4 GB RAM is also an issue if you're looking at virtualisation etc
<damex>
Borromini: ah no, i am looking for a storage box
<Borromini>
ok.
<damex>
i might run some extra <storage> services
<Borromini>
:)
<Borromini>
i have an odroid xu4 (exynos) that i switched to armbian last week, very happy with both. helios64 has armbian support as well, keeping an eye on it
<Borromini>
sorry for the offtopic!
<damex>
i currently use intel nuc with j5005 (7pjyh) with usb (single port/cable) attached box that have dual 5t 2.5 inch 15mm drives (jbod)
<damex>
gonna sell that box later
<Borromini>
:)
<Borromini>
celeron G1610 here with 2x 10TB and two smaller disks
<damex>
Borromini: space inefficient ;p
<rsalvaterra>
10+ TB (spinning rust) drives are scary…
<damex>
rsalvaterra: not as much when they are <fast>
<rsalvaterra>
I mean, the reliability hasn't improved proportionally to the size… when a drive dies, that's 10 TB you lose.
Redfoxmoon has quit [Changing host]
Redfoxmoon has joined #openwrt-devel
<damex>
i have had 10t 7.2k rpm hgst drives (desktop nas series? deskstar? uh...) - got them right before wd ditch hgst branding/production
Immanuel has quit [Quit: Connection reset by reptilians]
<damex>
they could do 250MB/s
Immanuel has joined #openwrt-devel
<Borromini>
damex: the 10TB ones? :P
<damex>
Borromini: yeah
<Borromini>
rsalvaterra: true, it's media though. HGST though B-)
<Borromini>
damex: how so?
<damex>
so just get more drives and use raid z3 if you're scared:)
<damex>
Borromini: how what? :)
<Borromini>
damex: how are they inefficient
<Borromini>
space inefficient.
<Borromini>
it's no raid just plain single disks (i can afford to lose what's on it)
<damex>
Borromini: physica space inefficient.
<damex>
Borromini: there is 16TB or 18TB drives in the same physical formfactor
<damex>
so you get more digital capacity over physical space it takes
<Borromini>
damex: true, but it's hella expensive.
feriman has joined #openwrt-devel
<Borromini>
my brother got me the 10 TB ones for services rendered :D
<damex>
Borromini: in my case - i'd rather have that and have less things to travel with (or to worry about)
<Borromini>
if not i might still be running the older 4 TB ones
<rsalvaterra>
Borromini: Yeah, I saw the chart, that's why I said I lied. :P
<Borromini>
:P
<rsalvaterra>
I'm entertaining the idea of building a drive array, since I'd really like to centralise all the storage somewhere (and avoid "The Cloud")…
<rsalvaterra>
… the ARM entry point for clock_gettime64 was only added in late November.
<rsalvaterra>
So, the __vdso_clock_gettime64 only needs to be patched-out (on systems without ARMv7 generic timers, like mvebu) in kernel versions after the one where this is available.
<rsalvaterra>
The other vDSO functions are patched-out already.
<rsalvaterra>
I'm going to check on which version of the kernel clock_gettime64 landed for ARM, but I'm almost sure we don't need to revert my patch. :)
<dangole>
grift: no need to move to github if you don't want to. it's in no way required for integration with OpenWrt. our build system actually automatically distributes reproducible .tar.xz checkouts of git sources, that's what we got PKG_MIRROR_HASH for.
<dangole>
grift: so all you need to do is create another tag when you feel the time has come for it (i feel it could be yesterday) and we'll use that and set PKG_MIRROR_HASH accordingly
<dangole>
grift: for future bumps, it already shows up in https://sdwalker.github.io/uscan/#packageSystem , so i could already just bump it to your git HEAD like I do in my staging tree (but there didn't bother to set PKG_MIRROR_HASH)
<karlp>
damex: no, the handler you're desiring only needs to know if it's >5 seconds or not. doesn't mean it's the only use of the button, and the dts should have a sufficient poll rate to match the debouch behaviour of the button so that it's useabel
<dangole>
grift: btw. i tried what you find in my staging tree on GL-iNET B1300 yesterday night, it works great including LuCI, without a single audit logline during normal use. sysupgrade incl. restoring configuration, temp. ramoverlay, ... all works. and "only" increases the total size of the sysupgrade image by half a megabyte to have all needed for selinux incl. your policy included (still a lot, but less than i thought it would be)
<grift>
dangole nice
<grift>
theres plenty loose ends though
<grift>
i just hit quite a few but working on that
<grift>
ill tag in a bit
<grift>
also i added a minimal target to the makefile which shaves off about 50 KB
<grift>
but that wont target luci and has no block mount support
<grift>
i guess i could create a target without luci but with blockmount
<grift>
its highly customizable
<grift>
could assemble all kinds of profiles
<rsalvaterra>
mangix: Only Linux 5.5 was affected. We're clear. :)
feriman has quit [Ping timeout: 260 seconds]
<grift>
theres also lots of other options to optimize the policy, all included its currently 160KiB
<dangole>
grift: libsepol is the most heavy-weighted thing among all what is added for selinux...
<grift>
if i add all the private lib file types then that should simplify things quite a bit and probably shave off a bunch of KiB
<grift>
err remove
<grift>
i think i might do try see if its worth it before i tag
aszeszo has quit [Read error: Connection reset by peer]
aszeszo has joined #openwrt-devel
<dangole>
grift: generally it's of course great that it is modular and we can have minimal versions of it, but i was trying to say is that the policy itself is really not that big a piece of the selinux cake in terms of storage requirements
<grift>
i know but still
MarioH has joined #openwrt-devel
Borromini has joined #openwrt-devel
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Nick_Lowe has joined #openwrt-devel
<grift>
dangole, if i dont target specific libs then i can shave off 16KiB so ill take it
<grift>
libs are interpretted anyway so not much to be gained to try to enforce who can interpret what libs
<grift>
so i will test that see if i didnt overlook anything obvious and then tag it
dedeckeh has joined #openwrt-devel
<mangix>
rsalvaterra: cool
<grift>
dangole: so now minimal policy is 107KiB and all-inclusive is 142KiB
<rsalvaterra>
mangix: Yeah, after spending two hours digging, it was definitely a relief. :P
adrianschmutzler has quit [Quit: ~ Trillian - www.trillian.im ~]
daregap has quit [Quit: daregap]
<damex>
PaulFertser: figured what was wrong with leds. configuration clash when i define 'blue' on gpio15 low and 'white' on gpio15 high
<PaulFertser>
damex: oh
<PaulFertser>
So EBUSY was correct after all
<PaulFertser>
damex: is it basically always on and you can just choose it to be blue or white?
<damex>
PaulFertser: yeah
<damex>
there is other gpio that can turn it white too
<damex>
and that one also can turn off the led
<PaulFertser>
damex: I find it a bit unlikely, it sounds like it might be an RGB led with separate controls for the components and it turns white on all of them on.
<damex>
gpio15 white/blue as 1/0, gpio17 white/off as 1/0
<damex>
but you need to pull two gpios
<damex>
PaulFertser: it is certainly not possible to pull two gpio?
<PaulFertser>
damex: what kind of a device it really is, can you see how many pins it has?
<PaulFertser>
Or take a macro photo or something?
<damex>
PaulFertser: 20 gpios exposed inside system ... let's see...
<PaulFertser>
damex: I mean the led itself
<damex>
lemmi: could you make a photo of led panel?
<PaulFertser>
So that the pins are visible
<PaulFertser>
It might be that the leds are controlled by some additional circuity thoug.h
<dangole>
grift: targetting busybox ntpd would be nice imho, when i tried it still run as u:r:sys.subj
<damex>
lemmi did a photo set for that er4 :)
<lemmi>
damex: photos from the small board in the frontpanel?
<damex>
lemmi: yes
<grift>
dangole ntpd (crond as well) is busybox
<lemmi>
need to finish something else first. hopefully i can get the board out easily
<grift>
can't really target busybox because its a shell (interpretter) ie. you cant foresee what its interpretting dangole
philipp64|work has quit [Ping timeout: 258 seconds]
<grift>
dangole one solution to that issue is what aparcar[m] wanted to do (add SELinuxContext= option to procd)
<dangole>
grift: i see... the context at run-time really comes with the binary... thought you could catch that kinda cases in the policy
philipp64|work has joined #openwrt-devel
<grift>
so that we can tell procd to manually transition to "ntpd.subj" when it runs the service command in /etc/init.d/ntpdsystime
<grift>
how do you figure dangole?
<grift>
you could add a shell wrapper around the busybox ntpd and tell procd to run that
<grift>
and then target the wrapper
<grift>
but adding a SELinuxContext= option could be the more elegant solution
<dangole>
grift: i reckon setting selinux-context anyway needs to happen for ujail as well for handling SELinuxContext given with OCI containers as well
<dangole>
grift: so procd could use ujail for that just like it does for other optional sandboxing features
<grift>
its a generally handy feature
<dangole>
grift: sure, just hesitating to implement it in two pleaces instead of in one
<grift>
essentially it would be like procd running: `runcon u:r:ntpd.subj -- busybox ntpd` or whatever
<grift>
the existing runcon command does the manual transition
<dangole>
grift: because procd shouldn't parse OCI JSON stuff to know context of container, but can use ujail to set it for normal services.
<grift>
btw i threw this out here a while ago, i was considering adding a sandbox option
<dangole>
grift: but that would mean we would need to name actual labels (ie. policy-specific stuff) in init-scripts, right?
<grift>
yes
<grift>
sandbox: basically its a ujail but then completely just policy
<grift>
so for example if you wanted to run a confined shell to do some stuff in you would either just to:
<grift>
runcon u:r:sandbox.subj -- sh or echo "ash $@" > mysandbox && chmod +x mysandbox && chcon -t sandbox.execfile mysandbox && ./mysandbox sh
<grift>
or something
<grift>
but it would be a container completely implemented in policy
<grift>
no code at all
<grift>
ofcourse one could add cgroup and name space bells and whistles
<grift>
and then it would be just some simple goals in there i guess, like no access to capabilities, no access to bind sockets to ports
<dangole>
grift: couldn't we query the policy for which context to transition to for /usr/sbin/ntpd (despite the fact that it's a link to busybox) and then have procd set that context?
<grift>
so that could just do a ./mysandbox -- irssi as root or mutt or whatever
<grift>
yes but thats a symlink right?
<grift>
/usr/sbin/ntpd
<grift>
but yes you can compute contexts from contexts aassociated with files
<grift>
but then you might as well transition automatically
<dangole>
grift: it's a symlink. and hence (from what i understood) cannot be used for automatic transition rules. but we could query the policy in procd/ujail to figure it out.
<grift>
automatic transition happen on execve
<grift>
if procd/ujail can do it then it could be done automatically as well
<grift>
if it cant be done automatically then procd and ujail cannot do it themselves either i believe
<grift>
unless you add selinux code
<grift>
for example thats how libvirt etc do it
<grift>
they read a file in /etc/selinux/TYPE/contexts
<grift>
and then they make a decision based on the content in there
<grift>
and if the policy allows it to happen then it happens
<dangole>
grift: that's kinda what i was thinking
<grift>
easiest would probably to just wrap that ntpd busybox command into a shell script
<grift>
and then transition automatically when the shell script is run
<grift>
and run ntpd with the permission associated with the shell script
<dangole>
grift: one of our declared goals is not to use even more shell stuff everywhere but try not to...
<grift>
just for consideration
<grift>
add selinux awareness is even worse IMHO
<grift>
you *reall* want to avoid adding selinux code if possible
<grift>
besides its only ntpd so an exception could be considered
<grift>
crond is a different story since that needs to run jobs on behalf of the device owner anyway
<grift>
so not much of a point targeting that
<dangole>
for procd we already got a selinux variant linking against libselinux and libsepol to load policy, so adding that there wouldn't be such a big deal. on the other hand, OCI run-time spec requires SELinux awareness (ie. ability to set context for container manually), and ujail tries to implement that, so there we will also need it anyway
<karlp>
"only" ntpd (today)
<grift>
k well thats not really my cup-of-tea, i dont really intent to run heavyweight oci compliant containers on my wireless router
<dangole>
grift: i'm just trying to avoid having to ship (or auto-generate at run-time) one liner shell scripts calling a busybox applet just for the sake of auto-transition to work... because that'd create quite some more overhead than just having a feature to optionally querying the context to be set for execution from the policy by the name of the symlink.
<grift>
understood
<dangole>
grift: not overhead in the single case where it's a manual hack, sure that's easy to do. but having ways to do that automagically, and only for the relevant things (cron, ntpd, ?) and only on SELinux builds....
gch981213 has quit [Read error: Connection reset by peer]
<grift>
but "context set for executes by name of a symlink" doesnt sound solid to me
<grift>
i might be wrong though but sounds insecure
gch981213 has joined #openwrt-devel
<grift>
probably better to use the context associated with the target of the symlink to make a decision
<dangole>
but that would again be busybox :(
<grift>
yes ..i know
<grift>
take your time weight your options .. no rush
<grift>
theres always something anyway
<grift>
ok i am going to tag selinux-policy so that will then automatically be picked up?
<dangole>
grift: i will pick it up, just like i did in my staging tree
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<grift>
k v0.3 is done
<grift>
also working on docs BTW
<grift>
but still long ways to go there
<grift>
there might also be some loose ends in fstools, for example is that ext partition that is mounted on boot with legacy BIOS labeled?
<grift>
and in my wrt1900ACS theres a ubifs mounted on /tmp/syscfg presumably is a space shared between the two boot partitions
<grift>
its currently not labeled either
<grift>
for both though, no big deal as its not accessed by any targeted processes seemingly
<grift>
and the system (sys.subj) can access it fine even if its unlabeled
<grift>
but anyway as for ntpd what we could do is for example
<karlp>
anyone seen any weirdness with net-snmp starting, but not really running?
<grift>
bake a procd_contexts file into libselinux
<karlp>
sometimes on reboot, it's "running" but it hasn't opened an agentx scoket, isn't responding to any requests, and just sits there...
<grift>
and then add that file in policy "procd_context" and it has ntpd = u:r:ntpd.subj
<karlp>
(on 19.07 at least...)
<grift>
and then somehow procd computes whether it can reach that context via the context associated with the targeted of /usr/sbin/ntpd
<grift>
and if true then it will run it with that specified context
<dangole>
grift: that's sounds nice. ie. would allow to specify service target context in policy
<grift>
yes
<grift>
its pretty simple to do and theres plenty examples
<dangole>
grift: looks like the way to go then, if it's easy to do...
<grift>
yes the libselinux side is easy
<karlp>
ubus service list verbose doesn't seem to include file parameters in the output either?
<dangole>
grift: and yes, great to see you are even writing docs for that. feel like presenting your work at upcoming battlemesh maybe?
<grift>
if virtual then sure
<dangole>
grift: yes, of course :)
<grift>
always happy to talk about this stuff
goliath has joined #openwrt-devel
<dangole>
grift: please contact Hauke about scheduling a talk then :) it's in exactly a month from now.
netprince has joined #openwrt-devel
<dangole>
grift: it's also quite unusual that a seemingly patchset gets picked up after months by someone else, then worked a lot on (hundreds of comments on github), then merged, and then just like if it was planned you showed up to contribute a policy :)
<dangole>
*seemingly abandonned...
<grift>
i was monitoring this from the day it was posted on phoronix, basically waiting for it to become usable enough for me to leverage it
<grift>
i see myself really as a user and not so much a developer so with that prep work there was not much i could be of assistence with
<grift>
except comment from the side line
<grift>
but when it comes to policy configuration, its another story
DonkeyHotei has quit [Ping timeout: 260 seconds]
gch981213 has quit [Read error: Connection reset by peer]
gch9812134 has joined #openwrt-devel
<dangole>
grift: thing is, 5+ people in 5+ different countries, no management what-so-ever involved. no formal project, no pre-defined milestones, no dancing-your-name in lengthy video calls once a week, ...
<dangole>
grift: i've just another commit making things easier for people to use this:
<dangole>
grift: now we got that single big 'enabled SELinux' button which does all the magic. and sane defaults.
<grift>
thats kind of what is appealing to me. i am a hobbyist kind of got tired of working with highly organised projects when lots of resources and directions
<grift>
yes nice, that consolidation
<rsalvaterra>
dangole: And to disable too! :D
<grift>
still need to find a way to do policy development, is there an easy way to override the provided policy with a local one without excluding the provided policy?
<grift>
i was hoping that if there was a local feed that has a more recent version of a provided package that it would automatically take the local one with a never version
<dangole>
grift: i'd just use CONFIG_SRC_TREE_OVERRIDE with a local git checkout of your policy as a starting point
<grift>
that sounds easy enough, thanks , ill look into that
<dangole>
rsalvaterra: exactly. though things now do work out-of-the-box even with SELinux enforcing, everyone wants to still have the option to disable or set to permissive mode to debug policy...
<grift>
theres still a huge amount of loose ends and tough decisions ahead
<grift>
but thats what i like about selinux its so flexible there is no challenge you cannot tackle with it one way or another
<grift>
most others actually see that as a bad thing
<grift>
its so misunderstood technology
Slimey__ has joined #openwrt-devel
Slimey___ has joined #openwrt-devel
Slimey has quit [Ping timeout: 260 seconds]
Slimey__ has quit [Ping timeout: 260 seconds]
<rsalvaterra>
grift: Oh, I don't see SELinux as bad, quite the opposite. But when you have less than 8 MiB of total available flash and your CPU is a single-core in-order MIPS32 at 500 MHz, the overhead is immense.
<rsalvaterra>
So, there must be a way to disable it for smaller targets, of course.
<ldir>
I have made contact with Simon
<grift>
rsalvaterra: sure agreed
feriman has joined #openwrt-devel
<karlp>
it's misunderstood because most peoples first contact with it is when it' smisbehaving :)
<rsalvaterra>
karlp: I know, right? :D
<rsalvaterra>
I believe the best deployments are in Fedora/RHEL/CentOS, aren't they?
<grift>
i would argue that a device with =< 8 MiB and that kind of processor is not really a target or a liability
<grift>
basically it implies that it runs very little code and if its compromised then it doesnt have the power of affects its neighbours the < *MB flash also implies theres little other data on it that can be compromised
<karlp>
rsalvaterra: even on fedora, most most recent experience with it was installing a tftp server, and having it have the tftp port blocked :)
<karlp>
well, a small device can still very much be a liability....
<grift>
karlp tftp isnt supported on openwrt yet either
<grift>
although it might "just" work
<karlp>
I'm not talking about your ðpartial work on openwrt, I'm talking about "flagship" stuff like fedora.
<grift>
its not explored yet
<grift>
the issue with selinux on redhat is thats its basically shoved down people throat
<grift>
so people get intimidated by it because most are underpaid sysadm's with too much on their plates already
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<grift>
besides for most security is an afterthought
<grift>
i never suggested that selinux should be a default on openwrt
<karlp>
I was really onlyu commenting to rsalvaterra's comment on "best deployments on fedora"
<karlp>
I'm sure you guys will eventually give us a more secure openwrt
<rsalvaterra>
And we'll thank you all for that. OpenWrt is usually the first line of defense in most (smart) people's homes. :)
<grift>
i am advocating easy access to selinux but i surely would like people to choose for it first
<grift>
push comes to shove humans are the weakest link
<grift>
no point in trying to save someone who doesnt want to be saved
valku has quit [Ping timeout: 272 seconds]
matteo| has joined #openwrt-devel
valku has joined #openwrt-devel
matteo has quit [Ping timeout: 256 seconds]
<rsalvaterra>
grift: Whoa, that was dramatic… ;)
dedeckeh has quit [Remote host closed the connection]
<grift>
passionate but i dont make a fuss about it, this just small-talk
<grift>
but eh, these arent the 70's anymore today a compromise can costs someone his livelyhood
<grift>
so i wouldnt characterize it as dramatic, more like forward looking in a sense
<rsalvaterra>
I agree, for sure.
<Grommish>
In Germany, the first Ransomeware murder/death occured a few weeks ago. Hospital got hit with ransomware and had to transfer a patient to another hospital, who died in transit
<Grommish>
I'm all for improving security
dopje has quit [Quit: Checking other places]
Slimey___ is now known as Slimey
dopje has joined #openwrt-devel
voxadam has quit [Quit: WeeChat 2.8]
voxadam has joined #openwrt-devel
<damex>
PaulFertser: no photos yet... i don't think i can make leds are easily configurable but i can make boot/failsafe/running and upgrade modes have different light combinations for each. will it be acceptable?
<PaulFertser>
damex: I guess
<damex>
White + Blinking Blue for boot, Blue + Blinking White for failsafe and upgrade and constant blue for running system
<PaulFertser>
damex: even a single led is enough, it just blinks with different frequencies during boot, and then stays on when ready.
netprince has quit [Read error: Connection reset by peer]
Grommish[M] has quit [Ping timeout: 240 seconds]
<damex>
PaulFertser: any clue why only one eeprom is visible to openwrt on one wire bus? boot to stock - you an see both chips. there is nothing to adjust on that bus from device tree bindings point of view.
<damex>
first guess would that frequency is different but i rechecked and it is the same 100Mhz
<PaulFertser>
damex: 100 kHz?
<damex>
PaulFertser: yeah, sorry, 100kHz
<PaulFertser>
damex: you can try manually probing with i2cget
<PaulFertser>
damex: you can dynamically bind/unbind drivers via /sys/bus/i2c/drivers/ if needed
black_ant has quit [Ping timeout: 272 seconds]
hsp has quit [Quit: WeeChat 2.9]
<damex>
PaulFertser: thanks, i wonder what kind of address i2cget will need... gonna try to read some docs
<damex>
will build firmware with i2c tools and try to play around
<PaulFertser>
damex: bus and then the i2c address (regular one, not the one that's 2x that)
hsp has joined #openwrt-devel
MichaelOF has joined #openwrt-devel
mwarning has joined #openwrt-devel
<rsalvaterra>
Beer o'clock. Be back later. :)
brn has quit [Remote host closed the connection]
feriman has quit [Read error: Connection reset by peer]
<mwarning>
heh
feriman has joined #openwrt-devel
brn has joined #openwrt-devel
brn has quit [Ping timeout: 272 seconds]
Grommish[M] has quit [Ping timeout: 264 seconds]
Grommish[M] has joined #openwrt-devel
finsternis has joined #openwrt-devel
Zero_Chaos has joined #openwrt-devel
brn has joined #openwrt-devel
<Zero_Chaos>
Okay, so I have two very odd and very related issues. I suspect the fix is simple. When I run openwrt on x86-64 in docker, using mac80211_hwsim devices, the mac addresses which openwrt generates for *both* bridge interfaces and APs are *not* unique. This causes obvious and predictable issues.
<Zero_Chaos>
I can manually set mac addresses for every interface, but if someone can help me find the right spot, I'd rather submit a real fix
adrianschmutzler has joined #openwrt-devel
<PaulFertser>
Zero_Chaos: hey :) can you please describe it in more details? How many hwsim interfaces are you creating and what you're doing after that etc.
<Zero_Chaos>
PaulFertser: 20 wlan* devices and 19 br-* devices
<Zero_Chaos>
PaulFertser: 10 mac80211_hwsim devices total, each one is only allowed 4 ssids
jg_ has joined #openwrt-devel
<PaulFertser>
Zero_Chaos: and how do you create and configure them?
<Zero_Chaos>
PaulFertser: /etc/config/wireless and /etc/config/network
<PaulFertser>
Zero_Chaos: so it sounds like hwsim is not getting unique MAC and then bridge inherits that.
<damex>
PaulFertser: actually feels like the same problem as with leds. -16 error with EBUSY and when i try to probe it - it says 'nope, i am busy'
<PaulFertser>
Zero_Chaos: how are the hwsim devices created?
<Zero_Chaos>
PaulFertser: so the initial hwsim devices have unique addresses, but when the wireless gets brought up it makes a bunch of wlan* interfaces which do not have unique addresses and obviously explode
<Zero_Chaos>
PaulFertser: the "initial" batch of wlan* devices, created by module load, have unique but *very* similar mac addresses. when openwrt starts wifi, a ton more wlan* devices are made and mac addresses collide
<Zero_Chaos>
PaulFertser: I don't know what makes all the extra wlan* devices. I know they are all needed, but I don't know how/where openwrt creates them. some script I'm sure, that's what I want to fix
<PaulFertser>
Zero_Chaos: interesting. Autocreated interfaces are "managed", and then OpenWrt switches them to AP mode.
<damex>
interesting... stock does not include driver for at24 eeprom ...
<Zero_Chaos>
PaulFertser: it doesn't just switch them to ap mode, it makes a bunch more virtual interfaces.... that's the step that breaks
<Zero_Chaos>
afaict
<PaulFertser>
Zero_Chaos: extra meaning in addition to those managed?
<PaulFertser>
That's not how it works on real hardware.
Borromini has joined #openwrt-devel
<Zero_Chaos>
I have phy0-phy10, but ifconfig | grep wlan | wc -l is 20
<Zero_Chaos>
yes, yes it is
<Zero_Chaos>
it absolutely is
<Zero_Chaos>
this is the same config as I ran on hardware
<Zero_Chaos>
if you have multiple ssids it makes multiple wlanX-X interfaces
<Zero_Chaos>
and actually, I take some of that back, it looks like ALL the wlan devices get the same mac address, which is obviously super bad
<Zero_Chaos>
PaulFertser: even if I randomize all the mac80211_hwsim mac addresses before starting wifi, the bridges all get the same mac
<Zero_Chaos>
PaulFertser: something generates that mac, from a very low entropy source in my case
ivanich has quit [Quit: Konversation terminated!]
ivanich has joined #openwrt-devel
<Zero_Chaos>
PaulFertser: all of my bridge interfaces end up with HWaddr 02:42:AC:12:00:02
<Zero_Chaos>
PaulFertser: as a fact, even if all the wlan* interfaces have randomized mac addresses, when I "wifi up" it destroys all of the interfaces and brings up new ap mode ones and collides macs at that point
<Zero_Chaos>
something generates the hostapd config file and adds a bssid= line, and the entropy sucks in my case
Nick_Lowe has joined #openwrt-devel
Nick_Lowe has quit [Client Quit]
Nick_Lowe has joined #openwrt-devel
<Zero_Chaos>
issue the first is in the mac80211_generate_mac function in netifrc
Grommish[M] has quit [Ping timeout: 244 seconds]
Grommish[M] has joined #openwrt-devel
valku has quit [Ping timeout: 256 seconds]
<Zero_Chaos>
I can't decipher much more than that but the fact that /sys/class/ieee80211/phy*/macaddress is 02:00:00:00:*:00 is likely a problem
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Grommish>
of each image? one with and one without selinux?
<Grommish>
Or, is this going to be a buried option only accessible by building from source
<Grommish>
for those who want/know/care
gch9812134 has joined #openwrt-devel
<Grommish>
That might be the best way to do it
<aparcar[m]>
Grommish: depends on lobbying and needs. I'm currently using GitHub CI to just build all archs and offer imagebuilders. For OpenWrt I could imagine to have a dedicated SELinux release next to other releases.
<Grommish>
Well.. If it's an option in the Dev menu that isn't on by default, and isn't an option in imagebuilder, then unless they wanted it enough to roll their own, nothing changes for everyone else
<dangole>
Grommish: I'd suggest to provide SELinux-enabled ImageBuilder aside with normal ImageBuilder for upcoming release builds. but really only that.
<Grommish>
unless/until it takes over as the default
<Grommish>
which I hope it does at some point, though too ealy now
Nick_Lowe has joined #openwrt-devel
<PaulFertser>
Zero_Chaos: and what about /sys/class/ieee80211/${phy}/address_mask ?
<dangole>
Grommish: it's still half a meg gone just for that, so not every might even have that choice
<Grommish>
dangole: that's why we have rsalvaterra, champion of every bit and byte to be found
<Grommish>
:D
<aparcar[m]>
dangole: I'm afraid of double kernel builds with the build system. would you build it twice and then rsync just the imagebuilders?
<dangole>
aparcar: i'd just run phase1 again, selecting CONFIG_SELINUX but not selecting any images. and then, if we take it serious, also build all kmods from all feeds.
Redfoxmoon has quit [Read error: Connection reset by peer]
<Zero_Chaos>
PaulFertser: all zeros
<PaulFertser>
Zero_Chaos: yes, I see the same in my testing. On my rt2800usb card I have 00:00:00:00:00:07
Redfoxmoon has joined #openwrt-devel
<PaulFertser>
And all zeroes on my ath5k.
<PaulFertser>
Zero_Chaos: for me with hwsim the first address is 02:00:00:00:00:00 and the next is 02:00:00:00:01:00 but that function should keep that 01 intact.
<Zero_Chaos>
PaulFertser: yes, that's how I understand it as well, but it doesn't seem to
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Zero_Chaos>
PaulFertser: at least, with 10 phys and 20 ssids, it manages to make 4 working interfaces and the other 16 have duplicate mac to one of the 4 working ones
<PaulFertser>
Zero_Chaos: ah, so you have multiple ssids on each phy, that adds to the equation.
Nick_Lowe has joined #openwrt-devel
<Zero_Chaos>
PaulFertser: yessir it does
brn has joined #openwrt-devel
<Zero_Chaos>
PaulFertser: doesn't explain why all the ethernet interfaces have the same mac mind you :-)
<damex>
seems like if i enable kmod-sfp in imagebuilder - whoe process breaks on broken dependencies later durin build. after checking kernel - there is no sfp support enabled
Nick_Lowe has quit [Client Quit]
Nick_Lowe has joined #openwrt-devel
Nick_Lowe has quit [Client Quit]
brn has quit [Ping timeout: 272 seconds]
Nick_Lowe has joined #openwrt-devel
<PaulFertser>
Zero_Chaos: I wonder what's the contents of all those /sys/class/ieee80211/phy*/macaddress files you get and what the resulting MACs are.
Nick_Lowe has quit [Client Quit]
shibboleth has joined #openwrt-devel
<shibboleth>
anyone know if robimarko is on irc? nickname?
Guest88073 is now known as lep-delete
<Zero_Chaos>
PaulFertser: 02:00:00:00:<phy number here>:00
<PaulFertser>
Zero_Chaos: I found another clue, addresses have two addresses per hwmac phy
shibboleth has quit [Remote host closed the connection]
<Zero_Chaos>
PaulFertser: I don't see that here
shibboleth has joined #openwrt-devel
shibboleth has quit [Remote host closed the connection]
<Zero_Chaos>
is there a way to set macaddr for the br-* and the eth0.*?
merbanan has quit [Ping timeout: 240 seconds]
<Zero_Chaos>
PaulFertser: huh, well look at that, there are two macs there :-)
shibboleth has joined #openwrt-devel
Ycarus has quit [Quit: Ycarus]
<PaulFertser>
Zero_Chaos: and mac80211_get_addr just fetches the last one no matter how much you ask for. That's indeed a bug.
<Zero_Chaos>
both my br-* devices and the eth0.* devices all have the same bloody mac
<PaulFertser>
Zero_Chaos: yes, for each phy you get just two macs and then the function keeps returning you the last one.
<PaulFertser>
bridge devices can have same mac it's ok afaik.
<Zero_Chaos>
PaulFertser: trust me when I say it's not
<Zero_Chaos>
[ 6106.406455] br-lan110: received packet on eth0.110 with own address as source address (addr:00:a1:32:a3:51:b0, vlan:0)
<Zero_Chaos>
the packets all appear to be dropped, dhcp, etc, doesn't work
<PaulFertser>
On both my OpenWrt devices br-lan has the same MAC as wlan0.
<russell-->
Zero_Chaos: is this an openwrt-devel question?
<Zero_Chaos>
russell--: netifrc generating the same mac address for all my devices? yeah, I would say it is...
<PaulFertser>
russell--: yes, it relates to how OpenWrt scripts assign addresses to wifi interfaces. And one bug/omission is already found.
<Zero_Chaos>
PaulFertser: all my br-* mac addresses are identical, all my eth0.* mac addresses are identical, it's more than a wifi issue
<PaulFertser>
Zero_Chaos: the br-* addresses are identical because they follow the address of whatever was added to them first.
<PaulFertser>
Zero_Chaos: so that's a consequence that doesn't need fixing
<Zero_Chaos>
PaulFertser: fair enough, except I think that is the ethernet mac. same consequence, but an additional problem to fix
<Zero_Chaos>
PaulFertser: this is a guess, because I have set macaddr for all the wifi definitions and it seems to work as expected
merbanan has joined #openwrt-devel
<adrianschmutzler>
PaulFertser: Zero_Chaos: I didn't get the start of your discussion, but by incident I'm dealing with a very similar problem here at the moment
<adrianschmutzler>
"kern.warn kernel: [ 2186.933269] br-mesh: received packet on bat0 with own address as source address "
<Zero_Chaos>
adrianschmutzler: bunch of mac80211_hwsim devices, x86-64, docker container, too many similar macs. if your issue is related to that, keep talking :-)
<adrianschmutzler>
I first thought this was a batman-adv problem, but following your discussion I became aware that it isn't
<Zero_Chaos>
adrianschmutzler: that link you pasted in a common issue, doesn't have to be related to the problem I found.
<adrianschmutzler>
I'm not sure yet what my problem is caused by specifically
<PaulFertser>
Zero_Chaos: can you try it?
<PaulFertser>
It was added in 2014 :) 4d99db168cf7b7068aae540b405f90065e305302
valku has quit [Remote host closed the connection]
brn has joined #openwrt-devel
<Zero_Chaos>
PaulFertser: confirmed, that does fix the issue
<PaulFertser>
Zero_Chaos: I'd expect first two addresses to be used as is, and then the last byte incremented (taking from the first address) with each vif.
<Zero_Chaos>
PaulFertser: I'm running the openwrt-19.07 branch, assuming that "it was added in 2014" comment was for me
brn has quit [Ping timeout: 260 seconds]
<PaulFertser>
Zero_Chaos: certainly not exactly what I expected, and 04: 08: are even wrong, as they lack the 02: bit.
MichaelOF has quit [Quit: Konversation terminated!]
<PaulFertser>
Zero_Chaos: that comment was to reference the history of the code that I changed.
<Zero_Chaos>
PaulFertser: ahh, yes, just saw that
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<Zero_Chaos>
PaulFertser: even when I run that generate_mac code on my local machine, it increments the first octet, not the last.
<Zero_Chaos>
PaulFertser: if it was meant to increment the last octet, I suspect it never worked
<PaulFertser>
Zero_Chaos: we'll see soon
<Zero_Chaos>
PaulFertser: working on something for me to test?
<Zero_Chaos>
I have so many crazy setups for testing :-)
<adrianschmutzler>
if this is about the addresses for wifi interfaces on the same radio, it's supposed to something like 00 02 06 etc. if 00 was the initial address
<adrianschmutzler>
so, except for the first (=original) one, all should have local bit set
<PaulFertser>
Zero_Chaos: are you sure you did no other changes? I just tried it on my machine and it does fancy things to the last octet only.
<PaulFertser>
Ok, i'll retry with hwsim
<Zero_Chaos>
PaulFertser: I haven't made any other changes, no.
<Zero_Chaos>
it was just changing 1 to $id, right?
<PaulFertser>
Zero_Chaos: aha, I get it now
<Zero_Chaos>
PaulFertser: you mentioned your mask was 00:00:00:00:00:07, right? mine is all zeros, maybe that is the difference?
<PaulFertser>
Zero_Chaos: mask="ff:ff:ff:ff:ff:ff" spoils the fun, if you remove that line it'll be more predictable.
<PaulFertser>
But I'm yet to understand the intent behind it.
<Zero_Chaos>
PaulFertser: I remain clueless on that as well.
<Zero_Chaos>
PaulFertser: my version of mac80211.sh is different there, I'm on the 19.07 branch and this build was a few weeks ago
<Zero_Chaos>
PaulFertser: I made that change, but it still rolls the first octet around. I think my function has more differences than the one I just noticed on your changed line
<PaulFertser>
Zero_Chaos: yes, it should roll the first octet, that's the intent
<Zero_Chaos>
okay, lemme show you what it looks like then
<Zero_Chaos>
PaulFertser: well if you like it, and it works for me, this is a net win :-)
black_ant has joined #openwrt-devel
black_ant has joined #openwrt-devel
black_ant has quit [Changing host]
<Zero_Chaos>
PaulFertser: how do we get this fixed in netifd? Or do you have this power?
<adrianschmutzler>
for your latest post, the -1 addresses are wrong. those are supposed to be 06:00:... unless you are trying something very specific
<PaulFertser>
Zero_Chaos: I'll send a patch and then it's up to somebody to review.
<adrianschmutzler>
so, four is added to the wrong position
<PaulFertser>
adrianschmutzler: those -1 come from hwsim addresses
<adrianschmutzler>
ah, so those are not generated, but read somewhere?
<PaulFertser>
adrianschmutzler: so first two vif addresses come from /sys/class/ieee80211/phyX/addresses , the others are generated
<Zero_Chaos>
PaulFertser: thanks man, much appreciated.
<adrianschmutzler>
okay, then never mind
<Zero_Chaos>
PaulFertser: any chance you are also curious why all my ethernet and bridges have the same mac?
<PaulFertser>
Zero_Chaos: :) I'd check how you're creating the ethernet interfaces. I assume they should have different mac initially right after the creating.
<Zero_Chaos>
PaulFertser: *I* am not creating them. I define them in /etc/config/network and openwrt creates them
<aparcar[m]>
adrianschmutzler: seems like a missing file
luke-jr has joined #openwrt-devel
Darkmatter66_ has quit [Ping timeout: 256 seconds]
Borromini has quit [Quit: Lost terminal]
<PaulFertser>
Zero_Chaos: btw, you pinpointed the function to look it, I guess I wouldn't find it that quickly otherwise. I'm not yet able to figure out where addresses for vlan interfaces come from.
Misanthropos has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
Misanthropos has joined #openwrt-devel
<adrianschmutzler>
vlan interfaces like eth0.100 simply take the address of the corresponding device, e.g. eth0
<adrianschmutzler>
unless they have a specific address configured via uci
<adrianschmutzler>
(or ifconfig/ip etc.)
<xdarklight>
nbd: is the following commit missing a "git add include/toplevel-vars.mk" https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=ef7c34c1d1beac6bca4a683a3a161dd12a81f7e8 ?
llewellyn has joined #openwrt-devel
<adrianschmutzler>
so, if you just set up eth0.1 to eth0.100 in /etc/config/network, they will all have the same address, i.e. that of eth0
<PaulFertser>
adrianschmutzler: yes, looks like netifd just asks the kernel to create it and that's it. thanks for the clarification.