Re: pxeboot and serial console

2006-01-11 Thread Danny Braniss
 On Tuesday 10 January 2006 09:11 am, Danny Braniss wrote:
  I can't tell when this broke, but compiling pxeboot with
  BOOT_PXELDR_PROBE_KEYBOARD set would redirect the console to the serial
  port if no keyboard was detected. This no longer works, which explains
  the problems i had with the serial port on my intel 1U servers.
 
  the relevant code is in /sys/boot/i386/pxeldr/pxeldr.S.
 
  compiling with BOOT_PXELDR_ALWAYS_SERIAL works as expected, so IMHO
  the test:
  testb $KEYBOARD_BIT, MEM_BIOS_KEYBOARD # keyboard present?
  is failing, but i have no idea why
 
  any ideas?
 
 USB keyboards?  Actually, it sounds in your case as if the BIOS is always 
 claiming a keyboard is present. Perhaps your BIOS is just being lame, but 
 that single test isn't the greatest test to use either.

2 words: Power Cycle
This will guarantee that the bios will/won't detect the keyboard.
all is ok now.



___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


rescheduling tasks using swi_add()

2006-01-11 Thread kamal kc
dear everybody,

i had previous thread going on about the cpu load 
average. and had some discussion regarding it. i have 
a newer thing to discuss on so i started this thread.

as i mentioned earlier i had put some code in the
bridge.c
that performed compression which took a long time and
hence 
i got a high number of interface interrupts (irq22: xl
interrupts).

so i thought of rescheduling the compression tasks
without 
blocking the bridge function. i found this function
swi_add() 
which i could use to add software interrupt handlers
that 
could be run at a later time without causing high
interface 
interrupts.

the man page discussed the swi_add() and swi_sched()
functions.

what i don't understand is, how do i register my
handler 
function ??
if i use the swi_add() for that purpose what 
do i use for the void *arg argument.
 
and how can i dispatch control to the software
interrupt handler ??
the swi_sched() uses only the cookie and the flags
arguments. 
there is no way i can pass arguments to my handler
function ..

i guess most of you are familiar with this and can
help me 
out ..



thanks, 

kamal







 
 



__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: rescheduling tasks using swi_add()

2006-01-11 Thread rookie
2006/1/11, kamal kc [EMAIL PROTECTED]:

 dear everybody,

 i had previous thread going on about the cpu load
 average. and had some discussion regarding it. i have
 a newer thing to discuss on so i started this thread.

 as i mentioned earlier i had put some code in the
 bridge.c
 that performed compression which took a long time and
 hence
 i got a high number of interface interrupts (irq22: xl
 interrupts).

 so i thought of rescheduling the compression tasks
 without
 blocking the bridge function. i found this function
 swi_add()

[snip]

swi_* are used to rule interrupt threads but as you're speaking it
doesn't seem you're in this case. In order to force a preemption you
might use mi_switch(9) which causes a machine-independent context
switch for curthread.

cheers,
Attilio

--
Peace can only be achieved by understanding - A. Einstein
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Ricoh PCI to SD device?

2006-01-11 Thread Andrew Gordon

On Tue, 10 Jan 2006, M. Warner Losh wrote:

 Are you sure they provide technical documentation sufficent to write
 the driver?  The last time I asked, I got a nice document that said
 that it implemented the sds standard sd host interface, but didn't
 document what that was.  TI and winbond chips datasheets are the same
 way.  Prove me wrong.  I'd love it :-)

Have you seen this datasheet from TI?

http://focus.ti.com/docs/apps/catalog/resources/appnoteabstract.jhtml?abstractName=sprue30

It's not the one you are looking for, but it does at least give
register-level documentation on the implementation in that particular
chip, and TI devices tend to share peripherals.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: rescheduling tasks using swi_add()

2006-01-11 Thread John Baldwin
On Wednesday 11 January 2006 07:13 am, kamal kc wrote:
 dear everybody,

 i had previous thread going on about the cpu load
 average. and had some discussion regarding it. i have
 a newer thing to discuss on so i started this thread.

 as i mentioned earlier i had put some code in the
 bridge.c
 that performed compression which took a long time and
 hence
 i got a high number of interface interrupts (irq22: xl
 interrupts).

 so i thought of rescheduling the compression tasks
 without
 blocking the bridge function. i found this function
 swi_add()
 which i could use to add software interrupt handlers
 that
 could be run at a later time without causing high
 interface
 interrupts.

 the man page discussed the swi_add() and swi_sched()
 functions.

 what i don't understand is, how do i register my
 handler
 function ??
 if i use the swi_add() for that purpose what
 do i use for the void *arg argument.

 and how can i dispatch control to the software
 interrupt handler ??
 the swi_sched() uses only the cookie and the flags
 arguments.
 there is no way i can pass arguments to my handler
 function ..

 i guess most of you are familiar with this and can
 help me
 out ..

