**** BEGIN LOGGING AT Thu Jan 14 02:59:57 2021 Jan 14 03:15:12 Did it! Jan 14 03:15:19 Runny a website from the BBB! Jan 14 03:15:21 Nice. Jan 14 03:15:27 I never figured it out until today. Jan 14 03:15:40 virtual hosts! Jan 14 03:16:22 That is awesome. Jan 14 03:16:39 bind9, apache2, and some other hubbub. Done! Jan 14 03:17:34 I still cannot get it to run on my LCD screen. But in time... Jan 14 04:52:56 what are people up to today Jan 14 12:23:33 * jkridner[m] hopes today starts slow. Jan 14 12:25:39 That means...I should not chat. Jan 14 12:26:05 Have fun! Jan 14 12:33:15 Just did an update on the debian image on a bbb this morning and it appears to have broken something regarding sshd startup. /run/sshd isn't created causing sshd start to fail. At least I don't think there is anything I did to cause this. Jan 14 12:33:46 Anyone else ran into this? Jan 14 12:34:52 Did you restart the sshd service? Jan 14 12:35:30 daemon, service, whatever...I have restarted my sshd .service file before. Jan 14 12:35:46 Just throwing that out there... Jan 14 12:37:09 Sometimes when things, the files within those dirs. get changed, restarting the daemon may prove valuable. Jan 14 12:37:43 Yes. Can get it running that way (after creating the /run/sshd dir (systemd-tmpfiles --create)), but it will not start automatically on reboot Jan 14 12:41:05 Oh. Let me check if sshd should be in /run/ Jan 14 12:41:36 Oh. Jan 14 12:42:05 Yep but I am sure there are more ideas to the story of your file input, right? Jan 14 12:42:28 I mean, what are you doing? Jan 14 12:43:11 systemctl restart sshd.service && systemctl daemon-reload? Jan 14 12:43:17 Oh and... Jan 14 12:43:29 systemctl enable sshd.service? Jan 14 12:44:04 The enable should make a symlink. Jan 14 12:44:15 That symlink should start it on boot. Jan 14 12:45:53 It tries to start, but it appears to fail because the temp dir /run/sshd doesn't exist. I can restart it after manually creating the temp dir. Jan 14 12:47:09 Okay. So, send over some of the red lines in the journalctl -xe and systemctl status sshd.service in a pastebin.com paste. Jan 14 12:47:34 All of systemctl status sshd.service would be nice if possible. Jan 14 12:51:18 are you making a ssh server? Jan 14 12:57:28 set_: No. I have about 20 devices at remote locations which I use SSH to connect to. I was just about to go and deploy 3 new ones today and decided to run an update...shouldn't have done that. Jan 14 12:58:05 Oh. Jan 14 12:58:07 Okay. Jan 14 12:59:29 Well, maybe someone else can help you. I am not in charge of handing out updates/upgrades but looking into your journalctl -xe output and status of sshd.service may help you. Jan 14 12:59:53 Yes. That's how I have gotten as far as I have with debugging the problem :) Jan 14 13:00:01 Oh. Okay. Jan 14 13:00:36 So, have you had to use ln -s on specific dirs? If so, maybe unlink them? Jan 14 13:01:05 Thanks for the input though. Impossible to know how much people know when they ask such questions like this one. Jan 14 13:01:15 Okay. No issue. Jan 14 13:01:37 Up, up, and Otay! Jan 14 13:01:41 I haven't done anything other than apt-get update / upgrade, and it appears to have broken :) Jan 14 13:02:37 Maybe something changed w/ the new Debian 10.7 distro upgrade? Jan 14 13:03:03 just some hints... Jan 14 13:03:49 Sometimes Debian changes from release to release on what is collective. Anyway, good luck sir. I hope you figure it out. I am out for now. Jan 14 13:04:23 set_: Thank you. See you later :) Jan 14 18:09:42 hmmm, interesting. if you try charging from a usb port that has a fusb302 on it, it may see the voltage drop as a disconnection and throw out interrupts that it was disconnected. Jan 14 20:09:46 zmatt: sorry i never made it back last night but i appreciate the ipv6 info and will definately spend some time into looking at what you were explaining Jan 14 20:09:53 thnx Jan 14 20:29:54 :) Jan 14 20:30:46 outrageous: "/run/sshd isn't created causing sshd start to fail" ... that sounds rather implausible and bizarre Jan 14 20:32:17 you sure you didn't swap cause and effect? systemd will remove that dir when the service stops Jan 14 20:32:31 (and create it when it starts) Jan 14 20:34:57 i always knew the device's mac was used in ipv6 just didnt know how till i seen what you posted but got busy and never go bak but i have since grabbed a couple of decent videos/tuts and will watch them between compile cycles later today Jan 14 20:35:17 buzzmarshall: like I mentioned it depends on whether privacy extensions are enabled Jan 14 20:36:03 or if DHCPv6 is used that it *may* assign an explicit address just like DHCP does in IPv4 (alternatively it might just provide auxiliary info like DNS and NTP) Jan 14 20:36:22 the other thing i wanted to pick your noggin about was i seen the other day you had mentioned something to someone else about the usb on the bbb not using dma which i had noticed while messing with some kernel stuff Jan 14 20:36:37 was curious as to if you know why its been disable? Jan 14 20:36:38 but I personally prefer MAC-derived IPv6 since it's stable and predictable Jan 14 20:36:58 I don't know exactly, I've seen mention of stability issues Jan 14 20:37:24 I very rarely use USB on the BBB so I haven't really dug into it Jan 14 20:37:50 k... Jan 14 20:38:12 I do recall seeing some other questionable thing last time I did look at the driver briefly... some kind of performance-hurting workaround for an am335x 1.0 erratum that is fixed in current devices Jan 14 20:38:19 mostly ive just kinda been pushing the bbb to see what i can expect and had kinda noticed the usb wasn't very good Jan 14 20:39:03 otherwise the boards actually pretty good for something so small on the sram end Jan 14 20:39:33 usb isn't very good... the musb controller is meant mostly as device/OTG and is not great when used in host role Jan 14 20:39:47 "small on the sram end" ? Jan 14 20:39:56 ive been looking at the mainstream kernel and rcn or i quess i should say ti's version just to see where the difs are Jan 14 20:40:04 like, what little internal sram it has is mostly unused Jan 14 20:40:16 512M Jan 14 20:40:23 that's ddr3 memory, not sram Jan 14 20:40:42 sram is static ram Jan 14 20:40:46 most of the other arms ive played with have at least 1g or more these days Jan 14 20:40:52 sorry brainfart Jan 14 20:41:40 internal was on my brain as im looking at the internal stuff while i mess with u-boots spl portion that i am messing with Jan 14 20:41:56 there are beaglebone variants with 1GB of ram... not sure what you need that much ram for though Jan 14 20:42:21 i bought the ai for that Jan 14 20:42:23 like, I don't think our beaglebones generally use even half of the ram they have... maybe our development beaglebone during big compile-jobs ? Jan 14 20:43:01 ya thats were i ran into the issue was with local compiling of some stuff rather then cross-compiling Jan 14 20:43:34 even tho its longer i tend to develop locally if i can till i get what i want and then will move over to crosscompiling Jan 14 20:43:35 then again we use distcc to delegate the actual compilation to an x86 build server (which gets you most of the performance of cross-compilation without any of the headaches) Jan 14 20:43:58 so only preprocessing and linking is done locally Jan 14 20:44:29 for what you guys are supporting i can see thats the best way Jan 14 20:45:37 plus for the last couple of years ive spent most of my arm time on amlogic and rockchips where theres much more Jan 14 20:45:54 of course you can also just native-compile on a beefier arm board Jan 14 20:46:23 raw cpu power is not the beaglebone's strength Jan 14 20:46:40 just sick of working on devices where theres to much vendor code hidden and i am no longer a big believer in doing the grunt work for the scumbag dealers Jan 14 20:47:00 true but for what i am looking to do i think its a good choice Jan 14 20:47:57 graphix stack and locked bootloaders are a big part of the soc's i was playing with but for what i want i don't expect out of the bbb Jan 14 20:48:44 yeah TI is pretty good at getting their stuff into mainline... the gpu has a hideous out-of-tree kernel driver but that's still open source, only its userspace libs are closed source (though with permissive redistribution license) Jan 14 20:48:58 and most people don't use the gpu anyway Jan 14 20:49:16 (the libs aren't shipped on the default image and in fact are a pain in the ass to get working) Jan 14 20:49:41 ya i had seen you talking a bit about the sgx stuff to someone the other day Jan 14 20:49:57 ive been grabbing stuff here and there but not really looked at it much yet Jan 14 20:50:11 and i agree TI's pretty open with what they got Jan 14 20:50:44 the only thing ive not come across but can fish out if i need is the rbl burried in the chip Jan 14 20:51:02 no need tho as theres no big secrets to what it contains Jan 14 20:51:58 aml and rk won't help with that and personally im done feeding the dealers by helping the projects they pilver their support from Jan 14 20:51:59 haha Jan 14 20:52:01 yeah nothing particularly relevant there... like, all the trustzone stuff is limited to "High Security" devices which are not available to us plebs Jan 14 20:52:26 (determined by eFUSE programming in the factory) Jan 14 20:52:56 can't say for TI's implemenation but the aml and rk's the trusted platforms not all that difficult to get around if you know how Jan 14 20:53:53 on "General Purpose" devices the secure-world bootloader will basically just irreversibly lock down secure world, leaving only a tiny Secure Monitor that can be invoked by privileged code to write to certain special cpu registers that are only accept secure privileged writes Jan 14 20:54:46 depends on what you mean by "get around" ... people often seem confused about what things like trustzone and a TPM are supposed to accomplish Jan 14 20:55:02 true Jan 14 20:55:09 they're generally passive and do nothing unless you opt to use them Jan 14 20:55:34 honestly I think it's kinda annoying that TI doesn't allow trustzone to be freely used on their GP devices Jan 14 20:57:23 ive not really looked much at that part of TI's setup as i really see no need as they don't appear to be hiding anything from the user Jan 14 20:58:24 most of the android box market on the other hand are trying to maintain locking the device to android so it makes it difficult for the hobbiest to play with linux on the device if they want to Jan 14 20:58:38 ti's not impeding that in anyway that i can see Jan 14 20:58:54 so ive no real need to go snooping Jan 14 20:58:56 lol Jan 14 20:58:57 well you can't read Secure ROM on the AM335x, but I have dumped it on the DM814x that is so closely related to it that the AM335x 1.0 bootrom actually accidently identified itself as DM814x via usb... Jan 14 21:00:01 it basically just does minimal secure-world init, checks the device type (test (no device type programmed yet, factory testing), EMU (dev device for HS), HS, or GP) Jan 14 21:00:16 well alot of soc vendors say you can't read secure rom but ive only seen a few that can truly make that claim Jan 14 21:00:43 altering or writing maybe not posible but reading it out in most cases can be done with the right tools Jan 14 21:01:24 and like I said, on GP it just locks down secure world after installing a tiny secure monitor that just handles a few calls to allow public world to write to some secure-only registers) Jan 14 21:01:49 altering/writing is not an option, it's mask rom baked into the SoC Jan 14 21:01:59 yes Jan 14 21:02:39 preventing reading is not hard and there doesn't seem any way around it on the AM335x ... on the DM814x they protected it at its primary address range but forgot it had an alias elsewhere in the address space Jan 14 21:04:01 on HS devices there's definitely a lot more interesting going on, bootrom actually has some kind of kernel it runs in secure privileged mode on HS devices, but none of that is relevant on GP devices Jan 14 21:04:31 i quess what im seein with ti is that things like the stack setup and in particular external ram timing which is usually hidden by the vendor in ti's case really has no relevance where as on the other soc's it usually has to do with preventing other software then what the vendor wants run to work Jan 14 21:04:50 external ram is setup by uboot, not by rbl Jan 14 21:05:13 ive not checked the ti but can definately say the aml/rk's implemtation can be glitched to bounce over the checks Jan 14 21:05:57 I mean there's nothing to "bounce over", it's a hardware check that prevents any public-world access to the rom's address range Jan 14 21:06:00 not on alot of the other soc's thats partly why when the maker alters the brand/type of chips used for memory the boxes start acting up Jan 14 21:06:28 soem of the smarter ones will put a learning routine in to unit but some don't Jan 14 21:06:48 yeah hardware ddr leveling is broken in the AM335x iirc Jan 14 21:06:59 but it doesn't matter much for DDR3-800 anyway Jan 14 21:07:07 you can get away with pretty wrong timings Jan 14 21:09:09 all code is still being executed by hardware driven by clocks and specific vcc/current levels so if one understands the cores instruction set and how its implemented in hardware Jan 14 21:09:19 usually when bootroms are compromised it's because they load data that you can manipulate Jan 14 21:09:28 checks and flow can be interrupted and alterd... thats kinda the nature of hacking Jan 14 21:10:32 no I'm not talking about instructions, I'm talking about an interconnect firewall, like an MMU-check Jan 14 21:11:02 its just stuff thats not really acceptable to discuss any more as the days of just playing to learn now carry certain consequnces so not much gets discussed any more Jan 14 21:11:03 you simply get a bus error Jan 14 21:11:54 so they say and secure smart card makers have said that for eons yet its been done for years Jan 14 21:12:35 these bigger socs may be much more complicated but in the end they still work on similar principles when it comes the code to hardware translation Jan 14 21:13:12 like, maybe you can inject a fault using an electron beam if you know exactly where to aim, but it doesn't seem very feasible Jan 14 21:13:19 anyways i will just leave that subject alone as its best not to go there Jan 14 21:13:45 it also doesn't seem very worthwhile Jan 14 21:14:44 like, perhaps dumping secrom may be of interest if you want to attack HS devices, but like I said it doesn't really do anything of interest on GP devices Jan 14 21:14:52 your right as its only worthwile to someone trying to abuse it for money which is what the maker wants Jan 14 21:15:24 but for the hobbiest just trying to learn where time and commitment arent the concern it can fun and feasible Jan 14 21:15:33 the actual bootloading (and most of the chip init) done by bootrom is done by public rom, which you can dump if you want to Jan 14 21:15:41 its just not something that in NA can be openly talked about anymore Jan 14 21:15:45 nothing of security relevance though Jan 14 21:15:55 why not? pretty sure people talk about it all the time Jan 14 21:16:28 being a hardware nut i just find all of it fascinating and in a lot of cases the only real reason i bother with some of this stuff Jan 14 21:16:54 looking at surface fab and understandin the fab process i find extremely interesting Jan 14 21:17:09 sure, curiosity is in the end also why I dumped bootrom on the DM814x and partially reverse engineered it :) Jan 14 21:17:30 over the years ive lost count of how much silicon ive decapped just to look Jan 14 21:17:49 bought some microscopes and even had access to sem for awhile Jan 14 21:18:59 (though most of bootrom is either boring or irrelevant... I did notice a bug in the secure monitor of DM814x HS devices which allows privileged code to trigger a stack overflow in secure monitor mode, but that won't accomplish anything other than a system reset) Jan 14 21:20:24 your probably right about the content of the bootrom but to someone like me being to cause that type of a reset would be of interest Jan 14 21:20:26 lol Jan 14 21:20:45 its neat that you've found that Jan 14 21:20:48 and on AM335x devices you can actually modify the secure world MMU tables... though again this doesn't seem to result in any control over secure world... you can change the cache policy if you want but any other changes will result in accesses that violate the security policy baked into the hardware firewall and result in a system reset Jan 14 21:22:21 thats cool Jan 14 21:22:35 (normally the necessary mmu entries are locked into the TBLs but one of the secure monitor calls implemented allows unlocking those) Jan 14 21:24:47 Does anyone know how I could change the configuration for libcomposite so I can see a different folder when I use my Beaglebone AI as a Mass Storage Device. My kernel version is 4.14 Jan 14 21:25:14 i want to learn alot more about the sitara's as i go and maybe someday after i kill a couple via some other unmeant stupidity i will decap a dead one and grab some hig rez pics Jan 14 21:25:26 pwhudson11: you mean which disk image is exposed via usb mass storage? Jan 14 21:25:41 if there's config for that it's probably in /etc/default/ Jan 14 21:25:51 anyways... biab... gotta run out for supper Jan 14 21:26:14 zmatt: thnx for your time its always nice yapping at ya Jan 14 21:27:05 Yes, But rather than an image file I'd like to expose a folder with read/write Jan 14 21:27:13 pwhudson11: that's not possible Jan 14 21:27:22 usb mass storage exports a raw block device Jan 14 21:27:58 so you cannot use usb mass storage to export a mounted filesystem or any part thereof Jan 14 21:28:26 Okay yeah that makes sense Jan 14 21:28:56 you could use a fileshare via usb-networking Jan 14 21:29:07 (though using ethernet would have better performance) Jan 14 21:30:17 in case it's of interest: the image file exposed is configured via the /var/local/bb_usb_mass_storage.img symlink Jan 14 21:34:43 Does the BBAI have any default domain name over Ethernet or Ethernet over USB? Jan 14 21:35:00 I kno how to get the IP, but I'm trying to make this better down the road Jan 14 21:36:05 well usually a home router will have a local dns that provides hostnames for devices on the lan. alternatively you can use mDNS/avahi to connect to "beaglebone.local", provided you're on a linux system, mac, or *maybe* windows 10 (mixed reports) Jan 14 21:37:01 via usb the former isn't applicable of course, but the latter is Jan 14 21:37:45 speaking of BBAI, has the thermal changes been implemented in the official stuff yet? Jan 15 01:37:17 so I am trying to wire up my male usb to a board. I cut the calbe Jan 15 01:37:36 and I have 4 wires red,green,white and black Jan 15 01:37:47 how can I find out which is Tx and Rx Jan 15 01:37:52 gnd etc.... Jan 15 02:31:31 mattb000ne: is there a name on your USB? Look up the specs. or test it. Send power to it by ruining it or by being successful. Jan 15 02:32:28 Send photo! Jan 15 02:44:49 Also...there is a spec. that must be "followed." Jan 15 02:45:35 Hopefully, the mfg. followed the spec. Jan 15 02:45:50 If not, test it! **** ENDING LOGGING AT Fri Jan 15 02:59:57 2021