> > The error message is kind of misleading, i wonder if we can
> > replace the return value in sys/net/rtsock.c with
> > ENOMSG /* No message of desired type */ ?
>
> I think at one point it was returning ENOENT. There are no good error
> messages for this purpose; programs should do a better j
< said:
> The error message is kind of misleading, i wonder if we can
> replace the return value in sys/net/rtsock.c with
> ENOMSG /* No message of desired type */ ?
I think at one point it was returning ENOENT. There are no good error
messages for this purpose; programs should do a better job
In article [EMAIL PROTECTED]> you
write:
>Thank you very much for your kindly advise.
>
>>The system timer ticks at a rate of 100 Hz on all IA32 processors. (I
>>believe on Alphas it ticks at 1024 Hz but I may be imagining it.)
>>Thus, the period is either 10 ms or 0.98 ms.
>>
>>In historic vers
Luigi Rizzo wrote:
> Does any userland application depend on ESRCH ?
pimd does, but only to decide to generate some log:
routesock.c: 207
if ((rlen = write(routing_socket, (char *)&m_rtmsg, l)) < 0) {
IF_DEBUG(DEBUG_RPF | DEBUG_KERN) {
if (errno == ESRCH)
log(LOG_DEBUG,
Hi,
when you issue a RTM_GET request to the routing socket for a non-existing
route, the write() to the socket fails with errno=3, ESRCH, which
is printed by the "route" command as
route: writing to routing socket: No such process
The error message is kind of misleading, i wonder if we
Thank you very much for your kindly advise.
>The system timer ticks at a rate of 100 Hz on all IA32 processors. (I
>believe on Alphas it ticks at 1024 Hz but I may be imagining it.)
>Thus, the period is either 10 ms or 0.98 ms.
>
>In historic versions of FreeBSD, most TCP timers ticked at 2 Hz w
< said:
> By the way, my running machine is P-III 1GHz with i820 chip and
> FreeBSD-4.0-RELEASE.
> Is the length of time tick for this plathome invert of 1GHz?
> (1/10^-9 [s])? or 10 [ms] (I think it is the time ticks for
> FreeBSD)?
The system timer ticks at a rate of 100 Hz on all IA32 process
Thanks for your advise.
> No. Please take a look at W. Richard Stevens' _TCP/IP Illustrated_
> series, particularly volume 2.
>
I'll try.
> Nothing inside the kernel is measured in milliseconds. TCP parameters
> are measured in timer ticks, the length of which depends on which
> version of Fr
< said:
> Does this program mean that ?
>RTT = (tp)->t_srtt >> (TCP_RTT_SHIFT - TCP_DELTA_SHIFT) [ms]
>RTO = tp->t_rxtcur [ms]
No. Please take a look at W. Richard Stevens' _TCP/IP Illustrated_
series, particularly volume 2.
Nothing inside the kernel is measured in milliseconds. TCP
Thank you for your advise.
>See the function tcp_xmit_timer() in netinet/tcp_input.c.
Does this program mean that ?
RTT = (tp)->t_srtt >> (TCP_RTT_SHIFT - TCP_DELTA_SHIFT) [ms]
RTO = tp->t_rxtcur [ms]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the
followup to my own message... the thing is easy to explain:
For TCP, tcp_output() allocates one mbuf for the header, and then
whenever the data does not fit into the remaining space in the
mbuf, it typically references the data in the clusters stored in
the socket queue. For an MSS-sized packet
On Wed, 24 Jan 2001, Jordan Hubbard wrote:
> > Something just doesn't sit well me. This shouldn't happen in a
> > 100Mbit LAN. This seems like a plain vanilla network transaction, and
> > FreeBSD is failing on something, where other OSes in the same
> > environment don't.
>
> You're almost cer
Hi,
i have been looking at how often a packet which is sent to
an ethernet driver is split over multiple mbufs, and it
seems that this happens for the vast majority of
packets -- basically everything above MHLEN goes into
two mbufs, and MTU-sized TCP packets end up using 3 or
more mbufs.
This is
< said:
> Something just doesn't sit well me. This shouldn't happen in a
> 100Mbit LAN. This seems like a plain vanilla network transaction, and
> FreeBSD is failing on something, where other OSes in the same
> environment don't.
Is your Solaris server attempting to do tinygram avoidance and g
> Something just doesn't sit well me. This shouldn't happen in a
> 100Mbit LAN. This seems like a plain vanilla network transaction, and
> FreeBSD is failing on something, where other OSes in the same
> environment don't.
You're almost certainly correct that there's a misfeature lurking in
ther
it looks like the tcp code is not acking the data when the PUSH
flag is set. It would be useful to generate an immediate ACK
when the PUSH flag is set.
it would be interesting to see if the other sends two full sized
tcp segments if the freebsd stack will then immediately acknowledge
the data.
Hi Jonathan,
On Wed, 24 Jan 2001, Jonathan Lemon wrote:
> >10:49:54.279497 16.1035 > 10.40438: . ack 19433 win 17520 (DF)
> >10:49:54.371025 16.1035 > 10.40438: . ack 21481 win 17520 (DF)
>
> Are you sure the trace has delayed ack turned off?
Sorry, wasn't clear there. Yes, this trace is w
>you are absolutely right that the code was correct at the time
>it was committed -- i think i tried to mention this.
>
>The question is where to move it now. Because it seems to be only
>necessary when we have fragmentation, perhaps the correct place is
>somewhere near the place where fragments a
< said:
> To me this seems incorrect because the firewall can drop the packet,
> divert it to a socket, maybe (not sure) change the output interface,
> pass it to a dummynet pipe, etc.
It's completely bogus (I had that argument with it at the time).
There is no predicting whether the interface q
David,
you are absolutely right that the code was correct at the time
it was committed -- i think i tried to mention this.
The question is where to move it now. Because it seems to be only
necessary when we have fragmentation, perhaps the correct place is
somewhere near the place where fragment
> You can't really assume this will work. FreeBSD has a sysctl
> to disable responses to broadcast/multicast ICMP-echo requests.
You know what, I tried it with Windows machines, that do not reply to
broadcast ping either, and it worked anyway. What gives?
- Original Message -
From:
>the change attached at the end was applied to ip_output()
>long ago -- it checks for room in the interface queue early
>in the delivery process -- but does this before passing the packet
>to the firewall.
>
>To me this seems incorrect because the firewall can drop the packet,
>divert it to a sock
Hi,
> On Wed, 24 Jan 2001 11:34:50 -0600
> Joseph E Eggleston <[EMAIL PROTECTED]> said:
Joe> I'm trying to get mozilla working with ipv6. I've read that the linux
Joe> mozilla is supposed to work with ipv6 by default. I tried installing the
Joe> FreeBSD port of mozilla+ipv6-M18 but it se
Hi,
the change attached at the end was applied to ip_output()
long ago -- it checks for room in the interface queue early
in the delivery process -- but does this before passing the packet
to the firewall.
To me this seems incorrect because the firewall can drop the packet,
divert it to a socket
Hi all,
I'm trying to get mozilla working with ipv6. I've read that the linux
mozilla is supposed to work with ipv6 by default. I tried installing the
FreeBSD port of mozilla+ipv6-M18 but it seg faults immediately. The
linux mozilla release .7 works with ipv4 under linux compatibility mode
but doe
> On Wed, 17 Jan 2001 02:04:26 +0900,
> [EMAIL PROTECTED] said:
>>> Your address prefix length is incorrect..can't remember what the
>>> correct value should be off the top of my head, but it's come up
>>> before so it should be in the archives upon closer examination.
>> It looks like 1
Matus KICZKO wrote:
>
> I'd like to get a list of all tcp connections established between my
> internal network and internet throug divert(4) socket. Running natd
> with -verbose option does not start the daemon and display all packet
> alterations. Is there a way how to list connections handled
In article
[EMAIL PROTECTED]>
you write:
>
>A question for the TCP stack gurus...
>
>We were testing a FreeBSD 4.1 client with a Solaris 7 Oracle server.
>The FreeBSD client would take 10 times longer (60 sec) than a Linux
>client (~6 sec.) to complete an *identical* request. Configuration,
>cl
< said:
> I know that UNIX is not allowed floating point calculation
> in the kernel, so RTT estimator is implemented as using int.
> However, I don't know the method of calculation of the now RTT, RTO
> using t_srtt, t_rttvar in kernel tcpcb and so on.
See the function tcp_xmit_timer() in netin
(This mail is the multi-post to freebsd-net-jp.
I'm sorry for the person who receives the duplicate mail.)
I have a question about the estimation RTT, RTO using
the information in tcpcb (t_srtt, t_rttvar).
I'm trying to estimate network status at the kernel level
using tcpcb information, obtain
On Tue, Jan 23, 2001 at 03:32:41PM -0800, Julian Elischer wrote:
> send a hand crafted arp packet out through the nergraph
> hook on the interface and let the response be put in the table.
This is a side-effect of the ARP packet processing mechanism
described in STD-0037. All inbound ARP packet
On Tue, Jan 23, 2001 at 06:40:14PM -0800, Renaud Waldura wrote:
> An amusing trick to populate the ARP table is to ping the broadcast address.
> Even if hosts do not reply to your ping packet (typically, Windows
> machines), they are entered in the ARP table.
>
> You still have to send a single
I'd like to get a list of all tcp connections established between my
internal network and internet throug divert(4) socket. Running natd
with -verbose option does not start the daemon and display all packet
alterations. Is there a way how to list connections handled by natd only
something like n
A question for the TCP stack gurus...
We were testing a FreeBSD 4.1 client with a Solaris 7 Oracle server.
The FreeBSD client would take 10 times longer (60 sec) than a Linux
client (~6 sec.) to complete an *identical* request. Configuration,
client software and hardware problems have been rule
I'd like to get the settings in the right place so
I'm asking the experts. Freebsd 4.2 release with firewall type set to "simple".
It works but I'd like to allow 2 things
through.
SSH connections from the public side to the
firewall.
Connections to a Web server on the
inside.
Thanks in a
35 matches
Mail list logo