Queue a task to a taskqueue.  Behind the scenes that will invoke a swi_add if 
you use the taskqueue_swi queue.  However, given that you want to do some 
rather complicated work, you'd be better off creating a dedicated taskqueue 
thread and queueing tasks off to it I think.

-- 
John Baldwin [EMAIL PROTECTED]    http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve  =  http://www.FreeBSD.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: devfs

2006-01-11 Thread Robert Watson


On Tue, 3 Jan 2006, TSaplin Mikhail wrote:


Hi all i have a problem with devfs device hiding.
My system is FreeBSD 6.0 (i386 and amd64, compiled from last sunday source
(RELENG_6))

After mounting defs:
#mount -t devfs devfs /tmp/proba

first devfs command:
# devfs -m /tmp/proba rule add type disk hide
devfs rule: ioctl DEVFSIO_RADD: Input/output error

the second command hangs:
# devfs -m /tmp/proba rule add type disk hide

command doesnt responds on HUP and TERM signals


A week or two ago I fixed a bug in devfs where an error condition results in a 
lock leak, followed by hanging processes and a deadlock.  I merged the change 
to RELENG_6 this morning having returned from India yesterday night.  If a 
fair number of people are running into this, we may want to merge it to 
RELENG_6_0 and do an errata announcement for it.  The change you want is this 
one:


  revision 1.21
  date: 2006/01/03 09:49:10;  author: rwatson;  state: Exp;  lines: +4 -2
  When returning EIO from DEVFSIO_RADD ioctl, drop the exclusive rule
  lock.  Otherwise the system comes to a rather sudden and grinding
  halt.

  MFC after:  1 week

I ran into it while on travel, as I was trying to get devfs to make /dev/bpf* 
readable by the operator group, and typed the command wrong.  The RELENG_6 
revision is devfs_rule.c:1.14.2.3.


Robert N M Watson
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: setfacl file modification time

2006-01-11 Thread Robert Watson


On Thu, 5 Jan 2006, Ceri Davies wrote:


On 5 Jan 2006, at 18:43, Ahnjoan Amous wrote:


In 5.2.1-RELEASE, setfacl updates the modification time of the file
when acls are changed.  I haven't been able to find any complaints
about this behavior, is this something folks on the list would expect
when using setfacl?  If so, does anyone know a work around?


PR 76818 is open for this issue, but there is no progress logged at present.


This likely occurs because EA writes modify the last modification timestamp. 
I can imagine a couple of possible avenues to explore in fixing it, including:


(1) Make system name space EA writes not update the modification time.

(2) Add a flag to allow EA writes to be marked as not updating the
modification time.

It could be POSIX.1e has something to say about time stamp modifications for 
setfacl; personally I'd expect it to match the behavior of chmod.  And I 
believe chmod doesn't update the time stamp.


Robert N M Watson
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: rescheduling tasks using swi_add()

2006-01-11 Thread kamal kc


--- John Baldwin [EMAIL PROTECTED] wrote:

 
  the man page discussed the swi_add() and
 swi_sched()
  functions.
 
  what i don't understand is, how do i register my
  handler
  function ??
  if i use the swi_add() for that purpose what
  do i use for the void *arg argument.
 
  and how can i dispatch control to the software
  interrupt handler ??
  the swi_sched() uses only the cookie and the flags
  arguments.
  there is no way i can pass arguments to my handler
  function ..
 
  i guess most of you are familiar with this and can
  help me
  out ..
 
 Queue a task to a taskqueue.  Behind the scenes that
 will invoke a swi_add if 
 you use the taskqueue_swi queue.  However, given
 that you want to do some 
 rather complicated work, you'd be better off
 creating a dedicated taskqueue 
 thread and queueing tasks off to it I think.

thanks for the suggestion on the taskqueue. i tried it

