[Hackrf-dev] hackrf_transfer -t issues?

[Mudge Zatko]

This is too heavyweight for the experiment I ultimately want to run, but it
was definitely useful to verify that I could transmit a meaningful signal
compared to hackrf_transfer -t.

Some quick notes to anyone else who might be coming up to speed like me...
 I needed to change hackrfreplay.grc and hackrfreplay.py to get them
working with the versions of gnuradio (3.7.0) and  osmosdr (v0.1.0-10) that
I built to test these.

hackrfreplay.grc:

replace osmosdr_sink_c_0  with osmosdr_sink_0.

hackrfreplay.py:

firdes is imported from gnuradio.filter rather than gnuradio.gr now, so
modify python imports appropriately, and the osmosdr object has method
osmosdr.sink() rather than osmosdr.sink_c().

thanks again :)

.mudge



On Sun, Sep 1, 2013 at 5:38 AM, Michael Ossmann <mike at ossmann.com> wrote:


> I started looking for the bug on an airplane, but I wasn't able to find

> it without hardware to test with.  I'm definitely hoping to get to it

> this week.

>

> I put together the attached flowgraph (.grc file and the generated .py

> program) for GNU Radio 3.6.  hackrfreplay.py may be an acceptable

> alternative until hackrf_transfer -t is fixed.  It's pretty easy to

> change the sample rate, file name, etc. in Python and avoid GRC.

>

> My next step on this when I get back to the lab will be comparing the

> signal produced by hackrfreplay.py with that produced by

> hackrf_transfer.

>

>

> On Fri, Aug 30, 2013 at 09:26:09AM -0700, Mudge Zatko wrote:

> >

> > Thanks Mike.

> >

> > Any idea when (if?) this will be looked into?

> >

> > GRC is cool and all, but part of the allure of HackRF (at least to me) is

> > the ability to perform meaningful replay and mutation fuzzing from a

> > minimalistic unix environment.

> >

> > To that end, hackrf_transfer -t would look to be ideal in quickly

> enabling

> > some initial  security analysis of various receiver codecs.

> >

> > Or perhaps there's another alternative to transfer -t that you or someone

> > else on the list is aware of they could point me to in the meantime?

> >

> > thanks again,

> >

> > .mudge

> >

> >

> >

> >

> >

> > On Fri, Aug 30, 2013 at 7:45 AM, Michael Ossmann <mike at ossmann.com>

> wrote:

> >

> > > On Tue, Aug 27, 2013 at 08:52:32AM -0700, Mudge Zatko wrote:

> > > >

> > > > has anyone had luck with replaying captured signals via

> > > > hackrf_transfer -t?

> > >

> > > There is definitely a bug:

> > >

> > > https://github.com/mossmann/hackrf/issues/91

> > >

> > > I haven't had a chance to look for the root cause yet.

> > >

>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://nine.pairlist.net/pipermail/hackrf-dev/attachments/20130905/6c0a874e/attachment.htm