slh64 has quit [Read error: Connection reset by peer]
danitool has joined #openwrt-devel
danitool has quit [Read error: Connection reset by peer]
rsalvaterra has quit []
rsalvaterra has joined #openwrt-devel
rua has quit [Remote host closed the connection]
guidosarducci has quit [Remote host closed the connection]
guidosarducci has joined #openwrt-devel
rua has joined #openwrt-devel
GNUmoon has quit [Remote host closed the connection]
slh has joined #openwrt-devel
slh64 has joined #openwrt-devel
GNUmoon has joined #openwrt-devel
merbanan has joined #openwrt-devel
noltari has quit [Quit: Bye ~ Happy Hacking!]
noltari has joined #openwrt-devel
danitool has joined #openwrt-devel
robimarko has joined #openwrt-devel
Tapper has joined #openwrt-devel
shibboleth has joined #openwrt-devel
borek has joined #openwrt-devel
<rsalvaterra>
grift: I don't expect people who care about SELinux to worry too much about image sizes… ;)
<grift>
why not?
<grift>
selinux is all about efficiency vs effectiveness
<rsalvaterra>
For the exact same configuration, what's the size difference with/without SELinux?
<grift>
yes but its not just size that matters. its balance that you strike
<grift>
security in general and selinux in particular is all about compromising where you can
<grift>
take for example physical object security
<grift>
you can opt to not guard stuff at all
<grift>
you cannot opt to guard everything all the time though
<grift>
the art is to find that perfect balance
<grift>
you guard optimally so that it helps and it is cost effective
<grift>
efficiency versus effectiveness
<grift>
and that is what selinux in oenwrt doe
<grift>
you get control and its affordable
<rsalvaterra>
You don't need to sell me SELinux… ;) I'm asking from the perspective of someone whose primordial concern is the image size. Say, someone who has a device with 8 MiB of flash.
<grift>
most engineers see "performance" and: go go go
<karlp>
mrnuke: does hexdumping the device file not interfere with anything else expecting to be able to read there?
<grift>
but yes that is why i like selinux so much
<grift>
its flexible. you get all the attributes you need to get the job done. whether its simple or complex. youre in control
<grift>
and sure security is expensive
<karlp>
but you have to take control, which is why lots of people hate it...
<grift>
true
<grift>
people shy away from taking responsibility
<karlp>
alternatively, people attempt to delegate responsiility to domain experts, then get a little annoyed whe the domain experts say, "you're in control! it's for your benefit!" :)
<grift>
LOL
<grift>
yes theres this guy on twitter (i keep an eye on selinux mentions)
<karlp>
but now i'm kinda stirring, rather than contributing usefully, sorry :)
<grift>
he's always comparing selinux to 'old man selinux telling me what is good for me"
<grift>
totally missing the point ofcourse
<grift>
but still funny
<grift>
but yes good point though in gnu/linux debian i actually have th luxury to take another approach
<grift>
instead of providing a "fixes" security policy (a painting), i provide a canvas. paint and brushes (and a do-it-yourself guide)
<grift>
basically its a very minimal policy that only lays some of the ground works and provides templates and abstractions for the basics
<grift>
the policy doesnt block anything at all by default, you can have selinux enabled and enforcing and not notice it at all most the time
<grift>
but you get easy access, you can control selinux at runtime on the fly
<grift>
but yes eventually, still, security on linux is hard because linux is a complex beast
<grift>
not to mention that security in general is hard
<grift>
so you need to be security aware, linux aware
<grift>
arguably the selinux technicalities are the least of your worries
<grift>
regardless i know, selinux exposes the contents of the black linux box, it can be initimdating. and sure many people will choose to look the other way (most do not have a choice).that is also why i am fine with selinux in openwrt the way it is
<grift>
its there but you need to opt-in
<grift>
if you dont want to, thats fine
c0sm1cSlug has joined #openwrt-devel
<grift>
besides selinux is used to get the flak for linux
<grift>
even linus himself hates selinux
<grift>
in an environment where its essentially "only the strong survive" / "survival of the fitest" i can not be bothered by any of that. my concern is my livelyhood.
<grift>
its like the song goes: live and let die
<karlp>
"i've got selinux enabled and enforcing! yes! I'm doing the right thing!" "it doesn't have any rules out of the box, you need to add them yourself, and learneverythign about all syscalls by all programs you may ever run" ..... ok then... :)
<karlp>
it's a very security crowd pov, "security first, everything else afterwards"
<karlp>
a rock is secure from remote exploits, but it also doesn't _do_ anything....
<grift>
well its selinux is access control
<grift>
you can only control access if you are aware of the access vectors
<grift>
and those are variables
<grift>
because it depends on access control requirements, your environment etc
<grift>
but sure aside, security should be taken into account from th ground of ideally (well ideally in an not-so-ideal world at least)
<grift>
if you want to control access to your home then its probably a good idea if you know where the entry points are
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
Strykar has quit [Remote host closed the connection]
Strykar has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
cbeznea1 has joined #openwrt-devel
cbeznea has quit [Ping timeout: 480 seconds]
srslypascal has quit [Ping timeout: 480 seconds]
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
valku has joined #openwrt-devel
srslypascal has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
shibboleth has quit [Quit: shibboleth]
csrf has joined #openwrt-devel
cbeznea has joined #openwrt-devel
cbeznea1 has quit [Read error: Connection reset by peer]
yu has joined #openwrt-devel
yu has quit []
yu has joined #openwrt-devel
yu has quit []
goliath has joined #openwrt-devel
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
Strykar has quit [Quit: /quit]
Strykar has joined #openwrt-devel
torv_ has joined #openwrt-devel
torv has quit [Ping timeout: 480 seconds]
<hurricos>
mrnuke: ooh, I must have screwed up the regex.
<hurricos>
mrnuke: the preferable way to watch would be to run ... oh
<hurricos>
mrnuke: you saw the response, not the sent frame, I think -- /dev/ttyUSB1 -- wait, what? ttyUSB1?
<hurricos>
It should be /dev/ttyS0 -- it's the integrated serial.
<hurricos>
unless you're tapped to it directly?
<mrnuke>
Of course I've tapped it directly!
<hurricos>
hmmm!!!
<hurricos>
Can you confirm a difference between what's seen on the serial line and what you see in /usr/bin/realtek-poe -d?
<hurricos>
To use the latter, you do need to /etc/init.d/poe stop.
<hurricos>
If you can, you've found a bug in how main.c is using ubus.
<mrnuke>
karlp: It gets lost in the chatter, but I have an external USB UART watching the Tx line (hence tttyUSB1 instead of ttyS1)
<hurricos>
mrnuke: `git format-patch -p1` and `git am`'d. Much appreciated ;^)
<mrnuke>
hurricos: I think I understand why the "ad" in "de ad be ef" is getting lost. It's being replaced by the sequence byte
<hurricos>
replaced?
<hurricos>
It should be regular-sequenced. You send an array A B C D and it should do A SEQ B C D FF FF ... FF CSUM
<mrnuke>
yeah, in poe_cmd_queue()
<hurricos>
we are, after all, using poe_cmd_queue.
<hurricos>
It doesn't expect second byte to be 0x00
<hurricos>
...
<hurricos>
:coughs: wait, yes it ... does
Tapper has joined #openwrt-devel
<hurricos>
:facepalm:
<hurricos>
I swear, I read this code after writing it.
<hurricos>
mrnuke: If you could shim in the 0x00, I'll am your patch onto my realtek-poe. I'll probably do it during our Repair Cafe on Saturday if you don't get to it
<mrnuke>
That's okay. I can literally send the sommands I get from a serial dump, and it does the sequence byte and checksum for me automagically
<hurricos>
right, I'm just
<hurricos>
well, you achieved what I needed
<hurricos>
to find the bugs in the ubus sendframe implementatoin
<hurricos>
If you are able to confirm sending the whole thing as frames works, I'll have a basis to work on. Basically, I'd like to let realtek-poe read and decode state updates from the PoE MCU, but have (potentially) an external script drive the hardware setup frames, until we can generalize those frames.
<hurricos>
It's OK if we don't watch the state of the hardware -- after all, one important feature is that when the switch reboots, the PoE hardware should not.
<mrnuke>
Shimming is trivial: "if (cmd_len == 1) cmd_len++;". I had it originally and took it out.
<hurricos>
mrnuke: Well, in my head the format for outputting A SEQ C D was to send A C D to poe_cmd_queue.
<hurricos>
Sending a null byte space for poe_cmd_queue to add the SEQ later is rather ugly to my eyes
<hurricos>
but then that's what the code does, so ...
<mrnuke>
that wouldn't be consistent with the other uses in realtek-poe. Every cmd has an extra "0x00" where the sequence byte would go
<hurricos>
I understand.
<hurricos>
I misread the code.
<mrnuke>
And then devs can just paste dumps from the serial port. I would recommend leaving it as is
<mrnuke>
I was not yet able to get the chip to init sending it through realtek-poe. At some point it misses a reply or something. It keeps waiting for a reply that never comes, and doesn't time-out.
<mrnuke>
Now that could also be because cmd is 9 bytes, instead 12 bytes in the parser, but I didn't check that
<mrnuke>
I'm going to try to check with "uint8_t cmd[11];" later tonight
<hurricos>
:thumbsup: Thank you. I'll probably tear down my test box and rig up two external listening serials so as to see what the OEM HW does
<hurricos>
s/HW/firmware/
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
minimal has joined #openwrt-devel
Gaspare has joined #openwrt-devel
srslypascal is now known as Guest1019
srslypascal has joined #openwrt-devel
Guest1019 has quit [Ping timeout: 480 seconds]
vasilich has joined #openwrt-devel
Gaspare has quit [Quit: Gaspare]
vasilich has quit [Quit: Leaving]
cbeznea has quit [Quit: Leaving.]
Gaspare has joined #openwrt-devel
shibboleth has joined #openwrt-devel
Gaspare has quit []
Gaspare has joined #openwrt-devel
ptudor has joined #openwrt-devel
borek has quit [Ping timeout: 480 seconds]
ptudor_ has quit [Ping timeout: 480 seconds]
GNUmoon has quit [Read error: Connection reset by peer]
<jow>
nbd: I think your proposal totally makes sense but if Pablo can't be convinced then hius proposed solution would be good enough for now
<jow>
since we do the retry-dance anyway already we wouldn't need to change much but we could remove the logic for filtering non-hw-offload netdevs in the hw-offload enabled case
<mrnuke>
There's a huge bug (more than one actually) in realtek-poe. One thing is, if you don't get a reply to a packet, it waits forever on that reply. It doesn't resubmit the request or move on to the next one in the queue. It's essentially a soft lockup