Re: Ping Problem

2001-03-14 Thread Julian Elischer
Satyajeet Seth wrote: An upgrade within the '4' family should be pretty painless. I tried using a FreeBSD4.1.1 system, but the problem is still there. I suppose for now, my hack on FreeBSD4.1 will serve the purpose. Am I correct? well 4.1.1 has the autosrc command which does what you

Re: Ping Problem

2001-03-14 Thread Satyajeet Seth
The problem is not solved. The pseudo ethernet interface(PEI) is responding with its MAC address. So arp resolution is taking place. But it is not responding to ICMP request packet. When I enable bridging the PEI's as well as fxp0 are responding to ARP with their MAC address leading to improper

Re: Mobile IP implementation for FreeBSD

2001-03-14 Thread itojun
I'm looking for open-sourced Mobile IP implementation on FreeBSD. Could anyone please give me some information? KAME (www.kame.net) has an experimental implementation which will be integrated into FreeBSD at some point in the future once it's considered ready enough. KAME does

Re: Strong vs. Weak ES models?

2001-03-14 Thread Jeroen Ruigrok/Asmodai
Hi Yu-Shun, -On [20010308 22:05], Yu-Shun Wang ([EMAIL PROTECTED]) wrote: Has the topic of Strong/Weak ES model been discussed here? Please give me a pointer if the topic has been debated. In what sense discussed? What type we are? What we support? I was wondering if

Re: Changing UDP select() behavior

2001-03-14 Thread Lars Eggert
Garrett Wollman wrote: On Tue, 13 Mar 2001 16:43:26 -0800, Lars Eggert [EMAIL PROTECTED] said: I'm considering changing this, so that a select-to-write on a UDP socket will block until queue space becomes available. Impossible. The only way to find out whether a packet (or set of

Re: Changing UDP select() behavior

2001-03-14 Thread Luigi Rizzo
As for efficiency, I agree that the per-packet send overhead will be larger. I'm not sure it'll be large enough to become a problem, though. yes it is probably constant work to find the first sleeping socket on the queue and issue a wakeup. All in all I think this approach would only help a

Re: Changing UDP select() behavior

2001-03-14 Thread Lars Eggert
Luigi Rizzo wrote: All in all I think this approach would only help a bit if if you were allowed to queue in the socket buffer (on which you can think of having some control, because you either opened the fd yourself or you inherited it from some parent), in addition to the device

IPv4 address is not unsigned int

2001-03-14 Thread Hajimu UMEMOTO
Hi, I wish to close PR 9982. This PR suggests that IPv4 address is not unsigned int and fix it to 32bit long. So, I took in_addr_t changes from OpenBSD and made a patch. It may break binary compatibility on Alpha, where u_long is 64 bits but in_addr_t would still be 32 bits. It seems working

IPv4 address is not unsigned int

2001-03-14 Thread Garrett Wollman
On Thu, 15 Mar 2001 01:53:16 +0900 (JST), Hajimu UMEMOTO [EMAIL PROTECTED] said: +in_addr_t inet_lnaof __P((struct in_addr)); +struct in_addrinet_makeaddr __P((in_addr_t, in_addr_t)); +in_addr_t inet_netof __P((struct in_addr)); If anything, these interfaces should be

UDP datagram max size.

2001-03-14 Thread David Malone
I'm trying to figure out what #define I should use for the largest UDP datagram. The header files don't seem to define a constant for this. The correct size would seem to be 65535 'cos there are two bytes in the UDP header for the size. IP_MAXPACKET and IPV6_MAXPACKET are available and have the

Re: UDP datagram max size.

2001-03-14 Thread Lars Eggert
David Malone wrote: I'm trying to figure out what #define I should use for the largest UDP datagram. The header files don't seem to define a constant for this. The correct size would seem to be 65535 'cos there are two bytes in the UDP header for the size. IP_MAXPACKET and IPV6_MAXPACKET

Re: UDP datagram max size.

2001-03-14 Thread David Malone
So it may be okay to punt on jumbograms for now, and use a 64K static buffer like the patch in the PR does. Even if you do implement support for jumbograms, I think keeping the 64K static buffer around as a "fast-path" for the common case makes sense. Does it talk about how jumbograms will

Re: UDP datagram max size.

