Thank you! I'll e-mail him.
--Brett
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
On Tue, Feb 10, 2004 at 01:13:29PM -0700, Brett Glass wrote:
> How can I get in touch with him to see how the project is coming
> along?
>
This thread was about the driver (including his email address):
http://news.gw.com/freebsd.hackers/[EMAIL PROTECTED]
- Christian
--
Christian Brueffer
Hello,
I have problems with net/l2tpd. The people at their mailing list can't help me and it
seems to be a problem with pppd, so I write to the list.
Situation:
I'm using L2TP over IPsec to secure a wireless lan. The lan connection itself works
fine. The IPsec connection works fine (transport m
How can I get in touch with him to see how the project is coming
along?
--Brett
At 06:31 AM 2/10/2004, Christian Brueffer wrote:
>Stuart Walsh was working on a driver for the USB atmel for some time.
>However, I don't know what the current status on that one is.
>
>- Christian
___
Hi,
Your problem here is that your TTCP connection times out and the
data is retransmitted (loosing all the benefits of TTCP) see my other
email for why this happens.
Karim.
Danny Braniss wrote:
hi,
im running some experiments, and it seems to me that
setting net.inet.tcp.rfc1644 h
Hi,
We actively use TTCP and we like it (www.xiplink.com). The problem is
that it does not behave exactly like in Steven's book. I have sample
code if you want to try it. But basically you need to set the NOPUSH
flag (setsockopt()) before using sendto() _and_ in the server as
well. For shor
Hi.
Imagine the following situation: two programs set up a TCP connection
between each other and then each starts send()ing data over it without
calling recv(). After a short while the receive windowss at both ends
close.
Now suppose that one of the two programs crashes or exits. The TCP at the
o
> My changes
> (tcp hostcache) are in 5.2 for the first time. Before it it's the
> legacy code as well. I hope I haven't broken TTCP more than it was
> before.
>
> > and solaris(but i guess they don't do ttcp) and linux (not yet).
>
> Linux never will. They consider TTCP broken by design. Sol
On Thu, Feb 05, 2004 at 10:43:22AM -0700, Brett Glass wrote:
> What is the state of support for USB Wi-Fi adapters in FreeBSD?
> Several clients have asked me if they can use these adapters on
> their BSD servers, but so far I can't find one that FreeBSD
> recognizes. I have one here that's based o
På Tue, 10 Feb 2004 07:08:09 -0500, skrev Chuck Swiger <[EMAIL PROTECTED]>:
Bjorn Eikeland wrote:
[ ... ]
DUMMYNET and HZ=1 is in the kernel.
Any suggestions what can be causing this? (I've only got the one nic,
and use a adsl router for internett)
I seem to recall some issues with setting HZ
Bjorn Eikeland wrote:
[ ... ]
DUMMYNET and HZ=1 is in the kernel.
Any suggestions what can be causing this? (I've only got the one nic,
and use a adsl router for internett)
I seem to recall some issues with setting HZ very fast, in that it breaks the
uniqueness assumptions made by TCP sequenc
Andre Oppermann <[EMAIL PROTECTED]> wrote:
>
>Linux never will. They consider TTCP broken by design. [...]
>The problem is that TTCP will never make it mainstream or even
>little side stream. FreeBSD is the only BSD implementing it.
The reason for its lack of popularity is that it has significan
thanks for insight! i guess it's time to change horses :-(
i was planning to use it for an application that is udp,
oh well, there goes another idea down the drain.
danny
> Danny Braniss wrote:
> >
> > > I have been the last one fuzz around in the TTCP code areas. However
> > > there could be p
Danny Braniss wrote:
>
> > I have been the last one fuzz around in the TTCP code areas. However
> > there could be problems that were lurking there before in other code
> > parts (syncache maybe). TTCP isn't used in production by anyone (AFAIK)
> > and only minimally tested.
> ahh, that's one re
> I have been the last one fuzz around in the TTCP code areas. However
> there could be problems that were lurking there before in other code
> parts (syncache maybe). TTCP isn't used in production by anyone (AFAIK)
> and only minimally tested.
ahh, that's one realy good piece of info so far.
th
Danny Braniss wrote:
>
> > Danny Braniss wrote:
> > > hi,
> > > im running some experiments, and it seems to me that
> > > setting net.inet.tcp.rfc1644 has the reverse effect.
> > > with sysctl net.inet.tcp.rfc1644 = 0, the transaction uses only 6 packets
> > > and it's less than 1 sec, settin
> Danny Braniss wrote:
> > hi,
> > im running some experiments, and it seems to me that
> > setting net.inet.tcp.rfc1644 has the reverse effect.
> > with sysctl net.inet.tcp.rfc1644 = 0, the transaction uses only 6 packets
> > and it's less than 1 sec, setting net.inet.tcp.rfc1644 to 1 uses
> >
Danny Braniss wrote:
hi,
im running some experiments, and it seems to me that
setting net.inet.tcp.rfc1644 has the reverse effect.
with sysctl net.inet.tcp.rfc1644 = 0, the transaction uses only 6 packets
and it's less than 1 sec, setting net.inet.tcp.rfc1644 to 1 uses
8 packets and takes m
At 08:32 10/02/2004, you wrote:
with sysctl net.inet.tcp.rfc1644 = 0, the transaction uses only 6 packets
and it's less than 1 sec, setting net.inet.tcp.rfc1644 to 1 uses
8 packets and takes more than 1 sec.
with net.inet.tcp.rfc1644 = 1:
No. TimeSourceDestination
hi,
im running some experiments, and it seems to me that
setting net.inet.tcp.rfc1644 has the reverse effect.
with sysctl net.inet.tcp.rfc1644 = 0, the transaction uses only 6 packets
and it's less than 1 sec, setting net.inet.tcp.rfc1644 to 1 uses
8 packets and takes more than 1 sec.
with
20 matches
Mail list logo
