0:0: class=0x02 card=0x10838086 chip=0x10b98086 rev=0x06
hdr=0x00
vendor = 'Intel Corporation'
device = '82572EI PRO/1000 PT Desktop Adapter (Copper)'
class = network
subclass = ethernet
Thank you,
Jonathan
_
there other changes that need to happen as well?
Jonathan
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
everyone, if as many get out and test that
>>> driver as possible.
>>
>> Can we just "csup -i src/sys/dev/em/ supfile" on a 7-stable system or
>> are there other changes that need to happen as well?
>>
>> Jonathan
>>
>
> hmmm, I'm not
mething
probably changed elsewhere. If you can give me a heads up when the MFC
occurs I would appreciate it. If the MFC doesn't get it working would
having remote access help at all?
Jonathan
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[snip discussion]
Sorry to all for the noise, turns out that with a motherboard BIOS update
the card is recognized and initialized fine.
For the archives the board was an Asus P5B-VM DO and had the 0505 BIOS. I
updated to the 1001 version.
Jonathan Stewart
t valid CIDR address using this notation.
I'm not sure that's true. Have you tried it? Because it seems to work here.
Jonathan
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any
On Friday 08 June 2012 09:43:25 Alexander V. Chernikov wrote:
> On 08.06.2012 11:20, Jonathan McKeown wrote:
> > On Thursday 07 June 2012 17:00:04 Alexander V. Chernikov wrote:
> >> Hello list!
> >>
> >> Since the early days ifconfig(8) has the following funct
Hiya
I have a server which acts as a gateway between the internet and my
internal network. The external interface receives its IP address via
DHCP. I set up pf.conf to allow DHCP packets via ports 67/68, but I
notice that when the server boots, the DHCP exchange happens /before/
PF gets
The following reply was made to PR kern/140647; it has been noted by GNATS.
From: Jonathan Looney
To: bug-follo...@freebsd.org, freebsd-b...@freebsd.org
Cc:
Subject: Re: kern/140647: [patch] e1000 driver does not correctly handle
multicast promiscuous mode with 128 or more multicast
Sorry for the cross-post, but this could be either lists problem.
I have 2 boxes running 7-STABLE as of 20081130, both i386 SMP. One is
running ISC DHCPD 3.0.x from recent ports, and the other dhclient from
make world.
The server is refusing to answer the DISCOVER request, as it thinks the
I
Can someone please confirm or rule out my issue with dhclient sending
bad IP checksum packets. It would really suck if 7.1 was released with a
broken DHCP client.
Jonathan Feally wrote:
Sorry for the cross-post, but this could be either lists problem.
I have 2 boxes running 7-STABLE as of
ny problems lately, but none involved checksum nor the dhcpd
(btw, I assume that you are seeing bad checksum on the receiving server)
could you add a nic to your PE1750?
danny
Jonathan Feally wrote:
Sorry for the cross-post, but this could be either lists problem.
I have 2 boxes runn
Jonathan Feally wrote:
I will try another em card in that server to confirm/rule out the nic
driver. I am seeing the same checksum number on both the source
machine, the dhcp server machine, and a 3rd windows xp machine
sniffing the traffic with etherreal/wireshark. The windows xp box is
OK, so I installed a different PE1750 with BETA2 and then updated the
source via cvsup RELENG_7 from cvsup3 and all is ok now on that box.
Went back the first box and cvsup'ed the src again into an empty
directory and it compiled and worked fine. Looks like my updating of the
source along the w
Ok, I managed to cause it again.
dhclient was the problem.
My source tree was fine. Turns out that it is my make.conf CFLAGS=-O3
setting.
When compiled with -O3 it will generate packets with bad checksums.
Simply recompiling it with -O2 did not cause this issue and dhclient
works fine.
So th
On 2014-08-27 01:40, Peter Wemm wrote:
On Tuesday 26 August 2014 10:40:27 free...@jonathanprice.org wrote:
Hello,
I am configuring a server with IPv4 and IPv6 addresses and have noticed that
FreeBSD seems to be preferring IPv4, such as when establishing SSH
connections.
After reading through /
F_..." line count IF as being explicitly configured, or
is it just interfaces with statically assigned addresses?
Thanks,
Jonathan.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
I'm in the process of upgrading my web/database/nfs/jack-of-all-trades box
from 6.2 to RELENG_7. I figured now would be a good time to clean up my
kernel config files. I have the following in my old kernel config:
# Statically Link in accept filters
options ACCEPT_FILTER_DATA
options
nfiguration, it just started up, presenting me with a dialog-wizard.
Is it possible that your deluge installation is corrupt? I would give
you a package if I could, but I've moved onto 7-STABLE so that I could
use the client.
Cheers.
--
Jonathan Chen <[EMAIL PROTECTED]>
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
The following reply was made to PR kern/120966; it has been noted by GNATS.
From: Jonathan Crook <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc:
Subject: Re: kern/120966: [rum] kernel panic with if_rum and WPA encryption
Date: Sat, 24 May 2008 23:05:12 +0100
Your problem lies in that vpnc is opening a raw socket to get it's ESP
packets. However when you enable esp in the kernel, the kernel already
is taking those packets, so you get the SOCK_RAW error as vpnc cannot
get ESP packets because the kernel is handling them.
I do not know if options FAST
If anyone is kind enough to
respond, let me know if there is any other info about my configuration that
would be helpful to you.
Thanks a bunch,
Jonathan Reeder
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
n, ng0 passes it off to rl0 (internal if).
I see steps one and two of that in tcpdump, but not three.
-Original Message-
From: Tim Pushor [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 15, 2004 7:49 PM
To: Jonathan Reeder
Cc: [EMAIL PROTECTED]
Subject: Re: MPD 3.18 Trouble
Jonath
Got a question about routing with regards to MPD. I'm able to make
connections to my MPD-based VPN server just fine, but once connected, I
can't communicate with anything on the other side of the tunnel, and it
appears to be a routing problem.
My ifconfig results for the ng0 device on the MPD ser
s support for RFC 2385 (TCP-MD5)
digests. These are
/sys/conf/NOTES:# This is enabled on a per-socket basis using the
TCP_MD5SIG socket option.
--
Jonathan Noack | [EMAIL PROTECTED] | OpenPGP: 0x991D8195
signature.asc
Description: OpenPGP digital signature
I'm trying to setup a machine that will be both routing traffic and
bridging 2 segments of one network with ipfw processing on that bridged
network. The routing seems to be OK and bridging is also OK from Side to
side, however when trying to talk to the IP of the machine from another
machine on
ICAST
options: RXCSUM, TXCSUM, VLAN_MTU, POLLING
vlan199 flags UP, BROADCAST, RUNNING, PROMISC, SIMPLEX, MULTICAST
vlan199 has no options.
Anybody else run into this problem? I am running 5-STABLE as of today.
-Jon
Jonathan Feally wrote:
I'm trying to setup a machine that will be bo
+ value = *count - 1;
+ } while (!atomic_cmpset_rel_int(count, value + 1, value));
+ return (value == 0);
+}
Sure you haven't been peeking at it? :-) :-) :-)
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
In article
[EMAIL PROTECTED]>
you write:
>
>No other changes have been made, and the updated patch is available at:
>http://www.silby.com/patches/ratelimit-enhancement-3.patch
Looks good to me.
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe fr
YWAIT vs M_TRY_WAIT because you have M_DONTWAIT/M_DONTBLOCK.
>>
>> -Alfred
>
> I agree. Anyone else before I re-roll? :-)
I second Alfred's suggestion.
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
it is a change in semantics, it does help to catch problems
in porting. AFAIK, NetBSD (and probably Open) do not allow m_get()
to return NULL in the M_WAIT case, so the underlying code will have to
be changed in order to handle this difference anyway.
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
TCP will start slowly ramping up
transmission to avoid overloading the network.
Try bumping up net.inet.tcp.slowstart_flightsize, which specifies
how many packets can be outstanding (unacked) at the beginning
of a TCP connection.
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
s Gigabit connection).
>Of course, this time scale may be valid for general internet envirounment.
>I'll study more.
The math for RTT calculations is explained somewhere in Van Jacobsen's
congestion avoidance & control paper, I believe. The equations have
since been modified sl
implementations actually set this.
However, it is better than the lower bound of acking every incoming
data packet.
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
ally and will commit it
unless there are any objections.
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Current updated patch for comments is below.
Jayanth did make one point that an application could assume that
the error return from accept was in regards to the listening socket
instead of the new socket, so that may be a concern.
--
Jonathan
Index: uipc_socket.c
In article [EMAIL PROTECTED]> you write:
>Jonathan Lemon writes:
>> Jayanth did make one point that an application could assume that
>> the error return from accept was in regards to the listening socket
>> instead of the new socket, so that may be a concern.
>
>Yes
In article
[EMAIL PROTECTED]>
you write:
>
>On Wed, 7 Feb 2001, Archie Cobbs wrote:
>
>> Jonathan Lemon writes:
>> > Jayanth did make one point that an application could assume that
>> > the error return from accept was in regards to the listening socket
>
On Thu, Feb 08, 2001 at 10:12:43AM -0800, Archie Cobbs wrote:
> Jonathan Lemon writes:
> > >> Jayanth did make one point that an application could assume that
> > >> the error return from accept was in regards to the listening socket
> > >> instead of t
In article [EMAIL PROTECTED]> you write:
>Hello:
>
>Has anyone considered doing a SCTP stack
>implementation for FreeBSD? I have a
>user space version working.. but before
>I start doing one for the kernel space.. just
>curious? Don't want to duplicate anyones eff
the case where we drop partial mbufs from the first packet
train.
In that spirit, I offer an amended patch below.
--
Jonathan
Index: kern/uipc_socket.c
===
RCS file: /ncvs/src/sys/kern/uipc_socket.c,v
retrieving revision 1.68.2.11
shedding load instead of queuing up numerous connections.
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
asis that 1) most apps already do the
wrong thing now anyway, and 2) it brings us closer to a 'standard',
e.g.: what other systems are doing as well.
I was planning on committing the change soon, but there isn't really
any hurry; effectively all it does is change the mechanism of e
On Mon, Feb 12, 2001 at 04:51:48PM -0800, Archie Cobbs wrote:
> Jonathan Lemon writes:
> > > > Did you guys agree on a commit-worthy fix yet?
> > >
> > > I wasn't party to the issue that generated this thread in the first
> > > place, but.. I t
On Mon, Feb 12, 2001 at 06:34:29PM -0800, Archie Cobbs wrote:
> Jonathan Lemon writes:
> > It seems to me that the odds of an application being able to correctly
> > handle an error return from accept() are far greater than the odds that
> > the code correctly checks &
In article
[EMAIL PROTECTED]> you
write:
>Hi
>
>how could i modify the amount of the maximum routes that freebsd allow?
Add more memory.
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
ode to the user layer.
Finally, ICMP errors should never be allowed to kill an existing TCP
connection; if an administrative filter is installed across some existing
flows, then those flows should be allowed to time out per the TCP protocol.
Patch attached, please review.
--
Jonathan
I
gt;
> I put it there as a extra check against "attackers" sending us malformed
> ICMP messages with only part of the attached IP header, or even without
> it.
Yup, but if you exmaine icmp_input, which calls this code, it has
already verified that there are a full 8 bytes of the TC
ssion. If this was a real problem, I'm wondering whether it
> should be checked into -current and considered for MFC into 4.3.
The patches are still sitting in my tree, as I've been unable
to come up with a test case that actually makes a difference.
The "tar cf host:..."
On Sun, Feb 25, 2001 at 11:10:54AM +0100, Paul Herman wrote:
> On Sat, 24 Feb 2001, Jonathan Lemon wrote:
>
> > On Sat, Feb 24, 2001 at 11:19:02AM -0800, Mark Peek wrote:
> > > Was there ever a final resolution to this problem?
> >
> > The patches are still
w
>
> But that is probably too fast, what if we delay the retransmit by say
> 100ms efter recieving the host unreachable ?
I was thinking of a slightly more generic solution, something like
the patch below. This isn't explicitly tied to ICMP unreachables,
though.
--
J
her all ICMP replies (source quench, mtu) have
sequence numbers within the tcp window.
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
> do 'netmask 255.255.255.255' instead or 'netmask 0x' since this is
> an alias... for some reason otherwise services may not bind to the ip
> correctly
Why would this be? The two are numerically equivalent.
-Jon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-
If a UDP socket selects readable, am I assured that the next read call will not
block?
If a socket is nonblocking, can I use setitimer and handle SIGALRM, and be
assured that the process will not be put to sleep waiting for I/O on the socket,
thus returning EINTR due to the signal?
--
Jonathan
> > $local_socket = sockaddr_in($port, inet_aton(INADDR_ANY) );
> >
> > to
> >
> > $local_socket = sockaddr_in($port,INADDR_ANY );
> >
> > now is working fine on FBSD 3.x.
>
> Ah. Ick. Perl. Bleh.
He'd have the same problem in C (except that the compiler would catch it -
INADDR_ANY is not a st
I probably poorly worded the commit message; it should read "return
ECONNABORTED if connection receives a RST while on the listen queue".
Under normal operation, the client's connection isn't really closed
until it receives a FIN/ACK from the server.
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
are slightly different.
I believe the correct thing to do at this point is push the
IS_DISCONNECTED test down to each protocol's accept routine,
instead of short-circuiting it in soaccept. It looks like the
short-circuit test was added in uipc_socket.c:1.41 in the NetBSD
sources, which we brought
g to
do with the ordering of accept() with respect to close().
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
> > Data CAN be lost if the TCP connection is RST. It has nothing to
> > do with the ordering of accept() with respect to close().
>
> Please educate me: how would RST come into this discussion at all?
> The client does connect() write() close(), there is no forced
> connection termination involv
I would like to preempt corrections to the effect that it is currently
impossible for accept to return both an error code and a socket to read the data
from. It sounds like there may be a bug in the behavior of accept w.r.t Unix
Domain sockets. For TCP, if the client sends data, then closes with
On Thu, Mar 08, 2001 at 01:00:48PM -0500, Wietse Venema wrote:
> Jonathan Lemon:
> > On Thu, Mar 08, 2001 at 10:38:17AM -0500, Wietse Venema wrote:
> > > If the result of connect() write() close() depends on whether
> > > accept() happens after or before close(), then t
On Thu, Mar 08, 2001 at 02:30:23PM -0800, Alfred Perlstein wrote:
> * Jonathan Lemon <[EMAIL PROTECTED]> [010308 14:19] wrote:
> > On Thu, Mar 08, 2001 at 01:00:48PM -0500, Wietse Venema wrote:
> > > Jonathan Lemon:
> > > > On Thu, Mar 08, 2001 at 1
some requests for
this particular feature. Doing this fixes the bug with DNS
and Apache, which assume the returned address is valid.
2. The app will still be able to retrieve any data that is
sitting in the TCP socket buffers, which might be desired
in the TCP case (just as it is in the unix-domain case)
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
cd /usr/ports/net/nemesis
make install
Nemesis (http://www.packetninja.net/nemesis/) is a command line tool that can
easily generate syn packets; if you want a flood, write a script.
There is also /usr/ports/net/libnet
http://www.packetfactory.net/Projects/Libnet/
- it is used by nemesis and is
#!/bin/sh
i=5; while [ $i -lt 50100 ]; do nemesis-tcp -S 209.68.199.246 -D
209.68.199.242 -fS -x $i -y 25; i=$(($i + 1)); done
... seems to work fine; a perl script would give a more legible for loop though
;)
--
Jonathan Graehl
email: [EMAIL PROTECTED]
web: http://jonathan.graehl.org
-S 209.68.199.246 -D
> 209.68.199.242 -fS -x $i -y 25; i=$(($i + 1)); done
>
> ... seems to work fine; a perl script would give a more legible for
> loop though
> ;)
>
> --
> Jonathan Graehl
> email: [EMAIL PROTECTED]
> web: http://jonathan.graehl.org/
To Unsubscribe: send mail
>When booting, FreeBSD 4.2 reports:
> >
> >fxp0: at device 13.0 on pci0
> >fxp0: could not map memory
>
> You might want to try the latest sources Jonathan Lemon [cc:'d] came up
> with. I've looked at the diffs and he did some nice cleanups to bring
> the
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
gt; It is recieving OK, just not sending. (or, the other machines are unable
> to see it, maybe the switch is dropping the packets as "damaged" or
> something?)
Try this following patch to mii/nsphy.c. It appears that we need to
toggle
;[EMAIL PROTECTED]>. However, I suggest
that you have plenty of documented information on hand to support
your changes.
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
cessing as
fast as possible, and that in-kernel servers (NFS and the TUX webserver) are
blazingly fast.
I do have Linux 2.4 running on an old machine, but I have no intention of taking
down my FreeBSD box to dual boot Linux just to compare penis size. Has anyone
recently done so?
--
Jonatha
tly. I suppose I should try 2.4 sometime and see exactly
what has improved.
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
hreaded, better on SMP, someone
>despise Linux should wakeup now, Linux is not so bad.
Unfortunately, you haven't confirmed anything here, other
than Linux has a different feature set than FreeBSD, which
we already are aware of.
Just having more features does not automatically make thin
ion. If the kqueue API is overengineered, well, then, so is the
Berkeley Sockets API.
--
Jonathan Graehl
http://jonathan.graehl.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
6_addr from
a sockaddr*? (I believe Ethernet and other address types may also be mapped
into the IPv6 address space).
I do realize that, if possible, transmission of protocol addresses should be
avoided because of evils such as NAT (although IPv6 may one day give us a truly
global address space)
rent port;
however, this is less than transparent as far as NAT is concerned.
--
Jonathan Graehl
http://jonathan.graehl.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
On Tue, Mar 27, 2001 at 01:12:47PM +0200, Jesper Skriver wrote:
> On Tue, Mar 27, 2001 at 12:45:31PM +0200, Jeroen Ruigrok/Asmodai wrote:
> > [making sure Jesper and Jonathan see this]
> >
> > -On [20010326 18:00], Bill Fenner ([EMAIL PROTECTED]) wrote:
> > >Now
On Tue, Mar 27, 2001 at 06:36:46PM +0200, Jesper Skriver wrote:
> On Tue, Mar 27, 2001 at 10:19:22AM -0600, Jonathan Lemon wrote:
> >
> > I forget why I picked ENETRESET; probably because it was the first
> > thing that leaped out at me when I quickly skimmed over
> >
ave hardware flowcontrol
enabled? Does an ifconfig up/down fix the problem?
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
and
process it in a synchronous fashion outside of my event handling logic. Relying
on undocumented behavior makes me nervous. Are there any other system calls I
should worry about returning EINTR even when I specify SA_RESTART?
Thanks,
--
Jonathan Graehl
http://jonathan.graehl.org/
To Unsubscribe:
On Wed, Apr 04, 2001 at 05:59:53PM -0700, Jonathan Graehl wrote:
> It is my understanding that an unmasked signal will always interrupt a call to
> kevent, even if SA_RESTART is specified in sigaction, or siginterrupt(signo, 0)
> is used.
Yes.
> Can this be officially documented so
ted and or working on this?
There is interest, yes. But there will be no progress without
documentation.
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Actually, you could argue that both should be changed to
2-3 segments, see http://www.aciri.org/floyd/tcp_init_win.html
--
Jonathan
In article
[EMAIL PROTECTED]>
you write:
>
>If there are no strong opinions supporting this feature, should we then
>ask the developers to set the de
In article [EMAIL PROTECTED]> you write:
>-=-=-=-=-=-
>
>Jonathan Lemon wrote:
>> Actually, you could argue that both should be changed to
>> 2-3 segments, see http://www.aciri.org/floyd/tcp_init_win.html
>
>To play with this setting, does this (in /etc/sysct
In article
[EMAIL PROTECTED]>
you write:
>I want to know is there any documentation about functionality of
>callout macros as Stevens Volume II does'nt have much of the details about
>it.
man 9 timeout
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "u
possibility, or else silently
reliant on process termination freeing all descriptors).
--
Jonathan Graehl
http://jonathan.graehl.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Thanks for the suggestion - it does fit the bill, although I have to
getsockopt(SO_SNDBUF on a per-socket basis (I'm using the kqueue
NOTE_LOWAT, which doesn't trigger if I supply a very large number - the
exact SO_SNDBUF needs to be used). I'd honestly just prefer to have the
kernel close the so
> > Problem: close() does not perform an orderly shutdown, does
> not resend
> > unacknowledged data - responds with RST to data/acks sent to me
>
> I suggest that this is a bug.
That is my feeling as well. I am well aware that depending on the
transport layer to ensure delivery of the "last
does play a game of Tribes now and then, so unpredictable
10ms delays would not be fun for them.
--
Jonathan Graehl
http://jonathan.graehl.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
've copied this over to kris, who (IIRC) brought in the new sequence
numbering.
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
ute;
ip_output(m, NULL, ro, ipflags, NULL);
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
ng mail to
-net is probably the best way to reach people who are interested in
the networking stack. When the patch is done, (or when you have something
working), I'm sure that you'll have no problem finding volunteers to
review the code and then commit it.
--
Jonathan
To Unsubscribe: se
handle a larger mtu (e.g: 9000 byte Jumbograms) already have to do
their own checks, and thus don't call this function.
See, for example, any of the gigabit drivers.
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
On Tue, Jun 26, 2001 at 07:56:24AM +1000, Peter Jeremy wrote:
> On 2001-Jun-25 14:25:42 -0500, Jonathan Lemon <[EMAIL PROTECTED]> wrote:
> >On Mon, Jun 25, 2001 at 11:02:55PM +0400, Yar Tikhiy wrote:
> >> Hi there,
> >>
> >> While more and more
f he says
> it's ok, I'll commit it soon and those affected will be able to use the
> old generation scheme.
I don't object; while the security provided by the new scheme is nice,
breaking TIME_WAIT assassination is a serious bug in some environments,
and there should be a way to work
th_seq, tp->last_ack_sent + tp->rcv_wnd)) {
And this probably should be "SEQ_GEQ(..) && SEQ_LEQ(...)".
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
On FreeBSD -CURRENT and -STABLE, packets to broadcast addresses are not
forwarded. For instance, if I have a FreeBSD router with interfaces
192.168.1.1 and 192.168.2.1, and I send packets from 192.168.1.2 to
192.168.2.255, the packets are dropped to the floor. IMO, this is wrong...
but I hav
On Thu, Aug 09, 2001 at 09:20:55AM -0700, Matthew Jacob wrote:
>
> I haven't consulted the RFCs either, but, ahem, I thought this was a major
> point of netmasks and routers and why multicast was invented- to keep
> broadcasts from clogging the world.
It would be nice if all applications support
On Thu, Aug 09, 2001 at 12:23:52PM -0400, Bill Vermillion wrote:
> On Thu, Aug 09, 2001 at 11:36:38AM -0400, Jonathan Chen thus sprach:
>
> > On FreeBSD -CURRENT and -STABLE, packets to broadcast addresses
> > are not forwarded. For instance, if I have a FreeBSD router wit
On Thu, Aug 09, 2001 at 12:57:47PM -0400, Bill Vermillion wrote:
> On Thu, Aug 09, 2001 at 12:30:56PM -0400, Jonathan Chen thus sprach:
> > On Thu, Aug 09, 2001 at 12:23:52PM -0400, Bill Vermillion wrote:
> > > On Thu, Aug 09, 2001 at 11:36:38AM -0400, Jonathan Chen thus sprach:
1 - 100 of 175 matches
Mail list logo