on a dummy kernel module and got some output, but i 
don't know if they were correct or not. i would like
to know
if i followed the right steps. here is the code i 
used ::


struct taskqueue_arguments
{ int a;
  int b;
};

void taskqueue_function(void *,int);
typedef void taskqueue_function_t(void *,int);

/* taskqueue function */
void taskqueue_function(void *arguments,int int_arg)
{
   struct taskqueue_arguments *arg;
   arg=(struct taskqueue_arguments *)arguments;
   printf(\ntakqueue_function was called the args are
%d 
%d,arg-a,arg-b);
return;
}











__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: rescheduling tasks using swi_add()

2006-01-11 Thread kamal kc


--- John Baldwin [EMAIL PROTECTED] wrote:

  the man page discussed the swi_add() and
 swi_sched()
  functions.
 
  what i don't understand is, how do i register my
  handler
  function ??
  if i use the swi_add() for that purpose what
  do i use for the void *arg argument.
 
  and how can i dispatch control to the software
  interrupt handler ??
  the swi_sched() uses only the cookie and the flags
  arguments.
  there is no way i can pass arguments to my handler
  function ..
 
  i guess most of you are familiar with this and can
  help me
  out ..
 
 Queue a task to a taskqueue.  Behind the scenes that
 will invoke a swi_add if 
 you use the taskqueue_swi queue.  However, given
 that you want to do some 
 rather complicated work, you'd be better off
 creating a dedicated taskqueue 
 thread and queueing tasks off to it I think.
 

thanks for the suggestion on the taskqueue. i tried it

on my dummy kernel module and got some output but i 
am not sure if i followed the correct steps to 
use the taskqueue. the only thing i found 
was the man pages and the taskqueue.h.

here is the code:
---

struct taskqueue_arguments
{ int a;
  int b;
};

void taskqueue_function(void *,int);
typedef void taskqueue_function_t(void *,int);

/* taskqueue function */
void taskqueue_function(void *arguments,int int_arg)
{
struct taskqueue_arguments *arg;
arg=(struct taskqueue_arguments *)arguments;
printf(\ntakqueue_function was called the args
are %d %d,arg-a,arg-b);
return;
}


/* function implementing the syscall */
static int
hello(struct thread *td, void *arg)
{.
struct task mytask; 
taskqueue_function_t *taskqueue_function_ptr;
taskqueue_function_ptr=taskqueue_function; 

struct taskqueue_arguments arg_var;
arg_var.a=10;
arg_var.b=20;

   
TASK_INIT(mytask,50,taskqueue_function_ptr,arg_var);
taskqueue_enqueue(taskqueue_swi, mytask);

...
} 

did i do it correctly ???

thanks,

kamal






__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


RE: Ricoh PCI to SD device?

