RE: dhclient not setting IP ...
>-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED]]On Behalf Of The Hermit >Hacker > >this is what it appears it was ... called up their tech support last >night, the girl there said "we dont' support Unix", I asked her to release >the IP whereupon she went to her administration console running on UNIX and.. and low-n-behold, I got a new one ... > Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: dhclient not setting IP ...
On 0, Matthew Emmerton <[EMAIL PROTECTED]> wrote: > > I'm connected through cable to the 'Net, and the provider I go > > through, it appears, somehow has it setup that if I change nics, I hvae a > > bugger of a time re-acquiring a lease ... > > What does dhclient log into /var/log/syslog? If you see a lot of > DHCPDISCOVER / DHCPREQUEST lines but no DHCPACKs, then your ISP's DHCP > server isn't a) getting your requests or b) responding to them. In the case > of b), it may be because your MAC address or host-name. Easy way to verify this is throw the -e flag into tcpdump - it'll print the MAC addresses of the tx/rx ethernet interfaces... If the "to" addr isn't the one of your ethernet card (or more to the point, it IS the one of the ethernet card that you originally obtained a working lease from), that pretty much proves that's the problem. Now if I could just figure out why one of my DSL providers keeps getting the MAC address for the >inside< ethernet card of my firewall for some (not all) IPs... mike PGP signature
Re: RTM_LOSING: Kernel Suspects Partitioning:
On Fri, Mar 23, 2001 at 12:11:06PM -0500, Garrett Wollman wrote: > < >said: > > >> This is perfectly natural. TCP will generate these messages whenever > >> its retransmission timer goes off; they should correlate with packet > >> losses. > > > Is it also natural that I cannot ftp from the box to anywhere > > (eg. ftp.cdrom.com)? > > One goes in hand with the other. Your TCP connections are timing out, > which causes the RTM_LOSING messages. Clearly, your packets are not > getting anywhere. Perhaps you should carefully check your > configuration. Traceroute & ping works fine from the box and everything to the box (still) works and I have checked, double checked and triple checked all settings and I've discussed about this in EFnet's #FreeBSDhelp (without success) and on #FreeBSD (and got a bit more help) and every setting/configuration seems to be correct. I've even changed the hardware once to disable the probability of broken hw and I've even tried another OS on the box (which worked just fine). Here's some settings/configurations so you can see everything is like they're supposed to be. $ ifconfig -a vr0: flags=8843 mtu 1500 inet 62.236.255.202 netmask 0xfff8 broadcast 62.236.255.207 inet 62.236.255.203 netmask 0x broadcast 62.236.255.203 inet 62.236.255.204 netmask 0x broadcast 62.236.255.204 inet 62.236.255.205 netmask 0x broadcast 62.236.255.205 ether 00:50:ba:0a:69:6e media: autoselect (10baseT/UTP) status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff00 $ netstat -rn Routing tables Internet: DestinationGatewayFlags Refs Use Netif Expire default62.236.255.201 UGSc 12 106117 vr0 62.236.255.200/29 link#1 UC 00 vr0 => 62.236.255.201 0:0:c:41:b9:40 UHLW 130 vr0277 62.236.255.202 0:50:ba:a:69:6eUHLW06 lo0 62.236.255.203 0:50:ba:a:69:6eUHLW04 lo0 => 62.236.255.203/32 link#1 UC 00 vr0 => 62.236.255.204 0:50:ba:a:69:6eUHLW04 lo0 => 62.236.255.204/32 link#1 UC 00 vr0 => 62.236.255.205 0:50:ba:a:69:6eUHLW04 lo0 => 62.236.255.205/32 link#1 UC 00 vr0 => 127.0.0.1 127.0.0.1 UH 0 22 lo0 $ ipfstat -io empty list for ipfilter(out) empty list for ipfilter(in) $ ipfw show ipfw: getsockopt(IP_FW_GET): Protocol not available No errors nor complaints in dmesg and so on. Please ask if you need more information. -- th To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
D-Link problem
I'm setting up a system (200MHz) with 4.2-RELEASE, and the network card that I have to go in it is a D-Link DFE-538TX/R PCI card, based on the RealTek 8139 chipset. I've been having all kinds of trouble getting it to work. The card works fine in a Win98 system, and the provided diagnostic tools report no problems. Sorry for the long message, but I'm trying to make sure that I have all the common questions answered. Here's what I've tried so far. I have if_rl_load="YES" in /boot/loader.conf Both enabled and disabled PnP OS support in the BIOS Both enabled and disabled WakeOnLan support in the card Moved the network card to different slots, including swapping order with the video card (these are the only boards in the system) Rebuilt the kernel to make sure rl support was enabled None of these provide any real change during the boot, which is that the device is not recognized, so when I try to ifconfig rl0 (or rl1), the interface does not exist. All possibly relevant output from boot -v: pcibios: PCI BIOS entry at 0x4b0 pnpbios: Found PnP BIOS data at 0xc00fca80 pnpbios: Entry = f:cab0 Rev = 1.0 pnpbios: OEM ID cd041 ... Preloaded elf module "if_rl.ko" at 0xc04600f8. Preloaded elf module "miibus.ko" at 0xc0460198. ... pci_open(1):mode 1 addr port (0x0cf8) is 0x805c pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=70308086) ... pci_open(1):mode 1 addr port (0x0cf8) is 0x pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=70308086) pcib0: on motherboard found-> vendor=0x8086, dev=0x7030, revid=0x02 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 found-> vendor=0x8086, dev=0x7000, revid=0x01 class=06-01-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 found-> vendor=0x8086, dev=0x7010, revid=0x00 class=01-01-80, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[20]: type 1, range 32, base e800, size 4 found-> vendor=0x1002, dev=0x4754, revid=0x48 class=03-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=10 map[10]: type 1, range 32, base e600, size 24 map[14]: type 1, range 32, base e000, size 8 found-> vendor=0x1186, dev=0x1300, revid=0x10 class=02-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=11 map[10]: type 1, range 32, base d800, size 8 map[14]: type 1, range 32, base e580, size 8 pci0: on pcib0 PCI Concurrency: enabled Cache: 512K pipelined-burst secondary; L1 enabled DRAM: no memory hole, 66 MHz refresh Read burst timing: x-3-3-3/x-4-4-4 Write burst timing: x-3-3-3 RAS-CAS delay: 3 clocks isab0: at device 7.0 on pci0 I/O Recovery Timing: 8-bit 3.5 clocks, 16-bit 3.5 clocks Extended BIOS: disabled Lower BIOS: disabled Coprocessor IRQ13: enabled Mouse IRQ12: disabled Interrupt Routing: A: disabled, B: IRQ11, C: disabled, D: IRQ10 MB0: IRQ15, MB1: isa0: on isab0 atapci0: port 0xe800-0xe80f at device 7.1 on pci0 ... pci0: (vendor=0x1002, dev=0x4754) at 9.0 irq 10 pci0: (vendor=0x1186, dev=0x1300) at 11.0 irq 11 I know the unknown card here is the network card, since the vendor ID matches the one shown by the BIOS as "network controller" during system boot. There are no other devices conflicting with IRQ 10 or 11. Here's what pciconf -l has to say: chip0@pci0:0:0: class=0x06 card=0x chip=0x70308086 rev=0x02 hdr=0x00 isab0@pci0:7:0: class=0x060100 card=0x chip=0x70008086 rev=0x01 hdr=0x00 atapci0@pci0:7:1: class=0x010180 card=0x chip=0x70108086 rev=0x00 hdr=0x00 none0@pci0:9:0: class=0x03 card=0x47541002 chip=0x47541002 rev=0x48 hdr=0x00 none1@pci0:11:0:class=0x02 card=0x13001186 chip=0x13001186 rev=0x10 hdr=0x00 Poring through the mailing list archives, I came across someone who posted a patch for a bug in /sys/pci/if_rl.c. It didn't help me, but while I was in there I noticed that there were other cards specified, but not mine. I checked on freebsd.org in the STABLE sources tree, but the last modification to the two files I was looking at was in 1999, so clearly nobody has done any official work in there in quite some time. I added the appropriate defines and extended the array of cards defined in if_rlreg.h, updated if_rl.c to match, and rebuilt the kernel. This now recognizes the card during the boot sequence, but then crashes like so: Doing initial network setup: hostname. Fatal trap 12: page fault in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0458007 stack pointer
Re: D-Link problem
> I'm setting up a system (200MHz) with 4.2-RELEASE, and the network card that > I have to go in it is a D-Link DFE-538TX/R PCI card, based on the RealTek > 8139 chipset. [ snip ] > pci0: (vendor=0x1186, dev=0x1300) at 11.0 irq 11 > > I know the unknown card here is the network card, since the vendor ID > matches the one shown by the BIOS as "network controller" during system > boot. There are no other devices conflicting with IRQ 10 or 11. [ snip ] > I added the appropriate > defines and extended the array of cards defined in if_rlreg.h, updated > if_rl.c to match, and rebuilt the kernel. This now recognizes the card > during the boot sequence, but then crashes like so: [ snip ] Well, you're on the right track. More than likely the D-Link card has some flags that aren't being properly set during the driver init. In the meantime, it would be best if you built a debug kernel and enabled crashdumps. This would give you (and us) more details on where (and why) this thing is crashing. Section 23 of the FreeBSD Handbook (http://www.freebsd.org/handbook/kerneldebug.html) has details of how to do this. (Be sure to set dumpdev to your swap slice, and make sure that sizeof(swap) > sizeof(RAM)). -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
orinoco silver card
Ok, I found out that I cannot use a cardbus card for now, so trying to figure out if I can use my orinoco siver 802.11b pcmcia card. This card initiallizes fine, I see a power led, and makes a startup beep. Now I am trying to figure out how to specify the encryption and other settings so it can connect to the residential gateway access point (RG-1000). I read somewhere to create the file listed below, change the approprite settings, and then place it in /etc folder. Now my question is, how does this file get called or run? I tried running it manually by ./setup-wi0, but it would return an error message saying " sed: option requires an argument -- e" and the name of my access point not found. I know my access point works since i can see if fine under win2k. If anyone can point me to good directions or know any solution, it would be greatly appreciated! Thanks. #! /bin/sh set -e ### # # Configuration variables: # IFC is the wavelan interface to use (e.g., "wi0"); this must be # specified: IFC=wi0 # STATION_NAME is, well, the "station name", which is really only used # by the WaveLan diagostic tools. When using the tools (in a remote # PC -- not this one), the tools will display this name when # identifying the WaveLan card in this system. Because it`s only used # by remote diagnostic tools, it`s not essential to set SYSTEM_NAME. # However, it is recommended that, if it is set, it be set to be the # same as the hostname (otherwise, you`ll have to remember which # station name goes with which hostname). # # Note, however, that the following uses `hostname` as the default. # This may not work if this script is called at bootup (especially # when called from pccard.conf), because the hostname may not yet have # been set. In this case, you should hardcode a value here. STATION_NAME=`hostname | sed -e `s/..*$//`` # NETWORK_NAME is the name of the network that you wish to join (be a # part of). NETWORK_NAME must be set if you wish this system to talk # to a WaveLan access point. The NETWORK_NAME can be "ANY" # (upper-case is required), in which case the card will talk to any # access point; otherwise, NETWORK_NAME must be set to the same name # used by the access point. If you are using "ad-hoc mode" (not using # an access point), which generally is the case with an home LAN, you # do not need to set NETWORK_NAME (because ad-hoc mode ignores the # NETWORK_NAME). NETWORK_NAME=`ANY` # MODE determines how the WaveLan card talks to other cards. If you # are using a WaveLan access point, you must set this to "1" (BSS # mode), and you must also set a valid NETWORK_NAME (above), as the # NETWORK_NAME must correspond to the name used by the access point. # For LANs without an access point (the usual case for home LANs), # MODE should be "3" (ad-hoc mode). MODE=3 # 1 --> BSS, 3 --> ad-hoc mode # CHANNEL is the frequency channel to use. The default for cards sold # in the USA and Europe (except France) is channel 3, 11 in France, # and 14 in Japan. Valid channels are: # # USA:1-11 # Europe (except France): 1-13 # France:10-13 # Japan:14 (only -- unchangeable) # # See wicontrol(8) for more information. CHANNEL=3 # Card default is channel 3 # KEY is the encryption key to use. If KEY is blank/empty or not set, # the encryption key is not set, and encryption will not be enabled. # If a key is specified here, encryption will be enabled (this script # does not support enabling/disabling encryption independently of key # values). Note that, although the wavelan supports up to four # different keys (but only one can be used at any one time), only one # key (key 1) is used here. # # Remember that all systems that talk to each other must use the same # key. # # See wicontrol(8) for valid key values. KEY= # # End of configuration variables. Nothing should have to be changed # past this point. # ### PATH="/usr/sbin:/usr/bin:/sbin:/bin:$PATH" if [ "X$STATION_NAME" != "X" ] then wicontrol -i $IFC -s "$STATION_NAME" fi wicontrol -i $IFC -p $MODE if [ "X$NETWORK_NAME" != "X" ] then wicontrol -i $IFC -n "$NETWORK_NAME" fi if [ "X$CHANNEL" != "X" ] then wicontrol -i $IFC -f $CHANNEL fi if [ ( "X$KEY" != "X" ) -a ( "X$KEY" != "XNO" ) -a ( "X$KEY" != "Xno" ) -a ( "X$KEY" != "XNo" ) ] then wicontrol -i $IFC -k $KEY wicontrol -i $IFC -e 1 fi exit 0 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Linux Vs. FreeBSD Networking Performance
great goobers of gahness. it's like comparing windows to any other operating system. I have never understood running Linux as a server based platform when FreeBSD and OpenBSD do it so much better. I'm pretty sure the only reason people even bothered with Linux to begin with was because it was new. Now they're doing it because it's "cool". I like FreeBSD. I despise Linux, the only flavor I can stand is Slackware. I won't use Linux because I don't believe in it as a server platform. If I wanted another desktop, I'd be running Windows. However, I have seen Linux do some amazing things (that FreeBSD can do a lot better). David Friedman runs a 38,000 client IRC server (twisted.ma.us.dal.net) on a 900MHz Thunderbird with 512MB of RAM. It also happens to be running Debian. The network is predominatly FreeBSD (in fact, the server application says FreeBSD only). When the network was in shambles, his machine took full load. Now he runs around 20,000 clients regularly. He's also got tsunami.ma.us.dal.net that's running a 600 coppermine on Debian. I know that twisted.* regularly swamps a T3. If you want to speak to him, you can find him on the network as "driz", I'm sure he'd like to shoot the shit with you. -Brian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: orinoco silver card
This is probably more appropriate to mobile than net, but I'll take a flyer. First, are you what version of FreeBSD are you using? Anything in this message is relevant to V4.x where x != 0. Try wicontrol. This should print out the configuration of the card. Make sure it's in BSS (not IBSS) mode. This is the most common problem. The file you included is not used automatically by FreeBSD. The author wrote the hooks into system startup. I just put the wicontrol commands into /etc/pccard.conf. card "Lucent Technologies" "WaveLAN/IEEE" config 0x1 "wi" ? insert /usr/sbin/wicontrol -i $device -p 1 insert /etc/pccard_ether $device start remove /etc/pccard_ether $device stop wicontrol must be run before running pccard_ether. Here is my wicontrol output for a working card talking to an RG-1000 (labeled as an Apple Airport). Note that port type must be 1 to talk to an access point. NIC serial number: [ 99UT11422042 ] Station name: [ FreeBSD WaveLAN/IEEE node ] SSID for IBSS creation: [ FreeBSD IBSS ] Current netname (SSID): [ X ] Desired netname (SSID): [ ] Current BSSID: [ 00:02:2d:0f:c9:35 ] Channel list: [ 2047 ] IBSS channel: [ 3 ] Current channel:[ 1 ] Comms quality/signal/noise: [ 34 87 53 ] Promiscuous mode: [ Off ] Port type (1=BSS, 3=ad-hoc):[ 1 ] MAC address:[ 00:60:1d:f0:37:3f ] TX rate (selection):[ 3 ] TX rate (actual speed): [ 11 ] RTS/CTS handshake threshold:[ 2347 ] Create IBSS:[ Off ] Access point density: [ 1 ] Power Mgmt (1=on, 0=off): [ 0 ] Max sleep time: [ 100 ] WEP encryption: [ Off ] TX encryption key: [ 1 ] Encryption keys:[ ][ ][ ][ ] R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 > From: "Satish Sambandham" <[EMAIL PROTECTED]> > Date: Sat, 24 Mar 2001 17:19:21 -0500 > Sender: [EMAIL PROTECTED] > > Ok, I found out that I cannot use a cardbus card for now, so trying to > figure out if I can use my orinoco siver 802.11b pcmcia card. This card > initiallizes fine, I see a power led, and makes a startup beep. Now I am > trying to figure out how to specify the encryption and other settings so it > can connect to the residential gateway access point (RG-1000). I read > somewhere to create the file listed below, change the approprite settings, > and then place it in /etc folder. Now my question is, how does this file > get called or run? I tried running it manually by ./setup-wi0, but it would > return an error message saying " sed: option requires an argument -- e" and > the name of my access point not found. I know my access point works since i > can see if fine under win2k. If anyone can point me to good directions or > know any solution, it would be greatly appreciated! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: SCTP code for FreeBSD
Garrett: > > One would assume that someone working for the manufacturer has access > to documentation. (Of course, Cisco being the empire that it is, it's > entirely possible for that not to be the case.) > Yes, I have plenty of documentation on hand to support all my changes... I have the internal PC4800 specification (the 4800 is the software base for the 340 and 350 series cards). The problem is I am not at liberty to give a copy of this to anyone, unless of course they have a cisco badge :/ ... if I did so I would be violating internal policy... So no, I can not supply the documentation as to why I changed things... I don't really care if my changes are adopted or not... it is FreeBSD that looses by not picking them up not I.. since my internal machines will always be using the driver that conforms to the hardware specifications... R -- Randall R. Stewart [EMAIL PROTECTED] or [EMAIL PROTECTED] 815-342-5222 (cell) 815-477-2127 (work) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: D-Link problem
>Well, you're on the right track. More than likely the D-Link card has some
>flags that aren't being properly set during the driver init.
>
>In the meantime, it would be best if you built a debug kernel and enabled
>crashdumps. This would give you (and us) more details on where (and why)
>this thing is crashing.
Okay, I've managed to get the debug kernel built and save the core file.
I'll include the output of some basic debugging below. If there's anything
else that would be helpful, let me know. The D-Link driver disk includes C
source for a Linux driver, so when the problem gets narrowed down, I or
someone more familiar with the code might be able to use this to determine
the correct settings.
First, though, I should have included this before, but I didn't notice it
until much later. Here's an excerpt from the boot messages that gets shown
before the crash. During a GENERIC boot:
pci0: (vendor=0x1186, dev=0x1300) at 11.0 irq 11
During my customized boot (I think this is right, but had to write it down
and type it in, so there may be minor errors) this turns into:
rl0: port 0xd800-0xd8ff
mem 0xe580-0xe58000ff irq 11 at device 11.0 on pci0
rl0: Ethernet address xx:xx:xx:xx:xx:xx
miibus0: on rl0
rlphy0: on miibus0
rlphy0: no media present
It then proceeds through the normal boot sequence to the crash. Here's the
gdb log I threatened above. Warning: it's long.
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd".
(kgdb) symbol-file /sys/compile/MARSA/kernel.debug
Reading symbols from /sys/compile/MARSA/kernel.debug...done.
(kgdb) exec-file /var/crash/kernel.2
(kgdb) core-file /var/crash/vmcore.2
IdlePTD 4661248
initial pcb at 3b56c0
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x8
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0458007
stack pointer = 0x10:0xc4110d1c
frame pointer = 0x10:0xc4110d28
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 56 (ifconfig)
interrupt mask = net tty
trap number = 12
panic: page fault
syncing disks... 11 11 4
done
Uptime: 3s
dumping to dev #ad/0x20001, offset 196608
dump ata0: resetting devices .. done
32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6
5 4 3 2 1
---
#0 dumpsys () at ../../kern/kern_shutdown.c:469
469 if (dumping++) {
(kgdb) bt
#0 dumpsys () at ../../kern/kern_shutdown.c:469
#1 0xc01a5aeb in boot (howto=256) at ../../kern/kern_shutdown.c:309
#2 0xc01a5e68 in poweroff_wait (junk=0xc037910f, howto=-1007868864)
at ../../kern/kern_shutdown.c:556
#3 0xc0314fb9 in trap_fatal (frame=0xc4110cdc, eva=8)
at ../../i386/i386/trap.c:951
#4 0xc0314c91 in trap_pfault (frame=0xc4110cdc, usermode=0, eva=8)
at ../../i386/i386/trap.c:844
#5 0xc031484b in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16,
tf_edi = -1061251648, tf_esi = 0, tf_ebp = -1005515480,
tf_isp = -1005515512, tf_ebx = -1061251712, tf_edx = -1061251648,
tf_ecx = 0, tf_eax = -1069187080, tf_trapno = 12, tf_err = 0,
tf_eip = -1069187065, tf_cs = 8, tf_eflags = 66178,
tf_esp = -1061251712, tf_ss = -1061251648}) at
../../i386/i386/trap.c:443
#6 0xc0458007 in ?? ()
#7 0xc01739b1 in mii_mediachg (mii=0xc0be95c0) at ../../dev/mii/mii.c:293
#8 0xc045061d in ?? ()
#9 0xc01e6fda in ether_ioctl (ifp=0xc0becc00, command=-2145359604,
data=0xc0c2cb80 "ÈËÂÀØËÂÀèËÂÀ") at ../../net/if_ethersubr.c:711
#10 0xc045073f in ?? ()
#11 0xc01f4afa in in_ifinit (ifp=0xc0becc00, ia=0xc0c2cb80, sin=0xc4110ebc,
scrub=0) at ../../netinet/in.c:660
#12 0xc01f4675 in in_control (so=0xc3ce6f00, cmd=2151704858,
data=0xc4110eac "rl0", ifp=0xc0becc00, p=0xc3ed2440)
at ../../netinet/in.c:412
#13 0xc01e6113 in ifioctl (so=0xc3ce6f00, cmd=2151704858,
data=0xc4110eac "rl0", p=0xc3ed2440) at ../../net/if.c:972
#14 0xc01b6bde in soo_ioctl (fp=0xc0c3fdc0, cmd=2151704858,
data=0xc4110eac "rl0", p=0xc3ed2440) at ../../kern/sys_socket.c:141
#15 0xc01b3c16 in ioctl (p=0xc3ed2440, uap=0xc4110f80) at
../../sys/file.h:174
#16 0xc0315265 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 0, tf_esi = -1077936720, tf_ebp = -1077936956,
tf_isp = -1005514796, tf_ebx = 134668824, tf_edx = 3,
tf_ecx = 134748144, tf_eax = 54, tf_trapno = 12, tf_err = 2,
tf_eip = 134529396, tf_cs = 31, tf_eflags = 663, tf_esp = -1077937096,
tf_ss = 47}) at
