[HN Gopher] GNU Radio 3.9
___________________________________________________________________
GNU Radio 3.9
Author : lukastyrychtr
Score : 87 points
Date : 2021-01-18 16:29 UTC (6 hours ago)
(HTM) web link (www.gnuradio.org)
(TXT) w3m dump (www.gnuradio.org)
| rsync wrote:
| What is the current "easy" tooling/workup for GNU Radio ?
|
| It used to be that you could download a GNU Radio livecd and that
| worked well - however it is no longer maintained. The latest
| release is from 2017 and I see it written that it is neither
| supported nor recommended.
|
| Is loading the distro of my choice and then managing and
| installing GNU Radio, plus associated utilities/applications, and
| their dependencies my only choice in 2021 ?
| moftz wrote:
| PyBOMBS is probably the best way if you want to be able to
| handle out-of-tree modules. If you just want to play around
| with the built-in functions, using a prebuilt binary from a
| package repo is the easiest.
|
| https://github.com/gnuradio/pybombs#pybombs
| earthscienceman wrote:
| A related note/question: why do projects like this choose github
| over gitlab? It's become a weird world to me, where a GNU project
| could ethically choose github.
|
| To be clear, I use github often as well, but it seems odd to me
| that a GNU sponsored project would.
| Triv888 wrote:
| They should at least push it to both (maybe blocking
| issues/comments/etc on one of them).
| [deleted]
| hollimolli wrote:
| gitlab is just another company; you probably mean a self-hosted
| gitlab server?
| [deleted]
| superkuh wrote:
| I have a physical box for each minor version of GNU Radio;
| working installs of 3.6 to 3.8. I doubt I'll be moving anything
| major to 3.9 any time soon.
|
| Unrelated, I wish the gnuradio website would have HTTP and HTTPS.
| HTTPS only is pretty restrictive and not relevant in the context.
| jimktrains2 wrote:
| > HTTPS only is pretty restrictive and not relevant in the
| context.
|
| This seems even more off-topic than complaining about the
| readability of a site's style. How is HTTPS restrictive and how
| does context outside of "being a website" make HTTPS excessive?
| superkuh wrote:
| When older systems try to access an HTTPS only site they get
| blocked because there's no cypher overlap or no copies of the
| cert authority's new root cert (ie, LetsEncrypt's new one).
| Everyone realized just how much of a problem this was at the
| start of the pandemic when millions couldn't access HTTPS
| only government information sources and sites rolled back
| their security theater.
|
| It's trading accessibility to cargo-cult security.
| cogman10 wrote:
| I've never heard of HTTPS being described as security
| theater.
|
| What are the issues with TLS 1.3 that make it insecure or
| ineffectual?
| superkuh wrote:
| It's security theater in the contex of HTTPS _only_ on
| websites that aren 't performing financial transactions.
| The idea that someone _might_ figure out a way to do a
| TLS downgrade attack and force someone over to the HTTP
| site is not justification for HTTPS only in those cases.
|
| I love TLS. I think it's the least worst system we have.
| But HTTPS _only_ outside of it 's proper context does a
| lot of harm and it's pointless. HTTP and HTTPS are two
| great tastes that go great together.
| MrRadar wrote:
| HTTPS-only is valuable for three reasons. Firstly it
| prevents MITM attacks that inject Javascript (or other)
| payloads into web pages which can be used e.g. for DDoS
| attacks. We saw this with the Great Firewall being used
| to attack Github for hosting material that was censored
| in China by hijacking an analytics script that was being
| served over HTTP[1].
|
| Secondly, it makes passive surveillance and data
| gathering much harder. You can still track which sites a
| user connects to, but you can't see which pages they
| access or the contents of those pages. You can still
| actively intercept those connections via MitM but that
| requires users to manually install an MitM certificate on
| their system so they should be aware when it's occurring.
|
| Thirdly, it makes it harder to intentionally block or
| break HTTPS altogether at the network level to force
| users to fall back to unencrypted HTTP. (TLS downgrade
| attacks are different from and much more difficult than,
| for example, just blocking all traffic on port 443.) If
| there's no unencrypted fallback, then users will complain
| loudly when they can't access sites.
|
| If your main concern is old computers the solution is to
| use a proxy that strips the encryption.
|
| [1] https://www.bankinfosecurity.com/github-hit-by-its-
| largest-d...
| apple_innocent wrote:
| "If your main concern is old computers the solution is to
| use a proxy that strips the encryption."
|
| Why not also use the proxy to add encryption when it is
| missing. Then "HTTPS-only" is not necessary. The decision
| of which scheme to use, http:// or https://, rests with
| the user, not the server.
| MrRadar wrote:
| Encrypting data _after_ it has transited untrustworthy
| networks (which could have surveilled or modified it
| before it gets to you) is about as useful as closing the
| barn door after the horse has already escaped. The
| encryption (and authentication) needs to happen at the
| origin to get any security benefit.
| eesmith wrote:
| http://n-gate.com/software/2017/ gives some pointers.
| I'll summarize them in my own words as:
|
| 1) a CA can issue an illegitimate certificate (gives four
| links where that's happened), and "cross your fingers and
| hope transparency and oversight works" for CAA records
|
| 2) difficulties of determining a competent certificate
| authority.
|
| 3) size still gives clues about content (see also
| https://news.ycombinator.com/item?id=14070130 ), so you
| still have some information leakage, which means you have
| to worry about your threat model to figure out if
| something like padding frames is worthwhile
|
| 4) speaking of threat model, do you really think your
| phone, or the phones of your users, don't include certs
| that lets the telco/government/etc. do #1?
|
| FWIW, found that link from comments after jwz's recent
| posting about problems updating from letsencrypt using
| certbot on CentOS. - https://web.archive.org/web/20210118
| 183806/https://www.jwz.o... .
|
| FWIW, my web site has been around for 20 years, serving
| static files mostly containing a blurb about my services,
| my blog, and various writings and source code I've
| developed and released.
|
| I still can't figure out why I should care to switch to
| https. I can't figure out any relevant threat model to
| justify the work or worry about possible failure cases.
|
| Eg, "Let's Encrypt warns about a third of Android devices
| will from next year stumble over sites that use its
| certs" - https://www.theregister.com/2020/11/06/android_e
| ncryption_ce... . (Updated earlier this month: Let's
| Encrypt "developed a new certificate chain that will
| prevent incompatibility with these devices to allow more
| time for them to age out of the market.")
|
| FWIW, my phone is 10 years old.
| MrRadar wrote:
| The reason to do it is because while HTTPS is not perfect
| (especially when it comes to certificates), the attacks
| against unencrypted and unauthenticated plaintext HTTP
| (as I outlined in my other post) are incredibly trivial
| in comparison. The main point of HTTPS-only is to make
| the attacks significantly harder and more costly to
| execute and easier to detect when they do happen. We
| cannot let the perfect be the enemy of the good. Are
| _you_ comfortable with ISPs injecting ads into your blog?
| [1][2]
|
| > FWIW, my phone is 10 years old.
|
| I'm curious, which phone is this and what do you use it
| for?
|
| The oldest phones I keep in somewhat regular use are a
| Moto X (8 years old) and a Moto E (6 years old) which I
| maintain service on using free service providers (which
| require I use their service at least once each month or
| my service will be discontinued). When I turn those
| phones on each month to place a call with them, they take
| at least an hour to download and install app updates
| before I can even start using them. On the Moto E I've
| had to uninstall most apps because the internal storage
| has been nearly exhausted just by installing the latest
| updates for the bundled apps. On both phones even just
| bringing up the keyboard after I select a text field
| takes multiple seconds and any kind of multitasking is
| out of the question. I could not imagine trying to use
| either of those phones on a daily basis.
|
| [1] https://arstechnica.com/tech-policy/2013/04/how-a-
| banner-ad-...
|
| [2] https://www.reddit.com/r/india/comments/8ry1k4/does_y
| our_isp...
| naf77 wrote:
| The threat model is malicious injection, not
| (some)information leakage.
|
| > my web site has been around for 20 years, serving
| static files mostly containing a blurb about my service,
| my blog,
|
| Your http website will be used for malicious injection,
| it doesn't matter how deep it is in the long tail. Are
| you ok with that? Can you take minimal measures to
| protect me, the user, from getting a malicious injection?
|
| Regarding rogue CAs, most modern OS (Android, Windows)
| report back malicious chains to their mothership, quickly
| detecting and eliminating rogue CAs. It's not the wild
| west anymore.
| apple_innocent wrote:
| Why 1.3? Most sites today are using TLSv1.2 at best, not
| 1.3.
|
| One argument it is/was "security theater"[1] is that
| there were/are numerous programs that "added support for
| SSL/TLS" under pressure to conform but did not bother to
| add authenticaton measures such as hostname checking and
| validation, which was not even a function of the OpenSSL
| library until 2015.
|
| 1. Adopting SSL/TLS for accessibility reasons instead of
| security reasons.
| naf77 wrote:
| HTTPS-everywhere, along with constant monitoring and
| reporting of certificate chains by the browser, are
| designed to protect against QUANTUM attacks [1], which, ~10
| years ago, was being scaled to support million of
| simultaneous attacked devices.
|
| It is not cargo-cult security.
|
| [1] https://en.wikipedia.org/wiki/Tailored_Access_Operation
| s#QUA...
| superkuh wrote:
| HTTPS Everywhere (client side option) is great. HTTPS
| only (server side option) is not.
| naf77 wrote:
| HTTPS only is a "Fail Closed" system, ie it blocks access
| in case of failure. This is safe for the general
| population.
|
| HTTPS/HTTP mixed support is a "Fail Open" system, ie it
| allows (unencrypted) access in case of failure. This is
| unsafe for the general population, see QUANTUM (above).
| superkuh wrote:
| You can argue for wearing a bulletproof vest at home if
| you're an iraqi nuclear scientist. But for most people it
| doesn't make sense and does more harm than good.
|
| In the same way, HTTPs _only_ , *requiring* a system that
| "fails open", is bad for the general population.
| HTTP+HTTPS, yes, definitely. HTTPS only, no, only for
| sites and contexts where the rigid security is justified.
| [deleted]
| 1024core wrote:
| I have a general question about these SDRs: what is the latency
| between when the radio wave "hits" the dongle, and when it is
| detected by the software framework?
| naf77 wrote:
| Buffers, buffers everywhere... It depends on the sampling rate
| and technology (USB, ethernet, direct PCI), but in general
| 1msec is achievable, 10microsec is not achievable.
|
| That's why BladeRF-wiphy (
| https://news.ycombinator.com/item?id=25814237 ) implements the
| lower level phy on FPGA - there's no way to reply an IEEE
| 802.11 ACK frame within 10 microseconds of the end of the
| received frame, as required by the standard.
| dlkinney wrote:
| Depends on your buffer size, bandwidth, and what you're
| demodulating/decoding, but it's pretty fast. With a narrow
| bandwidth on a fast port and simple modulation/encoding, maybe
| a few milliseconds?
| naf77 wrote:
| Counter-intuitively, it is often difficult to reach low
| latency with "narrow bandwidth" (you mean low sampling rate),
| because many SDR interfaces are designed to fill full packets
| with data, not send tiny packets (ex: Ethernet packets). This
| problem goes away above 1-10Msps.
| Evidlo wrote:
| A few ms as others have said, but it's also a non-deterministic
| delay.
|
| This is a problem for applications like time-of-flight
| measurement, so one way to account for this is to send a known
| signal on TX and look for it on RX
| the_only_law wrote:
| Somewhat unrelated but does anyone have any good resources for
| learning GNU radio and SDR for someone who's mostly and idiot. I
| took a single calc course in HS (which I hardly remember) and
| have some very limited digital communications knowledge from
| watching a few videos. I know what I want to eventually build and
| have a nice SDR, but I don't know how to use GNU radio. Most of
| the blocks I see outside some rather specific modulation ones
| seem to be primitive operations.
| she11c0de wrote:
| You may find Michael Ossmann's SDR course [1] helpful - it
| builds the knowledge from the groud up and uses GRC for
| implementation.
|
| [1] https://greatscottgadgets.com/sdr/
| cogman10 wrote:
| OK, so anyone more familiar with this project, how possible would
| it be to make my own home network streaming service for OTA
| radio?
|
| Like, I think it'd be fun to have something like an http server
| or whatever in my home that I could hit something like
| "streamer/99.9fm" and get an opus audio stream for that station.
| jimktrains2 wrote:
| You don't strictly need GNU Radio for something like that. A
| cheap RTL-SDR dongle and the `rtl_fm` command could work.
| na85 wrote:
| I played around with this a bit last year when I first got my
| HackRF. It's got quite the learning curve if you, like me, are
| not already knowledgeable about RF and SDR.
|
| First step for your desired use case would be, I think, to
| acquire an SDR module that can receive broadcast FM and then it
| would simply be a matter of having your server command the SDR
| to tune to 99.9 MHz and then stream the result to the network.
| [deleted]
| iracigt wrote:
| They moved away from SWIG and to PyBind11. As they mention, this
| is going to be an annoying transition for my custom out-of-tree
| modules. Overall though, I'm excited for the changes.
|
| Lots of new GUI blocks in this release. I'm especially glad to
| see the new eye diagram.
|
| Also the ability to load non-WAV audio files will be nice.
| OGG/Vorbis and FLAC are now supported. Plus a slew of minor
| conveniences such as a freq shift block and scaling options in
| the IShort to Complex block (useful for loading recorded samples
| from hardware).
|
| If only it would compile easily on my Mac.
| (https://github.com/ktemkin/gnuradio-for-mac-without-macports has
| a prebuilt 3.8 version)
| MaxBarraclough wrote:
| I have nothing substantive to contribute here but it's always
| nice to see a GNU project with a decent website. Presentable,
| clean, modern. Good stuff. My only quibble is that it's very
| slightly low on contrast.
| jackspratt33 wrote:
| Make a bookmarklet with this:
|
| javascript:var%20x%20=%20document.querySelectorAll("div,p,li,a,
| hr,em,font,strong,h1,h2,h3,td");var%20i;for%20(i%20=%200;%20i%2
| 0<%20x.length;%20i++)%20{%20%20%20%20x[i].style.backgroundColor
| %20=%20"white";x[i].style.color%20=%20"black";}undefined;//aler
| t("Done");;
|
| It changes the background to white and the text color to black.
| I use that on worse websites than the GNU Radio one.
| MaxBarraclough wrote:
| Interesting trick. When I find that a website's design would
| be improved by removing it, I tend to go with Reader Mode.
___________________________________________________________________
(page generated 2021-01-18 23:02 UTC)