**** BEGIN LOGGING AT Thu Jun 04 03:06:25 2020 Jun 04 12:57:16 m Jun 04 17:19:18 m 2 u Jun 04 18:43:50 Hi Jun 04 18:43:58 I have a beaglebone green Jun 04 18:44:13 why there's no wifi device with ip link? Jun 04 18:44:42 driver not loaded? Jun 04 18:44:50 missing firmware? Jun 04 18:44:53 where can I find some info about which driver do load? Jun 04 18:45:35 I see, I was used to the beaglebone green debian images with the drivers already shippied. Jun 04 18:45:46 what are you running now? Jun 04 18:45:54 the latest debian 10 iot Jun 04 18:48:23 well well well, embarassing as it is Jun 04 18:48:26 I have the green base Jun 04 18:48:34 without wifi? Jun 04 18:48:45 which is not shipped with the wifi. For some reason I thought it was included XD Jun 04 18:49:01 Thank you for answering anyways :) Jun 04 18:50:16 wifi is just too much trouble Jun 04 19:33:45 Hey Zmatt, I managed to get my internet via USB working great last night with your insight Jun 04 19:33:58 Once again, thank you for the help Jun 04 19:54:21 Anyone know of a way I could access a pocketbeagle via SSH connected to a Host from another PC on the Host's network? Jun 04 19:54:58 The most round-about solution I have come up with is installing a minimal VPN on the pocketbeagle which as internet connectivity and linking it to the desired PC Jun 04 19:55:34 But I feel like there should be some simple way to use the host to create a direct connection between the two devices (PC and PocketBeagle) Jun 04 19:55:47 setting routes properly and enabling routing on the host with the beagle. or using the host with the beagle as a jumphost Jun 04 19:57:31 Oh interesting! I hadn't known about jump hosts. Thanks for the pointer Jun 04 20:25:46 yeah, recent ssh makes that easy: ssh -J jumphost beaglebone Jun 04 20:26:50 you can also bridge the usb interface to ethernet (though not to wifi), but be careful not to do this as long as there's a dhcp server running on the pocketbeagle Jun 04 20:27:16 or setup port forwarding Jun 04 20:27:21 lots of options Jun 04 20:27:30 why not wifi? Jun 04 20:27:43 wifi doesn't support bridging, never has Jun 04 20:28:02 (until a very recent revision that nobody has implemented yet) Jun 04 20:30:17 see https://forums.virtualbox.org/viewtopic.php?f=6&t=84831#p473039 includes some more details in the small-print part Jun 04 20:31:02 I mean client-side bridging here, it obviously supports bridging on the AP side Jun 04 20:37:05 what a mess Jun 04 20:37:23 unsurprisingly with wifi Jun 04 20:38:18 I wonder how long it'll take for 802.11ak to actually get implemented Jun 04 20:38:33 does it need hardware changes? Jun 04 20:38:43 I don't think so? Jun 04 20:39:37 but it probably needs firmware support Jun 04 20:39:49 (similar to how not all clients support mesh networking) Jun 04 21:09:20 mru: the last pdf I link in that post gives a good exposition of the headaches Jun 04 21:09:34 I wonder which solution they ultimately went with Jun 04 21:12:37 it appears "set of point-to-point links" Jun 04 21:15:40 hmm Jun 04 21:19:26 it appears that for sending a multicast to a subset of bridge-clients the AP can deliver the frame to each bridge-client individually and/or create a "synthetic receiver address" for a set of clients to reduce traffic Jun 04 21:34:08 I once had a wifi AP that died if there was too much multicast traffic on the wired network Jun 04 21:35:20 how graceful Jun 04 21:35:39 I was working on some iptv stuff at the time, so it was quite annoying Jun 04 21:37:38 I recently noticed that when a wifi client sends a dhcp request, the reflected broadcast was transmitted by the AP _after_ the response from the dhcp server :D Jun 04 21:39:06 which is actually expected behaviour, especially when there are other clients on the network with powersave enabled, but it's not very intuitive Jun 04 21:39:55 ap/wired bridge and dhcp server on some device, or what? Jun 04 21:40:02 no Jun 04 21:40:30 who sent what where when then? Jun 04 21:41:24 the ap forwarded the wifi client's dhcp request (broadcast) to the wired network, received the (unicast) reply and transmitted it to the wifi client before the AP transmitted the original dhcp request (broadcast) on the wifi network Jun 04 21:41:50 I see Jun 04 21:43:05 nothing wrong with that sequence Jun 04 21:43:14 no expected ordering is violated Jun 04 21:43:50 well no *required* ordering is violated... I think one would be forgiven for not expecting this ordering :P Jun 04 21:44:18 even in a pure wired network, you might see responses to a broadcast before all hosts have received it Jun 04 21:44:25 unless you happen to know that wifi access points will delay broadcasts/multicasts until specific time slots Jun 04 21:44:48 yes but on almost any wired network you will still see the original broadcast before you see any reply to it Jun 04 21:44:52 I learned about that back when I had that unstable AP Jun 04 21:45:24 probably, but there's no promise Jun 04 21:45:25 it's weird when going from A to B to C is faster than going from A to C Jun 04 21:45:55 even though there are a bunch of cases where it's possible Jun 04 21:46:29 it's generally a bad idea to try to impose a global order on distributed systems Jun 04 21:47:12 just ask einstein Jun 04 21:47:18 if you mean a total ordering then sure... normally you'd at least expect causal ordering though Jun 04 21:47:31 einstein would agree with that Jun 04 21:47:44 have you ever looked at the dec alpha memory model? Jun 04 21:48:13 I've read some things about it... Jun 04 21:48:36 in some cases, you can have seemingly anti-causal behaviour Jun 04 21:48:47 such joy :P Jun 04 21:48:51 for real, not just permitted by some spec Jun 04 21:49:40 those machines were very fast back in the day **** ENDING LOGGING AT Fri Jun 05 02:59:57 2020