2006-01-11 Thread Darren Pilgrim
From: M. Warner Losh [mailto:[EMAIL PROTECTED] 
 In message: [EMAIL PROTECTED]
 Darren Pilgrim [EMAIL PROTECTED] writes:
 : From: Brooks Davis
 :  On Mon, Jan 09, 2006 at 11:12:30AM -0500, David Gilbert wrote:
 :   Has anyone had a look at the following:
 :  
 : [ Ricoh SD Bus Host Adapter, PCI ID 0x08221180 ]
 :  
 :  People are looking at it, but there are no docs available.
 :  Apparently, there is some work being done to reverse engineer
 :  it.  Linux doesn't support it either.
 : 
 : That's odd, because Ricoh provides technical documentation upon
 : request via the LSI Contact Us[1] page on their website.
 : 
 : 1: http://www.ricoh.com/LSI/mail.html
 
 Are you sure they provide technical documentation sufficent to write
 the driver?  The last time I asked, I got a nice document that said
 that it implemented the sds standard sd host interface, but didn't
 document what that was.  TI and winbond chips datasheets are the same
 way.  Prove me wrong.  I'd love it :-)

The SD protocols aren't open standards.  Ricoh can't legally include
information about the protocols in their documentation.  Without working
implementation of the SDA's standards, FreeBSD is stuck.  I don't blame the
funding behind FreeBSD development for not ponying up the dosh; I think such
fees are extortion made legal by intellectual property laws.

But hey, it's the business.  It's not like we're trying to make a good, free
product everyone can use, right?


___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Ricoh PCI to SD device?

2006-01-11 Thread Warner Losh
From: Darren Pilgrim [EMAIL PROTECTED]
Subject: RE: Ricoh PCI to SD device?
Date: Wed, 11 Jan 2006 10:32:16 -0800

 From: M. Warner Losh [mailto:[EMAIL PROTECTED] 
  In message: [EMAIL PROTECTED]
  Darren Pilgrim [EMAIL PROTECTED] writes:
  : From: Brooks Davis
  :  On Mon, Jan 09, 2006 at 11:12:30AM -0500, David Gilbert wrote:
  :   Has anyone had a look at the following:
  :  
  : [ Ricoh SD Bus Host Adapter, PCI ID 0x08221180 ]
  :  
  :  People are looking at it, but there are no docs available.
  :  Apparently, there is some work being done to reverse engineer
  :  it.  Linux doesn't support it either.
  : 
  : That's odd, because Ricoh provides technical documentation upon
  : request via the LSI Contact Us[1] page on their website.
  : 
  : 1: http://www.ricoh.com/LSI/mail.html
  
  Are you sure they provide technical documentation sufficent to write
  the driver?  The last time I asked, I got a nice document that said
  that it implemented the sds standard sd host interface, but didn't
  document what that was.  TI and winbond chips datasheets are the same
  way.  Prove me wrong.  I'd love it :-)
 
 The SD protocols aren't open standards.  Ricoh can't legally include
 information about the protocols in their documentation.  Without working
 implementation of the SDA's standards, FreeBSD is stuck.  I don't blame the
 funding behind FreeBSD development for not ponying up the dosh; I think such
 fees are extortion made legal by intellectual property laws.

The SD protocols are protected by trade secret means.  Some of the
protocol has leaked out, and can easily be implemented, once someone
knows how to send the protocol to the devices on the bus.  There may
be some patent issues with the DRM control that's in the SD parts that
may be problematic.  There's no way to know all the issues because of
the NDAs.

The SDA Standard SD Host Interface is covered, as far as the basics
go, should be reverse engineerable.  There's enough data floating out
there which should help those trying to engineer it.  I don't think
I'll be doing it, however.

Warner
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Telling BSD to stop resetting the connection!

2006-01-11 Thread Dan Joumaa

Hello,

I'm trying to code a software gateway with divert sockets. So far basic 
things are working, but the net stack constantly resets the connection 
whenever a SYN-ACK is sent to it.


103   9.443254  192.168.1.6 - 205.166.76.40 TCP pacmand  https [SYN] 
Seq=0 Ack=0 Win=2920 Len=0 MSS=536
104   9.443364  192.168.1.2 - 205.166.76.40 TCP pacmand  https [SYN] 
Seq=0 Ack=0 Win=2920 Len=0 MSS=536
105   9.443617  192.168.1.6 - 205.166.76.40 TCP pacmand  https [SYN] 
Seq=0 Ack=0 Win=2920 Len=0 MSS=536
106   9.443654  192.168.1.2 - 205.166.76.40 TCP pacmand  https [SYN] 
Seq=0 Ack=0 Win=2920 Len=0 MSS=536
107   9.496102 205.166.76.40 - 192.168.1.2  TCP https  pacmand [SYN, 
ACK] Seq=0 Ack=1 Win=1608 Len=0 MSS=1460
108   9.496185  192.168.1.2 - 205.166.76.40 TCP pacmand  https [RST] 
Seq=1 Ack=341266652 Win=0 Len=0


(192.168.1.1 = next hop, 192.168.1.2 = this computer, 192.168.1.6 = the 
client)


Any ideas on how to stop the net stack from resetting my connections, 
preferably programmatically?


--ness

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Telling BSD to stop resetting the connection!

2006-01-11 Thread Julian Elischer

Dan Joumaa wrote:


Hello,

I'm trying to code a software gateway with divert sockets. So far 
basic things are working, but the net stack constantly resets the 
connection whenever a SYN-ACK is sent to it.


103   9.443254  192.168.1.6 - 205.166.76.40 TCP pacmand  https [SYN] 
Seq=0 Ack=0 Win=2920 Len=0 MSS=536
104   9.443364  192.168.1.2 - 205.166.76.40 TCP pacmand  https [SYN] 
Seq=0 Ack=0 Win=2920 Len=0 MSS=536
105   9.443617  192.168.1.6 - 205.166.76.40 TCP pacmand  https [SYN] 
Seq=0 Ack=0 Win=2920 Len=0 MSS=536
106   9.443654  192.168.1.2 - 205.166.76.40 TCP pacmand  https [SYN] 
Seq=0 Ack=0 Win=2920 Len=0 MSS=536
107   9.496102 205.166.76.40 - 192.168.1.2  TCP https  pacmand [SYN, 
ACK] Seq=0 Ack=1 Win=1608 Len=0 MSS=1460
108   9.496185  192.168.1.2 - 205.166.76.40 TCP pacmand  https [RST] 
Seq=1 Ack=341266652 Win=0 Len=0


(192.168.1.1 = next hop, 192.168.1.2 = this computer, 192.168.1.6 = 
the client)



sounds like the SYN ACK is not getting diverted?



Any ideas on how to stop the net stack from resetting my connections, 
preferably programmatically?


--ness

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to 
[EMAIL PROTECTED]


___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Telling BSD to stop resetting the connection!

2006-01-11 Thread David S. Madole

From: Dan Joumaa [EMAIL PROTECTED]


I'm trying to code a software gateway with divert sockets. So far basic 
things are working, but the net stack constantly resets the connection 
whenever a SYN-ACK is sent to it.


Any ideas on how to stop the net stack from resetting my connections, 
preferably programmatically?


I think you are doing something wrong, either not diverting packets that 
should be, or reinjecting packets from your code that are incorrect in 
some way.


Without seeing the ipfw rules or code, there's not much else that can be 
said.


David

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Telling BSD to stop resetting the connection!

2006-01-11 Thread Dan Joumaa


On Jan 11, 2006, at 7:24 PM, David S. Madole wrote:


From: Dan Joumaa [EMAIL PROTECTED]


I'm trying to code a software gateway with divert sockets. So far 
basic things are working, but the net stack constantly resets the 
connection whenever a SYN-ACK is sent to it.


Any ideas on how to stop the net stack from resetting my connections, 
preferably programmatically?


I think you are doing something wrong, either not diverting packets 
that should be, or reinjecting packets from your code that are 
incorrect in some way.


Without seeing the ipfw rules or code, there's not much else that can 
be said.


David




Here's the rules:

1 divert 4747 tcp from 192.168.1.6 to any in
1 divert 4747 udp from 192.168.1.6 to any in

The following rules are added dynamically when my client sends a packet 
to a server so we can get it back on the divert socket. In this case, 
it would be:


1 divert 4747 tcp from 205.166.76.216 to any in
1 divert 4747 udp from 205.166.76.216 to any in

First thing, I receive the packets from the divert socket.

...
if( (datagramlen = recvfrom( sock-ipfd, buffer, buflen, 0x0,
 (struct sockaddr *)sin, sinlen ))  
0 )

(void)fprintf( stderr, Failed to receive packet. Error: %i\n,
   errno );
...

If it is from my client, I add the destination host the client wants to 
talk to as a divert rule to the IPFW...


entry-version = IP_FW_CURRENT_API_VERSION;
entry-fw_number = 1;
entry-fw_src.s_addr = htonl(host);
entry-fw_smsk.s_addr = ~0;
entry-fw_prot = IPPROTO_TCP;
entry-fw_flg = IP_FW_F_DIVERT|IP_FW_F_IN;
entry-fw_un.fu_divert_port = DIVERTSOCKET_PORT;
(void)memcpy( entry-fw_in_if.fu_via_if.name, sock-dev, FW_IFNLEN );
entry-fw_in_if.fu_via_if.unit = -1;
if( setsockopt( sock-fwfd, IPPROTO_IP, IP_FW_ADD, entry,
sizeof(struct ip_fw) )  0 ) {
(void)fprintf( stderr, Failed to add entry to filter. Error: 
%i\n,

   errno );
return (-1);
}

... modify the packet for sending ...

ip_hdr-ip_src.s_addr = htonl( thisIP );
/* checksuming code below */

... and send it through a raw socket.

sin.sin_family = AF_INET;
sin.sin_port = 0;
sin.sin_addr.s_addr = ip_hdr-ip_dst.s_addr;
if( (datagramlen = sendto( socket-fwfd, buffer, buflen, 0x0,
   (struct sockaddr *)sin, sizeof(sin) )) 
 0 )
(void)fprintf( stderr, Failed to send packet. Error: %i\n, 
errno );


If it's from someone outside the LAN, modify it for forwarding to the 
client...


ip_hdr-ip_dst.s_addr = htonl( clientIP );

ip_hdr-ip_sum = 0;
ip_hdr-ip_sum = htons( in_cksum( (u_short *)ip_hdr,

  sizeof(struct iphdr) ) );
/* checksuming code below */

And send it through a raw socket.

All in all, that's really what it is. This seems to work with normal 
HTTP requests, but fails to work with establishing a connection on 
HTTPS. :/


--ness

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Telling BSD to stop resetting the connection!

2006-01-11 Thread David S. Madole

From: Dan Joumaa [EMAIL PROTECTED]


103   9.443254  192.168.1.6 - 205.166.76.40 TCP pacmand  https [SYN]
Seq=0 Ack=0 Win=2920 Len=0 MSS=536
104   9.443364  192.168.1.2 - 205.166.76.40 TCP pacmand  https [SYN]
Seq=0 Ack=0 Win=2920 Len=0 MSS=536
105   9.443617  192.168.1.6 - 205.166.76.40 TCP pacmand  https [SYN]
Seq=0 Ack=0 Win=2920 Len=0 MSS=536
106   9.443654  192.168.1.2 - 205.166.76.40 TCP pacmand  https [SYN]
Seq=0 Ack=0 Win=2920 Len=0 MSS=536
107   9.496102 205.166.76.40 - 192.168.1.2  TCP https  pacmand [SYN,
ACK] Seq=0 Ack=1 Win=1608 Len=0 MSS=1460
108   9.496185  192.168.1.2 - 205.166.76.40 TCP pacmand  https [RST]
Seq=1 Ack=341266652 Win=0 Len=0

(192.168.1.1 = next hop, 192.168.1.2 = this computer, 192.168.1.6 =
the client)

Here's the rules:

1 divert 4747 tcp from 192.168.1.6 to any in
1 divert 4747 udp from 192.168.1.6 to any in

The following rules are added dynamically when my client sends a packet 
to a server so we can get it back on the divert socket. In this case, 
it would be:


That seems like a maybe dicey strategy to me. Seems like it wouldn't 
scale well and could be subject to some race conditions. Why not just 
divert all packets (or all TCP and UDP) and sift them in your program for 
what's interesting? Or use a rule based on a destination of 192.168.1.6?



1 divert 4747 tcp from 205.166.76.216 to any in
1 divert 4747 udp from 205.166.76.216 to any in


Ok, so why shouldn't the machine send a RST when the SYN,ACK is received?

It sounds like you are sending a synthesized SYN packet (one the OS 
didn't generate) with the source address of your machine (192.168.1.2), 
which the other end responds correctly to with a SYN,ACK which is getting 
delivered to the OS since you have no divert rule for 192.168.1.2. Since 
the OS didn't send the SYN and knows nothing of the connection, it sends 
a RST. Perfectly normal.



... modify the packet for sending ...
... and send it through a raw socket.


I find it more convenient when working with divert sockets to send 
packets through the divert socket itself. It lets you control where it 
reenters the rule chain, which direction it is travelling, which 
interface, etc. Just an idea.


If it's from someone outside the LAN, modify it for forwarding to the 
client...


I don't have any idea what you are trying to accomplish but am having a 
hard time imagining any situation where it would be useful to send the 
same packet out twice to two different destinations.


I don't know that it will help much, but if you are interested in an 
example of another program working through divert sockets, you can take a 
look at this one I wrote: http://www.madole.net/shaper/


David

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Ricoh PCI to SD device?

2006-01-11 Thread M. Warner Losh
In message: [EMAIL PROTECTED]
Andrew Gordon [EMAIL PROTECTED] writes:
: 
: On Tue, 10 Jan 2006, M. Warner Losh wrote:
: 
:  Are you sure they provide technical documentation sufficent to write
:  the driver?  The last time I asked, I got a nice document that said
:  that it implemented the sds standard sd host interface, but didn't
:  document what that was.  TI and winbond chips datasheets are the same
:  way.  Prove me wrong.  I'd love it :-)
: 
: Have you seen this datasheet from TI?
: 
: 
http://focus.ti.com/docs/apps/catalog/resources/appnoteabstract.jhtml?abstractName=sprue30
: 
: It's not the one you are looking for, but it does at least give
: register-level documentation on the implementation in that particular
: chip, and TI devices tend to share peripherals.

Thanks for the pointer...

Warner
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]