sb0_ changed the topic of #m-labs to: https://m-labs.hk :: Logs http://irclog.whitequark.org/m-labs
<sb0> d_n|a: yes
<sb0> it's interesting that the MCH asks for a password for the web interface, but not for the natview interface. if you speak the natview protocol, you are trusted?
<whitequark> sb0: maybe that's why it's udp
<sb0> i also wonder how many buffer overflows and other vulns this thing has
<sb0> whitequark: firewalls can equally block (or not) tcp and udp
<whitequark> do you have a binary of the firmware there?
<sb0> ftp://natmch:natmch@ftp.nateurope.com
<whitequark> the... archive is password-protected?
<whitequark> including the release notes and update instructions?
<sb0> possibly. if you want to try recovering from the device, it's up - tschernobyl.lab.m-labs.hk
<sb0> please just don't break it
<whitequark> ahahaha great name
<whitequark> no i'll just run john the ripper on the zip
<whitequark> i mean, it starts off like they're using cgi scripts with gets() or something
<bb-m-labs> build #2204 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2204
<bb-m-labs> build #2205 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2205
<bb-m-labs> build #985 of artiq-win64-test is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/985
<bb-m-labs> build #2796 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2796
<bb-m-labs> build #2206 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2206
<whitequark> sb0: incredible
<whitequark> so, you can google one of those files, and download them.
<whitequark> and PKWARE encryption is vulnerable to known plaintext attacks.
<whitequark> key0=a24cd050, key1= 860d30d, key2=3f5fdf20
<bb-m-labs> build #2207 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2207
<bb-m-labs> build #2797 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2797 blamelist: David Nadlinger <code@klickverbot.at>
<whitequark> why in the god's name does it have "msvcrt.dll" as a string in the firmware?!
<whitequark> sb0: do you have any idea what sort of CPU might be in that crate?
<whitequark> well, it's full of AVRs, but that's not what i mean
<whitequark> sb0: nevermind
<whitequark> you can telnet to it
<whitequark> without a password.
<whitequark> it lets you update the FPGA, which according to the manual may cause physical damage to the crate.
<whitequark> sb0: anyway. i have the firmware. it's a Coldfire CPU. which is m68k.
<whitequark> i'm sure it's full of holes but i know nothing about m68k so someone else will RE it
rohitksingh_work has joined #m-labs
kc5tja has joined #m-labs
rohitksingh has joined #m-labs
<whitequark> sb0: i've decrypted all of that junk (or the parts that were encrypted, anyway) and uploaded it to ~whitequark/nat_mch_shite.zip on lab.
TD-Linux has quit [Ping timeout: 260 seconds]
TD-Linux has joined #m-labs
rohitksingh has quit [Ping timeout: 245 seconds]
kc5tja has quit [Ping timeout: 250 seconds]
rohitksingh has joined #m-labs
rohitksingh has quit [Read error: No route to host]
daveshah has quit [Read error: Connection reset by peer]
daveshah has joined #m-labs
rohitksingh has joined #m-labs
m4ssi has joined #m-labs
rohitksingh has quit [Read error: Connection reset by peer]
rohitksingh has joined #m-labs
<sb0> whitequark: did you change the passwords?
<sb0> whitequark: or change the configuration in any other way?
rohitksingh has quit [Ping timeout: 240 seconds]
_whitelogger has joined #m-labs
rohitksingh has joined #m-labs
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh has quit [Ping timeout: 258 seconds]
<bb-m-labs> build #2208 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2208
<bb-m-labs> build #2209 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2209
futarisIRCcloud has joined #m-labs
rohitksingh has joined #m-labs
<sb0> wtf, vivado doesn't crash anymore after I ran the exact same command again
<key2> lol
<key2> have u checked ur memory ?
<acathla> C'est tombé en marche (I don't know the english for this) !
<d_n|a> sb0: drtio destination 0 is always supposed to be local RTIO, right? I'll fix up the get_rtio_destination_status() calls in the examples, then
<sb0> d_n|a: no, you can put local RTIO anywhere using the routing table
<sb0> local RTIO is not special
<sb0> it doesn't even have to be hop 0 in the gateware, though that's a sensible convention
<d_n|a> sb0: Sorry, I was being imprecise; what I meant is that it should be exposed somewhere as a user-facing destination
<sb0> well, you don't even have to have local RTIO channels
<d_n|a> All the busy-wait loops that previously were get_drtio_link_status are now off by one (assuming default routing tables)
<sb0> and get_drtio_link_status() on local RTIO returns True as it should
<sb0> so that's not a problem
<sb0> *get_rtio_destination_status
<d_n|a> Agreed, not a problem. It's just that s/get_drtio_link_status/get_rtio_destination_status/g isn't enough; the index also needs to be shifted by one (assuming default routing tables)
<sb0> it doesn't need to, the destination number is abstract
cr1901_modern1 has joined #m-labs
<d_n|a> I'm just talking about the examples/previous DRTIO user code
<sb0> yes. it is valid to call get_rtio_destination_status() on a destination number which is then mapped to local RTIO by the routing table.
<sb0> or are those examples failing to check status for a destination that they then use?
cr1901_modern has quit [Ping timeout: 250 seconds]
<d_n|a> sb0: The loops in e.g. examples/kasli_sawgmaster are now off by one. I'll fix it
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined #m-labs
kc5tja has joined #m-labs
rohitksingh has quit [Ping timeout: 244 seconds]
<bb-m-labs> build #2798 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2798 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
m4ssi has quit [Remote host closed the connection]
rohitksingh has joined #m-labs
kc5tja has quit [Ping timeout: 250 seconds]
rohitksingh has quit [Remote host closed the connection]
X-Scale has quit [Ping timeout: 244 seconds]
<bb-m-labs> build #2210 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2210
mumptai has joined #m-labs
<bb-m-labs> build #2211 of artiq-board is complete: Failure [failed conda_build] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2211 blamelist: David Nadlinger <code@klickverbot.at>
<bb-m-labs> build #2799 of artiq is complete: Failure [failed] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2799 blamelist: David Nadlinger <code@klickverbot.at>
X-Scale has joined #m-labs
_whitenotifier-e has joined #m-labs
<_whitenotifier-e> [nmigen] 104player opened issue #23: Show a better error message when "module contains unmapped RTLIL processes" - https://git.io/fhZT4
Xark has quit [Ping timeout: 245 seconds]
<_whitenotifier-e> [nmigen] 104player commented on issue #23: Show a better error message when "module contains unmapped RTLIL processes" - https://git.io/fhZTB
<_whitenotifier-e> [nmigen] 104player deleted a comment on issue #23: Show a better error message when "module contains unmapped RTLIL processes" - https://git.io/fhZTB
<_whitenotifier-e> [nmigen] 104player commented on issue #23: Show a better error message when "module contains unmapped RTLIL processes" - https://git.io/fhZTR
<_whitenotifier-e> [nmigen] whitequark commented on issue #23: Show a better error message when "module contains unmapped RTLIL processes" - https://git.io/fhZTE
Xark has joined #m-labs
<adamgreig> whitequark: I've definitely hit that ^ error in #23 a few times when trying to hook up top level modules
<adamgreig> mostly when doing ill advised things with Fragment though so..
<whitequark> adamgreig:
<whitequark> the root cause is I can't write a proper Select condition for yosys
<whitequark> the problem is that i don't even know what's wrong
<whitequark> i should just remove that check, it's no longer relevant
<d_n|a> sb0: Seems like timing is marginal again - the above failing change is a noop gateware-wise
Gurty has quit [Ping timeout: 252 seconds]
mumptai has quit [Quit: Verlassend]
<_whitenotifier-e> [m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fhZLq
<_whitenotifier-e> [m-labs/nmigen] whitequark 307de72 - back.verilog: remove undriven check.
<_whitenotifier-e> [nmigen] whitequark closed issue #23: Show a better error message when "module contains unmapped RTLIL processes" - https://git.io/fhZT4
<adamgreig> whitequark: should I have to manually specify the ports for my top-level module, either when doing rtlil.convert or with Fragment.add_ports, or should it be inferred?
<whitequark> manually in rtlil.convert
<whitequark> outputs will never be inferred
<adamgreig> ack
<whitequark> and i think inferring inputs should not be always done either
<adamgreig> yea that's fine, i can easily enough track which ports i need
<adamgreig> in my top module i'm frag=m.lower(platform) and then frag.add_ports(...) so that the fragment i return already has ports, is that ok?
<adamgreig> since i then pass it back up and rtlil and verilog convert it and would rather the thing above not know about the ports
<whitequark> mm, should be fine
<adamgreig> cool, thanks
<_whitenotifier-e> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/477074351?utm_source=github_status&utm_medium=notification