Very cool! I have one more busy day before I can play. I'll try this out
in the next couple days and send a full report by Saturday.
I currently have these 6 interfaces, but that does not include the PC
Card that gets named eth1
Thank you very much,
-mikeu
[mikeu@rigel Desktop]$ ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:26:B9:24:D8:B0
inet addr:192.168.214.254 Bcast:192.168.214.255
Mask:255.255.255.0
inet6 addr: fe80::226:b9ff:fe24:d8b0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:33064 errors:0 dropped:0 overruns:0 frame:0
TX packets:31810 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:32485115 (30.9 MiB) TX bytes:6032798 (5.7 MiB)
Interrupt:17
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:82 errors:0 dropped:0 overruns:0 frame:0
TX packets:82 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:5624 (5.4 KiB) TX bytes:5624 (5.4 KiB)
pan0 Link encap:Ethernet HWaddr 4E:4D:DF:52:34:08
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
virbr0 Link encap:Ethernet HWaddr 52:54:00:4D:C2:17
inet addr:192.168.122.1 Bcast:192.168.122.255
Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:22 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:2093 (2.0 KiB)
virbr0-nic Link encap:Ethernet HWaddr 52:54:00:4D:C2:17
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
wlan0 Link encap:Ethernet HWaddr 00:21:6A:AE:D9:08
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
[mikeu@rigel Desktop]$ cat /proc/net/dev
Inter-| Receive |
Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes
packets errs drop fifo colls carrier compressed
lo: 5624 82 0 0 0 0 0 0
5624 82 0 0 0 0 0 0
eth0:32487353 33078 0 0 0 0 0 0
6039459 31828 0 0 0 0 0 0
wlan0: 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
pan0: 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
virbr0: 0 0 0 0 0 0 0 0
2093 22 0 0 0 0 0 0
virbr0-nic: 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
> -------- Original Message --------
> Subject: RE: [Simh] trouble selecting VAX ethernet on CentOS
> From: Mark Pizzolato - Info Comm <[email protected]>
> Date: Tue, February 28, 2012 5:16 pm
> To: "[email protected]" <[email protected]>, "Michael L.
> Umbricht" <[email protected]>
> Cc: Mark Pizzolato - Info Comm <[email protected]>
>
>
> On Monday, February 27, 2012 at 2:48 PM, Mark Pizzolato wrote:
>
> > On Monday, February 27, 2012 at 2:37 PM, Michael L. Umbricht wrote:
>
> > > My version info is below.
>
> > >
>
> > > I pulled pcap from the CentOS repo, and it looks very old. Circa 2008/9
> > > if the
>
> > > version number is correct. That could be part of the trouble.
>
> > > I'll try getting the latest from tcpdump later in the week when I have a
> > > bit
>
> > > more time to fiddle with this.
>
> >
>
> > I've just downloaded CentOS 6.2 x64 and am in the process of installing a
>
> > VirtualBox VM running it.
>
> >
>
> > Do not bother messing with the www.tcpdump.org libpcap. All observations
>
> > to date have shown that current OS distributed libpcap is sufficient for the
>
> > needs of simh. The distro's libpcap (and libpcap-devel) is always much
> > easier
>
> > to install in a consistent fashion. I just asked to be sure I wasn't
> > chasing what
>
> > appeared to be a OS distributed libpcap but wasn't.
>
> >
>
> > Thanks for the info.
>
> >
>
> > I'll let you know what I find.
>
>
>
> I downloaded an ISO image: CentOS-6.2-x86_64-bin-DVD1.iso
>
> I installed a VM using this Image onto an empty virtual disk which is 64GB in
> size.
>
> During the install I selected a Desktop install.
>
>
>
> Once the install finished, I created my user account and logged in.
>
> I needed to install gcc and libpcap-devel
>
>
>
> I pulled down the current simh source from github with wget and built a vax
> simulator.
>
> I then (as root) ran the resulting vax binary. I was able to attach eth0
> without any problem.
>
> I shutdown the VM and added 2 more network interfaces (attached externally to
> different networks).
>
> I started the system and once again, things worked completely as expected
> (without any SegFaults).
>
> I looked for differences in your and my systems. Your 'uname -a' had
> centos.plus while mine didn't. I changed the configuration to use the
> centos.plus kernel components and tried again.
>
> Things still work as expected...
>
>
>
> Clearly there is something different about your system and the network
> devices it may have, as compared to the simple case of my virtual machine
> with only Ethernet devices.
>
>
>
> Can you send me the output of 'ifconfig -a'? Also the contents of
> /proc/net/dev
>
>
>
> The difference between my working environment and your non-working one must
> have something to do with the difference in hardware/network stacks in use.
> That is why I asked for your 'ifconfig -a' output and the /proc/net/dev
> content.
>
>
>
> By the way, your observation that 'attach xq eth' worked for you was actually
> a bug in the name matching logic. The code in eth_open tries to accommodate
> several different forms of 'names'. The first checked is the ethN form which
> I previously described. The second is a check against the device
> description, which if an exact match is found the corresponding interface is
> opened. The third check is against the OS device name. The names and/or
> description checks are against the data which is shown in the output of 'show
> xq eth'. The bug which the 'attach xq eth' found was that the device name
> check was only using the length of the argument (eth in this case 3) to
> compare against each of the actual device names and it considered a match if
> the first 3 bytes of the names matched. Since the scan went in the order
> displayed by 'show xq eth' the match found your eth0 interface.
>
>
>
> Each of those scanning mechanisms (as well as the code which produces the
> output of 'show xq eth') use a common routine to build the array of device
> names/descriptions. I can't really explain why in your case the process
> which creates this table for the number lookup is failing while each of the
> other cases doesn't fail ('show xq eth' works for you and the fact that you
> can do a 'atta xq wlan0' works means that BOTH the description check didn't
> SegFault and the Device name didn't segfault AND it actually found the name.
>
>
>
> AHHH HAHHH!!!!
>
>
>
> I found the issue. The common routine which builds the above mentioned list
> could overrun the list by 1 if the set of potential pcap connectable devices
> was greater than 10 (it must be on your system but not on my test system). I
> changed the constant which determines the size of this table from 10 to 3 and
> I reproduced the SegFault failure. The difference in behavior for the 3
> cases which used this common routine had to do with the different number of
> local variables on the stack which got overwritten by the error.
>
>
>
> The code has been fixed and is available at
> https://github.com/markpizz/simh/zipball/master
>
>
>
>
>
> > - Mark
>
> >
>
> >
>
> > >
>
> > > -mikeu
>
> > >
>
> > >
>
> > > [mikeu@rigel Desktop]$ cat /etc/redhat-release CentOS release 6.2 (Final)
>
> > > [mikeu@rigel Desktop]$ uname -a Linux rigel 2.6.32-
>
> > > 220.4.2.el6.centos.plus.x86_64 #1 SMP Mon Feb 13
>
> > > 23:42:47 GMT 2012 x86_64 x86_64 x86_64 GNU/Linux [mikeu@rigel
>
> > > Desktop]$
>
> > >
>
> > > [mikeu@rigel Desktop]$ yum info libpcap* Loaded plugins: fastestmirror,
>
> > > refresh-packagekit Loading mirror speeds from cached hostfile
>
> > > * base: yum.singlehop.com
>
> > > * centosplus: mirror.vcu.edu
>
> > > * extras: centos.mirror.nac.net
>
> > > * rpmforge: fr2.rpmfind.net
>
> > > * updates: mirror.umd.edu
>
> > > Installed Packages
>
> > > Name : libpcap
>
> > > Arch : x86_64
>
> > > Epoch : 14
>
> > > Version : 1.0.0
>
> > > Release : 6.20091201git117cb5.el6
>
> > > Size : 324 k
>
> > > Repo : installed
>
> > > From repo : anaconda-CentOS-201106060106.x86_64
>
> > > Summary : A system-independent interface for user-level packet
>
> > > capture
>
> > > URL : http://www.tcpdump.org
>
> > > License : BSD with advertising
>
> > > Description : Libpcap provides a portable framework for low-level network
>
> > > : monitoring. Libpcap can provide network statistics
> > > collection,
>
> > > : security monitoring and network debugging. Since almost
> > > every
>
> > > system
>
> > > : vendor provides a different interface for packet capture,
> > > the libpcap
>
> > > : authors created this system-independent API to ease in
> > > porting and
>
> > > to
>
> > > : alleviate the need for several system-dependent packet
> > > capture
>
> > > modules
>
> > > : in each application.
>
> > > :
>
> > > : Install libpcap if you need to do low-level network traffic
> > > monitoring
>
> > > : on your network.
>
> > >
>
> > > Name : libpcap-devel
>
> > > Arch : x86_64
>
> > > Epoch : 14
>
> > > Version : 1.0.0
>
> > > Release : 6.20091201git117cb5.el6
>
> > > Size : 134 k
>
> > > Repo : installed
>
> > > From repo : base
>
> > > Summary : Libraries and header files for the libpcap library
>
> > > URL : http://www.tcpdump.org
>
> > > License : BSD with advertising
>
> > > Description : Libpcap provides a portable framework for low-level network
>
> > > : monitoring. Libpcap can provide network statistics
> > > collection,
>
> > > : security monitoring and network debugging. Since almost
> > > every
>
> > > system
>
> > > : vendor provides a different interface for packet capture,
> > > the libpcap
>
> > > : authors created this system-independent API to ease in
> > > porting and
>
> > > to
>
> > > : alleviate the need for several system-dependent packet
> > > capture
>
> > > modules
>
> > > : in each application.
>
> > > :
>
> > > : This package provides the libraries, include files, and
> > > other
>
> > > : resources needed for developing libpcap applications.
>
> > >
>
> > >
>
> > >
>
> > > > -------- Original Message --------
>
> > > > Subject: RE: [Simh] trouble selecting VAX ethernet on CentOS
>
> > > > From: Mark Pizzolato - Info Comm <[email protected]>
>
> > > > Date: Mon, February 27, 2012 3:02 pm
>
> > > > To: "Michael L. Umbricht" <[email protected]>, Mark Pizzolato - Info
>
> > > > Comm <[email protected]>
>
> > > >
>
> > > >
>
> > > > On Monday, February 27, 2012 at 9:21 AM, Michael L. Umbricht wrote:
>
> > > >
>
> > > > > Ok, I'll give that and the other suggestions a try. I'm busy at work
>
> > > > > for the next
>
> > > >
>
> > > > > two days, but I'll work on this more later in the week.
>
> > > >
>
> > > > >
>
> > > >
>
> > > > > One odd thing. If I type "at xq eth" (with no "0") it attaches to
>
> > > > > eth0 and works
>
> > > >
>
> > > > > fine. However, if I type "at xq eth0" I get the segfault. I would
>
> > > > > think eth0
>
> > > >
>
> > > > > would work with either naming scheme and point to the same device...
>
> > > >
>
> > > > >
>
> > > >
>
> > > > > Also, "at xq eth1" should attach to wlan0 from what you are saying,
>
> > > > > but
>
> > > >
>
> > > > > instead causes a segfault. Using "at xq wlan0" works.
>
> > > >
>
> > > >
>
> > > >
>
> > > > These are definitely odd, but they each exercise (or avoid) a common
>
> > code
>
> > > path. The failing cases are each trying to translate a simh ethN name to
> > > an
>
> > OS
>
> > > device name by calling eth_getname.
>
> > > >
>
> > > >
>
> > > >
>
> > > > > I'm in a cafe with no 10b2 network :) but I'll try ETH 3 / eth1 later.
>
> > > >
>
> > > >
>
> > > >
>
> > > > Given the pattern of failures calling eth_getname, I now think this will
>
> > also
>
> > > fail.
>
> > > >
>
> > > >
>
> > > >
>
> > > > NONE of them should fail (at least not with a SegFault), so your case is
>
> > > somewhat simplified.
>
> > > >
>
> > > >
>
> > > >
>
> > > > Can you describe the exact version of CentOS you are running. Maybe I
>
> > > can reproduce this here and get directly to the root cause.
>
> > > >
>
> > > >
>
> > > >
>
> > > > Did you install the OS supplied libpcap-devel package or did you
>
> > download
>
> > > the latest source from www.tcpdump.org and somehow build it to
>
> > > install/replace the OS supplied code?
>
> > > >
>
> > > >
>
> > > >
>
> > > > I know the makefile announces that you are using the Linux vendor's
>
> > > libpcap components, but it makes that determination by finding the pcap.h
>
> > > include files in /usr/include/pcap.h and finding the libpcap.so file
> > > available.
>
> > A
>
> > > creative install of the www.tcpdump.org components could cause this
>
> > > announcement and determination to be incorrect.
>
> > > >
>
> > > >
>
> > > >
>
> > > > Let me know.
>
> > > >
>
> > > >
>
> > > >
>
> > > > - Mark
>
> > > >
>
> > > >
>
> > > >
>
> > > > > -mikeu
>
> > > >
>
> > > > >
>
> > > >
>
> > > > > > -------- Original Message --------
>
> > > >
>
> > > > > > Subject: RE: [Simh] trouble selecting VAX ethernet on CentOS
>
> > > >
>
> > > > > > From: Mark Pizzolato - Info Comm <[email protected]>
>
> > > >
>
> > > > > > Date: Mon, February 27, 2012 9:31 am
>
> > > >
>
> > > > > > To: "Michael L. Umbricht" <[email protected]>
>
> > > >
>
> > > > > > Cc: "[email protected]" <[email protected]>,
>
> > > > > > Jan-Benedict
>
> > > >
>
> > > > > > Glaw <[email protected]>
>
> > > >
>
> > > > > >
>
> > > >
>
> > > > > >
>
> > > >
>
> > > > > > Hi Mike,
>
> > > >
>
> > > > > >
>
> > > >
>
> > > > > > I just got off a red-eye airplane flight and on the drive home
>
> > > > > > from the
>
> > > >
>
> > > > > airport I realized part of the problem you are having.
>
> > > >
>
> > > > > >
>
> > > >
>
> > > > > > I suspect that things will work just fine for you if you have
>
> > > > > > "attach
>
> > > >
>
> > > > > > xq eth3" in your vax.ini
>
> > > >
>
> > > > > >
>
> > > >
>
> > > > > > This is due to the simh generic naming for Ethernet devices. Simh
>
> > > > > > has
>
> > > >
>
> > > > > names "eth0", "eth1".... which correspond to the number in column 1
>
> > > > > of the
>
> > > >
>
> > > > > output of 'show xq eth'.
>
> > > >
>
> > > > > >
>
> > > >
>
> > > > > > > > > ETH devices:
>
> > > >
>
> > > > > > > > > 0 eth0 (No description available) ! on-board gig
> > > > > > > > > ethernet
>
> > > >
>
> > > > > > > > > 1 wlan0 (No description available) ! on-board wireless
>
> > > >
>
> > > > > > > > > 2 virbr0 (No description available) ! used by VirtualBox
>
> > > >
>
> > > > > > > > > 3 eth1 (No description available) ! PCMCIA 10b2 or
> > > > > > > > > 10bT
>
> > > >
>
> > > > > >
>
> > > >
>
> > > > > > The simh Ethernet names take precedence over the physical device
>
> > > names.
>
> > > >
>
> > > > > This means that if a name is of the form "ethN" then the simh naming
>
> > > >
>
> > > > > convention is used. If the name doesn't have that form, then an
>
> > > > > open is
>
> > > >
>
> > > > > attempted presuming that the name supplied is a physical Ethernet
>
> > > > > device
>
> > > >
>
> > > > > name. If things succeed, then all is well.
>
> > > >
>
> > > > > >
>
> > > >
>
> > > > > > I don't have a good explanation for the segfault (that shouldn't
>
> > > > > > happen),
>
> > > >
>
> > > > > but I'll look into that later today. I may need to ask you to run
>
> > > > > some tests
>
> > > >
>
> > > > > since I don't have a system which produces this failure.
>
> > > >
>
> > > > > >
>
> > > >
>
> > > > > > - Mark
>
> > > >
>
> > > > > >
>
> > > >
>
> > > > > > > -----Original Message-----
>
> > > >
>
> > > > > > > From: [email protected]
>
> > > > > > > [mailto:simh-bounces@trailing-
>
> > > >
>
> > > > > > > edge.com] On Behalf Of Michael L. Umbricht
>
> > > >
>
> > > > > > > Sent: Sunday, February 26, 2012 4:50 PM
>
> > > >
>
> > > > > > > To: Jan-Benedict Glaw
>
> > > >
>
> > > > > > > Cc: [email protected]
>
> > > >
>
> > > > > > > Subject: Re: [Simh] trouble selecting VAX ethernet on CentOS
>
> > > >
>
> > > > > > >
>
> > > >
>
> > > > > > > Here is the GDB output. -mikeu
>
> > > >
>
> > > > > > >
>
> > > >
>
> > > > > > > [root@rigel vms]# gdb ./vax
>
> > > >
>
> > > > > > > GNU gdb (GDB) Red Hat Enterprise Linux (7.2-50.el6) Copyright
>
> > > > > > > (C)
>
> > > >
>
> > > > > > > 2010 Free Software Foundation, Inc.
>
> > > >
>
> > > > > > > License GPLv3+: GNU GPL version 3 or later
>
> > > >
>
> > > > > > > <http://gnu.org/licenses/gpl.html>
>
> > > >
>
> > > > > > > This is free software: you are free to change and redistribute it.
>
> > > >
>
> > > > > > > There is NO WARRANTY, to the extent permitted by law. Type
>
> > > > > > > "show
>
> > > >
>
> > > > > > > copying"
>
> > > >
>
> > > > > > > and "show warranty" for details.
>
> > > >
>
> > > > > > > This GDB was configured as "x86_64-redhat-linux-gnu".
>
> > > >
>
> > > > > > > For bug reporting instructions, please see:
>
> > > >
>
> > > > > > > <http://www.gnu.org/software/gdb/bugs/>...
>
> > > >
>
> > > > > > > Reading symbols from /home/mikeu/Downloads/simhv38-
>
> > > >
>
> > > > > > > 2/vms/vax...done.
>
> > > >
>
> > > > > > > (gdb) run
>
> > > >
>
> > > > > > > Starting program: /home/mikeu/Downloads/simhv38-2/vms/vax
>
> > > >
>
> > > > > > > [Thread debugging using libthread_db enabled]
>
> > > >
>
> > > > > > >
>
> > > >
>
> > > > > > > VAX simulator V3.8-2
>
> > > >
>
> > > > > > > NVR: buffering file in memory
>
> > > >
>
> > > > > > > [New Thread 0x7ffff7fe0700 (LWP 3555)] [New Thread
>
> > > > > > > 0x7fffd6e64700
>
> > > >
>
> > > > > > > (LWP 3556)]
>
> > > >
>
> > > > > > > RQ2: unit is read only
>
> > > >
>
> > > > > > > [New Thread 0x7fffd6462700 (LWP 3557)]
>
> > > >
>
> > > > > > > RQ3: unit is read only
>
> > > >
>
> > > > > > > [New Thread 0x7fffd5a60700 (LWP 3558)] Listening on port 2020
>
> > > >
>
> > > > > > > (socket 13) Modem control activated Auto disconnect activated
>
> > > >
>
> > > > > > > sim> at xq eth1
>
> > > >
>
> > > > > > > libpcap version 1.0.0
>
> > > >
>
> > > > > > >
>
> > > >
>
> > > > > > > Program received signal SIGSEGV, Segmentation fault.
>
> > > >
>
> > > > > > > 0x00000000004533e1 in eth_open (dev=Cannot access memory at
>
> > > >
>
> > > > > address
>
> > > >
>
> > > > > > > 0x7fff00366877
>
> > > >
>
> > > > > > > ) at sim_ether.c:1454
>
> > > >
>
> > > > > > > 1454 savname = eth_getname(num, temp);
>
> > > >
>
> > > > > > > Missing separate debuginfos, use: debuginfo-install
>
> > > >
>
> > > > > > > glibc-2.12-1.47.el6_2.5.x86_64
>
> > > >
>
> > > > > > > libpcap-devel-1.0.0-6.20091201git117cb5.el6.x86_64
>
> > > >
>
> > > > > > > ncurses-devel-5.7-3.20090208.el6.x86_64
>
> > > >
>
> > > > > > > ncurses-libs-5.7-3.20090208.el6.x86_64
>
> > > >
>
> > > > > > > readline-devel-6.0-3.el6.x86_64
>
> > > >
>
> > > > > > > (gdb)
>
> > > >
>
> > > > > > >
>
> > > >
>
> > > > > > >
>
> > > >
>
> > > > > > >
>
> > > >
>
> > > > > > > > -------- Original Message --------
>
> > > >
>
> > > > > > > > Subject: Re: [Simh] trouble selecting VAX ethernet on CentOS
>
> > > >
>
> > > > > > > > From: Jan-Benedict Glaw <[email protected]>
>
> > > >
>
> > > > > > > > Date: Sun, February 26, 2012 5:45 pm
>
> > > >
>
> > > > > > > > To: "Michael L. Umbricht" <[email protected]>
>
> > > >
>
> > > > > > > > Cc: Mark Pizzolato - Info Comm <[email protected]>,
>
> > > >
>
> > > > > > > > "[email protected]" <[email protected]>
>
> > > >
>
> > > > > > > >
>
> > > >
>
> > > > > > > >
>
> > > >
>
> > > > > > > > On Sun, 2012-02-26 15:16:21 -0700, Michael L. Umbricht
>
> > > >
>
> > > > > > > <[email protected]> wrote:
>
> > > >
>
> > > > > > > > > Yeah, I didn't have such a great night of sleep last
>
> > > > > > > > > night... I
>
> > > >
>
> > > > > > > > > kind of noticed "-aa" was but just did a c&p. Anyway, now it
>
> > > compiles!
>
> > > >
>
> > > > > > > > > Thank you, all, for the suggestions and help.
>
> > > >
>
> > > > > > > > >
>
> > > >
>
> > > > > > > > > Same sort of trouble, though. It only allows me to choose
> > > > > > > > > "eth"
>
> > > >
>
> > > > > > > > > which grabs eth0 or I can choose "wlan0" to grab the wireless.
>
> > > >
>
> > > > > > > > > Any attempt to attach to either "eth0" or "eth1" fails with a
> > > > > > > > > seg
>
> > > fault.
>
> > > >
>
> > > > > > > > >
>
> > > >
>
> > > > > > > > > -mikeu
>
> > > >
>
> > > > > > > > >
>
> > > >
>
> > > > > > > > > VAX simulator V3.8-2
>
> > > >
>
> > > > > > > > >
>
> > > >
>
> > > > > > > > > sim> at xq ?
>
> > > >
>
> > > > > > > > > libpcap version 1.0.0
>
> > > >
>
> > > > > > > > > ETH devices:
>
> > > >
>
> > > > > > > > > 0 eth0 (No description available) ! on-board gig
> > > > > > > > > ethernet
>
> > > >
>
> > > > > > > > > 1 wlan0 (No description available) ! on-board wireless
>
> > > >
>
> > > > > > > > > 2 virbr0 (No description available) ! used by VirtualBox
>
> > > >
>
> > > > > > > > > 3 eth1 (No description available) ! PCMCIA 10b2 or
> > > > > > > > > 10bT
>
> > > >
>
> > > > > > > > > 4 tap:tapN (Integrated Tun/Tap support) Select device
>
> > > > > > > > > (ethX
>
> > > >
>
> > > > > > > > > or <device_name>)? eth0 Segmentation fault (core dumped)
>
> > > >
>
> > > > > > > > >
>
> > > >
>
> > > > > > > > > sim> at xq eth
>
> > > >
>
> > > > > > > > > libpcap version 1.0.0
>
> > > >
>
> > > > > > > > > Eth: opened OS device eth0
>
> > > >
>
> > > > > > > > > sim> at xq wlan0
>
> > > >
>
> > > > > > > > > Eth: closed eth0
>
> > > >
>
> > > > > > > > > Eth: opened OS device wlan0
>
> > > >
>
> > > > > > > > > sim> at xq eth1
>
> > > >
>
> > > > > > > > > Eth: closed wlan0
>
> > > >
>
> > > > > > > > > Segmentation fault (core dumped)
>
> > > >
>
> > > > > > > >
>
> > > >
>
> > > > > > > > Are all object files built with -g and is the `vax' binary not
>
> > > >
>
> > > > > > > > stripped? Then you'd just run it with gdb:
>
> > > >
>
> > > > > > > >
>
> > > >
>
> > > > > > > > $ gdb ./vax .....
>
> > > >
>
> > > > > > > >
>
> > > >
>
> > > > > > > > Then do your work (-> make it segfault) and when you're back
>
> > > > > > > > at
>
> > > >
>
> > > > > > > > GDB's prompt, use the `bt' command to show us where it's
>
> > > breaking.
>
> > > >
>
> > > > > > > >
>
> > > >
>
> > > > > > > > MfG, JBG
>
> > > >
>
> > > > > > > >
>
> > > >
>
> > > > > > > > --
>
> > > >
>
> > > > > > > > Jan-Benedict Glaw [email protected]
> > > > > > > > +49-172-
>
> > 7608481
>
> > > >
>
> > > > > > > > Signature of: The real problem with C++ for
> > > > > > > > kernel modules
>
> > > is:
>
> > > >
>
> > > > > > > > the second : the language just
> > > > > > > > sucks.
>
> > > >
>
> > > > > > > > -- Linus
>
> > > >
>
> > > > > > > > Torvalds
>
> > > >
>
> > > > > > >
>
> > > >
>
> > > > > > > _______________________________________________
>
> > > >
>
> > > > > > > Simh mailing list
>
> > > >
>
> > > > > > > [email protected]
>
> > > >
>
> > > > > > > http://mailman.trailing-edge.com/mailman/listinfo/simh
>
> > > >
>
> > > > >
>
> > >
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
