starblue1 has quit [Ping timeout: 246 seconds]
starblue1 has joined #rust-embedded
<re_irc> <> dirbaio: classic `mem::forget`
fabic_ has joined #rust-embedded
fabic_ has quit [Quit: Leaving]
fabic has joined #rust-embedded
PyroPeter has quit [Ping timeout: 264 seconds]
PyroPeter has joined #rust-embedded
fabic_ has joined #rust-embedded
fabic has quit [*.net *.split]
flatwhatson has quit [*.net *.split]
inara has quit [*.net *.split]
flatwhatson has joined #rust-embedded
inara has joined #rust-embedded
Darius has quit [Ping timeout: 250 seconds]
Darius has joined #rust-embedded
inara has quit [Ping timeout: 252 seconds]
inara has joined #rust-embedded
troth1 has joined #rust-embedded
troth has quit [Ping timeout: 252 seconds]
vancz has quit [Ping timeout: 252 seconds]
vancz has joined #rust-embedded
edm has quit [Ping timeout: 252 seconds]
edm_ has joined #rust-embedded
Amanieu_ has joined #rust-embedded
fooker has quit [Ping timeout: 252 seconds]
Amanieu has quit [Ping timeout: 252 seconds]
fooker has joined #rust-embedded
unmanbearpig has joined #rust-embedded
unmanbearpig has quit [Changing host]
unmanbearpig has joined #rust-embedded
unmanbearpig has quit [Client Quit]
unmanbearpig has joined #rust-embedded
unmanbearpig has quit [Changing host]
unmanbearpig has joined #rust-embedded
unmanbearpig has quit [Client Quit]
unmanbearpig has joined #rust-embedded
vancz has quit [Ping timeout: 252 seconds]
vancz has joined #rust-embedded
<re_irc> <> adamgreig: ? it is not stm32 specific?
<re_irc> <> it's not stm32-specific but the major user is the stm32 pacs
<re_irc> <> it's also used in the rp2040 (raspberry pi pico) pac, and maybe others
<re_irc> <> I think also esp32 and lpc55? And some others, maybe imxrt
fabic_ has quit [Ping timeout: 260 seconds]
<Lumpio-> Even though some of the tools say "stm32", SVD files and PAC crates are pretty much platform agnostic
<Lumpio-> You might not be able to find prewritten SVD files for non-ARM devices though. But you could feasibly convert from some other format to it, for instance.
<Lumpio-> I should say the PAC crate generators are platform agnostic, the crates themselves are just about as platform specific as it gets
<re_irc> <> you definitely can find prewritten SVDs for a couple of riscv targets now
<re_irc> <> i haven't used svdtools against them but I don't expect any major issues
<re_irc> <> šŸ‘ļø
xnor has quit [Ping timeout: 260 seconds]
fabic_ has joined #rust-embedded
fabic_ has quit [Ping timeout: 252 seconds]
xnor has joined #rust-embedded
<re_irc> <> I believe we use svdtools to patch fu740 and gd32vf103 SVDs
fabic_ has joined #rust-embedded
fabic_ has quit [Ping timeout: 252 seconds]
xnor has quit [Changing host]
xnor has joined #rust-embedded
emerent has quit [Ping timeout: 265 seconds]
emerent has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 276 seconds]
loki_val has joined #rust-embedded
<re_irc> <> are hosts supposed to update the ARP cache when receiving non-ARP packets?
<re_irc> <> ie when receiving any random packet with src_mac=X, src_ip=Y, set arp_cache[X]=Y
<re_irc> <> smoltcp does, but lwip doesn't, uIP has code for it commented out, Linux seems not to
<re_irc> <> I have one device in teh field that fails due to this (arguably because broken router behavior, but they won't fix it because PCs work fine...)
<re_irc> <> Ugh
<re_irc> <> I don't think anything is "supposed" to but are allowed to?
<re_irc> <> How's it making it break?
<re_irc> <> router has mac xx.03, ip
<re_irc> <> A miracle any network devices ever work tbh
<re_irc> <> but every 1 min it sends some random UDP broadcast with src_mac xx.02, src_ip, some "mikrotik discovery" bullshit
<re_irc> <> I feel like most switches will add macs to switching tables for any traffic
<re_irc> <> which poisons the cache, and my device starts sending everything to xx.02
<re_irc> <> But it's just macs per port so wouldn't poison the list
<re_irc> <> which of course goes nowhere
<re_irc> <> Urgh wow wtf
<re_irc> <> and the arp cache lifetime is set to 1min, so effectively it's most of the time poisoned šŸ’€
<re_irc> <> Why send it from the wrong Mac and the right ip, that's awful
<re_irc> <> yeah
<re_irc> <> it's the same mac except :02 instead of :03, so I guess it uses the mac from a wrong interface or something
<re_irc> <> it's so broken
<re_irc> <> but windows, macos, android, linux etc still work perfectly
<re_irc> <> all I can think of is "don't populate the cache from random packets, just ARP replies"
<re_irc> <> but holy shit are routers so broken
<re_irc> <> maybe this device has some logical interfaces configured
<re_irc> <> yeah but it should use mac :02 on one interface, and mac :03 on the other... not mix them
<re_irc> <> well yeas unless those logical interfaces are bound to one phisical one
<re_irc> <> like bond
<re_irc> <> hmm I don't think that's the case.. packets going to :02 just get blackholed...
<re_irc> <> Pretty sure ARP cache isn't *supposed* to be updated other than from explicit ARP requests, to avoid deliberate poisoning. Linux has a setting to ignore courteous ARP response packets to help harden against ARP poisoning MITM attacks IIRC.
<re_irc> <> Been a while since I played with that stuff.
<re_irc> <> šŸ¤”
<re_irc> <> security is another reason to not to that, I guess
<re_irc> <> other than reliabilty vs broken routers šŸ‘Œ
<re_irc> <> smoltcp currently updates the addr from any arp response, but also from arp requests lol
<re_irc> <> not sure whether that's another reliability concern, lolol
<re_irc> <> Can't you spoof an ARP response just as easily?
<re_irc> <> the idea is ARP responses would only be accepted if we have sent an ARP request, so the time window where you can poison one is much smaller
<re_irc> <> But yea if all the big OSs are only using responses probably makes sense to do the same... it's not much of a loss except sometimes needing to do an arp req to reply to someone?
<re_irc> <> but it's still a lost cause
<re_irc> <> ethernet is security swiss cheese
<re_irc> <> there's still sooo much bad shit you can do to an Ethernet network with physical access :D
<re_irc> <> It's not designed to be secure. Would you expect an SPI or IĀ²C bus to be secure against bad actors with physical access? Why should Ethernet be different?
<re_irc> <> it's switched, you're not on a shared wire with everyone else
<re_irc> <> but it used to, and today's switches emulate that for compatibility, so we're now stuck with it
<re_irc> <> and vendors love it, so that they can sell you fancy "L3 switches" that do per-port IP filtering and DHCP snooping and stuff for HUGE amounts of money
<re_irc> <> Exactly. Good switches can add a layer of security, mainly by filtering out many unexpected things, but because it's been added retroactively it's extremely complex and difficult to make water tight.
<re_irc> <> it's not secure because vendors have no incentive to make it secure :P
<re_irc> <> switches could be just "routers with lots of ports", routing everything based on IP
<re_irc> <> 1 ip = 1 port. No spoofing possible!
<re_irc> <> it would be cheaper, faster, better, simpler
<re_irc> <> no need for ARP at all
<re_irc> <> no need for switches to maintain a table of MAC addrs in the network
<re_irc> <> Hey Guys,
<re_irc> <> Are there any good Real time os resources for Rust at the moment?
<re_irc> <> here's a nice list
<re_irc> <> So not RTOS yet :(
<re_irc> <> many are prduction ready
<re_irc> <> I'm shipping thousands of devices with embassy, others are doing so with RTIC too
<re_irc> <> Not sure all the columns on that page are up-to-date either.
<re_irc> <> (IMO embassy, rtic aren't RTOSs in the traditional sense as in having threads and context-switching)
<re_irc> <> also, there's lots of holes in C that C RTOSs fill that Rust simply doesn't have
<re_irc> <> such as RTOS HALs for writing portable drivers. C doesn't have traits/interfaces but Rust does :)
<re_irc> <> so there's `embedded-hal`
<re_irc> <> Tock is kind of an odd one in that it's an RTOS written in Rust that primarily supports C userspace applications. And it's on release 2.0, but the support for userspace Rust code seems to be held up by llvm support for generating position-independent code. Or at least that's what the github issues seem to be saying.
<re_irc> <> We might get that gcc back-end before we get decent PIC in llvm
<re_irc> <> The missing bits for ropi/rwpi pic are in rustc, not llvm. the gcc backend won't solve that either
<re_irc> <> uh but do you really need dynamically-loadable hardware-independent *without recompiling* apps like tock's?
<re_irc> <> that's a super rare requirement IMO
<re_irc> <> and the cost of getting that is *massive complexity*
<re_irc> <> I worked on an automotive product using a C++ automotive-oriented RTOS that was not much more complex than RTIC and seemed to be based on a similar premise. Worked pretty well for our use case, anyway. I think that style of OS is used in a lot of the smaller CAN-based controllers in cars.
<re_irc> <> Really? I don't think llvm can do ropi/rwpi either, even if rust also needs work
<re_irc> <> Arm had some patches for it but they weren't merged as too involved and stayed in keil's armcc iirc
<re_irc> <> these were clang patches
<re_irc> <> I think the llvm side is upstreamed
<re_irc> <> the equivalent of these patches is what would rustc need
<re_irc> <> hm, I thought llvm also needed more work but don't have links handy atm
<re_irc> <> don't quote me on that though lol
<re_irc> <> clang can do ropi/rwpi for C iirc, but vtables and various other bits don't work so no c++?
<re_irc> <> Yea same, I'd have to dig the links out
<re_irc> <> I think in C statics whose initial value points to another static are also broken
<re_irc> <> vtables are also the same issue in the end
<re_irc> <> statics that point to other statics, or to .text
<re_irc> <> people did like being able to install apps on their pebble smartwatches. It is a niche use-case though
<re_irc> <> rip my pebble watch
<re_irc> <> A few days before my masters thesis was due I got the original one and instead of starting my thesis I made an app for it that showed how many hours were left to the deadline
<re_irc> <> The app worked at least
<re_irc> <> LOL