Re: [Discuss-gnuradio] Error while receiving
The last problem which I posted is solved and now finally I got the backtrace of error, which is the following: -- #0 0xb710c289 in std::_List_node_base::hook () from /usr/lib/libstdc++.so.6 #1 0xb54e324a in fusb_ephandle_linux::completed_list_add (this=0x4f70, urb=0x8d5ec88) at /usr/include/c++/4.2.1/bits/stl_list.h:1162 #2 0xb54e364b in fusb_devhandle_linux::_reap (this=0x8d50888, ok_to_block_p=true) at fusb_linux.cc:268 #3 0xb54e37b2 in fusb_ephandle_linux::reload_read_buffer (this=0x8d508a0) at fusb_linux.cc:609 #4 0xb54e38b0 in fusb_ephandle_linux::read (this=0x8d508a0, buffer=0xb4a640ec, nbytes=14336) at fusb_linux.cc:575 #5 0xb54d69e9 in usrp_basic_rx::read (this=0x8d50600, buf=0xb4a640ec, len=14336, overrun=0xb4a680fb) at usrp_basic.cc:607 #6 0xb54a2de7 in usrp1_source_base::work (this=0x8d42e58, noutput_items=3584, [EMAIL PROTECTED], [EMAIL PROTECTED]) at usrp1_source_base.cc:105 #7 0xb60a80fa in gr_sync_block::general_work (this=0x8d42e58, noutput_items=3584, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]) at gr_sync_block.cc:64 #8 0xb60a6194 in gr_single_threaded_scheduler::main_loop (this=0x8d74788) at gr_single_threaded_scheduler.cc:338 #9 0xb60a76dd in gr_single_threaded_scheduler::run (this=0x8d74788) at gr_single_threaded_scheduler.cc:86 #10 0xb60a51d4 in gr_scheduler_thread::run_undetached (this=0x8d74a20, arg=0x0) at gr_scheduler_thread.cc:98 - Can some help me to understand it and let me know where is the error. Best Regards Kaleem Ahmad Eric Blossom wrote: On Sat, Oct 11, 2008 at 09:33:15AM -0700, kaleem ahmad wrote: Thanks Johnathan, I am tring following as you suggested: The usrp.source_c block only has one output, so you just connect: fg.connect(src, fg1) fg.connect(src, fg2) But by doing this my fg2 is working but fg1 is not...It seems as the connection of fg1 is overwritten by fg2??? This definitely works. We use it all the time. By the way I am using gnuradio3.1.1...is there any update in connect method in later versions? By the way I have also tried following: fg.connect(src, fg1) You need to be using gr.top_block code, not gr.flow_graph, then bracket the reconfigration with self.lock() and self.unlock(). self.lock() disconnect_all() self.connect(src,fg2) ... disconnect_all() self.connect(src,fg1) self.unlock() See usrp_siggen.py for example usage. Eric while(1): disconnect_all() fg.connect(src,fg2) ... disconnect_all() fg.connect(src,fg1) But it is also not working? any suggestion for both of these methods? Best Regards Kaleem Ahmad ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://www.nabble.com/Error-while-receiving-tp19900161p20030693.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP schematics Etc license.
I'm writing a paper which has a section on open hardware, and would like to mention the USRP. I've checked-out usrp-hw from SVN, but can't see any license notices. So my question is, what license applies to the schematics Etc? And am I right in assuming there are no gerber files? And lastly, does anyone know where I can find an appropriately licensed (ideally high-res) copy of this image? http://blog.makezine.com/gnuradio_board.jpg Regards, Andrew - Andrew Back FRSA MIEEE MBCS CITP Open Source Strategist Osmosoft - open source from BT E: [EMAIL PROTECTED] T: 07795 987822 http://www.osmosoft.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Problem with trondeau/dbs/ code
Dear All, I don't get any RX signal from side-B of the USRP when running the trondeau/dbs/ code. BR/ Per ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] updated BBN 80211 code?
Eric Blossom [EMAIL PROTECTED] writes: Let me try that without adding anything else: All code in the gnuradio.org svn repository shall be GPL and assigned to FSF. Just to stir the pot: it's the copyright holder that chooses the license. So it's really (Note that the GNU Radio project is a sub-organization of the FSF.) All code in the gnuradio.org svn repository shall be assigned to FSF. (Because the GNU Radio project has a policy that says it can't go in unless it is assigned) GNU Radio Project has a policy that all of its code will be GPL. Practically, people with assignments put the GPL markings on, but they are following project policy when doing so, not making a license choice. pgpLrczT3vaIe.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Are 64-bit machines a concern for GNUradioinstallation?
You were right. At the end was just only a problem of the compiler being not able to find the right files. I finally hard-coded in Makefile.common the right gnuradio include folders that the BBN code was asking for. Now it compiled and BBN 802.11 code works nice over Gnuradio again. Thanks. De: Eric Blossom [EMAIL PROTECTED] Enviado el: miércoles, 15 de octubre de 2008 20:29 Para: JUAN LARA AMBEL CC: discuss-gnuradio@gnu.org Asunto: Re: [Discuss-gnuradio] Are 64-bit machines a concern for GNUradioinstallation? On Wed, Oct 15, 2008 at 12:49:41PM +0200, JUAN LARA AMBEL wrote: Hello, after successfully playing around for a while with USRP and GNU (amazing tools) and developing some modules by my own, now I've moved to a more powerful PC: a 64-bit Quad Core machine. But now I cannot install properly GNUradio and when trying to build e.g the BBN patches just prints out: *** No rule to make target `/swig/gnuradio.i', needed by `bbn.cc'. Stop. This isn't a 64-bit problem, but a most likely a change required to get out-of-tree builds updated to build with recent versions of the trunk. Most likely what's needed is something like this in the Makefile.common: SWIGGRFLAGS = -I$(GNURADIO_CORE_INCLUDEDIR)/swig -I$(GNURADIO_CORE_INCLUDEDIR) $(GNURADIO_CORE_CPPFLAGS) The bottom line is that swig needs to have the correct set of -I's passed to it on the command line. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: [Patch-gnuradio] Fixing Bug in usrp_spectrum_sense.py
What do you mean by reason? I mean if you're right about this Fixing Bug in usrp_spectrum_sense.py. Yes it is possible. You can use gnuPlot or something like the GUI used in fft_sink. How?? It's seems to be too easy but I don't know so much python to do it... Could you write me some initial code to start trying? Thanks in advance! 2008/10/14 Firas Abbas [EMAIL PROTECTED] Hi, *Santi Ortega [EMAIL PROTECTED]* wrote: Does anyone give you the reason? What do you mean by reason? Is it possible to show the wideband spectrum in a Graphic Window? Yes it is possible. You can use gnuPlot or something like the GUI used in fft_sink. Regards, Firas --- On *Tue, 10/14/08, Santi Ortega [EMAIL PROTECTED]* wrote: From: Santi Ortega [EMAIL PROTECTED] Subject: [Patch-gnuradio] Fixing Bug in usrp_spectrum_sense.py To: [EMAIL PROTECTED] Cc: discuss-gnuradio@gnu.org Date: Tuesday, October 14, 2008, 8:58 PM Hi! about this: http://www.mail-archive.com/[EMAIL PROTECTED]/msg00039.html Does anyone give you the reason? Furthermore, Is it possible to show the wideband spectrum in a Graphic Window? (Not at real-time, but introducing the data-flow and showing it in the computer while it comes) Thanks in Advance! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] About OFDM modulation
Hi! I am working with an OFDM modulator for digital radio. I use a 4096-point IFFT implemented in a FPGA, and because this is my sampling frequency 4.096MHz. At the final of my system i need to obtain an analog signal. The problem is that my DAC works with an 80MHz clock. I can interpolate my signal (originaly at Fs=4.096MHz) to 81.196MHz but not to 80MHz. Then my question are: What problems might I have in the case of using the DAC at a frequency of 80MHz? -- Imagination is more important than knowledge - Albert Einstein ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] About OFDM modulation
On Fri, Oct 17, 2008 at 12:39 PM, Pablo Mendoza [EMAIL PROTECTED] wrote: Hi! I am working with an OFDM modulator for digital radio. I use a 4096-point IFFT implemented in a FPGA, and because this is my sampling frequency 4.096MHz. At the final of my system i need to obtain an analog signal. The problem is that my DAC works with an 80MHz clock. I can interpolate my signal (originaly at Fs=4.096MHz) to 81.196MHz but not to 80MHz. Then my question are: Which DAC? Are we talking about a USRP, USRP2, other? What problems might I have in the case of using the DAC at a frequency of 80MHz? Are you supplying the sample clock of 80MHz for samples which are supposed to be at 81.196MHz? Is 80MHz the maximum sample rate for the DAC? There seem to be a lot of questions left unanswered. Let me propose a solution - use a resampling filter to get to a time base which makes sense, then do the proper upconverstion on your signal. In your case, you have a 4.096Msps signal which you want to get to 80MHz. Maybe you want to have an integer upconversion of 10 or 5? In that case, you want 4.096Msps to really be 8Msps or 16Msps. To get there, you re-sample your 4.096Msps signal by a rate 125/64 or 125/32 (respectively). Follow this by your up by 10 or 5, and you have an 80Msps signal running into an 80Msps DAC. A quick Google search for resampling filter comes up with this FAQ: http://dspguru.org/info/faqs/multrate/resamp.htm Hope this helps! Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] inband signaling and m-blocks
Hi, I have a couple of basic questions regarding USRP inband signaling and m-blocks. 1) Should these two be used together, or are they separate, eg, can i use inband signaling with standard blocks? 2) There is a brief description of inband signling in the trank; is there a simple example that i can look up to see how it works in practice. I have in mind something really simple: I want to build a transmitter that transmits a sinusoid or nothing in PRECICELY specified time intervals; thus my interest in inband signaling. When I understand how to do that I want to build a frequency hopping transmitter/receiver... Thanks Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: [Patch-gnuradio] Fixing Bug in usrp_spectrum_sense.py
Hi, 1) Why you are posting in Patch-gnuradio ?. Posting to Patch-gnuradio is used only if you have a patch to the gnuradio project. 2) Santi Ortega [EMAIL PROTECTED] wrote: How?? It's seems to be too easy but I don't know so much python to do it... Could you write me some initial code to start trying? You have to learn python. Best Regards, Firas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] TunTap device problem in GRC
Has anybody had any luck using the Tun/Tap device in GRC? I've tried it with GRC 0.70 and 0.69 under Fedora 8, and GRC 0.69 under Mac OSX and had no luck, even when running everything as root. Under OSX 10.4, I installed Mattias Nissler's tun/tap driver ( http://tuntaposx.sourceforge.net/ ) dated 2008-Aug-4. It creates all the /dev/tunx and /dev/tapx devices right away, and doesn't seem to have the /dev/net/tun master device. (Michael Dickens, have you had any experience with the tun/tap driver on OSX?) Trying to use the /dev/tun0 in place of /dev/net/tun predictably failed, producing ifs = ioctl(tun_fd, TUNSETIFF, struct.pack(16sH, virtual_device_filename, mode)) IOError: [Errno 25] Inappropriate ioctl for device Under Fedora 8, with either GRC 0.69 or 0.70, things went a little better, but not much. With the following flow graph -- ----- || | Tun/Tap || | | Vector |-| Dev = /dev/net/tun |---| File | | Source | | Virt Dev = tun%d || Sink | || | IP addr = 10.0.0.1 || | -- ----- things ran without error and the net pseudo-device tun0 was created, but an ifconfig showed that no IP address was assigned to it. I successfully used ifconfig to assign address 10.0.0.1 to it, and sent packets to that address, but nothing was captured in the file. And another 'ifconfig tun0' showed that no new TX bytes had been sent out the interface. Is there an error in GRC that results in the IP address not being assigned? And why didn't my packets get there when there WAS an address assigned? @(^.^)@ Ed ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Using gnu-radio for ARM NEON
It is actually an ARMv7a. This a LATER chip than the ARM11, much less the ARM9. The NEON is a powerful 128 bit wide SIMD processor capable of doing floating point arithmetic. Bob This is definitely going to make a VERY nice low power SDR board. Another we should consider is the OMAP-L137 which has ARRL SDR Working Group Chair Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. Trample the slow Hurdle the dead -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Philip Balister Sent: Tuesday, October 14, 2008 9:11 PM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Using gnu-radio for ARM NEON On Tue, Sep 30, 2008 at 9:24 PM, John Gilmore [EMAIL PROTECTED] wrote: Do you mind adding NEON to this list? NEON is a SIMD unit on ARM Cortex-A8 processors. Information on NEON instructions is at http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204h/Bcfjicf j.html. Sorry it si the superseded link, I'm too lazy to find the current one :) This assembler language manual gives pretty good details (except actual instruction encodings): http://infocenter.arm.com/help/topic/com.arm.doc.dui0204h/DUI0204H_rvct_asse mbler_guide.pdf I also tried looking at NEON for the ARM-9, but got: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0409a/index.html Cortex-A9 NEON Media Processing Engine Technical Reference Manual Revision: r0p0 The Cortex-A9 is not the same as an arm9. The Beagle uses a Cortex-A8 which is an armv7 architecture processor. Confusing? Yes. An arm9 processor uses an armv5 instruction set. (From memory) The arm7 technical reference is not public, but if you ask nicely you can get a copy. Needing it to implement NEON based filters for GNU Radio was a good reason. Bottom line: companies are still funny about doucmentation for high end products, but attitudes are changing very slowly. Philip This is a placeholder for a restricted document that is not available from this site. Please contact ARM for more information. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] TunTap device problem in GRC
I pasted the relevant code below so we can reference its mystery hex number.
The tun tap block in grc takes code from the tun tap example to open a
tun tap file descriptor. The file descriptor is fed into a file
descriptor source and sink. From the outside of the tun tap block, we
see the input to the file descriptor sink and the output of the file
descriptor source.
GRC will try to exec ifconfig on the tun tap device name, if an ip
address is specified. You can manually run ifconfig as well. I dont
think this is the problem.
Should this work in linux? Maybe.
Should this work in mac os? Possibilities are even worse: those hard
coded hex values, they probably have header file constants that change
numeric value from linux to freebsd.
This could be helpful:
http://alex.king.net.nz/tuntap.html
Relevant Code from 0.70:
###
## TUN/TAP
###
IFF_TUN = 0x0001 # tunnel IP packets
IFF_TAP = 0x0002 # tunnel ethernet frames
IFF_NO_PI = 0x1000 # don't pass extra packet info
IFF_ONE_QUEUE = 0x2000 # beats me ;)
DEFAULT_TUN_DEVICE = '/dev/net/tun'
DEFAULT_VIRTUAL_DEVICE = 'tun%d'
DEFAULT_IP_ADDR = '10.0.0.1'
def open_tun_interface(tun_device_filename=DEFAULT_TUN_DEVICE,
virtual_device_filename=DEFAULT_VIRTUAL_DEVICE):
!
Open a virtual ethernet interface via the Tun/Tap framework.
An alternative function can be found: from eunuchs.tuntap import
opentuntap
@param tun_device_filename the path to the tun device
@param virtual_device_filename the name of the virtual device (to be
created)
@return a file descriptor to rw the device, name of the virtual device
(created)
from fcntl import ioctl
mode = IFF_TAP | IFF_NO_PI
TUNSETIFF = 0x400454ca
tun_fd = os.open(tun_device_filename, os.O_RDWR)
ifs = ioctl(tun_fd, TUNSETIFF, struct.pack(16sH,
virtual_device_filename, mode))
ifname = ifs[:16].strip(\x00)
return tun_fd, ifname
class TunTapHelper(gr.hier_block2):
Make the tun tap hier2 block.
def __init__(self, item_size, tun_fd):
!
TunTapHelper constructor.
@param item_size the size in bytes of the IO data stream
@param tun_fd the file descriptor for the virtual device
#create hier block
gr.hier_block2.__init__(
self, 'tun_tap',
gr.io_signature(1, 1, item_size),
gr.io_signature(1, 1, item_size)
)
#I/O blocks
sink = gr.file_descriptor_sink(item_size, tun_fd)
source = gr.file_descriptor_source(item_size, tun_fd)
#connect
self.connect(self, sink)
self.connect(source, self)
def TunTap(sb):
gr.file_descriptor_sink, gr.file_descriptor_source #uses
type = Enum(all_choices, 1)
sb.add_input_socket('in', Variable(type))
sb.add_output_socket('out', Variable(type))
sb.add_param('Type', type, False, type=True)
sb.add_param('Tun Device', String(DEFAULT_TUN_DEVICE))
sb.add_param('Virtual Device', String(DEFAULT_VIRTUAL_DEVICE))
sb.add_param('IP Address', String(DEFAULT_IP_ADDR))
sb.set_docs('''\
Foward data between gnuradio and a virtual ethernet interface.
---
Tun Device: File path to the tun device.
Virtual Device: Desired name for the virtual ethernet device. \
%d will give the device a number starting at zero.
IP Address: IP address for the virtual device, leave blank and device
will not be configured.
''')
def make(fg, type, tun, virt, ip_addr):
item_size = type.parse().get_num_bytes()
tun_fd, ifname = open_tun_interface(tun.parse(), virt.parse())
#try to set the ip address
ip_addr = ip_addr.parse()
if ip_addr: os.system('ifconfig %s %s'%(ifname, ip_addr))
return TunTapHelper(item_size, tun_fd)
return sb, make
Ed Criscuolo wrote:
Has anybody had any luck using the Tun/Tap device in GRC?
I've tried it with GRC 0.70 and 0.69 under Fedora 8, and
GRC 0.69 under Mac OSX and had no luck, even when running
everything as root.
Under OSX 10.4, I installed Mattias Nissler's tun/tap driver
( http://tuntaposx.sourceforge.net/ ) dated 2008-Aug-4. It
creates all the /dev/tunx and /dev/tapx devices
right away, and doesn't seem to have the /dev/net/tun
master device. (Michael Dickens, have you had any experience
with the tun/tap driver on OSX?) Trying to use the
/dev/tun0 in place of /dev/net/tun predictably failed,
producing
ifs = ioctl(tun_fd, TUNSETIFF, struct.pack(16sH,
virtual_device_filename, mode))
Re: [Discuss-gnuradio] TunTap device problem in GRC
On Oct 17, 2008, at 4:01 PM, Ed Criscuolo wrote: (Michael Dickens, have you had any experience with the tun/tap driver on OSX?) Nope; never heard of it. I'll look at it, but no promises. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] TunTap device problem in GRC
Josh Blum wrote: I pasted the relevant code below so we can reference its mystery hex number. The tun tap block in grc takes code from the tun tap example to open a tun tap file descriptor. The file descriptor is fed into a file descriptor source and sink. From the outside of the tun tap block, we see the input to the file descriptor sink and the output of the file descriptor source. GRC will try to exec ifconfig on the tun tap device name, if an ip address is specified. You can manually run ifconfig as well. I dont think this is the problem. Should this work in linux? Maybe. Looks like it should. Yet, when I run it in linux, the tun0 network device gets created without the IP address, but manually running the same ifconfig command works. At least as far as asigning the address. Should this work in mac os? Possibilities are even worse: those hard coded hex values, they probably have header file constants that change numeric value from linux to freebsd. Quite likely. In addition, I've found that the tun/tap driver works differently on OSX. In Linux, there's a master tun device called /dev/net/tun. Opening this returns a unique fd and creates both the /dev/tunx character device, and the associated tunx network device. In the Mac OSX tun/tap driver, there is no master /dev/net/tun device. Instead, the driver precreates all the character devices from /dev/tun0 thru /dev/tun15. You have to open the specific one to get the associated net device created. In addition, the ifconfig command works differently on OSX than on Linux. The OSX tunx network devices are created as point-to-point devices, and the OSX ifconfig command REQUIRES the IP address of the far side of the link. And the syntax is different. Linux uses the keyword pointopoint, while OSX just uses two addresses, eg - ifconfig tun0 10.0.0.1 10.0.0.2. Looks like we either need an abstraction layer, or something that converts the OSX semantics to the Linux API. @(^.^)@ Ed ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] TunTap device problem in GRC
Looks like it should. Yet, when I run it in linux, the tun0 network device gets created without the IP address, but manually running the same ifconfig command works. At least as far as asigning the address. GRC expects to have root access in this case, you may be running grc as user, and ifconfig with sudo. Looks like we either need an abstraction layer, or something that converts the OSX semantics to the Linux API. Can you make a ticket with any osx specific findings? I will do something about this tun/tap for the grc trunk in a few... @(^.^)@ Ed ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] TunTap device problem in GRC
On Saturday 18 October 2008 13:49:23 Ed Criscuolo wrote:
Josh Blum wrote:
I pasted the relevant code below so we can reference its mystery hex
number.
The tun tap block in grc takes code from the tun tap example to open a
tun tap file descriptor. The file descriptor is fed into a file
descriptor source and sink. From the outside of the tun tap block, we
see the input to the file descriptor sink and the output of the file
descriptor source.
GRC will try to exec ifconfig on the tun tap device name, if an ip
address is specified. You can manually run ifconfig as well. I dont
think this is the problem.
Should this work in linux? Maybe.
Looks like it should. Yet, when I run it in linux, the tun0 network
device gets created without the IP address, but manually running
the same ifconfig command works. At least as far as asigning the
address.
Should this work in mac os? Possibilities are even worse: those hard
coded hex values, they probably have header file constants that change
numeric value from linux to freebsd.
Quite likely. In addition, I've found that the tun/tap driver works
differently on OSX. In Linux, there's a master tun device called
/dev/net/tun. Opening this returns a unique fd and creates both the
/dev/tunx character device, and the associated tunx network device.
In the Mac OSX tun/tap driver, there is no master /dev/net/tun device.
Instead, the driver precreates all the character devices from /dev/tun0
thru /dev/tun15. You have to open the specific one to get the associated
net device created.
In addition, the ifconfig command works differently on OSX than
on Linux. The OSX tunx network devices are created as
point-to-point devices, and the OSX ifconfig command REQUIRES
the IP address of the far side of the link. And the syntax is
different. Linux uses the keyword pointopoint, while OSX
just uses two addresses, eg - ifconfig tun0 10.0.0.1 10.0.0.2.
Looks like we either need an abstraction layer, or something
that converts the OSX semantics to the Linux API.
OSX and NetBSD seem to be very similar in behaviour see below:
barossa: {10} ifconfig tun0 create
barossa: {11} ifconfig tun0 10.0.0.1 10.0.0.2
barossa: {12} ifconfig tun0
tun0: flags=51UP,POINTOPOINT,RUNNING mtu 1500
inet 10.0.0.1 - 10.0.0.2 netmask 0xff00
cheerio Berndt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] ImportError: libgnuradio-core.so.0
Hi there... I have this error appear when I try to run any examples: Traceback (most recent call last): File ./dial_tone.py, line 23, in module from gnuradio import gr File /usr/local/lib/python2.5/site-packages/gnuradio/gr/__init__.py, line 43, in module from gnuradio_swig_python import * File /usr/local/lib/python2.5/site-packages/gnuradio/gr/gnuradio_swig_python.py , line 23, in module from gnuradio_swig_py_runtime import * File /usr/local/lib/python2.5/site-packages/gnuradio/gr/gnuradio_swig_py_runtime .py, line 6, in module import _gnuradio_swig_py_runtime ImportError: libgnuradio-core.so.0: cannot open shared object file: No such file or directory Same error if I try to import gnuradio.gr from within Python. My Linux distro is openSUSE 11.0 and I downloaded gnuradio using svn. The parts not set up by ./configure are audio-osx, audio-windows, audio-jack, audio-portaudio and comedi. Make and make check are error-free. The files do exist... at /usr/local/lib/ and /home/me/gnuradio/gnuradio-core/src/lib/.libs/ I had a look through some earlier threads regarding this problem and tried 'sudo ldconfig', but I get command not found. Can anyone help me with this? I'm getting better with Linux, but still need 'baby step' instructions. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
