Re: sendto() giving EPERM outside a jail

2007-03-22 Thread Daniel O'Connor 
On Thursday 22 March 2007 12:13, Julian Elischer wrote:
> > According to my reading of the man page it is not possible to get this
> > error unless I'm using jails (which I'm not). The code in question does..
>
> you can get it from the firewall too..


Ahah, I guess my firewall rules aren't doing exactly what I though because 
adding a specific rule to allow the packets worked.

Thanks!

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: sendto() giving EPERM outside a jail

2007-03-22 Thread Steve Watt 
In article <[EMAIL PROTECTED]>,
Daniel O'Connor <[EMAIL PROTECTED]> wrote:
>
>Hi,
>I am trying to port miniupnpd (http://miniupnp.tuxfamily.org/) and by in large 
>it seems to work fine (evil idea as it is :) However it spews out a lot of..
>miniupnpd[13010]: sendto(udp_notify): Operation not permitted
>
>According to my reading of the man page it is not possible to get this error 
>unless I'm using jails (which I'm not). The code in question does..
>
>memset(&sockname, 0, sizeof(struct sockaddr_in));
>sockname.sin_family = AF_INET;
>sockname.sin_port = htons(PORT);
>sockname.sin_addr.s_addr = inet_addr(UPNP_MCAST_ADDR);
>while(known_service_types[i])
>{
>snprintf(bufr, sizeof(bufr),
> "NOTIFY * HTTP/1.1\r\n"
>"HOST:%s:%d\r\n"
>...
>n = sendto(s, bufr, strlen(bufr), 0,
>(struct sockaddr *)&sockname, sizeof(struct sockaddr_in) );
>
>(line 278 of miniupnpd.c).
>
>Can someone shed light on what the problem is? The application appears to work 
>fine even with this error though.

man setsockopt, search for SO_BROADCAST.
-- 
Steve Watt KD6GGD  PP-ASEL-IA  ICBM: 121W 56' 57.5" / 37N 20' 15.3"
 Internet: steve @ Watt.COM  Whois: SW32-ARIN
   Free time?  There's no such thing.  It just comes in varying prices...
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

FreeBSD panics...

2007-03-22 Thread Sławomir Babiński SYSINFO 
Hello.

 

Can anyone look at this and sell any tips why my server panics?

 

[EMAIL PROTECTED]:/root# uname -a

FreeBSD mercury.msi.pl 6.2-STABLE FreeBSD 6.2-STABLE #7: Wed Mar 21 19:20:18
CET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/cobaltus  i386

 

[EMAIL PROTECTED]:/usr/obj/usr/src/sys/cobaltus# kgdb kernel.debug
/var/crash/vmcore.0 

kgdb: kvm_nlist(_stopped_cpus): 

kgdb: kvm_nlist(_stoppcbs): 

[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol "ps_pglobal_lookup"]

GNU gdb 6.1.1 [FreeBSD]

Copyright 2004 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-marcel-freebsd".

 

Unread portion of the kernel message buffer:

 

 

Fatal trap 12: page fault while in kernel mode

fault virtual address   = 0xc

fault code  = supervisor read, page not present

instruction pointer = 0x20:0xc0743318

stack pointer   = 0x28:0xe2d4d998

frame pointer   = 0x28:0xe2d4d9b0

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 = 13 (swi1: net)

trap number = 12

panic: page fault

Uptime: 1d1h9m6s

Dumping 1023 MB (2 chunks)

  chunk 0: 1MB (158 pages) ... ok

  chunk 1: 1023MB (261776 pages) 1007 991 975 959 943 927 911 895 879 863
847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559
543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255
239 223 207 191 175 159 143 127 111 95 79 63 47 31 15

 

#0  doadump () at pcpu.h:165

165 __asm __volatile("movl %%fs:0,%0" : "=r" (td));

(kgdb) backtrace

#0  doadump () at pcpu.h:165

#1  0xc0703942 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409

#2  0xc0703c76 in panic (fmt=0xc09c1368 "%s") at
/usr/src/sys/kern/kern_shutdown.c:565

#3  0xc09770cf in trap_fatal (frame=0xe2d4d958, eva=0) at
/usr/src/sys/i386/i386/trap.c:837

#4  0xc0976db4 in trap_pfault (frame=0xe2d4d958, usermode=0, eva=12) at
/usr/src/sys/i386/i386/trap.c:745

#5  0xc0976942 in trap (frame=

  {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = 1, tf_esi = 0, tf_ebp =
-489367120, tf_isp = -489367164, tf_ebx = 66, tf_edx = -989675834, tf_ecx =
0, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1066126568, tf_cs = 32,
tf_eflags = 590338, tf_esp = -996046656, tf_ss = -989675834}) at
/usr/src/sys/i386/i386/trap.c:435

#6  0xc09631ca in calltrap () at /usr/src/sys/i386/i386/exception.s:139

#7  0xc0743318 in m_copydata (m=0x0, off=0, len=1, cp=0xc502bf08
"essful\r\n257 \"/\" is the current directory\r\n250 CWó\f")

