On Thu, Nov 16, 2000 at 09:19:54AM -0600, Jonathan Lemon wrote:
> On Thu, Nov 16, 2000 at 12:09:36PM +0200, Ruslan Ermilov wrote:
> > Hi!
> >
> > RFC768> If the computed checksum is zero, it is transmitted as all ones
> > RFC768> (the equivalent in one's complement arithmetic). An all zero
> > R
Hi FreeBSD team,
Consider this manipulation on host A:
# netstat -rn
Routing tables
Internet:
DestinationGatewayFlags Refs Use Netif
Expire
127.0.0.1 127.0.0.1 UH 00 lo0
172.16 link#1 UC 0
It seems to be a netmask routing problem.
Can you check the net config ?
Olivier
>
>Can you ping the host you're talking to? The log lines describe
>options in a single LCP request being sent, which apparently
>cannot be sent because there is no route for the target IP addr.
>
>Barney Wolff
>
Hi!
IP_TTL and IP_TOS setsockopt(2) options currently do not take
any effect on raw IP sockets (actually, everything that uses
rip_usrreqs function set). The attached patch fixes this.
Also, I have the question. Should we use MAXTTL constant or
net.inet.ip.ttl MIB variable, as the initial valu
> > So that the same logic applies to TCP packets as well. Currently, we
> > can send a TCP packet with a checksum of 0, which is legal. Of possible
> > interest is that Linux doesn't do this; they alwyas send a non-zero
> > checksum in the TCP case, if a checksum was computed.
> >
> Hmm, but
On Wed, Mar 07, 2001 at 09:40:34AM -0500, Louis A. Mamakos wrote:
>
> > > So that the same logic applies to TCP packets as well. Currently, we
> > > can send a TCP packet with a checksum of 0, which is legal. Of possible
> > > interest is that Linux doesn't do this; they alwyas send a non-zero
> On Wed, Mar 07, 2001 at 09:40:34AM -0500, Louis A. Mamakos wrote:
> >
> > > > So that the same logic applies to TCP packets as well. Currently, we
> > > > can send a TCP packet with a checksum of 0, which is legal. Of possible
> > > > interest is that Linux doesn't do this; they alwyas send a
On Wed, Mar 07, 2001 at 09:58:32AM -0500, Louis A. Mamakos wrote:
> > On Wed, Mar 07, 2001 at 09:40:34AM -0500, Louis A. Mamakos wrote:
> > >
> > > > > So that the same logic applies to TCP packets as well. Currently, we
> > > > > can send a TCP packet with a checksum of 0, which is legal. Of p
> In two's complement arithmetics, yes. What matters here is how the
> the real checkers are implemented. For BSD-derived implementations,
> this does not matter. I don't know if others really exist. RFC 1624
> is pretty clear on this topic. The usual Internet principle is in place
> (from R
Hi All
Just built a new kernel with
options IPFIREWALL
options IPDIVERT
and all went in ok. However, when I
user the ipfw command to add a rule
(or when rc.firewall does) I get the
following error message:-
ipfw: getsocketopt(IP_FW_ADD): Invalid argument
Can anyone point out the obvious mist
On Wed, 7 Mar 2001, Andy [TECC NOPS] wrote:
> Just built a new kernel with
>
> options IPFIREWALL
> options IPDIVERT
>
> and all went in ok. However, when I
> user the ipfw command to add a rule
> (or when rc.firewall does) I get the
> following error message:-
>
> ipfw: getsocketopt(IP_FW_AD
Na did all that. Thanks thou, the answer
was actually in my own email (I think
still build new kernel) aka install
from CDRom and 4.2-STABLE. Sure the
CDRom is 4.2-RELEASE, so when did I
cvsup my kernel src tree! dunno,
reinstalled srcs so hopefully that's
sort it out.
cheers
Ak
> -Origin
On Wed, 7 Mar 2001, Andy [TECC NOPS] wrote:
> Can anyone point out the obvious mistake
> I must be making?
In /etc/rc.conf:
firewall_enable="YES"
I can't remember if you need this even if the kernel is compiled
with IPFIREWALL support or not.
Nick Rogn
On Wed, 7 Mar 2001, Nick Rogness wrote:
> On Wed, 7 Mar 2001, Andy [TECC NOPS] wrote:
>
>
> > Can anyone point out the obvious mistake
> > I must be making?
>
> In /etc/rc.conf:
>
> firewall_enable="YES"
>
> I can't remember if you need this even if the kernel is
In article
<[EMAIL PROTECTED]> Robert
Watson wrote:
>It seems that the ECONNABORTED is the "standard" way to address this
>scenario; it might be an interesting exercise for someone to look at the
>common application suites and see how they respond to various failure
>modes in accept(). It certai
Let's say I had two internal subnets that i'd like to nat with different
external ip's, while also doing static nat on one of each of the internal
ip's. Could i do that by doing something like thils:
rc.conf
natd_flags="-f /etc/natd.conf1"
natd_flags="-f /etc/natd.conf2"
rc.firewall
$fwcmd add
In article [EMAIL PROTECTED]> you write:
>In article
><[EMAIL PROTECTED]> Robert
>Watson wrote:
>
>>It seems that the ECONNABORTED is the "standard" way to address this
>>scenario; it might be an interesting exercise for someone to look at the
>>common application suites and see how they respond t
On Wed, 7 Mar 2001, Peter Brezny wrote:
>
> Let's say I had two internal subnets that i'd like to nat with different
> external ip's, while also doing static nat on one of each of the internal
> ip's. Could i do that by doing something like thils:
>
> rc.conf
> natd_flags="-f /etc/natd.conf1"
On Wed, 7 Mar 2001, Peter Brezny wrote:
>
> Won't your example below show all outbound traffic from the same
> external ip, the ip that natd uses?
>
Yes and No, if the internal machine does not have a
redirect_address statement in natd.conf then it will use the
global i
Several parts of Postfix do: connect() write() close(), where the
close() may happen before the server has accept()ed the connection.
Due to an incompatible change in FreeBSD 4.2-STABLE, this causes
accept() after close() to fail. The already written data is lost.
This is a bad incompatible chan
On Wed, 7 Mar 2001, Nick Rogness wrote:
ACK! Read your message wrong...let me clarify.
> On Wed, 7 Mar 2001, Peter Brezny wrote:
>
> >
> > Let's say I had two internal subnets that i'd like to nat with different
> > external ip's, while also doing static nat on one of each of the int
On Wed, 7 Mar 2001, Nick Rogness wrote:
ACK! I read your email wrong. I responded with the correct
reply...please void the message below.
> >
> > Won't your example below show all outbound traffic from the same
> > external ip, the ip that natd uses?
> >
>
> Yes and N
< said:
> A problem of updating route appears when you delete the IPv4 alias on the
> interface like this:
> # ifconfig xl0 delete 172.16.1.2 netmask 255.255.255.255
> 127.0.0.1 127.0.0.1 UH 00 lo0
> 172.16 link#1 UC 0
Now that the fxp driver seems to be outdated, what is recommended for
those us that build servers on a regular basis? It's a shame, the Intel
cards generally work best under Windoze as well and I hate to start buying
different types of cards.
Tim
To Unsubscribe: send mail to [EMAIL PROTECTED]
w
> Date: Wed, 7 Mar 2001 17:10:09 -0600
> From: Tim <[EMAIL PROTECTED]>
>
> Now that the fxp driver seems to be outdated, what is recommended for
> those us that build servers on a regular basis? It's a shame, the Intel
> cards generally work best under Windoze as well and I hate to start
> buyin
< said:
> Now that the fxp driver seems to be outdated,
Eh? What's ``outdated'' about it?
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Apparently lack of support for newer cards. See the thread on -hackers.
Tim
On Wed, Mar 07, 2001 at 06:38:34PM -0500, Garrett Wollman wrote:
> < said:
>
> > Now that the fxp driver seems to be outdated,
>
> Eh? What's ``outdated'' about it?
>
> -GAWollman
To Unsubscribe: send mail to
On 7 Mar 2001 18:38:44 -0500, in sentex.lists.freebsd.net you wrote:
>< said:
>
>> Now that the fxp driver seems to be outdated,
>
>Eh? What's ``outdated'' about it?
Some of the newer revs are not supported / recognized. Also, there is the
flow control issue with some switches that result in
>Several parts of Postfix do: connect() write() close(), where the
>close() may happen before the server has accept()ed the connection.
>Due to an incompatible change in FreeBSD 4.2-STABLE, this causes
>accept() after close() to fail. The already written data is lost.
>This is a bad incompatible
On Thu, Mar 08, 2001 at 12:52:31PM +0900, [EMAIL PROTECTED] wrote:
>
> >Several parts of Postfix do: connect() write() close(), where the
> >close() may happen before the server has accept()ed the connection.
> >Due to an incompatible change in FreeBSD 4.2-STABLE, this causes
> >accept() after cl
It aint the firewall!!
Further to default routes etc .
I believe that I have cured the problem (final testing after the network
number shift
to the 10.x.y.z range and I connect the phone line!)
Factoids:
A Windoze computers on the network are given IP numbers via DHCP from an NT
Server
31 matches
Mail list logo
