Mike Nowlin wrote:
>
> (Looking for some general pointers to solutions here...)
>
> Just had a second DSL connection installed, and have several questions
> regarding how to map it into the FBSD router we use...
I assume this is DSL without PPPoE..
>
> The basic setup here (with just the sing
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 wh
On Tue, Mar 13, 2001 at 02:48:37PM -0800, Guangrui Fu wrote:
> Hi,
>
> 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 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 s
>> 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 do
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 t
-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 Intel as being P#: 689661-004).
>
>When booting, FreeBSD 4.2 reports:
>
>fxp0: at device 13.0 on pci0
>fxp0: could not map memory
You might w
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 Intel as being P#: 689661-004).
> >
> >When booting, FreeBSD 4.2 re
Brian Somers wrote:
> Having said this, it would be nice if it was possible to pre-allocate
> (a small number of) mbufs for a pipe() or socketpair(), giving a
> reliable SOCK_DGRAM file-descriptor based ipc mechanism.
We're talking Internet here, so it won't be reliable. It'd just block the
selec
Garrett Wollman wrote:
>
> < 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
> packets, or a fragment of a packet) would be successfully
Luigi Rizzo wrote:
>
> > Hi,
> >
> > I'm wondering if anyone has ever considered modifying the UDP behavior with
> > regard to selecting:
> >
> > Currently, writing to a UDP socket either enqueues packets in the interface
> > queue (returning success), or drops them on the floor (returning ENOBUF
> 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 hel
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
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 we
< 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 removed.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "un
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 r
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_MAX
> 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 wil
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
Hi all,
I am currently attempting to get PPPoE working using MPD on 4.2-Release.
I'm talking to an Alcatel 1000. I can get connected using PPP and a tun
interface, but I'm having no luck with MPD. The log file shows this:
mpd: pid 202, version 3.2 (root@bsd 21:32 11-Mar-2001)
[PPPoE] ppp node
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
I'll second that. Upgrade your ppp, set
enable tcpmssfixup
(or not, I believe it's on by default) in /etc/ppp/ppp.conf and you're all
set.
- Original Message -
From: "Brian Somers" <[EMAIL PROTECTED]>
To: "Paul Armor" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED
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/
Björn
--
Björn Andersson <[EMAIL PROTECTED]>
> > 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
> > > 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 Fr
< said:
> 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.
-GA
> > 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.
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]
wit
On Wed, Mar 14, 2001 at 05:03:10PM +, 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 t
Perhaps you have allready find this:
http://www.mobile-ip.de
Some Links, but no for FreeBSD 4.x.
But if you find an implementation there you could test it.
Falco
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
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 all
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 (report
In article [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 configuring my
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.ka
This is a re-write of the network setup I am devising with fixes suggested
by Julian Elisher (many thanks)
There are still some questions though which anybody is welcome to take
a
shot at
RTFMs used
- man netgraph, ng_frame_relay, ng_lmi, ng_iface, ng_rfc1490, ng_bridge
- /usr/share/e
35 matches
Mail list logo
