Re: gateway+multi-PPPoE

2001-05-12 Thread Brian Somers 

> 
> Hi!
> 
>   I'm triyng to set-up a Gateway that will use 3 different PPPoE (to 
> the same provider) adsl connection (3 modem , 3 account),  to 
> distribute it back to a soho network.  In instance to get the more 
> bandwith possible.
> 
>  I've been able to set-up the gateway with one modem by using netgraph 
> and PPP. 
> 
> I tought that using mpd would allow me to to get the maximun of these 
> three connections.

ppp should do that too.

> It seem to work well on the gateway.  But the rest of the network is 
> dead (the gate way see everybody and vice versa) but station dont see 
> the net.   
> 
> If somebody have any idea how to make that thing work it will be a 
> great help.

You don't describe exactly how you've got things set up.  Are you 
using Multi-link ppp over PPPoE links ?  If so, you'll need a very 
co-operative provider to sit at the other end.

If you're setting up 3 distinct PPPoE links and then running a 4th 
ppp session using multi-link with (say) UDP links that talk accross 
each of your PPPoE setups to a remote server which demuxes them (by 
running a similar multi-link ppp setup), then you should be able to 
get this working :0)

Feel free to post your configuration and I can see if it makes sense 
to me.

> P.S. I try that solution, if there's other who work better, please tell 
> me .
> thanks
> 
> Nicolas Beauchesne
> [EMAIL PROTECTED] 

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

DUMMYNET and IPv6

2001-05-12 Thread David Delibasic 

Hellow 

Will IPv6 start supporting DUMMYNET and when ???


With Regards,
David

> FreeBSD < -- > Power so serve <
> Line noise provided by Telekom Slovenia <



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: t/tcp behaviour has changed in -current and -stable

2001-05-12 Thread Paul Herman 

On Thu, 10 May 2001, jayanth wrote:

> I would like to back out the DELAY_ACK macro changes for now. The
> ttcp code behavior has changed because of the addition of the
> DELAY_ACK macro.
>
> The macro is forcing the ttcp code to send an immediate SYN, ACK
> for an initial ttcp segment which has the SYN/FIN/PSH flag set.
> Instead the SYN,ACK should be delayed such that next segment
> should be SYN/FIN/PSH from the server side.

I'm hesitant to comment, because I don't really have a patch :-) but
I'll give it a whirl anyway.

Thing is, delack is still broken.  It just isn't nearly as broken now
as it was before the patch.  I'm pretty sure what you are seeing now,
worked before only because of the brokenness.  The way to go here is
to fix this problem.  Besides, if you back out the latest delack
change, ttcp will be affected by the old delack problems anyway.

I don't have a testbed for ttcp, so I'm flying blind, but how about
where you wrote:

> if (DELAY_ACK(tp) && (tp->t_flags & TF_NEEDSYN))
>   
> At this point the DELAY_ACK macro returns false because there is a
> callout_pending(). Hence the TF_ACKNOW will be set.

If the new ttcp SYN,ACKs *always* get delayed, having something like:

  if ( (DELAY_ACK(tp) || this_is_a_ttcp_connection) &&
(tp->t_flags & TF_NEEDSYN))

 - or -

  if ( tcp_delack_enabled &&
(!callout_pending(...) || this_is_a_ttcp_connection) &&
(tp->t_flags & TF_NEEDSYN))

...depending on what The Right Thing is when tcp_delack_enabled = 0.
I don't know ttcp, so of course "this_is_a_ttcp_connection" should be
replaced with the corresponding boolean.

-Paul.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Linksys Wavelan WPC11 non-laptop links

2001-05-12 Thread Bruce R. Montague 



This describes setup of an 802.11b (Wi-Fi) radio
link between two desktop (non-laptop) PCs using
LinkSys Wavelan cards and without using a separate
access point,

One end of the link ran FreeBSD 4.3-RC #5 and the
other PicoBSD (same source code, that is, using 4.3
freebsd-stable). I knew little about this when I
started, and if there is a single doc capturing this
information I didn't find it.

I used two LinkSys WPC11 wireless PCMCIA cards (which
seem relatively common and reasonably cheap) and
did _not_ use a separate base station or access
point; the link is point-to-point. Although I found
a number of helpful resources, there are a number
of variables and a manual driver patch was required
(for 4.3 freebsd-stable), so I thought I'd log this
in one place.

If I'm off in the weeds anywhere in the following
or putting out bogus info, please let me know...


--
* Helpful URLS include:

http://www.live.com/wireless/unix-base-station.html
http://www.onlamp.com/pub/a/bsd/2000/11/02/Big_Scary_Daemons.html
http://people.freebsd.org/~wpaul/wi.patch

 and the online CVS files at
http://www.freebsd.org/cgi/cvsweb.cgi


* The LinkSys WPC11 PCMCIA card is similar to the
Lucent Orinoco "gold/silver" cards, but with a few
differences (incompatibilities).  The generic name
for these cards is "WAVELAN/IEEE 802.11b".  The
FreeBSD-stable driver ("device wi") is in files
"/usr/src/sys/i386/isa/if_wi.c" and "if_wiregs.h".
This driver has been moved in freebsd-current to
the "usr/src/sys/dev/wi" directory, and appears to
be undergoing a reasonable amount of enhancement
(including mods motivated by "Linksys cards").  The
"isa/if_wi.c" source has been moved to the attic,
that is, deprecated.  The wi driver is colloquially
known as the "FreeBSD Wavelan driver" and on
non-laptops under freebsd-stable it only works with
ISA->PCMCIA bridge cards (not PCI->PCMCIA bridge
cards).

