<cr1901_modern>
I kinda want to do TCP/IP impl myself so I understand it. But since whitequark is already doing their own custom small TCP/IP stack, can't decide whether to just play with that source (easier, but I learn less looking at other's code) or impl it from scratch (learn more, harder).
<azonenberg_hk>
cr1901_modern: In most cases on a wrt54g class device
<azonenberg_hk>
you have a 5-port switch and 2-port router
<azonenberg_hk>
with one switch port going to one port of the router
<azonenberg_hk>
other 4 switch ports labeled lan
<azonenberg_hk>
other port of the router labeled wan
<azonenberg_hk>
and then somewhere in the pipe the switch is also bridged to the wireless interface
<cr1901_modern>
So 4 switch ports on lan == one port of the router?
<cr1901_modern>
And the 1 wan port == other port of the router?
<azonenberg_hk>
Yep
<azonenberg_hk>
Gotta run, work
<cr1901_modern>
have fun
azonenberg_hk has quit [Remote host closed the connection]
azonenberg_hk has joined ##openfpga
carl0s has quit [Quit: Leaving]
talsit has joined ##openfpga
digshadow has quit [Quit: Leaving.]
cr1901 has joined ##openfpga
cr1901 has quit [Client Quit]
<pointfree>
There are 4 HS tiles per UDB Pair or DSI. They are arranged in quadrants and their wires are numbered in a circle around the outside, from 0 to 95. I will upload my diagram once I've mapped all the HS bytes to this.
<azonenberg_hk>
well unless your emulator ran on an fpga... :P
<cr1901_modern>
no, that's something you have to fix in the protocol <-- Idk what azonenberg_hk was referring to here
<azonenberg_hk>
cr1901_modern: noise being interpreted as data
<azonenberg_hk>
this is an inherent problem in any long distance data transfer system
<azonenberg_hk>
only solution is checksums/MACs of some sort
<cr1901_modern>
Yea someone did a SNES FPGA impl recently, but isn't sharing their source, so... :/
<rqou>
also high speed links with the cable unplugged? :P
pie_ has joined ##openfpga
<azonenberg_hk>
plus FEC to mitigate corruption of individual data bits en route
<rqou>
i remember reading about some hardware guys that were having problems with their SATA during hot plug
<cr1901_modern>
mildly pissy about this, considering they claimed to formally verify the CPU core
<rqou>
it turned out that noise on the unplugged SATA cable would (with good probability) eventually match the "phy sleep" command
<cr1901_modern>
(which is possible b/c bus cycle behavior for the SNES CPU are given in the datasheet)
<azonenberg_hk>
rqou: with my 1gbase-X core i just declare the link down after a short time with no idle frames
<azonenberg_hk>
Lol
<rqou>
apparently the link down logic was broken
<rqou>
and then the phy would go to sleep after being unplugged
pie_ has quit [Changing host]
pie_ has joined ##openfpga
<rqou>
has the snes cpu been digitized yet?
<cr1901_modern>
There have been attempts, but nothing successful
<rqou>
really?
<rqou>
are the images lacking or do people just not have the patience?
<rqou>
how many metal layers is it?
<cr1901_modern>
Former. Have no idea. When byuu was developing higan, he asked someone on his forum to do it, but the images weren't sufficient
<whitequark>
rqou: nice bug
<cr1901_modern>
to actually vectorize
<cr1901_modern>
"it turned out that noise on the unplugged SATA cable would (with good probability) eventually match the "phy sleep" command" Erm, was this by design, or by freak stroke of luck o.0;
<azonenberg_hk>
cr1901_modern: lol
<cr1901_modern>
I'd be very humored if a protocol did that
<rqou>
consider that you are sampling random values at 6 gbps
<cr1901_modern>
i.e. "take noise profile of various cables, make the sleep command match the noise"
<azonenberg_hk>
rqou: does sata not have idle characters transmitted when the link is busy?
<cr1901_modern>
or some other "harmless" comand
<azonenberg_hk>
is not busy*
<azonenberg_hk>
you'll lose 8b10b sync almost immediately if the link goes down
<azonenberg_hk>
that alone should be enough to detect an unplug event
<rqou>
it probably does, i think the story claimed that somehow the loss of sync wasn't working
<azonenberg_hk>
a sequence of X consecutive invalid 8b10b characters
<azonenberg_hk>
or X characters with Y% being invalid
<azonenberg_hk>
At which point you go back to looking for COMWAKE
<azonenberg_hk>
and see what happens
<azonenberg_hk>
or is it COMINIT?
<rqou>
yes, doing it correctly without a bug should not cause this to happen
<azonenberg_hk>
i spent a while reading up on the sata link layer planning to implement it a while ago
<azonenberg_hk>
but never got around to it
<rqou>
the whole premise of the story was that there was a bug somewhere to start
<cr1901_modern>
Is the FPGA PLL sufficient for clock recovery of SATA, or will the PLL output go to hell once it detects a missing transition?
<azonenberg_hk>
Yeah
<azonenberg_hk>
cr1901_modern: You use the GTP forthis
<azonenberg_hk>
which has its own RX PLL
<azonenberg_hk>
the normal FPGA clock PLLs are meant to deal with squarewaves, first off
<azonenberg_hk>
second, the FPGA GPIOs arent fast enough to do this
<rqou>
not necessarily square, can be sine-ish :P
<azonenberg_hk>
the transceivers have a PLL specifically tuned for clock recovery
<rqou>
reduced swing ftw :P
* azonenberg_hk
off to gym
<rqou>
whitequark: simple solution to the ., problem: just use US keyboard layouts :P
<whitequark>
rqou: lol no
<whitequark>
as far as i'm concerned, us-only solutions do not exist
<rqou>
then use us-intl-altgr-dead-keys :P
<whitequark>
in fact i'll gladly support zh_HK-specific features before en_US-specific features, that will be better for codebase health long term
<rqou>
heh, i usually use us layouts with an IME to input chinese
<rqou>
zh_HK is actually relatively "not weird" on the "different from English is weird" scale
<whitequark>
well...
<whitequark>
if your program assumes it can index into strings by bytes everywhere...
<whitequark>
or that it can render characters by simply loading every single one of them from ttf on startup...
<rqou>
then it was already totally borked to start
<whitequark>
do you see what i mean now
<rqou>
rendering actually works fine
<whitequark>
no its not if you're rendering like 8000 vector chars on startup into a texture
<rqou>
eh, it just takes more ram :P
<whitequark>
i mean if you're ok with being as slow to start as vivado
<whitequark>
then maybe
<rqou>
it'll be slow, but it still renders correctly-shaped characters
<rqou>
you don't need "advanced" text shaping like arabic/indic languages
<whitequark>
arabic isn't that bad actually
<whitequark>
devanagari..... yeah...
<whitequark>
a bit of a nightmare
<rqou>
interestingly enough sublime text somehow managed to make themselves not accept IME input
<rqou>
fortunately i don't usually put chinese in my code
<whitequark>
I had to RE sublime to make that work
<whitequark>
they read a global variable from gtk before it's initialized or something like that
<rqou>
goddammit
<rqou>
shouldn't valgrind or whatever detect that?
<whitequark>
it's a logic error
<whitequark>
I mean, it's a null initially, not garbage
<rqou>
oh
<rqou>
on btw regarding chinese in code
<rqou>
i've seen files that are a mix of utf-8 and gbk in the same file
<rqou>
parsing that is fun
<rqou>
whitequark: so how does xim interact with scim or ibus or "whatever the thing is that lets me type pinyin on linux"?
<rqou>
why does the linux desktop suck so much?
<cr1901_modern>
Because nobody can agree on what the linux desktop should actually be
<rqou>
there was a great quote about this on lwn a while back
<rqou>
it was essentially "things I care about should work the way I want; things I don't care about shouldn't bother me by having backward-incomatible changes or security bugs"
<rqou>
"and for every user the two sets are different"
<cr1901_modern>
FWIW, I think XFCE is closest to what I want. It's the most minimal DE with a consistent feel (which LXDE lacks)
<rqou>
i don't care about DEs as long as the program does the thing I want
<rqou>
i run a mix
<cr1901_modern>
I've run everything from TWM (yes, *that* TWM) to Openbox
firebird_ has joined ##openfpga
<rqou>
i mostly run "gnome-like with some parts switched around"
<rqou>
most notably not the gnome shell thing
<rqou>
i run awesome wm
<cr1901_modern>
TWM actually isn't *that* bad if you can live w/o EWMH and are willing to be made fun of in public.
<rqou>
i don't even know what EWMH is
<cr1901_modern>
Basically it's "the part of freedesktop that gives you little icons in a taskbar", among other goodies
<whitequark>
rqou: just set the gtk input method
<cr1901_modern>
TWM doesn't implement it, thus taskbar icons don't work
<whitequark>
rqou: hang on
<whitequark>
rqou: remove "export GTK_IM_MODULE=xim" or change it to your input method in /opt/sublime_text/sublime_text.wrapper
<whitequark>
after installing my fix
<rqou>
so i have a speaker and networkmanager icon, does that use EWMH?
<whitequark>
s/xim/scim/ or w/e that should work
<whitequark>
rqou: no
<whitequark>
thats xembed
<rqou>
i remember reading a huge rant about these icon thingamabobs a while ago
<whitequark>
or, if you're using new gnome or kde, some dbus thing
<rqou>
probably from @eevee
<whitequark>
the dbus thing actually makes sense for one, because there's no xembed on wayland and other reasons
<whitequark>
but it resulted in Yet Another Split
<rqou>
i have no idea what "new" gnome or kde is vs "old"
<whitequark>
kde5 gnome3
<cr1901_modern>
EWMH does specify icons tho...
<rqou>
i also have no idea what dbus does other than "yet another IPC"
<whitequark>
nothing else
<whitequark>
it's just an IPC method
<rqou>
and "drama about putting it in the kernel"
<whitequark>
kdbus actually makes a moderate amount of sense
<whitequark>
by which I mean it's still stupid and a result of bad design in the 1st place
<rqou>
seems very drama-attracting for some reason
<whitequark>
but it's not as inane as some poeople make it out to be
<whitequark>
well
<whitequark>
dbus stuff is made by the same people who do systemd stuff
<whitequark>
dbus is not anywhere as bad. it's a slightly weird ipc method but i've seen far worse
<rqou>
systemd had a godawful migration plan but otherwise seems to "work" for me
<whitequark>
dbus security is a disaster
<whitequark>
systemd doens't work
<rqou>
as in "it has not intruded such that I have to care about it"
<whitequark>
pulseaudio doesn't work
* whitequark
shrugs
<rqou>
pulseaudio indeed doesn't work
<whitequark>
i literally have fixed multiple audio problems on my desktop by doing dpkg --purge pulseaudio
<whitequark>
the only thing that doesn't work without PA is skype, because MS ripped out *all other methods*
<cr1901_modern>
I don't know of a "better supported" audio mixer
<whitequark>
despite qt supporting them
<whitequark>
morons
<rqou>
i just don't care enough because it works most of the time
<whitequark>
cr1901_modern: alsa.
<whitequark>
rqou: yeah but you don't caring means it gets included in my distro more aggressively
<whitequark>
therefore, you are bad :p
<rqou>
i'm not azonenberg_hk, i don't enjoy shaving yaks :P
<whitequark>
azonenberg_hk: so when are you writing your own display server? :P
<cr1901_modern>
Oh, I guess that would work
<whitequark>
also 3d graphics stack?
<rqou>
i want to get not-sysadmin work done
<rqou>
my browser can play sound in my headphones, good enough
<cr1901_modern>
Hmmm... if xembed provides icons, why do I specifically remember ewmh support being a necessity for my desktop experience? I suppose I should've written this stuff down back when I needed to know
<rqou>
"So there are currently at least four different system tray gizmos for Linux: whatever Ubuntu does, whatever GNOME 3 does, whatever Plasma 5 does, and the standard thing. Maybe some of these are interoperable, or actually the same thing; I don't know. I don't even know where I should look to find out. I guess Ubuntu and Plasma 5 use the same thing, but under different names? But GNOME 3's is...
<rqou>
...different, if the Transmission anecdote is any indication?
<rqou>
If I were an application developer in need of a system tray icon, you can bet I would throw my hands in the air and just do the standard thing. Keeping up with all the forked replacements sounds like a huge waste of time when there's a new one every year, and anyway everyone seems to have some kludge to keep xembed working for now."
<whitequark>
there are two. there's the xembed thing and the dbus thing
<whitequark>
both gnome and kde use the StatusNotifier dbus rotocol now
<rqou>
i just rely on @eevee to research linux desktop footguns so i don't have to
<rqou>
why is putting a damn icon in the corner of the screen such rocket science anyways?
<rqou>
somehow windows has managed to make their notification area backwards compatible back to like win95?
<cr1901_modern>
b/c GUIs are hundreds of times harder than command line
<rqou>
i've never had this problem on windows
<rqou>
(granted you have other problems instead)
<cr1901_modern>
that's b/c some poor bastards were paid a full salary for many months to solve these problems.
<rqou>
doesn't e.g. canonical pay people?
<rqou>
(other than to NIH things?)
* cr1901_modern
shrugs. I imagine there was a massive amount of communication overhead in making sure Windoze components interacted nicely w/ each other
<cr1901_modern>
tbh, probably the most jarring thing for me in Linux desktop is having two clipboards- one provided by X, the other provided by GTK or Qt (?)
<rqou>
there are?
<cr1901_modern>
this... really shouldn't have happened
<rqou>
i never noticed
<rqou>
maybe this explains gnome-terminal's broken clipboard
<cr1901_modern>
middle mouse click if for the X clipboard
<cr1901_modern>
CTRL+C is the GTK clipboard (which may override the X clipboard?)
<rqou>
they seem to stay in sync for me?
<cr1901_modern>
Maybe it was a bug? I do remember them going out of sync before
<rqou>
although the windows clipboard kinda sucks too
<rqou>
there are multiple ways to access the same clipboard
<rqou>
not all the ways can round-trip all the types of information that can be on the clipboard
<rqou>
in general windows IPC is horrible
<rqou>
it's like every team in MSFT that needed an IPC built their own
<rqou>
same for "mechanism to exchange data to/from the kernel"
pie__ has joined ##openfpga
pie___ has joined ##openfpga
pie_ has quit [Ping timeout: 248 seconds]
pie__ has quit [Ping timeout: 268 seconds]
pie___ has quit [Ping timeout: 268 seconds]
pie_ has joined ##openfpga
pie_ has quit [Ping timeout: 258 seconds]
<azonenberg_hk>
whitequark: So how's the TCP stack going? Can you ping it yet?
<azonenberg_hk>
Can it SYN+ACK yet?
<whitequark>
I've implemented ICMPv4 yesterday, so yes, you can ping it!
<whitequark>
no SYN+ACK; I'm going to start with UDP and hone my buffering strategy on it (i.e. how does it mesh with Rust ownership rules)
<whitequark>
then I will implement TCP once this is done
<whitequark>
this night, perhaps, I'll get first SYN+ACK :p
pie_ has joined ##openfpga
<whitequark>
azonenberg_hk: you should be able to build it if you get a rust nightly (I use some unstable rust features) and then follow the instructions on https://github.com/m-labs/smoltcp
<rqou>
it's linux-based? not freestanding?
<whitequark>
it's not linux-based
<whitequark>
it's freestanding and in fact will not even need an allocator
<whitequark>
but to test it out you probably want to use some OS
<rqou>
oh so the tuntap is for testing only
<whitequark>
sure
<rqou>
hmm i might actually use this
<whitequark>
let me clarify the README
<whitequark>
:D
<rqou>
a while back my friend wrote a really shitty not-TCP that only knew how to do a three-way handshake and acks because all the freestanding tcp/ip stacks sucked
<cr1901_modern>
Right now, I can think of two micros this can target: ARM and OpenRISC (and I can't even really build the latter)
<rqou>
e.g. it ignored out of order packets
<cr1901_modern>
micro archs*
<whitequark>
rqou: I'm going to start with no fragmentation, no out of order segments
<whitequark>
but I see no reason these will not eventually be done
<whitequark>
I thought of a really elegant way to imlpement them
<rqou>
the thing my friend did didn't sit on ip though
<rqou>
it ran over a uart
<rqou>
and no, it didn't use hdlc or something stupid like that
<cr1901_modern>
B/c Pipistrello doesn't have Ethernet :/
<whitequark>
rqou: pushed some clarification
<cr1901_modern>
whitequark: If I have the OpenRISC llvm port already compiled, is there a painless way to compile a Rust for it? On Windoze.
<rqou>
use bash on windows :P
<whitequark>
cr1901_modern: dunno, don't care about developing on non-unix platforms
<whitequark>
deployment, yes, do care a bit
<whitequark>
development, just use a real OS
<cr1901_modern>
There are no real OSes.
<whitequark>
sure there is, the one that doesn't make my life hard :p
<whitequark>
and if it wasn't making your life hard you wouldn't be asking this question
<cr1901_modern>
I don't use Windows primarily b/c it makes life easy at this point.
<cr1901_modern>
Once this hardware dies I'll go to a mix of BSD and Linux, but while I'm here, I will damn well make sure software I use compiles for it
<cr1901_modern>
If only b/c I'm the only person in a 500 mile radius who cares enough
<whitequark>
cr1901_modern: we have an idiom in Russian, "being a vicious Pinoccio towards yourself"
<whitequark>
... or something like that, it doesn't sound quite as nice in English
<cr1901_modern>
hmmm... not sure I get it lol
<cr1901_modern>
Pinocchio was a liar. Am I lying to myself?
<whitequark>
it's more that he's fundamentally good but gets himself in trouble for silly reasons.
<whitequark>
that he has caused himself.
<cr1901_modern>
I can't disagree in that case :). In any case, I haven't compiled Rust in over a year, and in many cases, compilation would fail even on Linux (mainly Ubuntu flavors)
<cr1901_modern>
so I am anticipating some pain if I want to use your TCP stack on non-ARM micos
<whitequark>
wait, openrisc?
<rqou>
how well does rust freestanding work at this point?
<whitequark>
or risc-v?
<whitequark>
rqou: less painful than freestanding c but more painful than it should be
<cr1901_modern>
openrisc
<whitequark>
you can generally use no_std libraries fairly freely
<rqou>
less painful than freestanding c? I don't believe you :P
<whitequark>
but there are some notable silly omissions, like io traits not being on libcore
<rqou>
that's quite impressive if it is indeed less painful
<whitequark>
is a real snippet you can insert in your freestanding code
<whitequark>
and have it just work
<rqou>
no f*cking with newlib required?
<whitequark>
absolutely no libc dependencies
<whitequark>
also you get rich formatting/pretty-printing that doesn't need heap
<rqou>
can i still force it to generate an elf .o to go into binutils?
<whitequark>
write!(UART, "{}", &[&[1.0, 2.0, 3.0], &[4.0]]) will simply work
<whitequark>
sure
<rqou>
(i had huge problems with this using emscripten)
<whitequark>
rustc --emit obj
<rqou>
because emscripten doesn't have a "binutils"
<whitequark>
I actually am not sure how to make rustc itself invoke the linker, so that's what I do
<whitequark>
you can also do --crate-type staticlib
<rqou>
so what is the interaction between llvm and binutils?
<whitequark>
none?
<whitequark>
well
<whitequark>
llvm is a compiler library, it doesn't know that linkers exist nor does it care
<rqou>
so what does it produce?
<whitequark>
object files
<rqou>
hmm
<whitequark>
so it has a comiler and and assembler
<rqou>
so when I use clang how does the object file become an executable?
<rqou>
it uses binutils?
<whitequark>
frontends (clang, rustc, etc) include custom lpatform-specific rules for invoking the linker
<whitequark>
it uses gcc usually, in fact
<cr1901_modern>
whitequark: I was asking how to compile Rust b/c I don't actually know how to target a non-default LLVM. I recall there being a switch for this during the ./configure step >>
<whitequark>
to link
<cr1901_modern>
but since I've never actually gotten this to succeed, I'm not sure if extra work is required afterward to make my mor1k-rustc target mor1k by default
<rqou>
wtf
<whitequark>
cr1901_modern: --llvm-root= or something
<whitequark>
cr1901_modern: there are no cross-rustcs.
<rqou>
so clang --> llvm --> gcc --> ld ?
<whitequark>
every rustc is a cross-compiler and only a cross-compiler
<rqou>
how does it work on osx?
<cr1901_modern>
Well the llvm I want to target ONLY have mor1k enabled, so... LOL
<cr1901_modern>
I guess I'm rebuilding
<whitequark>
cr1901_modern: yes, you won't be able to bootstrap rustc with that
<whitequark>
rqou: it also knows about system linkers on various OSes
<whitequark>
on windows it knows to invoke link.exe, on fbsd and osx it knows to invoke ld64 and whatever fbsd is using now
<whitequark>
it doesn't *always* go through gcc, it does on linux though
<rqou>
i see
<whitequark>
rqou: there is now lld, which is great
<whitequark>
so i hope at some point, maybe in a year or two, it will simply always invoke lld, or rather link lld into itself
<rqou>
so where does libc++, libstdc++, libc, libgcc, and other glue fit in?
<whitequark>
then producing any executable would happen entirely without forks
<rqou>
there's the "clang" set of libc++ and compiler_rt iirc
<cr1901_modern>
whitequark: Is that really an issue? I mean the configure step is going to download a Rust, right?
<whitequark>
clang also has custom glue for libc++, libstdc++, libc, libgcc_s, libcompiler-rt (which is like libgcc_s except when it's not) and so on
<cr1901_modern>
for bootstrap purposes*
<whitequark>
this is why rustc uses a system gcc
<whitequark>
to avoid having that
<whitequark>
clang has to know about it anyway because of include files and such
<whitequark>
and because sometimes it *is* the single source of truth for linking, like gcc usually is
<rqou>
so does rust not need any of that glue?
<rqou>
or does it still need libgcc?
<whitequark>
rqou: are you building a dynamic executable using glibc? then it does
<rqou>
what if i'm building arm freestanding softfloat?
<whitequark>
are you building freestanding? it only needs compiler-rt then, which is already packaged in crates.io
<rqou>
and not libgcc?
<whitequark>
libgcc_s and libcompiler-rt provide ~same set of intrinsics
<whitequark>
well
<whitequark>
libgcc_s ~ libcompiler-rt+libunwind
<rqou>
so it still needs one of those
<whitequark>
if you're masochistic and want to use unwinding on your freestanding micro, sure, just build libunwind
<cr1901_modern>
"this is why rustc uses a system gcc" So wait... I thought Rust emits code using LLVM
<rqou>
for e.g. softfloat libs
<whitequark>
I actually patched it upstream to be able to do that
<whitequark>
cr1901_modern: correct
<whitequark>
rqou: yes.
<whitequark>
this is unfortunate and they are being rewritten in rust
<rqou>
also softfloat and unwind both totally work on micros
<whitequark>
but it's not yet done so for now it requires a compiler-rt compiled
<cr1901_modern>
Then why does it need the system gcc if it already uses LLVM, which implies all that glue
<rqou>
i would much appricate a rewritten softfloat btw
<whitequark>
I know, I was talking about building llvm's libunwind for freestanding specifically
<whitequark>
cr1901_modern: LLVM is a compiler, LLVM knows nothnig about linking
<whitequark>
LLVM doesn't know how multiarch on your debian system works, or where to find libc
<rqou>
because linking is where all of the footguns and alcohol consumption occur :P
<cr1901_modern>
gcc is a compiler too
<whitequark>
no.
<whitequark>
gcc and clang are compilers combined with compiler drivers.
<rqou>
cc1 is the compiler
<whitequark>
the compiler driver part knows how to link.
<whitequark>
llvm does not include a compiler driver anywhere.
<whitequark>
you could make rustc invoke clang, with about same effect, i think
<whitequark>
and rustc on windows knows how to invoke msvc too
<whitequark>
if building a native executable without mingw
<whitequark>
hilariously, sometimes it may invoke link.exe but the link.exe is actually lld.exe (which is the linker produced by the LLVM community)
<whitequark>
because lld.exe can emulate link.exe on windows, and ld on unix
<rqou>
does rustc generate seh unwinding or mingw unwinding?
<cr1901_modern>
So why doesn't Rust just... ya know... invoke ld directly?
<rqou>
on 32 bit and 64 bit windows?
<whitequark>
rqou: llvm generates that, and since recently it has the capability to do both
<cr1901_modern>
instead of using the compiler driver
<whitequark>
rqou: i believe it does the thing appropriate for the platform
<rqou>
even 32-bit fs:[0] unwinding?
<rqou>
non-zero-cost unwinding
<whitequark>
so if you're building a crate compatible with msvc, you'll get seh
<whitequark>
i don't know about fs:[0] unwinding
<whitequark>
i know there's a serious effort to be exactly compatible with msvc abi in clang
<rqou>
btw native binaries on windows suck super horribly
<rqou>
tons of ABI footguns everywhere
<whitequark>
cr1901_modern: because then it would have to reimplement all the weird shit the compiler driver knows
<whitequark>
like where in /usr the libraries are
<whitequark>
and which bullshit the platform requires linking with
<whitequark>
there are several thousand lines in clang dealing with exclusively the above
<whitequark>
i think it does invoke link.exe on windows if you build a fully native binary/library
<whitequark>
because link.exe knows all that
<rqou>
it would be quite impressive if llvm has 32-bit seh
<azonenberg_hk>
as your properties are shown to hold on the actual circuit description
<azonenberg_hk>
not just the hdl
<azonenberg_hk>
whitequark: now all they need is a formally verified CPU to run it on
<azonenberg_hk>
and i might be interested :p
<rqou>
but i _want_ to be able to root computers (as long as I'm the one doing the rooting :P )
<azonenberg_hk>
rqou: lol
<whitequark>
rqou: even antikernel has a debug port
<rqou>
where can we hide the us gov golden master key? :P
<azonenberg_hk>
whitequark: interestingly enough the debug port is still limited
<azonenberg_hk>
for example, you cannot use it to read memory belonging to another node
<azonenberg_hk>
(unless you compile a packet sniffer into the netlist at synth time)
<azonenberg_hk>
The debug port provides layer 2 bridging between your PC and the NoC
<azonenberg_hk>
But it forces your packets to be in a certain subnet
<azonenberg_hk>
which is not used for any on-chip IP
<azonenberg_hk>
i think it just hard-wires the two MSBs high
<azonenberg_hk>
So the bridge cannot ever forward a packet that impersonates an on-chip entity
<azonenberg_hk>
This is by design, i want the bridge (unlike e.g. a LA core) to be something you can safely leave in a released system
<azonenberg_hk>
without breaking the security model
<azonenberg_hk>
nothing stops you from fusing it off, of course, but leaving it there should not allow anyone to see or modify sensitive state
<whitequark>
mhm
<whitequark>
i want the MSB hardwire to be disabled by a physical pin pulled high :p
<whitequark>
that could also erase some security module as a side effect
<azonenberg_hk>
I intentionally limited debug capabilities
<azonenberg_hk>
If you want to read memory belonging to an app on the CPU, for example
<azonenberg_hk>
you cannot ask the RAM controller directly
<whitequark>
well yes, I'm unhappy with that
<whitequark>
if I have physical access to a device I own
<azonenberg_hk>
you have to use the bridge to send a request to the debug controller on the CPU
<whitequark>
I must be able to do anything, as a form of fundamental freedom
<azonenberg_hk>
Which then forwards the request, if permitted by the app's manifest
<azonenberg_hk>
whitequark: here's the thing though
<azonenberg_hk>
it doesnt stop you from running and debugging arbitrary code on the cpu, assuming you have a key the CPU's secure boot trusts (in a freedom-preserving system there'd be a means to load your own key in there, after wiping existing key material etc)
<azonenberg_hk>
What it DOES do is require that the app consent to being debugged
<azonenberg_hk>
You can take any binary you want, re-sign with your own key after setting the debug-enable bit, and run it on your board that trusts your signing key
<whitequark>
well, yes, I don't care about "app consent", that just means ads and/or implants
<whitequark>
I want a system where DRM is inviable by design
<azonenberg_hk>
I hate DRM with a burning passion, and i'd rather write spy code for NSA 10x over than do DRM
<whitequark>
okay that's a good amount of hate
<whitequark>
so why the app consent thing then?..
<azonenberg_hk>
but I don't think "DRM inviable by design" is possible in a system that is also secured against malicious software
<azonenberg_hk>
The goal is to allow untrusted code to share the CPU with trusted code
<azonenberg_hk>
and not be able to modify or observe it
<cr1901_modern>
DRM is awful, but I do recognize that I'm unlikely to pursue the knowledge/data hidden from me via DRM anyway lol
<azonenberg_hk>
i.e. a random game you downloaded shouldn't be able to attach to your browser and dump TLS keys
<azonenberg_hk>
This is especially important in a server or SCADA environment
<whitequark>
hm
<azonenberg_hk>
You may have multiple mutually untrusting parties running code on one platform
<azonenberg_hk>
and none should have any access to the other's state
<azonenberg_hk>
I believe this is impossible to provide without also being DRM-friendly
<azonenberg_hk>
although i'd be happy to be proven wrong
<whitequark>
why not have the debug port have the ultimate capability?
<whitequark>
more trusted than anything else in the system
<azonenberg_hk>
I want some level of protection against someone subverting the system through a few seconds of physical access
<azonenberg_hk>
obviously extended physical access can't be stopped
<azonenberg_hk>
But plug-and-pwn can
<whitequark>
azonenberg_hk: so my suggestion is:
<whitequark>
a) have a physical switch
<whitequark>
b) have it routed in a way that toggling it hard-resets the system, alerting the operator
<azonenberg_hk>
In a full-production system i'd likely have a strap pin that when held high wipes crypto engine state and allows you to add new signing keys
<azonenberg_hk>
(after a reboot)
<whitequark>
so you couldn't do drive-by USB attacks
<azonenberg_hk>
Once the user has their own signing key installed, they can re-sign and debug any code they want
<azonenberg_hk>
They just lose whatever that app encrypted to itself
<whitequark>
you'd require the operator face an unexpected reboot, and a key store erasure
<azonenberg_hk>
thus preserving confidentiality of e.g. FDE keys
<azonenberg_hk>
keep in mind, TV owner trying to read HDCP keys
<azonenberg_hk>
is indistinguishable in a threat model perspective
<azonenberg_hk>
from evil maid trying to read FDE keys
<whitequark>
yes, that's not the kind of DRM I'm worried about
<azonenberg_hk>
I want a system that is fully auditable and verifiable, and you can tell exactly what code is running
<azonenberg_hk>
for example in my current cpu i have a command that lets you query the CPU for a PID
<whitequark>
appliances are fine, what's not fine is a system that's fundamentally wired to run code you cannot affect
<whitequark>
Intel ME
<azonenberg_hk>
and it gives bakc a signature over the app
<whitequark>
this kind of stuff
<azonenberg_hk>
Yes
<whitequark>
hence why I'm worried about undebuggable apps
<azonenberg_hk>
Well...
<cr1901_modern>
azonenberg_hk: Question is, can a single person actually audit/verify your system in a reasonable amount of time :P?
<azonenberg_hk>
I am OK with code you cannot modify
<whitequark>
cr1901_modern: you run the proof assistant
<azonenberg_hk>
As long as you can verifiable audit it
<azonenberg_hk>
verifiably*
<azonenberg_hk>
i.e. i'd be OK with ME if i could decrypt the blob and check it for backdoors
<azonenberg_hk>
even if i couldn't overwrite it
<whitequark>
I largely agree here
<whitequark>
if it doesn't have unwanted capability there is generally little reason to remove it
<whitequark>
in practice
<azonenberg_hk>
And if it does, you can always corrupt the executable on disk
<azonenberg_hk>
at which point secure boot will refuse to run it :p
<azonenberg_hk>
Or replace it with a null blob you signed
<azonenberg_hk>
now, a non-freedom-preserving system could contain a hard IP core that queried the CPU for the signature of a given binary
<cr1901_modern>
whitequark: Fair enough. I don't have a background in logic, so I really don't know how to use a proof assistant.
<azonenberg_hk>
and if not matching the desired value, forced a reset or something
<azonenberg_hk>
But this is the SoC designer's choice
<cr1901_modern>
Even figuring out "what I want to prove" and then describing that to say, yosys, is tough.
<azonenberg_hk>
and again, i don't think it's possible to have DRM completely impossible architecturally while still providing any degree of strong security
<azonenberg_hk>
My long-term dream is to have an antikernel SoC made using an open source cell library, e.g. vsclib for 180 nm
<azonenberg_hk>
using overly generic restrictive design rules
<azonenberg_hk>
PAR and implement the entire system
<azonenberg_hk>
Put the GDS of the entire SoC core on github
<azonenberg_hk>
Add black-box foundry I/O cells as i don't think you can realistically avoid that
<azonenberg_hk>
every time a production run of chips comes back, decap and delayer a few at random
<azonenberg_hk>
and diff against the published GDS
<azonenberg_hk>
this would of course have to be heavily automated, and done by an independent third party testing house or at least with independent oversight, to provide assurance
<azonenberg_hk>
So at this point you can have very high trust that the chip you bought actually implements the published layout
<azonenberg_hk>
There would be LVS checks to verify that the layout is equivalent to the published RTL
<azonenberg_hk>
And presumably correctness proofs on the RTL
<azonenberg_hk>
for at least major subsystems, probably impractical to do the entire soc
<azonenberg_hk>
The choice of what software to run on this soc, and what keys to trust, etc is not my problem
<azonenberg_hk>
Yes, someone can build a non-freedom-preserving system on it
<azonenberg_hk>
But you can also build an extremely free and trustworthy system on it
<azonenberg_hk>
Which is my goal
<whitequark>
azonenberg_hk: I agree that making DRM comletely impossible is at odds with building a secure system
<whitequark>
this is not about a formal rule but rather ethical guidelines on the kinds of systems we should build and promote
<azonenberg_hk>
And my contention is, the ethical decision is the system designer's responsibility
<azonenberg_hk>
if i build a high performance NIC for a server i can't stop someone from DDoSing with it
<azonenberg_hk>
that's an inherent capability it has which makes it useful
<whitequark>
I'm talking about such things as e.g. not providing strong DRM capabilities out of box (see my debug port qualms above)
<whitequark>
about refusing to upstream such features
<whitequark>
etc
<whitequark>
they are clearly *possible* on any turing-complete system
<azonenberg_hk>
The intention of the debug port setup was not to enable DRM, or prevent debugging
<whitequark>
that doesn't mean we have an obligation to make them easy, architecturally or structurally
<azonenberg_hk>
It was to offload that decision to the individual modules
<whitequark>
right, I understand that wasn't the intention
<azonenberg_hk>
i.e. the CPU owns this page of ram
<whitequark>
I'm just looking at it on a higher level
<azonenberg_hk>
therefore the CPU has discretion on who gets access
<azonenberg_hk>
if you want to have a strap pin that lets the CPU say "OK" to anyone?
<azonenberg_hk>
fine
<azonenberg_hk>
but correct routing and packet origin tagging is so fundamental to the security of the system that i'm extremely hesitant to break it
<azonenberg_hk>
i prefer to enable debug capabilities at the endpoint rather than break the network
<azonenberg_hk>
So in GRAFTON, my single-threaded CPU, for example
<azonenberg_hk>
I had a debug port that provided a virtual memory read API
<azonenberg_hk>
There was no security on it
<azonenberg_hk>
Anyone could ask the CPU to halt and then read from a given virtual address
<azonenberg_hk>
but you'd be denied if you wanted to read the corresponding physical address directly from ram
<whitequark>
it's a tradeoff, sure
<azonenberg_hk>
not a tradeoff
<azonenberg_hk>
You can provide the exact same capabilities at the endpoint
<azonenberg_hk>
and not on the network
<whitequark>
ah, I see what you mean
<azonenberg_hk>
one of the key tenets of antikernel is to make piecewise analysis possible
<whitequark>
sure, it could have a memory access port instead of the network spoof capability
<azonenberg_hk>
i.e. you can prove correctness of any module in isolation
<whitequark>
I don't insist on a specific imlpementation
<azonenberg_hk>
and the proof of all modules, plus the network, equals a proof of the system
<azonenberg_hk>
This only works if you cannot break the network
<azonenberg_hk>
My current plan is for each executable to contain, in the signed elf image, a "debug allowed" bit
<azonenberg_hk>
Which enables or disables the debug port per app
<azonenberg_hk>
or may even permit debug from certain sources and not others
<azonenberg_hk>
you can modify this metadata as you see fit, but you have to re-sign the app to do that
<azonenberg_hk>
Just like e.g. android
<azonenberg_hk>
Which means the system you run on has to trust your key and you can't spread the patched version around willy-nilly to non-consenting hosts
<azonenberg_hk>
Other code on the system can also query for the key that signed a given app and refuse to talk to your modified version
<azonenberg_hk>
again, you can patch and re-sign that code too
<azonenberg_hk>
if you control the root CA
<azonenberg_hk>
Which i think the owner of a system should be able to do
<azonenberg_hk>
But in an appliance scenario, the owner needs some assurance that the system is what he thinks it is
<azonenberg_hk>
And one of the easy ways to do that is to provide a verifiable, auditable means to query what CAs are installed on the system
<azonenberg_hk>
and which apps were signed by which CA
<whitequark>
ultimately if you have the root key it doesn't seem like there's anything that will lock in DRM
<azonenberg_hk>
Correct
<whitequark>
because you can just take all of its binaries
<whitequark>
and enable debug
<azonenberg_hk>
Exactly
<azonenberg_hk>
But there is still an attestation feature that allows you to detect (via the debug port or NoC) that this modification happened
<azonenberg_hk>
the auditability is key
<azonenberg_hk>
I'm OK with you being able to run arbitrary code on your own hardware
<azonenberg_hk>
I'm not OK with not being able to tell that this happened
<azonenberg_hk>
this isn't classic remote attestation in that you have to be on the system to do this
<azonenberg_hk>
It is possible to implement DRM-esque remote attestation by having an app on the CPU that checks the key an app was signed with in response to a network query, then signs with a key in the crypto engine
<azonenberg_hk>
A key that would be wiped if you added a new CA
<azonenberg_hk>
But I'm OK with a third party refusing you to access their system if they can tell you modified yours
<whitequark>
there are valid reasons for that, like credit cards
<azonenberg_hk>
The thing I care about is that you, the user, can run code on your own hardware, and can tell with high assurance that you are running the code you think you are
<whitequark>
yeah
<azonenberg_hk>
Exactly
<azonenberg_hk>
good example here actually
<azonenberg_hk>
payment processing subsystem attached to a web server
<azonenberg_hk>
you dont want the web app able to debug the payment app
<whitequark>
yup
<azonenberg_hk>
And neither the web dev nor the credit card company trust each other
<azonenberg_hk>
so both have to be protected from each other
<whitequark>
... and I'm not even sure what has more vulnerabilities, it's a tough race...
<azonenberg_hk>
Lol
<azonenberg_hk>
Anyway, that's really where i'm trying to go with this architecturally
* whitequark
recalls a payment company in RU whose signatures were vulnerable to trivial md5 hash length extension attacks
<azonenberg_hk>
lol
<whitequark>
apart from, you know, md5
<azonenberg_hk>
And i don't see any ethical concerns with the architecture i have defined at a high level
<azonenberg_hk>
particular implementations of it, sure
<whitequark>
I agree that this is about implementations
<azonenberg_hk>
But this is one of the many reasons i want to get more interested parties involved as i flesh out the design
<whitequark>
ultimately the reason is the imbalance of power between vendors of hardware and users
<azonenberg_hk>
Yeah
<whitequark>
a vendor can unilaterally decide to force DRM on you
<whitequark>
or a cartel of vendors
<whitequark>
and there's nothing you can really do about this
<azonenberg_hk>
Yes, exactly
<azonenberg_hk>
ditto with subscription model software
<azonenberg_hk>
like photoshop
<azonenberg_hk>
they have the only viable tool in the industry for it, gimp doesnt come close
<azonenberg_hk>
if they decide you have to pay them every month/year instead of buying it once
<azonenberg_hk>
there's nothing you can do
<azonenberg_hk>
short of patching gimp to add those extra features :p
<azonenberg_hk>
And that's not a route $WIFE has any interest in taking lol
<whitequark>
heh
<azonenberg_hk>
and now we come full circle back to open FPGA tools
<azonenberg_hk>
Lol
<azonenberg_hk>
whitequark: so any idea when you'll have time to work on pcbhdl?
<azonenberg_hk>
This weekend sound viable still?
<whitequark>
azonenberg_hk: yes absolutely
<whitequark>
I plan to do UDP today and TCP today or tomorrow
<whitequark>
as a first approximation that can be dpeloyed
<whitequark>
further improvements can be postponed
<azonenberg_hk>
TCP in one day? good luck on that
<azonenberg_hk>
UDP is a cakewalk
<azonenberg_hk>
once you have IP
<azonenberg_hk>
Of course my last TCP stack was on an FPGA :P
<azonenberg_hk>
Speaking of which when i get around to that part of my upgrade
<azonenberg_hk>
i just got an idea on how to be much more efficient
<azonenberg_hk>
area wise
<azonenberg_hk>
i can cut out a bunch of block ram fifos and replace them with a few pages of main RAM plus ~32 bits of state per socket
<azonenberg_hk>
once i retool things 128+ sockets in a relatively small fpga area should be viable
<azonenberg_hk>
During the rewrite i'm also going to fix it so you can have more than one connection per port
<azonenberg_hk>
right now socket handles are bound to port numbers 1:1
<whitequark>
azonenberg_hk: the hard part is buffering here
<azonenberg_hk>
So my plan is
<whitequark>
or rather doing it in rust
<azonenberg_hk>
ah yeah
<azonenberg_hk>
on the FPGA side my plan is
<azonenberg_hk>
when you open a socket, immediately malloc a page to use as an RX buffer
<azonenberg_hk>
When you get a new segment on an empty buffer, DMA directly to the buffer
<azonenberg_hk>
Then send an informational message to the owner saying a frame is ready
<azonenberg_hk>
When you DMA to the buffer, if the packet isn't a multiple of 32 bits long
<rvense>
me and a friend got an lattice's sdram controller running on a hx8k board and (apparently) speaking to a 32mb chip last night
<azonenberg_hk>
store the odd bytes in the offload engine as a temp value
<azonenberg_hk>
The next DMA write gets shifted and rotated
<azonenberg_hk>
so for example if you have 2 bytes left over from the last segment
<whitequark>
rvense: which board?
<azonenberg_hk>
the next segment writes (archived bytes, first 2 of next segment) to the buffer first clock
<whitequark>
breakout?
<azonenberg_hk>
next one is (bytes 2-5 of next segment) etc
<rvense>
whitequark: lattice's hx8k "breakout" with our own thing plugged in
<azonenberg_hk>
Then whenever you get a read request, flush the last few bytes to ram and send the page over to whoever wanted it
<azonenberg_hk>
whitequark: make sense?
<whitequark>
rvense: nice, care to share the breakout layout?
<whitequark>
i assume it uses the jedec sdram chip?
<whitequark>
chip interface rather
<azonenberg_hk>
(I might do 64 or 128 bit temp buffer instead of 32 depending on dram burst size etc)
<whitequark>
azonenberg_hk: yup
<azonenberg_hk>
So if i have a 128-bit temp buffer worst case
<rvense>
whitequark: the plugin board? it needs to cleaned up. the muppet who laid it out didn't check if the pins were used elsewhere, so some of the address pins have the LEDs on them :/
<whitequark>
"the muppet who laid it out" lol
<whitequark>
harsh
<rvense>
it's a-me!
<whitequark>
azonenberg_hk: having a real weird bug here
<whitequark>
ip header checksum is ok
<whitequark>
ic*mp* header checksum is not ok
<whitequark>
they use the same checksum algo right?
azonenberg_hk has quit [Ping timeout: 260 seconds]
azonenberg_hk has joined ##openfpga
<azonenberg_hk>
gaah wifi derped out again
<azonenberg_hk>
whitequark: what was last you got from me?
<whitequark>
"14:18 < azonenberg_hk> So if i have a 128-bit temp buffer worst case"
<azonenberg_hk>
(22:18:49) azonenberg_hk: that's 128 sockets worth of state per block ram
<azonenberg_hk>
(22:19:05) azonenberg_hk: plus probably a lutram that stores the size of the temp buffer for each socket
<azonenberg_hk>
(22:19:14) azonenberg_hk: or maybe another bram if i can shove some other state in there too
<azonenberg_hk>
(22:19:28) azonenberg_hk: one of the TODOs during my refactoring is to enumerate all of the state per socket and try to collapse it into as few rams as i can
<azonenberg_hk>
(22:19:35) azonenberg_hk: possibly taking a few more clocks to load state
<azonenberg_hk>
(22:19:49) azonenberg_hk: whitequark: oh so the other fun bit is, in order to reduce latency
<azonenberg_hk>
(22:20:02) azonenberg_hk: you have to start the DMA streaming before you know if the checksum is good or not
<azonenberg_hk>
(22:20:10) azonenberg_hk: then be able to undo it if the checksum turns out bad
<azonenberg_hk>
(22:20:59) azonenberg_hk: I think the worst case main system RAM usage for the buffering will be one page per socket plus one in-progress page
<azonenberg_hk>
(22:21:07) azonenberg_hk: for RX side
<azonenberg_hk>
(22:21:13) azonenberg_hk: for TX, window size will set that
<whitequark>
ack
<azonenberg_hk>
That's in addition to the ~300 bits of state per socket i need elsewhere
<azonenberg_hk>
for things like the remote IPv6 and MAC addresses
<azonenberg_hk>
a bit for ipv4 vs ipv6 if i go dual-stack (unlikely but possible)
<azonenberg_hk>
the current rx/tx sequence numbers
<whitequark>
right, the remote addresses alone take 176 bits of state
<azonenberg_hk>
Yeah
<whitequark>
ipv6 addresses are so huge :o
<azonenberg_hk>
Rounding up to 384 bits total
<azonenberg_hk>
Three block rams gives us 128 sockets of state
<azonenberg_hk>
obviously the engine will be parameterizable for # sockets
<azonenberg_hk>
but i think i can probably get down to roughly 4 brams plus a few small lutrams
<azonenberg_hk>
plus a few pages of dynamically allocated ram per *open* socket for buffers
<azonenberg_hk>
This rewrite is going to be part of the f/w for my jtag thingie
<azonenberg_hk>
so its on the nearish-term TODO
<azonenberg_hk>
next 6 months i'd say
<azonenberg_hk>
i think, in fact, that after the NoC
<azonenberg_hk>
this is going to be the first part of antikernel i touch in my refactoring/cleanup
<azonenberg_hk>
well ok, NoC first then the LA core
<azonenberg_hk>
as i need that to debug the rest :p
<azonenberg_hk>
In other news
<azonenberg_hk>
The list of SLG4662x features not supported in our toolchain is quite short now :)
<azonenberg_hk>
wake/sleep (needs a bit of support from the counters)
<azonenberg_hk>
a lot of alternate modes of the counter IP
<azonenberg_hk>
DCMP/PWM
<azonenberg_hk>
DAC (needs DCMP since they share input muxes)
<azonenberg_hk>
ADC
<azonenberg_hk>
and slave SPI (massive pain in the butt routing-wise)
<azonenberg_hk>
At least, slave SPI routing to fabric
<azonenberg_hk>
SPI going to the ADC only wont be too hard
<azonenberg_hk>
i may do that soonish
<whitequark>
you have managed to not implement all three features critical for use in my real-world projects :D
<whitequark>
I could have used either
* whitequark
has just implemented echoing back the data in ICMP packets
<whitequark>
that required some clever wrangling of rust borrow checker...
<azonenberg_hk>
whitequark: lol
<azonenberg_hk>
Well the problem is
<azonenberg_hk>
those few features happen to be the ones that are the most nontrivial to implement
<azonenberg_hk>
Counters - lots of complex shared clocking
<azonenberg_hk>
DCMP - has some very messy shared muxes driving the input
<azonenberg_hk>
DAC - input is shared with DCMP so same mess
<azonenberg_hk>
ADC - kinda requires SPI to be useful
<azonenberg_hk>
SPI - depending on operating mode it clobbers a bunch of signals in half of the routing matrix
<azonenberg_hk>
Some of those signals are not routed anywhere else
<azonenberg_hk>
so using the SPI in parallel mode (vs direct to the ADC etc) basically means you can't use that block
<azonenberg_hk>
Other signals are available in the far matrix
<azonenberg_hk>
but when you're using the SPI, you have to access them via cross-connections
<azonenberg_hk>
as the primary source isnt available
<azonenberg_hk>
Making the PAR realize that some routing channels can change function depending on whether a given hard IP block is used is... nontrivial
<azonenberg_hk>
i.e. the same net number can be driven by either of two blocks
<azonenberg_hk>
it kinda-sorta makes sense given how routing-constrained the architecture is, but it's a corner case that really kills me
<azonenberg_hk>
i think a subset of the DCMP will be my TODO for tomorrow
<azonenberg_hk>
But it will be hard to verify without a devkit
<azonenberg_hk>
Once i get the DCMP working i'm going to try and implement support in yosys for inferring DCMPs from counter
<azonenberg_hk>
so you can do something like
<azonenberg_hk>
reg[7:0] count_reg;
<azonenberg_hk>
//increment count_reg under some conditions
<azonenberg_hk>
and have that comparator infer a DCMP
<azonenberg_hk>
This will require some changes to how i infer counters in yosys though
<azonenberg_hk>
so it'll take time
<azonenberg_hk>
starting out i'll create a parallel output from the COUNT8_ADV cell and require explicit connection to a GP_DCMP, then once i get that working i'll allow inferring a GP_DCMP from a digital comparison driven by a COUNT8_ADV's parallel output
<azonenberg_hk>
Doesn't help that the DCMP documentation is unclear and seems to contradict itself
<azonenberg_hk>
i may have to poke nazar about this when i get back
<azonenberg_hk>
in particular the outputs are labeled OUT+/OUT in some parts of the doc
<azonenberg_hk>
OUT+/OUT- in others
<azonenberg_hk>
and OUT/EQ in others
<azonenberg_hk>
so trying to figure out which does which might take some experimenting :p
<azonenberg_hk>
I think i can figure it out but the doc needs to be fixed lol
firebird_ has quit [Ping timeout: 260 seconds]
azonenberg_hk has quit [Ping timeout: 260 seconds]
azonenberg_hk has joined ##openfpga
<azonenberg_hk>
Aaand back again
<azonenberg_hk>
stupid hotel wifi making me re-auth to their captive portal every so often
<azonenberg_hk>
And doing so silently, dropping all open connections
<azonenberg_hk>
Why do captive portals even exist? 802.1x was invented for a reason
<azonenberg_hk>
But instead I see open or pre-shared-key wpa2 and then a portal on top of that
<whitequark>
good job deploying that
<whitequark>
(802.1x)
<whitequark>
it has to work on the shittiest android phone out there
<whitequark>
awful as they are... captive portals *work*
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<azonenberg_hk>
They are impossible to automatically auth to though
<whitequark>
yup
<azonenberg_hk>
and wpa_supplicant has been around for ages
<azonenberg_hk>
Also, they prevent me from launching a VPN etc until i run a browser to auth to the portal
<azonenberg_hk>
my current setup has a dedicated VM just for authing to the portal
<whitequark>
yup
<azonenberg_hk>
with my other VMs frozen
<azonenberg_hk>
then once i auth i wipe and revert that VM
<whitequark>
they *are* awful
<azonenberg_hk>
start the VPN
<azonenberg_hk>
then move on
<azonenberg_hk>
my point is, android is linux
<azonenberg_hk>
linux does 802.1x just fine
<whitequark>
pfffffhahahah
<azonenberg_hk>
doesnt matter what fancy java you paint over it
<azonenberg_hk>
it's a linux kernel and linux tcp/ip stack
<azonenberg_hk>
wpa_supplicant plus a fancy java front end? big deal
<whitequark>
it could use qnx inside, i couldn't care less; what matters to me as a user is whether it is harder to set up than to click one button in the browser
<azonenberg_hk>
click the network
<azonenberg_hk>
enter user/pass instead of preshared key
<whitequark>
(and even more so to all the people who never heard of and never should hear about 802.1x ever)
<azonenberg_hk>
log in
<whitequark>
well
<azonenberg_hk>
whats the big deal
<whitequark>
that works for hotel wifi with auth but not free wifi with interstitials
<whitequark>
which IME is the major source of captive portals in general
<azonenberg_hk>
Yes, i agree, and it's awful
<azonenberg_hk>
Maybe there should be an extension to .1x
<azonenberg_hk>
that provides a banner text in the auth packet
<whitequark>
it's kind of amazing, people add interstitials *even when they don't show ads
<azonenberg_hk>
and have the RFC require clients display it in some kind of window when you first connect
<whitequark>
for example in RU you are required by law to do that
<azonenberg_hk>
??
<whitequark>
[ ] I am older than 18 [ Submit ]
<azonenberg_hk>
lol wow
<whitequark>
or you'll get thrown in jail for running public wifi
<whitequark>
I imagine thats not the only place with moron MPs
<azonenberg_hk>
So running unencrypted wifi at home is illegal in .ru?
<whitequark>
I think that technically, yes
<whitequark>
but it's only enforced for businesses
<whitequark>
this is actually a very clever position because it means everyone runs open wifi illegally and you have a reason to fine or arrest them if necessary
<azonenberg_hk>
Lol well i'm pretty sure in .ru the gov can make up an excuse to fine/arrest anyone
<whitequark>
(doesnt just apply to wifi)
<azonenberg_hk>
if they dont like you
<azonenberg_hk>
they dont need wifi to do it
<whitequark>
thats how they do it.
<whitequark>
they dont need wifi specifically.
<whitequark>
but in general this is how they make up excuses
<whitequark>
it has to be legal at some opint. it's still a legalist society
<azonenberg_hk>
i was more making a reference to corrupt local officials
<whitequark>
corrupt local officials dont want to fine or arrest you, they maybe want to extort money
<whitequark>
which is more efficiently done in other ways
<azonenberg_hk>
> fine
<whitequark>
like withholding services
<azonenberg_hk>
i was more talking about, somebody who has it in for you
<azonenberg_hk>
can make up some obscure offense
<azonenberg_hk>
or corner of city code nobody ever looks at
<azonenberg_hk>
i'm sure this happens in US too
<whitequark>
sure. i am just saying that this is one of such corners.
<azonenberg_hk>
also are you saying it's illegal for a business to provide internet access to a minor in .ru?
<whitequark>
the US actually seems a bit more blatant, like "civil asset forfeiture"
<whitequark>
as far as I understand yes, it is illegal to provide unfiltered internet access
<azonenberg_hk>
> unfiltered
<whitequark>
theres a special corner for under-18s
<azonenberg_hk>
So its OK to have a portal-free internet that filters?
<whitequark>
which is even more censored than the rest of it
<whitequark>
I mean it's a whitelist
<azonenberg_hk>
... oh
<whitequark>
it's kind of pointless to
<azonenberg_hk>
whitelist
<azonenberg_hk>
wow
<whitequark>
theres an MP who is very concerned about "pedophiles" but in reality uses that as a pretext to advance draconian censorship measures
<azonenberg_hk>
i mean even my local library back when i was a little kid blacklisted
<whitequark>
the great russian firewall was built under that pretext
<azonenberg_hk>
they banned email, IM, everything
<azonenberg_hk>
but it was still a blacklist
<azonenberg_hk>
not a whitelist
<azonenberg_hk>
And i assumed internet censorship was done at the ISP level
<whitequark>
it is
<azonenberg_hk>
Rather than placing obligations on end user businesses
<whitequark>
businesses offload filtering on captive portals to ISPs because otherwise they can't comply
<whitequark>
it's a mixture of DPI and DNS blocking, so far
<whitequark>
used to be just DNS a year ago, they stepped up the game, I guess ISPs had to take time to set up DPI equipment
<azonenberg_hk>
Oh joy
<whitequark>
the worst mistake they made is blocking rutracker.org
<azonenberg_hk>
hotbed of new vpns coming up?
<whitequark>
the moment they did that, the amount of tor circuits originating from RU grew like five times overnight
<azonenberg_hk>
Lol
<whitequark>
before... no, they could have continued blocking political opposition
<whitequark>
idiots
<whitequark>
the blocking is really loose in general, just like the rest of such initiatives prove to be run by incompetents
<whitequark>
for example... pleer.com is blocked
<whitequark>
pleer.net isn't
<whitequark>
its the same website
<azonenberg_hk>
back at the library
<azonenberg_hk>
gamedev.net was blocked
<azonenberg_hk>
actually, no
<whitequark>
also someone quickly switched their DNS to 127.0.0.1 when they got word that their website will be blocked