at /usr/src/sys/kern/uipc_mbuf.c:543

#8  0xc048d71d in ippr_ftp_process (fin=0xe2d4db30, nat=0xca66e400,
ftp=0xc502be00, rv=1) at ip_ftp_pxy.c:1192

#9  0xc048db2c in ippr_ftp_in (fin=0xe2d4db30, aps=0x0, nat=0xca66e400) at
ip_ftp_pxy.c:1358

#10 0xc0492dfb in appr_check (fin=0xe2d4db30, nat=0xca66e400) at
/usr/src/sys/contrib/ipfilter/netinet/ip_proxy.c:540

#11 0xc048a8af in fr_natin (fin=0xe2d4db30, nat=0xca66e400, natadd=1,
nflags=1)

at /usr/src/sys/contrib/ipfilter/netinet/ip_nat.c:4105

#12 0xc048a744 in fr_checknatin (fin=0xe2d4db30, passp=0xe2d4db2c) at
/usr/src/sys/contrib/ipfilter/netinet/ip_nat.c:4040

#13 0xc047c666 in fr_check (ip=0xc4a18820, hlen=20, ifp=0x0, out=0,
mp=0xe2d4dc18)

at /usr/src/sys/contrib/ipfilter/netinet/fil.c:2466

#14 0xc0481778 in fr_check_wrapper (arg=0x0, mp=0xc502bec6, ifp=0x0, dir=1)

at /usr/src/sys/contrib/ipfilter/netinet/ip_fil_freebsd.c:171

#15 0xc07932f7 in pfil_run_hooks (ph=0xc0ae6680, mp=0xe2d4dc6c,
ifp=0xc4524400, dir=1, inp=0x0) at /usr/src/sys/net/pfil.c:139

#16 0xc07cb6e6 in ip_input (m=0xc49f4e00) at
/usr/src/sys/netinet/ip_input.c:468

#17 0xc0791bc3 in netisr_processqueue (ni=0xc0ae57b8) at
/usr/src/sys/net/netisr.c:236

#18 0xc0791e10 in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:349

#19 0xc06e8b86 in ithread_execute_handlers (p=0xc43a3648, ie=0xc43ee180) at
/usr/src/sys/kern/kern_intr.c:682

#20 0xc06e8cc7 in ithread_loop (arg=0xc436b690) at
/usr/src/sys/kern/kern_intr.c:765

#21 0xc06e77bd in fork_exit (callout=0xc06e8c64 , arg=0x0,
frame=0x0) at /usr/src/sys/kern/kern_fork.c:821

#22 0xc096322c in fork_trampoline () at
/usr/src/sys/i386/i386/exception.s:208

(kgdb) where

#0  doadump () at pcpu.h:165

#1  0xc0703942 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409

#2  0xc0703c76 in panic (fmt=0xc09c1368 "%s") at
/usr/src/sys/kern/kern_shutdown.c:565

#3  0xc09770cf in trap_fatal (frame=0xe2d4d958, eva=0) at
/usr/src/sys/i386/i386/trap.c:837

#4  0xc0976db4 in trap_pfault (frame=0xe2d4d958, usermode=0, eva

mtx_unlock in kernel

2007-03-22 Thread xpeng 
If I want to use mtx_unlock for some threads, should I use mtx_lock() 
before?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: mtx_unlock in kernel

2007-03-22 Thread Pietro Cerutti 

On 3/23/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

If I want to use mtx_unlock for some threads, should I use mtx_lock()
before?


I admit, I don't understand your question, but anyway:
man 9 mutex

--
Pietro Cerutti

- ASCII Ribbon Campaign -
against HTML e-mail and
proprietary attachments
  www.asciiribbon.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"