The chipset in the WPC11 is the Intersil (ex-Harris)
HFA3841/HFA3842.  The interface to the Orinoco and
similar cards is based on some sort of firmware-driven
microcontroller called the Lucent Hermes. Getting
Lucent doc for this has apparently been a source of
problems.  According to the required "if_wi.c" driver
patch for freebsd-stable, the WPC11 uses the "PRISM
II chip" as opposed to the "Lucent chip".

* Due to differences in laptop and non-laptop PCI
hardware, use of a PCI->PCMCIA bridge card in
non-laptops is not currently supported in FreeBSD-stable.
See:

http://groups.yahoo.com/group/freebsd-hackers/message/61239

 
* Thus, to use PCMCIA cards (PCCARDS) in desktop
FreeBSD systems, ISA->PCMCIA bridge cards must be
used. I had a hard time finding these. I ended
up using two "LinkSys ProConnect Desktop PCMCIA Card
Reader/Writer" (Model PCMRDWR) kits.  These include
an "internal" ISA->PCMCIA bridge card that connects
by ribbon cable to a 2-slot PCMCIA card adapter
physically similar to a floppy-drive unit.  These
are considered "external" PCMCIA kits because the
PCMCIA card does not mount directly into the bridge
card.

PCI->PCMCIA bridge kits seem to be quite popular
currently in association with Windows wireless
networks.  These seem to almost all be "internal"
kits, that is, the PCMCIA card mounts directly in
the bridge card, extending out the back of the PC.

* A patch by Bill Paul must be applied to the
FreeBSD-stable "isa/if_wi.c" driver file to support
the LinkSys WPC11. It looks like there might be a
slight version problem between the patch and 4.3
stable.



Key steps to installing and configuring picobsd and
freebsd support for the WPC11, using 4.3 freebsd-stable
source, are:

 
-
* In both kernel config files, assure the Wavelan
driver is added:

---
device  wi
---

This is already the case in GENERIC.  In picobsd
you probably need to put it into the PICOBSD config
file in your config directory.

-
* In both kernel config files, you also need the
PCMCIA driver (also already in GENERIC, you'll
probably only need one device in picobsd):


# PCCARD (PCMCIA) support
device  card
device  pcic0   at isa? irq 0 port 0x3e0 iomem 0xd
device  pcic1   at isa? irq 0 port 0x3e2 iomem 0xd4000 disable
-


-
* Modify "/usr/src/sys/i386/isa/if_wi.c" and
"/usr/src/sys/i386/isa/if_wiregs.h" as per patch:

 http://people.freebsd.org/~wpaul/wi.patch

That is, download the patch in the "i386/isa"
directory and do a "patch iobase = bus_alloc_resource(dev, SYS_RES_IOPORT, &rid,
0, ~0, (1 << 6),
rman_make_alignment_flags(1 << 6) | RF_ACTIVE);


 with:


static int wi_alloc(dev)
device_tdev;
{
struct wi_softc *sc = device_get_softc(dev);
int rid;

rid = 0;
sc->iobase = bus_alloc_resource(dev, SYS_RES_IOPORT

Problems with ng_one2many

2001-05-12 Thread Ade Lovett 

Hi,

I have a box with 5 old-style netgear (de) interfaces on it, one talking
to the outside world, and 4 sending large quantities of data to a number
of other machines on the same switch.  At the moment, we're setting up
a bunch of separate network addresses, one per card (de1-de4) and then
use the application to bind to particular addresses when sending data
to one machine.

Now, what I'd like to do is to aggregate de1-de4 into a single virtual
interface, with a simple round-robin setup, giving me a 400Mbit pipe
to play with, and making the internal network setup a great deal easier.

I first looked at Bill Paul's fec netgraph module, but this lacks a
pure round-robin approach, and odd things happen when the data load
is greater than a single interface.  I also note that there are a number
of places in the code where it's suggested that the code is not MP-safe.

After a bit more investigation, I came across ng_one2many which appears
to do exactly what I want, only it just refuses to work for me.

The machine is running 4.3-STABLE as of a day or so, all appropriate
modules have been loaded, viz:

matrix 86# kldstat
Id Refs AddressSize Name
 15 0xc010 1b143c   kernel
 21 0xc71d5000 c3000vinum.ko
 31 0xc72f8000 3000 ng_one2many.ko
 42 0xc72fc000 8000 netgraph.ko
 51 0xc7307000 3000 ng_socket.ko

Yet when I try to perform the first part of the setup as documented
in the manpage, I get the following:

matrix 131# /usr/sbin/ngctl mkpeer de1: one2many upper one
ngctl: send msg: No such file or directory
matrix 132#

and obviously, everything else fails to do anything.

Any suggestions?  I guess I could take the fec code, and rip it to
bits with a pure round-robin approach, but that seems like reinventing
the wheel given the existence of ng_one2many.

What am I missing here?

Regards,
-aDe

-- 
Ade Lovett, Austin, TX.[EMAIL PROTECTED]
FreeBSD: The Power to Serve http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message