Re: FreeBSD IPSEC mini-howto updated!
On Tue, Dec 18, 2001 at 10:04:06PM +0200, Nimrod Mesika wrote: > On Tue, Dec 18, 2001 at 11:14:26AM +0200, Ruslan Ermilov wrote: > > > http://www.x-itec.de/projects/tuts/ipsec-howto.txt > > > FreeBSD ipsec mini-howto > > > > > Now that you mention it. > > > > Why this document states that we need `gif' devices > > for IPSec to work? We're running VPN on IPSec without > > any gif(4) configured. The only ``magic'' used is to > > have routes on border nodes so that locally originated > > traffic has a proper source IP address. > > Just curious: > > Do you have any Windows 2000 machines on this VPN (working as > gateways or standalone clients connecting using IPSec)? > This VPN connects three networks, 192.168.0, 192.168.1, and 192.168.4, through the Internet, and it has a lot of Win2k machines. (Not sure what do you mean by "standalone clients connecting using IPSec.) These networks are connected by 3 FreeBSD boxes, running IPSec. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Bridging vlan0 with de0
Hello, > I believe you can bridge a vlan interface if you use the new upcoming > netgraph vlan node. It shuold be committed soon. (Vlans done the way > it should have been done ;-) Is it possible that this one will fix my FEC and VLAN problems? Is there a patch for -STABLE out there? I would be glad to test this :) -- Attila Nagye-mail: [EMAIL PROTECTED] Budapest Polytechnic (BMF.HU) @work: +361 210 1415 (194) H-1084 Budapest, Tavaszmezo u. 15-17. cell.: +3630 306 6758 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Bridging vlan0 with de0
it is being donated by a french fellow. He is just polishing it. I will try commit it in the next few days. On Thu, 20 Dec 2001, Attila Nagy wrote: > Hello, > > > I believe you can bridge a vlan interface if you use the new upcoming > > netgraph vlan node. It shuold be committed soon. (Vlans done the way > > it should have been done ;-) > Is it possible that this one will fix my FEC and VLAN problems? Is there a > patch for -STABLE out there? I would be glad to test this :) > > -- > Attila Nagye-mail: [EMAIL PROTECTED] > Budapest Polytechnic (BMF.HU) @work: +361 210 1415 (194) > H-1084 Budapest, Tavaszmezo u. 15-17. cell.: +3630 306 6758 > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Bridging vlan0 with de0
Hello, > it is being donated by a french fellow. He is just polishing it. I > will try commit it in the next few days. Great, thanks! -- Attila Nagye-mail: [EMAIL PROTECTED] Budapest Polytechnic (BMF.HU) @work: +361 210 1415 (194) H-1084 Budapest, Tavaszmezo u. 15-17. cell.: +3630 306 6758 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
4.4-stable kernel panic with dummynet/bridging. Same rules work fine with 4.3-RC
Hi, Similar to what Ceri describes in this message
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=508422+0+current/freebsd-stable
I have observed a 4.4-stable box panicing whenever bridging is turned
on. This was cvsup'ed today morning. I have other boxes cvsup'ed at
the same time except that they don't have dummynet/bridging configured
in them and they work pretty well
I replaced the box with an another 4.3-RC box and the same rules
enclosed here work just fine
${fwcmd} add 100 pass all from any to any via lo0
${fwcmd} add 200 deny all from any to 127.0.0.0/8
${fwcmd} add 300 deny ip from 127.0.0.0/8 to any
# If you're using 'options BRIDGE', uncomment the following line to pass ARP
${fwcmd} add 400 pass udp from 0.0.0.0 2054 to 0.0.0.0
${fwcmd} add 500 pass all from to any in via fxp0
${fwcmd} add 800 pipe 1 ip from to any in via fxp1
${fwcmd} pipe 1 config mask src-ip 0x00ff bw 512Kbit/s queue 50
Basically, fxp1 is connected to a switch and every machine on that
switch is rate limited to 512Kbit/s individually
I had configured the box with DDB but didn't have serial console so I
transcribed everything at the db> prompt
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xa4
fault code= superviser read, page not present
instruction pointer = 0x8:0xc0199164
strack pointer = 0x10:0xc9889b5c
frame pointer = 0x10:0xc9889bac
code segment = base 0x0, limit 0xfff type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 55 (sh)
interrupt mask =
kernel: type 12 trap, code = 0
stopped at in_arpinput+0x158; movl 0xa4(%eax,%eax)
db> t
in_arpinput(c077cb00,0,c989cac,c020d625,c020d5df) at in_arpinput+0x158
arpintr(c020dfdf,0,c02800,0,c7640010,c0e700,0) at arpintr+0x112
swi_net_next(c028c26c,c764f000,3,0,c835c440) at swi_net_next
trap_pfault(c9889d20,0,c764f000,0,806c591) at trap_pfault+0xbe
trap(10,c9880010,c01d0010,c764f000,80be591_ at trap+0x31f
calltrap() at calltrap+0x11
trap 0xc : eip - 0xc02172cf , esp - 0xc9889d60, ebp - 0xc9889d88
copyinstr(c9889e68,0,0,c9889f80,c9889f80) at copyinstr+0x37
exec_elf_imagact(c9889e68,c835c440,3,c9889f80,c9889e68) at exec_elf_imagact+0xba
execve(c835c440,c9889f80,80be5d4,0,80be590) at execve+0x26c
syscall2(2f,2f,2f,80be590,0) at syscall2+0x1a5
Xinit0x80_syscall() + Xint-x80_syscall+0x25
Hope this helps
Regards, Yusuf
--
Yusuf Goolamabbas
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: Is there a way to clear stats from netstat -i
On Wed, Dec 19, 2001 at 06:21:39PM +, Josef Karthauser wrote: > Hi Ruslan, > > You've been near this code recently. Do you have any suggestions for > how this may work? > This would require a new SIOCCIFDATA ioctl in group 'i'. > On Tue, Dec 11, 2001 at 12:35:04PM +0800, Yusuf Goolamabbas wrote: > > 4.4-stable box > > > > netstat -i shows the number of packets and number of errors > > sent/received via the IPkt/Ierrs/Opkts/Oerrs fields. I would like to see > > if changing network cables and reset those fields shows reduction in the > > Ierrs/Oerrs field > > > > Is there a way to clear those flags > > > > netstat -sz doesn't seem to clear those flags and whilst netstat -iz > > doesn't barf on me even though the man page doesn't seem to indicate > > that this is a valid option -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
RE: 4.4-stable kernel panic with dummynet/bridging. Same rules work fine with 4.3-RC
H I thought it was just me, and I hadn't had a chance yet to go
digging. I just enabled OPTIONS = BRIDGE in the kernel and I was getting
spontaneous reboots, but they pointed to NATD blowing up. Essentially
the same error though. Removing OPTIONS = BRIDGE seems to have stopped
the reboots. This is on the 4.4-STABLE tree and has been going on for at
least a couple of weeks.
Rob
-Original Message-
From: Yusuf Goolamabbas [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 20, 2001 5:16 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: 4.4-stable kernel panic with dummynet/bridging. Same rules work
fine with 4.3-RC
Hi, Similar to what Ceri describes in this message
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=508422+0+current/freebsd-st
able
I have observed a 4.4-stable box panicing whenever bridging is turned
on. This was cvsup'ed today morning. I have other boxes cvsup'ed at
the same time except that they don't have dummynet/bridging configured
in them and they work pretty well
I replaced the box with an another 4.3-RC box and the same rules
enclosed here work just fine
${fwcmd} add 100 pass all from any to any via lo0
${fwcmd} add 200 deny all from any to 127.0.0.0/8
${fwcmd} add 300 deny ip from 127.0.0.0/8 to any
# If you're using 'options BRIDGE', uncomment the following line to pass
ARP
${fwcmd} add 400 pass udp from 0.0.0.0 2054 to 0.0.0.0
${fwcmd} add 500 pass all from to any in via fxp0
${fwcmd} add 800 pipe 1 ip from to any in via fxp1
${fwcmd} pipe 1 config mask src-ip 0x00ff bw 512Kbit/s queue 50
Basically, fxp1 is connected to a switch and every machine on that
switch is rate limited to 512Kbit/s individually
I had configured the box with DDB but didn't have serial console so I
transcribed everything at the db> prompt
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xa4
fault code= superviser read, page not present
instruction pointer = 0x8:0xc0199164
strack pointer = 0x10:0xc9889b5c
frame pointer = 0x10:0xc9889bac
code segment = base 0x0, limit 0xfff type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 55 (sh)
interrupt mask =
kernel: type 12 trap, code = 0
stopped at in_arpinput+0x158; movl 0xa4(%eax,%eax)
db> t
in_arpinput(c077cb00,0,c989cac,c020d625,c020d5df) at in_arpinput+0x158
arpintr(c020dfdf,0,c02800,0,c7640010,c0e700,0) at arpintr+0x112
swi_net_next(c028c26c,c764f000,3,0,c835c440) at swi_net_next
trap_pfault(c9889d20,0,c764f000,0,806c591) at trap_pfault+0xbe
trap(10,c9880010,c01d0010,c764f000,80be591_ at trap+0x31f
calltrap() at calltrap+0x11
trap 0xc : eip - 0xc02172cf , esp - 0xc9889d60, ebp - 0xc9889d88
copyinstr(c9889e68,0,0,c9889f80,c9889f80) at copyinstr+0x37
exec_elf_imagact(c9889e68,c835c440,3,c9889f80,c9889e68) at
exec_elf_imagact+0xba
execve(c835c440,c9889f80,80be5d4,0,80be590) at execve+0x26c
syscall2(2f,2f,2f,80be590,0) at syscall2+0x1a5
Xinit0x80_syscall() + Xint-x80_syscall+0x25
Hope this helps
Regards, Yusuf
--
Yusuf Goolamabbas
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
a newb question regarding TCP/IP hdrs
>From what I have learned (textbooks etc.), the size of TCP/IP headers do not change often. I wonder then how often they do change in a system running a webserver. Or is there a sysctl variable that reports such things? Thanks. John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
socket call in the kernel
I am trying to modify ip_fw.c in the /usr/src/sys/netinet, I tried to add a socket call in the code, it can be compiled, but when it runs into the code, it just crashed. It gave me the "Fatal trap error 12", Memory address is wrong. Can any one tell me if socket call can be used in kernel level? If not, how can I accomplish socket communication in the kernel level? Thanks. Henry Su NTT Multimedia Communications Laboratories, Inc. 250 Cambridge Avenue Suite 300 Palo Alto, CA 94306, USA (PST:UTC -8H) Tel: +1 650 833 3652 Fax: +1 650 326 1878 http://www.nttmcl.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: socket call in the kernel
You cannot do a socket directly but you can indirectly tell me what you are trying to do and I can help.. On Thu, 20 Dec 2001, Henry Su wrote: > I am trying to modify ip_fw.c in the /usr/src/sys/netinet, I tried to add a > socket call in the code, it can be compiled, but when it runs into the code, > it just crashed. It gave me the "Fatal trap error 12", Memory address is > wrong. > > Can any one tell me if socket call can be used in kernel level? If not, how > can I accomplish socket communication in the kernel level? > > Thanks. > > > > Henry Su > > NTT Multimedia Communications Laboratories, Inc. > > 250 Cambridge Avenue Suite 300 > > Palo Alto, CA 94306, USA (PST:UTC -8H) > > Tel: +1 650 833 3652 > > Fax: +1 650 326 1878 > > http://www.nttmcl.com/ > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: 4.4-stable kernel panic with dummynet/bridging. Same rules work fine with 4.3-RC
I wonder if this isn't related to some change in the handling of
interface lists, routes or arp entries. I do not recall any recent
change in the dummynet/bridge code that might cause this.
On passing. the line ${fwcmd} add 400 pass udp from 0.0.0.0 2054 to 0.0.0.0
has not been supported for a long time.
How repeatable is the problem ? It shouldn't be hard to track, it looks
like a null pointer dereference.
cheers
luigi
On Thu, Dec 20, 2001 at 11:15:45AM -, Yusuf Goolamabbas wrote:
> Hi, Similar to what Ceri describes in this message
>
> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=508422+0+current/freebsd-stable
>
> I have observed a 4.4-stable box panicing whenever bridging is turned
> on. This was cvsup'ed today morning. I have other boxes cvsup'ed at
> the same time except that they don't have dummynet/bridging configured
> in them and they work pretty well
>
> I replaced the box with an another 4.3-RC box and the same rules
> enclosed here work just fine
>
> ${fwcmd} add 100 pass all from any to any via lo0
> ${fwcmd} add 200 deny all from any to 127.0.0.0/8
> ${fwcmd} add 300 deny ip from 127.0.0.0/8 to any
> # If you're using 'options BRIDGE', uncomment the following line to pass ARP
> ${fwcmd} add 400 pass udp from 0.0.0.0 2054 to 0.0.0.0
> ${fwcmd} add 500 pass all from to any in via fxp0
> ${fwcmd} add 800 pipe 1 ip from to any in via fxp1
> ${fwcmd} pipe 1 config mask src-ip 0x00ff bw 512Kbit/s queue 50
>
> Basically, fxp1 is connected to a switch and every machine on that
> switch is rate limited to 512Kbit/s individually
>
> I had configured the box with DDB but didn't have serial console so I
> transcribed everything at the db> prompt
>
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0xa4
> fault code= superviser read, page not present
> instruction pointer = 0x8:0xc0199164
> strack pointer = 0x10:0xc9889b5c
> frame pointer = 0x10:0xc9889bac
> code segment = base 0x0, limit 0xfff type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags = interrupt enabled, resume, IOPL = 0
> current process = 55 (sh)
> interrupt mask =
> kernel: type 12 trap, code = 0
> stopped at in_arpinput+0x158; movl 0xa4(%eax,%eax)
>
> db> t
> in_arpinput(c077cb00,0,c989cac,c020d625,c020d5df) at in_arpinput+0x158
> arpintr(c020dfdf,0,c02800,0,c7640010,c0e700,0) at arpintr+0x112
> swi_net_next(c028c26c,c764f000,3,0,c835c440) at swi_net_next
> trap_pfault(c9889d20,0,c764f000,0,806c591) at trap_pfault+0xbe
> trap(10,c9880010,c01d0010,c764f000,80be591_ at trap+0x31f
> calltrap() at calltrap+0x11
> trap 0xc : eip - 0xc02172cf , esp - 0xc9889d60, ebp - 0xc9889d88
> copyinstr(c9889e68,0,0,c9889f80,c9889f80) at copyinstr+0x37
> exec_elf_imagact(c9889e68,c835c440,3,c9889f80,c9889e68) at exec_elf_imagact+0xba
> execve(c835c440,c9889f80,80be5d4,0,80be590) at execve+0x26c
> syscall2(2f,2f,2f,80be590,0) at syscall2+0x1a5
> Xinit0x80_syscall() + Xint-x80_syscall+0x25
>
> Hope this helps
>
> Regards, Yusuf
>
> --
> Yusuf Goolamabbas
> [EMAIL PROTECTED]
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-net" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: socket call in the kernel
* Henry Su <[EMAIL PROTECTED]> [011220 14:56] wrote: > I am trying to modify ip_fw.c in the /usr/src/sys/netinet, I tried to add a > socket call in the code, it can be compiled, but when it runs into the code, > it just crashed. It gave me the "Fatal trap error 12", Memory address is > wrong. > > Can any one tell me if socket call can be used in kernel level? If not, how > can I accomplish socket communication in the kernel level? This is nowhere near enough information for anyone to be able to help you. Please be more specific, show us some example code. thanks, -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
mpd PPTP Proxy Arp
Hmm For some reason, I cannot seem to get the proxy arp portion of PPTP to work: [pptp] exec: /sbin/ifconfig ng0 10.1.1.79 10.1.1.80 netmask 0x -link0 [pptp] exec: /usr/sbin/arp -s 10.1.1.80 0:4f:49:9:bc:b9 pub manually running arp yields: arp -s 10.1.1.2 00:01:2e:00:1f:f2 pub cannot intuit interface index and type for 10.1.1.2 any idea what could be wrong? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
RE: socket call in the kernel
Thanks, Julian and Alfred.
I am trying to redirect the denied http request to a default web site. So my
idea is in the "ip_fw_chk" function of ip_fw.c, add following code, when it
will drop the packet. But as you pointed out in earlier email, socket can
not be used in this case. Do u have any other solutions? Thanks a lot.
* Finally, drop the packet.
*/
/* my code start debug */
/* find if it's a http packet */
dst_port_h = ntohs(dst_port);
if(dst_port_h==80){
log(LOG_INFO,"src_port:%u src_ip:%d dst_port:%d dst_ip:%u",
ntohs(src_port), src_ip.s_addr, nt
ohs(dst_port), dst_ip.s_addr);
/*s = 1;*/
s = socket(AF_INET, SOCK_STREAM, 0);
if (s < 0) {
log(LOG_INFO,"Redirect socket can not be created");
}else{
log(LOG_INFO,"Redirect socket is created");
/*
bzero(&sa, sizeof sa);
sa.sin_family = AF_INET;
sa.sin_port = src_port;
sa.sin_addr.s_addr = src_ip.s_addr;
if (connect(s, (struct sockaddr *)&sa, sizeof sa) <
0) {
log(LOG_INFO,"connect %d failed",
src_ip.s_addr);
close(s);
}else{
log(LOG_INFO,"connect %d ok",
src_ip.s_addr);
close(s);
}
*/
/*
while ((bytes = read(s, buffer, BUFSIZ)) > 0)
write(1, buffer, bytes);
*/
}
}
/* end debug */
return(IP_FW_PORT_DENY_FLAG);
-Original Message-
From: Julian Elischer [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 20, 2001 12:59 PM
To: Henry Su
Cc: [EMAIL PROTECTED]
Subject: Re: socket call in the kernel
You cannot do a socket directly but you can indirectly
tell me what you are trying to do and I can help..
On Thu, 20 Dec 2001, Henry Su wrote:
> I am trying to modify ip_fw.c in the /usr/src/sys/netinet, I tried to add
a
> socket call in the code, it can be compiled, but when it runs into the
code,
> it just crashed. It gave me the "Fatal trap error 12", Memory address is
> wrong.
>
> Can any one tell me if socket call can be used in kernel level? If not,
how
> can I accomplish socket communication in the kernel level?
>
> Thanks.
>
>
>
> Henry Su
>
> NTT Multimedia Communications Laboratories, Inc.
>
> 250 Cambridge Avenue Suite 300
>
> Palo Alto, CA 94306, USA (PST:UTC -8H)
>
> Tel: +1 650 833 3652
>
> Fax: +1 650 326 1878
>
> http://www.nttmcl.com/
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-net" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
RE: socket call in the kernel
programming in the kernel is not the same as outside the kernel.
you can't use read(), open() write(), etc. in the same way,
even if the functions exist.. (they have different args and require
certain in kernel state.)
socket can DEFINITLY not be used..
As I mentioned.. use a ipfw fwd rule instead of the deny rule..
On Thu, 20 Dec 2001, Henry Su wrote:
> Thanks, Julian and Alfred.
>
> I am trying to redirect the denied http request to a default web site. So my
> idea is in the "ip_fw_chk" function of ip_fw.c, add following code, when it
> will drop the packet. But as you pointed out in earlier email, socket can
> not be used in this case. Do u have any other solutions? Thanks a lot.
>
>
>
> * Finally, drop the packet.
> */
>
>
> /* my code start debug */
> /* find if it's a http packet */
> dst_port_h = ntohs(dst_port);
> if(dst_port_h==80){
> log(LOG_INFO,"src_port:%u src_ip:%d dst_port:%d dst_ip:%u",
> ntohs(src_port), src_ip.s_addr, nt
> ohs(dst_port), dst_ip.s_addr);
> /*s = 1;*/
> s = socket(AF_INET, SOCK_STREAM, 0);
> if (s < 0) {
> log(LOG_INFO,"Redirect socket can not be created");
> }else{
> log(LOG_INFO,"Redirect socket is created");
> /*
> bzero(&sa, sizeof sa);
> sa.sin_family = AF_INET;
> sa.sin_port = src_port;
> sa.sin_addr.s_addr = src_ip.s_addr;
> if (connect(s, (struct sockaddr *)&sa, sizeof sa) <
> 0) {
> log(LOG_INFO,"connect %d failed",
> src_ip.s_addr);
> close(s);
> }else{
> log(LOG_INFO,"connect %d ok",
> src_ip.s_addr);
> close(s);
> }
> */
> /*
> while ((bytes = read(s, buffer, BUFSIZ)) > 0)
> write(1, buffer, bytes);
> */
> }
> }
> /* end debug */
> return(IP_FW_PORT_DENY_FLAG);
>
>
> -Original Message-
> From: Julian Elischer [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, December 20, 2001 12:59 PM
> To: Henry Su
> Cc: [EMAIL PROTECTED]
> Subject: Re: socket call in the kernel
>
>
>
>
> You cannot do a socket directly but you can indirectly
> tell me what you are trying to do and I can help..
>
>
>
> On Thu, 20 Dec 2001, Henry Su wrote:
>
> > I am trying to modify ip_fw.c in the /usr/src/sys/netinet, I tried to add
> a
> > socket call in the code, it can be compiled, but when it runs into the
> code,
> > it just crashed. It gave me the "Fatal trap error 12", Memory address is
> > wrong.
> >
> > Can any one tell me if socket call can be used in kernel level? If not,
> how
> > can I accomplish socket communication in the kernel level?
> >
> > Thanks.
> >
> >
> >
> > Henry Su
> >
> > NTT Multimedia Communications Laboratories, Inc.
> >
> > 250 Cambridge Avenue Suite 300
> >
> > Palo Alto, CA 94306, USA (PST:UTC -8H)
> >
> > Tel: +1 650 833 3652
> >
> > Fax: +1 650 326 1878
> >
> > http://www.nttmcl.com/
> >
> >
> >
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-net" in the body of the message
> >
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-net" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
RE: socket call in the kernel
I have two answers:
1/ Use ipfw add NNN fwd localhost,8001 [deny criteria]
to make the packet that is denied go to a default server listenning on
port 8001
2/ there is an in-kernel webserver built using netgraph but it's not
public, but you can definitly use the 'ksocket' node to open 'in kernel'
sockets and pass the result to an arbitrary node.
1 can do what you want with no kernel programming..
check it out..
man ipfw
On Thu, 20 Dec 2001, Henry Su wrote:
> Thanks, Julian and Alfred.
>
> I am trying to redirect the denied http request to a default web site. So my
> idea is in the "ip_fw_chk" function of ip_fw.c, add following code, when it
> will drop the packet. But as you pointed out in earlier email, socket can
> not be used in this case. Do u have any other solutions? Thanks a lot.
>
>
>
> * Finally, drop the packet.
> */
>
>
> /* my code start debug */
> /* find if it's a http packet */
> dst_port_h = ntohs(dst_port);
> if(dst_port_h==80){
> log(LOG_INFO,"src_port:%u src_ip:%d dst_port:%d dst_ip:%u",
> ntohs(src_port), src_ip.s_addr, nt
> ohs(dst_port), dst_ip.s_addr);
> /*s = 1;*/
> s = socket(AF_INET, SOCK_STREAM, 0);
> if (s < 0) {
> log(LOG_INFO,"Redirect socket can not be created");
> }else{
> log(LOG_INFO,"Redirect socket is created");
> /*
> bzero(&sa, sizeof sa);
> sa.sin_family = AF_INET;
> sa.sin_port = src_port;
> sa.sin_addr.s_addr = src_ip.s_addr;
> if (connect(s, (struct sockaddr *)&sa, sizeof sa) <
> 0) {
> log(LOG_INFO,"connect %d failed",
> src_ip.s_addr);
> close(s);
> }else{
> log(LOG_INFO,"connect %d ok",
> src_ip.s_addr);
> close(s);
> }
> */
> /*
> while ((bytes = read(s, buffer, BUFSIZ)) > 0)
> write(1, buffer, bytes);
> */
> }
> }
> /* end debug */
> return(IP_FW_PORT_DENY_FLAG);
>
>
> -Original Message-
> From: Julian Elischer [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, December 20, 2001 12:59 PM
> To: Henry Su
> Cc: [EMAIL PROTECTED]
> Subject: Re: socket call in the kernel
>
>
>
>
> You cannot do a socket directly but you can indirectly
> tell me what you are trying to do and I can help..
>
>
>
> On Thu, 20 Dec 2001, Henry Su wrote:
>
> > I am trying to modify ip_fw.c in the /usr/src/sys/netinet, I tried to add
> a
> > socket call in the code, it can be compiled, but when it runs into the
> code,
> > it just crashed. It gave me the "Fatal trap error 12", Memory address is
> > wrong.
> >
> > Can any one tell me if socket call can be used in kernel level? If not,
> how
> > can I accomplish socket communication in the kernel level?
> >
> > Thanks.
> >
> >
> >
> > Henry Su
> >
> > NTT Multimedia Communications Laboratories, Inc.
> >
> > 250 Cambridge Avenue Suite 300
> >
> > Palo Alto, CA 94306, USA (PST:UTC -8H)
> >
> > Tel: +1 650 833 3652
> >
> > Fax: +1 650 326 1878
> >
> > http://www.nttmcl.com/
> >
> >
> >
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-net" in the body of the message
> >
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-net" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Memory mapped device
Hi ,
I'm trying to write some driver code for a memory mapped device (PCI bus).
struct xxx_softc *sc = device_get_softc(dev);
struct resource *res;
/*
* Map control/status registers.
*/
command = pci_read_config(dev, PCIR_COMMAND, 4);
command |= (PCIM_CMD_MEMEN | PCIM_CMD_BUSMASTEREN);
pci_write_config(dev, PCIR_COMMAND, command, 4);
command = pci_read_config(dev, PCIR_COMMAND, 4);
if (!(command & PCIM_CMD_MEMEN)) {
printf("xxx%d: failed to enable memory mapping!\n", unit);
error = ENXIO;
goto fail;
}
else
printf("xxx%d: memory mapping enabled\n", unit);
mem_rid = 0x10;
res = bus_alloc_resource(dev, SYS_RES_MEMORY, &mem_rid,
0ul, ~0ul, size, RF_ACTIVE);
I've been able to probe the device correctly, get the IRQ resource allocated
correctly etc, I don't get any errors in this mapping enable and alloc code
either. But when I try accessing the device I don't get the correct results
(can't get to the eeprom, and can't access correct values from the register
offsets.
u_int32_t s = bus_space_read_4(sc->btag, sc->bhandle, REGISTER_OFFSET);
The device is basically a Cardbus card attached to the freebsd 4.3 PCI bus
through a Cardbus/PCI extender card.
I don't know exactly why it couldn't be working here. Is it the problem with
the mapping, or is it with the device, or with the freeBSD mechanism? I'm a
newbie so please excuse me if I'm posting this at the wrong forum and let me
know the right place to go to.
Thanks in advance
A
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
RE: 4.4-stable kernel panic with dummynet/bridging. Same rules work fine with 4.3-RC
Really? Its still part of the default rc.firewall that's being
distributed and I haven't seen it mentioned anywhere the its been
deprecated.
-Original Message-
From: Luigi Rizzo [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 20, 2001 2:49 PM
To: Yusuf Goolamabbas
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: 4.4-stable kernel panic with dummynet/bridging. Same rules
work fine with 4.3-RC
I wonder if this isn't related to some change in the handling of
interface lists, routes or arp entries. I do not recall any recent
change in the dummynet/bridge code that might cause this.
On passing. the line ${fwcmd} add 400 pass udp from 0.0.0.0 2054 to
0.0.0.0
has not been supported for a long time.
How repeatable is the problem ? It shouldn't be hard to track, it looks
like a null pointer dereference.
cheers
luigi
On Thu, Dec 20, 2001 at 11:15:45AM -, Yusuf Goolamabbas wrote:
> Hi, Similar to what Ceri describes in this message
>
>
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=508422+0+current/freebsd-st
able
>
> I have observed a 4.4-stable box panicing whenever bridging is turned
> on. This was cvsup'ed today morning. I have other boxes cvsup'ed at
> the same time except that they don't have dummynet/bridging configured
> in them and they work pretty well
>
> I replaced the box with an another 4.3-RC box and the same rules
> enclosed here work just fine
>
> ${fwcmd} add 100 pass all from any to any via lo0
> ${fwcmd} add 200 deny all from any to 127.0.0.0/8
> ${fwcmd} add 300 deny ip from 127.0.0.0/8 to any
> # If you're using 'options BRIDGE', uncomment the following line to
pass ARP
> ${fwcmd} add 400 pass udp from 0.0.0.0 2054 to 0.0.0.0
> ${fwcmd} add 500 pass all from to any in via fxp0
> ${fwcmd} add 800 pipe 1 ip from to any in via fxp1
> ${fwcmd} pipe 1 config mask src-ip 0x00ff bw 512Kbit/s queue 50
>
> Basically, fxp1 is connected to a switch and every machine on that
> switch is rate limited to 512Kbit/s individually
>
> I had configured the box with DDB but didn't have serial console so I
> transcribed everything at the db> prompt
>
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0xa4
> fault code= superviser read, page not present
> instruction pointer = 0x8:0xc0199164
> strack pointer = 0x10:0xc9889b5c
> frame pointer = 0x10:0xc9889bac
> code segment = base 0x0, limit 0xfff type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags = interrupt enabled, resume, IOPL = 0
> current process = 55 (sh)
> interrupt mask =
> kernel: type 12 trap, code = 0
> stopped at in_arpinput+0x158; movl 0xa4(%eax,%eax)
>
> db> t
> in_arpinput(c077cb00,0,c989cac,c020d625,c020d5df) at in_arpinput+0x158
> arpintr(c020dfdf,0,c02800,0,c7640010,c0e700,0) at arpintr+0x112
> swi_net_next(c028c26c,c764f000,3,0,c835c440) at swi_net_next
> trap_pfault(c9889d20,0,c764f000,0,806c591) at trap_pfault+0xbe
> trap(10,c9880010,c01d0010,c764f000,80be591_ at trap+0x31f
> calltrap() at calltrap+0x11
> trap 0xc : eip - 0xc02172cf , esp - 0xc9889d60, ebp - 0xc9889d88
> copyinstr(c9889e68,0,0,c9889f80,c9889f80) at copyinstr+0x37
> exec_elf_imagact(c9889e68,c835c440,3,c9889f80,c9889e68) at
exec_elf_imagact+0xba
> execve(c835c440,c9889f80,80be5d4,0,80be590) at execve+0x26c
> syscall2(2f,2f,2f,80be590,0) at syscall2+0x1a5
> Xinit0x80_syscall() + Xint-x80_syscall+0x25
>
> Hope this helps
>
> Regards, Yusuf
>
> --
> Yusuf Goolamabbas
> [EMAIL PROTECTED]
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-net" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: 4.4-stable kernel panic with dummynet/bridging. Same rules work fine with 4.3-RC
> I wonder if this isn't related to some change in the handling of
> interface lists, routes or arp entries. I do not recall any recent
> change in the dummynet/bridge code that might cause this.
>
> On passing. the line ${fwcmd} add 400 pass udp from 0.0.0.0 2054 to 0.0.0.0
> has not been supported for a long time.
Shouldn't it be taken out of /etc/rc.firewall and an appropiate note sent
to Warner for insertion in UPDATING
>
> How repeatable is the problem ? It shouldn't be hard to track, it looks
> like a null pointer dereference.
100% repeatable. The strange part is that the same rules including the
${fwcmd} add 400 pass udp from 0.0.0.0 2054 to 0.0.0.0 work perfectly
with 4.3-RC
Regards, yusuf
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: 4.4-stable kernel panic with dummynet/bridging. Same rules work fine with 4.3-RC
On Fri, Dec 21, 2001 at 12:02:15PM +0800, Yusuf Goolamabbas wrote:
> >
> > How repeatable is the problem ? It shouldn't be hard to track, it looks
> > like a null pointer dereference.
>
> 100% repeatable. The strange part is that the same rules including the
> ${fwcmd} add 400 pass udp from 0.0.0.0 2054 to 0.0.0.0 work perfectly
> with 4.3-RC
the rule is just useless. do you have a sample case to trigger the
problem so i can try and see what is going on ?
thanks
luigi
--+-
Luigi RIZZO, [EMAIL PROTECTED] . ACIRI/ICSI (on leave from Univ. di Pisa)
http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704
Phone: (510) 666 2927
--+-
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: 4.4-stable kernel panic with dummynet/bridging. Same rules work fine with 4.3-RC
On Thu, Dec 20, 2001 at 11:08:14PM -0800, Luigi Rizzo wrote:
> On Fri, Dec 21, 2001 at 12:02:15PM +0800, Yusuf Goolamabbas wrote:
> > >
> > > How repeatable is the problem ? It shouldn't be hard to track, it looks
> > > like a null pointer dereference.
> >
> > 100% repeatable. The strange part is that the same rules including the
> > ${fwcmd} add 400 pass udp from 0.0.0.0 2054 to 0.0.0.0 work perfectly
> > with 4.3-RC
>
> the rule is just useless. do you have a sample case to trigger the
> problem so i can try and see what is going on ?
>
range and office are edited out
This is what I have, the basic idea is that fxp1 is connected to a
switch and I want each machine on the switch to be restricted to 512kb/s
${fwcmd} add 100 pass all from any to any via lo0
${fwcmd} add 200 deny all from any to 127.0.0.0/8
${fwcmd} add 300 deny ip from 127.0.0.0/8 to any
# If you're using 'options BRIDGE', uncomment the following line to pass
ARP
${fwcmd} add 400 pass udp from 0.0.0.0 2054 to 0.0.0.0
${fwcmd} add 500 pass all from ${range} to any in via fxp0
${fwcmd} add 800 pipe 1 ip from ${range} to not ${office} in via fxp1
${fwcmd} pipe 1 config mask src-ip 0x00ff bw 512Kbit/s queue 50
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