2001-03-14 Thread Lars Eggert
David Malone wrote: Does it talk about how jumbograms will apply to UDP? I suspect the max udp data size might be unchanged anyway... It does (see below). And it does allow UDP packet with more than 64K of data. ftp://ftp.isi.edu/in-notes/rfc2675.txt 4. UDP Jumbograms The 16-bit Length

Re: Strong vs. Weak ES models?

2001-03-14 Thread Yu-Shun Wang
Hi, The current FreeBSD (or all BSD IP stacks) implements Weak End System model as described in RFC 1122. And as Jonathan pointed out, there is a switch similar to but not completely does the Strong ES model called net.inet.ip.check_interface, but it's in

Re: Mobile IP implementation for FreeBSD

2001-03-14 Thread Bjorn Andersson
On Tue, Mar 13 2001, at 14:48:37 -0800, Guangrui Fu wrote: I'm looking for open-sourced Mobile IP implementation on FreeBSD. Could anyone please give me some information? Check out the Monarch Project: http://www.monarch.cs.cmu.edu/ Bjrn -- Bjrn Andersson [EMAIL PROTECTED]

Re: Mobile IP implementation for FreeBSD

2001-03-14 Thread Lyndon Nerenberg
I'm looking for open-sourced Mobile IP implementation on FreeBSD. Check out the Monarch Project: http://www.monarch.cs.cmu.edu/ This supports FreeBSD 2.2.x, which is long dead. (And this was the case for the other mobile ip implementations I tracked down.) Is anyone working on this for a

Re: Mobile IP implementation for FreeBSD

2001-03-14 Thread Nate Williams
I'm looking for open-sourced Mobile IP implementation on FreeBSD. Check out the Monarch Project: http://www.monarch.cs.cmu.edu/ This supports FreeBSD 2.2.x, which is long dead. FreeBSD's networking stack isn't that much different from FreeBSD 2.X (or for that matter FreeBSD 1.X)

Re: Mobile IP implementation for FreeBSD

2001-03-14 Thread Nate Williams
FreeBSD's networking stack isn't that much different from FreeBSD 2.X (or for that matter FreeBSD 1.X) to what it is now. More than you would think. It's not different in design, but there are enough new excrescences to require manual application of almost any nontrivial patch. Oh, I

Re: Mobile IP implementation for FreeBSD

2001-03-14 Thread Lyndon Nerenberg
So what are the odds of getting this code incorporated into -current? Is this something that's in KAMEs realm of responsibility? (From what I've been able to track down, they aren't doing much active development of mobile ip right now.) --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED]

Re: problem with secondary dns update through ipfw firewall

2001-03-14 Thread Bill Fumerola
On Wed, Mar 14, 2001 at 10:22:32AM -0500, Peter Brezny wrote: Bill, I do have a list? ... Which list is that? I think the light bulb is begining to glow, dimly but still glow. I guess I only have to allow the root servers access? Is that what you mean? Typically you would want to allow

Re: Intel PRO/100+ PCI problem

2001-03-14 Thread Christopher Nielsen
On Wed, Mar 14, 2001 at 08:47:57AM -0600, Jonathan Lemon wrote: On Wed, Mar 14, 2001 at 02:28:47PM +0100, Jeroen Ruigrok/Asmodai wrote: -On [20010308 22:02], Rafael Tonin ([EMAIL PROTECTED]) wrote: I'm having some problems on configuring my just purchased Intel PRO/100+ PCI (reported by

Re: Intel PRO/100+ PCI problem

2001-03-14 Thread Jonathan Lemon
In article local.mail.freebsd-net/[EMAIL PROTECTED] you write: On Wed, Mar 14, 2001 at 08:47:57AM -0600, Jonathan Lemon wrote: On Wed, Mar 14, 2001 at 02:28:47PM +0100, Jeroen Ruigrok/Asmodai wrote: -On [20010308 22:02], Rafael Tonin ([EMAIL PROTECTED]) wrote: I'm having some problems on

Re: Mobile IP implementation for FreeBSD

2001-03-14 Thread Motonori Shindo
Kris, From: [EMAIL PROTECTED] Subject: Re: Mobile IP implementation for FreeBSD Date: Wed, 14 Mar 2001 21:50:32 +0900 Message-ID: [EMAIL PROTECTED] I'm looking for open-sourced Mobile IP implementation on FreeBSD. Could anyone please give me some information? KAME (www.kame.net) has an