**** BEGIN LOGGING AT Sun Dec 13 02:59:56 2020 Dec 13 03:52:59 so i've been reading about ssh, and apparently the server sends its public key and secret keys are developed using some time of diffe-hellman Dec 13 03:53:18 (both of those things happen w/ some type* of DH) Dec 13 03:53:58 and i don't understand why, if the client has a public key for the server, they don't just communicate a secret key for the symmetric algo using that PKI Dec 13 03:54:45 (real begginner here) Dec 13 03:54:52 beginner lol Dec 13 04:02:53 Me three! Dec 13 06:40:01 huh no i guess this spec is old now Dec 13 07:45:29 Thanks all for answering my gigabit port question. Unfortunately I had to run out and grab an RPi4, which does come with gigabit. Incidentally, I tested it and the RPi4 maxes out at about 612Mbps. The BBB was maxing at 94Mbps (expected since it's a 100Mbps port). It was for WAN network diagnostics, and speeds can easily get to 400Mbps+, so Dec 13 07:45:29 unfortunately couldn't use the BBB. Any idea when a BBB will come with Gbps? I like the BBB better than the RPi for several reasons, but wish it wasn't crippled by a 10/100 port :( Dec 13 08:36:38 hello Dec 13 09:52:05 Emmy87: the BBB itself isn't going to change, but like I said there is a beaglebone variant with gigabit ethernet (SanCloud's BeagleBone Enhanced) Dec 13 09:52:41 the new BeagleBone AI also has gigabit, but it's a totally different board (with a different SoC) that just has the same form-factor Dec 13 15:17:06 ayjay_t: 1. signature algorithms and their keys are distinct from public-key encryption algorithms and their keys, and keys used to identify something or someone are generally signature keys (in particular they are in ssh, tls, and pgp). in many cases there are signature-schemes and public-key encryption keys based on the same low-level mathematical primitive that in theory allow a keypair to be used ... Dec 13 15:17:12 ...for both purposes, this is generally regarded as a bad idea and could result in attacks from their interaction. better to just generate a separate keypair for encryption and sign that with the signing key Dec 13 15:20:54 ayjay_t: 2. using diffie-hellman with per-connection ephemeral keys results in "forward security", meaning the communications are protected against retrospective attacks: if an attacker records the traffic and then later manages to obtain the private keys, he still can't decrypt it Dec 13 15:24:09 it also gives complete security against passive attackers (for which anonymous diffie-hellman suffices): to eavesdrop on an ssh conversation they need to perform an active man-in-the-middle attack while having the private key or keys used available at that time (host, and client if key-based authentication is used) Dec 13 15:30:49 TLS supports similar schemes, using DH or ECDH to establish the session key with the server's (RSA, DSA, or ECDSA) static key used only to authenticate itself to the client Dec 13 15:32:28 (and TLS 1.3 removes the older schemes that lack forward security) Dec 13 21:31:55 I guess running mcspi without fifo is not really practical as unclear when the response is received without irqs Dec 13 21:32:35 uhh, using fifo or not doesn't really change much apart from performance Dec 13 21:32:49 you don't need irqs either way Dec 13 21:33:49 by which I mean you don't need the actual irq signal from mcspi... the irq status register is still the best way to check for completion probably Dec 13 21:33:53 I wrote a simple program that does not use fifo, but I don't see any way in the spec to tell when the response is received Dec 13 21:35:33 what I mean is, without interrupts I write to MCSPI_TX0 and read from MCSPI_RX0 for the response, but no idea how long I need to wait for it Dec 13 21:39:18 bit 2 (RX0_FULL) of MCSPI_IRQSTATUS (or alternatively bit 0 (RXS) of MCSPI_CH0STAT) Dec 13 21:42:17 thanks, yes I need to enable IRQ, you're right I was thinking that fifo+irq was something more complex, but makes sense Dec 13 21:42:44 you don't need to enable it Dec 13 21:43:34 I need to enable in MCSPI_IRQENABLE I think Dec 13 21:43:48 enabling it is needed if you want the actual interrupt line from mcspi to cortex-a8/pruss to be asserted when the corresponding irqstatus bit is set Dec 13 21:44:54 interrupt_line = ((irqstatus & irqenable) != 0) Dec 13 21:45:55 so if you're polling irqstatus (e.g. because you're too lazy to set up the intc, or if you want to use mcspi 1 which has no interrupt line to pruss) then you don't need irqenable Dec 13 21:46:33 oh Dec 13 21:50:51 thank you Matt, that's great makes it easier than I thought Dec 13 22:12:39 mm302: note that for some other peripherals the irqstatus register bits are already ANDed with irqenable and a separate irqstatus_raw register exists to see the actual status bits without this masking. Dec 13 22:12:58 mm302: summary of the two common irq combiners you'll find on TI SoCs: https://pastebin.com/wNmmu7QU Dec 13 22:42:10 I was playing the guitar taking avantage it's not too late before the neighbours complain. Thanks again, indeed irq can mean multiple things in bb Dec 13 22:43:14 irq means the same thing on the am335x as it does everywhere else Dec 13 22:48:09 let's just say then that bb insider knowledge is needed Dec 13 22:48:44 if by "insider knowledge" you mean the documentation, then yes that's usually required for every complex chip Dec 13 22:50:24 how interrupt requests are managed isn't really significantly different on the BBB than on any other SoC or big microcontroller I think Dec 13 22:51:20 ok, what I meant is a few things on mcspi even with TRM are not obvious Dec 13 22:51:50 but I'm getting there Dec 13 22:52:02 that's possible, some peripherals have clearer documentation than others Dec 13 22:52:25 I do recall some things about mcspi weren't super clear to me either Dec 13 22:52:45 but it's still pretty straightforward to use Dec 13 22:55:06 I wouldn't call it straightforward, but after getting a better understading it makes more sense Dec 13 22:55:24 just be glad you're not trying to use the i2c controller :P Dec 13 22:57:01 I was a bit slow on this project because I've spent not a lot of time on it, but I'm looking forward to finish this off over the christmas holidays Dec 13 22:58:02 just to check I'm not confusing people with each other.. you were trying to use some adc with spi interface from pru right? Dec 13 22:58:15 yes, you're right Dec 13 22:58:43 remind me what the motivation was to use mcspi instead of just using pru to bit-bang the protocol? Dec 13 22:58:53 I wrote a digital capture app for the other pru so I can dianose spi better Dec 13 22:59:04 yes Dec 13 23:00:07 "yes" ? Dec 13 23:01:21 the motivation is: seems more in the right spirit to use the hardware perhiperals to also learn how things work Dec 13 23:01:52 ok sure, those are decent reasons, especially the latter Dec 13 23:03:50 this is hobby/DIY for me, so I don't have the pressure of just getting things done one an easy way that I would get it if was work Dec 13 23:05:28 well, performance might be another reason to bit-bang (which is not a statement you'll hear often outside of using PRU :P ) Dec 13 23:08:01 I was wondering if it's possible to build an oscilloscope like this (even using more powerful hardware), however it seems will never reach speeds like 1Gsps, so must use a very different approach Dec 13 23:10:34 I mean, it *is* possible to build an oscilloscope like this, but not one that does 1Gsps no :P Dec 13 23:12:11 just googling now I found this 8 bit parallel outputs 100Msps ADC apprently used in a Rigol 1052E oscilloscope https://www.analog.com/media/en/technical-documentation/data-sheets/AD9288.pdf Dec 13 23:18:16 night Dec 14 02:13:57 W/ making a wrapper in python from c++ for the BBB for PWM enable, duty_cycle, and/or frequency, would I need to take into account the am335x-bone-common-univ.dtsi? Dec 14 02:15:28 Also...would, while making a lib. for the BBB pwm peripherals, I need to make my own .dtsi file just for the PWM sections? Dec 14 02:53:46 Hi. FIrst time trying to bring up a beagle. I flashed the latest image to a microsd card and connected it by usb, but I don't see the expected behavior. Dec 14 02:54:16 I am free. Dec 14 02:54:24 What are you expecting to see? Dec 14 02:55:31 I was expecting an ethernet over usb device to show up in ifconfig (Linux...) with an ip of 192.168.6.1, and to be able to hit the board in a browser on *.2. Dec 14 02:56:02 There is no ethernet device. It seems to show up as a usb drive, and I can open it and see the start documentation. Dec 14 02:56:28 Oh. Hmm. Did you try in your browser, beaglebone.local? Dec 14 02:56:41 I think that brings up the Cloud9 IDE. Dec 14 02:56:46 No, I just tried the IPs in the getting started docs. Dec 14 02:56:50 Okay. Dec 14 02:57:06 I'll check beaglebone.local in a sec. Dec 14 02:57:14 So, you have a Ubuntu or Debian distro? Dec 14 02:57:41 And this desktop/laptop cannot see your BBB via ifconfig. Did you try ip addr? Dec 14 02:57:48 Yeah, it's kubuntu. Latest unless they've released recently. Dec 14 02:58:10 Okay. Try, ip addr to see if eth0 shows up. Dec 14 02:58:15 I tried just loading 192.168.6.2, but the browser hangs as you'd expect if it gets no reply. Dec 14 02:59:11 Let me check some docs. for Kubuntu. I am not too familiar w/ that distro. But in the meantime, try beaglebone.local and ip addr on the command line. Dec 14 02:59:33 OK. Sure, I can see eth0 with either that or with ifconfig, but that's my wired connection to my ethernet hub. **** ENDING LOGGING AT Mon Dec 14 03:00:00 2020