Bridging FDDI to Ethernet
Does anybody have experience in setting up OpenBSD/FreeBSD/Linux boxes as a bridge between FDDI (Snap) and Ethernet (Gigabit or 100Mb)? I need a bridge to let NetBEUI pass through these topologies. Best would be if the bridge code does support differing mtu's, but this is optional. Yes i know there are standalone solutions out there. If FDDI to Ethernet is not supported yet, it would be helpful for me to know when it will be, or if there are plans to do. Thanks Oliver To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
inet_pton(3) Does Not Replace inet_aton(3)
I am not at all sure whether this is a bug or feature. I was just surprised by the results. If it is a feature, the documentation is misleading. The issue is that inet_aton(3) will correctly understand, "127.1" To be the IP address, 127.0.0.1 Where inet_pton(3) will fail (return a 1). That is, inet_pton(3) only understands dotted quads. The comments in src/lib/libc/net/inet_pton.c clearly show this is the intended behavior. But is that what we want? -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: RFC: MFC M_ZERO usage for bpf.c
On Tue, 27 Nov 2001, Luigi Rizzo wrote:
> On Tue, Nov 27, 2001 at 02:52:49PM -0500, Andrew R. Reiter wrote:
> >
> > Just as a note, I decided against MFC'ing this and similar changes because
> > I didn't feel it was necesary for -STABLE to have this "fix."
>
> why not ? code is more compact (and cache friendly) and readable,
> diffs from HEAD are reduced, no functional changes... I see only
> good things in these MFCs.
>
> While we are on the topic, I would also love to see more consistency
> in the use of macros vs. inline functions. E.g. below we have
>
> MALLOC(d, struct bpf_d *, sizeof(*d), M_BPF, M_WAITOK | M_ZERO);
>
> and
>
> bp = (struct bpf_if *)malloc(sizeof(*bp), M_BPF, M_DONTWAIT | M_ZERO);
>
why cast the thing? it returns a void *
which obviates the need for any casting
> and the same occurs elsewhere for free() and FREE(). This is confusing
> because it leads you into thinking that they are two different things
> while they are not.
>
> cheers
> luigi
>
> > On Tue, 27 Nov 2001, Bruce A. Mah wrote:
> >
> > :Hi--
> > :
> > :I've been reading through src/sys/net/bpf.c, and I noticed that the
> > :changes to make it use M_ZERO haven't been MFC-ed to RELENG_4 yet. Any
> > :objection if I do this? (Nothing broke in my quick testing.)
> > :
> > :Thanks,
> > :
> > :Bruce.
> > :
> > :Index: bpf.c
> > :===
> > :RCS file: /usr/ncvs/src/sys/net/bpf.c,v
> > :retrieving revision 1.59.2.6
> > :diff -u -r1.59.2.6 bpf.c
> > :--- bpf.c 20 Sep 2001 14:31:33 - 1.59.2.6
> > :+++ bpf.c 27 Nov 2001 18:49:45 -
> > :@@ -358,8 +358,7 @@
> > : if (d)
> > : return (EBUSY);
> > : make_dev(&bpf_cdevsw, minor(dev), 0, 0, 0600, "bpf%d", lminor(dev));
> > :- MALLOC(d, struct bpf_d *, sizeof(*d), M_BPF, M_WAITOK);
> > :- bzero(d, sizeof(*d));
> > :+ MALLOC(d, struct bpf_d *, sizeof(*d), M_BPF, M_WAITOK | M_ZERO);
> > : dev->si_drv1 = d;
> > : d->bd_bufsize = bpf_bufsize;
> > : d->bd_sig = SIGIO;
> > :@@ -1285,11 +1284,10 @@
> > : u_int dlt, hdrlen;
> > : {
> > : struct bpf_if *bp;
> > :- bp = (struct bpf_if *)malloc(sizeof(*bp), M_BPF, M_DONTWAIT);
> > :+ bp = (struct bpf_if *)malloc(sizeof(*bp), M_BPF, M_DONTWAIT | M_ZERO);
> > : if (bp == 0)
> > : panic("bpfattach");
> > :
> > :- bp->bif_dlist = 0;
> > : bp->bif_ifp = ifp;
> > : bp->bif_dlt = dlt;
> > :
> > :
> > :
> > :
> >
> > --
> > Andrew R. Reiter
> > [EMAIL PROTECTED]
> > [EMAIL PROTECTED]
> >
> >
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-net" in the body of the message
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-net" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
ip change ? not according to tcpdump.
his post is about an IP address not being reflected "on the wire": Two freebsd 4.4-release boxes are connected over ethernet via a hub (using nics at 10Mbs). The hub is simple in that it doesn't do anything fancy like arp proxying or caching [ A ] --- --- [ B ] | | [ hub ] I change the ip address on A as follows: * ifconfig fxp0 down * ifconfig 192.168.1.33(it was 192.168.1.3) * ifconfig fxp0 up (for good measure!) now, on A: * pinging 192.168.1.33 works * pinging 192.168.1.3 does not -- all good so far now pinging machine B (ping 192.168.1.1) WORKS : 13:13:48.460568 192.168.1.3 > 192.168.1.1: icmp: echo request 13:13:48.460862 192.168.1.1 > 192.168.1.3: icmp: echo reply BUT a tcpdump shows pings coming from the old 192.168.1.3 address. This is a problem as other applications like IKE daemons (isakmpd ported from openbsd) wants to respond to the old 192.168.1.3 which isn't there... causing arp requests... icmp-redirects 13:13:00.297762 192.168.1.1 > 192.168.1.3: ESP(spi=0x70214267,seq=0x51) 13:13:00.298396 arp who-has 192.168.1.3 tell 192.168.1.33 13:13:00.298468 192.168.1.33 > 192.168.1.1: icmp: redirect 192.168.1.3 to host 192.168.1.3 Necxt, I tried doing arp -da on both machines... but to no avail: this time the pings from machine A to B fail with: 13:15:16.914413 192.168.1.3 > 192.168.1.1: icmp: echo request 13:15:17.924035 192.168.1.3 > 192.168.1.1: icmp: echo request 13:15:18.934023 192.168.1.3 > 192.168.1.1: icmp: echo request 13:15:19.944032 192.168.1.3 > 192.168.1.1: icmp: echo request any ideas anyone? tariq --- Information in this electronic mail message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorised. If you are not the intended recipient any use, disclosure, copying or distribution of this message is prohibited and may be unlawful. When addressed to our customers, any information contained in this message is subject to Intelligent Network Technology Ltd Terms & Conditions. --- Take part in the intY 2001 Email Usage survey online at http://www.inty.net/email/survey.html --- intY has automatically scanned this email using Sophos Anti-Virus (www.inty.net) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
solved : ip change ? not according to tcpdump.
apologies - natd was running on the interfaces which causes the effects. well - i didn't know that natd didn't respond to ip address changes... t -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Tariq Rashid Sent: 28 November 2001 14:18 To: [EMAIL PROTECTED] Subject: ip change ? not according to tcpdump. his post is about an IP address not being reflected "on the wire": Two freebsd 4.4-release boxes are connected over ethernet via a hub (using nics at 10Mbs). The hub is simple in that it doesn't do anything fancy like arp proxying or caching [ A ] --- --- [ B ] | | [ hub ] I change the ip address on A as follows: * ifconfig fxp0 down * ifconfig 192.168.1.33(it was 192.168.1.3) * ifconfig fxp0 up (for good measure!) now, on A: * pinging 192.168.1.33 works * pinging 192.168.1.3 does not -- all good so far now pinging machine B (ping 192.168.1.1) WORKS : 13:13:48.460568 192.168.1.3 > 192.168.1.1: icmp: echo request 13:13:48.460862 192.168.1.1 > 192.168.1.3: icmp: echo reply BUT a tcpdump shows pings coming from the old 192.168.1.3 address. This is a problem as other applications like IKE daemons (isakmpd ported from openbsd) wants to respond to the old 192.168.1.3 which isn't there... causing arp requests... icmp-redirects 13:13:00.297762 192.168.1.1 > 192.168.1.3: ESP(spi=0x70214267,seq=0x51) 13:13:00.298396 arp who-has 192.168.1.3 tell 192.168.1.33 13:13:00.298468 192.168.1.33 > 192.168.1.1: icmp: redirect 192.168.1.3 to host 192.168.1.3 Necxt, I tried doing arp -da on both machines... but to no avail: this time the pings from machine A to B fail with: 13:15:16.914413 192.168.1.3 > 192.168.1.1: icmp: echo request 13:15:17.924035 192.168.1.3 > 192.168.1.1: icmp: echo request 13:15:18.934023 192.168.1.3 > 192.168.1.1: icmp: echo request 13:15:19.944032 192.168.1.3 > 192.168.1.1: icmp: echo request any ideas anyone? tariq --- Information in this electronic mail message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorised. If you are not the intended recipient any use, disclosure, copying or distribution of this message is prohibited and may be unlawful. When addressed to our customers, any information contained in this message is subject to Intelligent Network Technology Ltd Terms & Conditions. --- Take part in the intY 2001 Email Usage survey online at http://www.inty.net/email/survey.html --- intY has automatically scanned this email using Sophos Anti-Virus (www.inty.net) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message --- Information in this electronic mail message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorised. If you are not the intended recipient any use, disclosure, copying or distribution of this message is prohibited and may be unlawful. When addressed to our customers, any information contained in this message is subject to Intelligent Network Technology Ltd Terms & Conditions. --- Take part in the intY 2001 Email Usage survey online at http://www.inty.net/email/survey.html --- intY has automatically scanned this email using Sophos Anti-Virus (www.inty.net) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: solved : ip change ? not according to tcpdump.
On Wed, 28 Nov 2001, Tariq Rashid wrote: > > apologies - natd was running on the interfaces which causes the effects. > > well - i didn't know that natd didn't respond to ip address changes... It will, if you run it with the '-dynamic' flag. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
netmask for aliased ip
somebody told me that, when aliasing, the 2nd to ´n´ ipaddress netmask must not be the regular one, but 0x instead. Example: rl0 = 200.200.200.200 netmask 255.255.0.0 rl0:0 (the aliased) 200.200.220.200 netmask 0x [lots more] rl0:3000 200.200.255.200 netmask 0x is it for real?? what is the reason for this? saudações, irado furioso com tudo GNU/Linux user CASSADO explicando o padre marcelo (mala) ´popstar´ rossi: mer%# velha com roupagem nova. por favor, clique aqui: http://www.thehungersite.com e aqui também: http://cf6.uol.com.br/umminuto/ Nettaxi would like to ask for your help in donations to the RED CROSS today! http://www.nyredcross.org/donate/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
inet_pton(3) Does Not Replace inet_aton(3)
< said: > Where inet_pton(3) will fail (return a 1). That is, inet_pton(3) only > understands dotted quads. The comments in src/lib/libc/net/inet_pton.c > clearly show this is the intended behavior. But is that what we want? Yes. The old format is deprecated, obsolete, legacy, however you want to put it. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
get client ip from accept(2) ?
Hello
Colleagues, I have some question about accept(2) functions.
I have wrote the following programm:
---
/* set up the listening tcp socket*/
if ( (l_fd = socket(AF_INET, SOCK_STREAM, 0)) < 0)
{ log_error("socket (tcp) error"); exit(0); }
memset(&l_servaddr,0,sizeof(l_servaddr));
l_servaddr.sin_family = AF_INET;
l_servaddr.sin_addr.s_addr = htonl(INADDR_ANY);
l_servaddr.sin_port= htons(c_tcpport);
if ( bind(l_fd,(struct sockaddr *) &l_servaddr, sizeof(l_servaddr)) < 0)
{ log_error ("bind TCP error"); exit(0); }
if ( listen(l_fd, 32) < 0)
{ log_error("listen error"); exit(0); }
if ( (l_connfd = accept(l_fd,(struct sockaddr *) l_cliaddr, &l_addrlen))
< 0)
{ log_error("accept error"); exit(0); }
I'm trying to find out the client ip that connects to this server.
But l_cliaddr structure is NULL after succesfull accept call.
As I understand from manuals in this structure must be client ip.
Where I'm wrong and how I can get this ip?
Thank you for advance.
--
With best regards.
--
Sergey Artjushkin Network Operation Center
(SKIV-RIPE) ISP "CARAVAN"
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: get client ip from accept(2) ?
On 28 Nov, "Sergey V. Artjushkin" wrote:
> if ( (l_connfd = accept(l_fd,(struct sockaddr *) l_cliaddr, &l_addrlen))
> < 0)
> { log_error("accept error"); exit(0); }
Don't you need an '&' before l_cliaddr above?
Dennis
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
[Bernard Aboba: Announcement of Bill Fenner as IETF Rout]
Congratulations, Bill! I hope this won't suck up all of your Copious Free Time... :-) -GAWollman --- start of forwarded message (RFC 934 encapsulation) --- Message-Id: <[EMAIL PROTECTED]> From: Bernard Aboba <[EMAIL PROTECTED]> Sender: [EMAIL PROTECTED] To: IETF-Announce: ; Subject: Announcement of Bill Fenner as IETF Routing Director Date: Wed, 28 Nov 2001 07:07:21 -0500 The 2000 IETF Nominations Committee has now completed the task of recommending a replacement for the Routing AD slot vacated by the passing of Abha Ahuja, and the IAB has now approved the recommendation. Please join us in welcoming Bill Fenner as IESG Routing Area Director. A word of thanks The RFC 2727 Interim Vacancy process, once invoked, requires the nomcom to complete its deliberations in a short period of time. This required the 2000 nomcom members to put in an intense effort in order to complete the task. I would also like to thank those individuals who agreed to be considered for the Routing AD position, and therefore had to complete their applications in such a short time frame. We hope that the brevity of the Interim Vacancy process does not dissuade you from continuing as a candidate for the other Routing AD slot that is being filled by the 2001 nomcom. The IETF needs you. Our best wishes for your success in the years ahead, The role of non-voting members (from RFC 2727) The nominations committee comprises at least a non-voting Chair, 10 voting volunteers, and 3 non-voting liaisons. The sitting IAB and IESG members each appoint a non-voting liaison to the nominating committee from their current membership who are not sitting in an open position. The Chair of the prior year's nominating committee also serves as a non-voting liaison. The 2000 Nominations Committee Phil Roberts Stuart Cheshire Perry E. Metzger Bill Woodcock Hadriel Kaplan Alain Durand Vijay Srinivasan Hal Sandick David Robinson David Allan Non-voting members: Bernard Aboba (Chair) Avri Doria (Past Chair) Leslie Daigle (IAB Liason) Allison Mankin <[EMAIL PROTECTED]> The role of non-voting members (from RFC 2727) The nominations committee comprises at least a non-voting Chair, 10 voting volunteers, and 3 non-voting liaisons. The sitting IAB and IESG members each appoint a non-voting liaison to the nominating committee from their current membership who are not sitting in an open position. The Chair of the prior year's nominating committee also serves as a non-voting liaison. --- end --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: get client ip from accept(2) ?
You probably forgot to initialize l_addrlen to sizeof(sockaddr_in).
(As well as needing the & before l_cliaddr, but that's probably a
typo as it wouldn't compile without it.)
On Wed, Nov 28, 2001 at 08:37:31PM +0300, Sergey V. Artjushkin wrote:
> Hello
>
> Colleagues, I have some question about accept(2) functions.
> I have wrote the following programm:
>
> ---
>/* set up the listening tcp socket*/
> if ( (l_fd = socket(AF_INET, SOCK_STREAM, 0)) < 0)
> { log_error("socket (tcp) error"); exit(0); }
> memset(&l_servaddr,0,sizeof(l_servaddr));
> l_servaddr.sin_family = AF_INET;
> l_servaddr.sin_addr.s_addr = htonl(INADDR_ANY);
> l_servaddr.sin_port= htons(c_tcpport);
>
> if ( bind(l_fd,(struct sockaddr *) &l_servaddr, sizeof(l_servaddr)) < 0)
> { log_error ("bind TCP error"); exit(0); }
>
> if ( listen(l_fd, 32) < 0)
> { log_error("listen error"); exit(0); }
>
> if ( (l_connfd = accept(l_fd,(struct sockaddr *) l_cliaddr, &l_addrlen))
> < 0)
> { log_error("accept error"); exit(0); }
>
>
> I'm trying to find out the client ip that connects to this server.
> But l_cliaddr structure is NULL after succesfull accept call.
> As I understand from manuals in this structure must be client ip.
> Where I'm wrong and how I can get this ip?
>
> Thank you for advance.
>
> --
> With best regards.
> --
> Sergey Artjushkin Network Operation Center
> (SKIV-RIPE) ISP "CARAVAN"
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-net" in the body of the message
--
Barney Wolff
"Nonetheless, ease and peace had left this people still curiously tough.
They were, if it came to it, difficult to daunt or to kill; and they were,
perhaps, so unwearyingly fond of good things not least because they could,
when put to it, do without them, and could survive rough handling by grief,
foe, or weather in a way that astonished those who did not know them well
and looked no further than their bellies and their well-fed faces." J.R.R.T.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: Intel gigabit driver
Yay..stable jumbo frames! :^) On Wed, 28 Nov 2001, Prafulla Deuskar wrote: > All, > > Intel Corporation has released a gigabit driver for > PRO/1000 series of adapters. > > The driver is available for download from the following > url: > > http://appsr.intel.com/scripts-df/Product_Filter.asp?ProductID=415 > > > The driver will be committed to -CURRENT first and MFC'ed to > -STABLE later. > > > Thanks, > Prafulla > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > --- Geoff Mohler To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Intel gigabit driver
Prafulla Deuskar wrote: > > All, > > Intel Corporation has released a gigabit driver for > PRO/1000 series of adapters. That is funny! jlemon commited his gx driver for the same boards just two weeks ago. What happend at Intel? Their driver is even released under the BSD license! (and the Linux one under the GPL) How come considering their strict NDA policy the last years? > The driver is available for download from the following > url: > > http://appsr.intel.com/scripts-df/Product_Filter.asp?ProductID=415 > > The driver will be committed to -CURRENT first and MFC'ed to > -STABLE later. Really? What about the gx driver? -- Andre To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Intel gigabit driver
> What happend at Intel? Their driver is even released under the > BSD license! (and the Linux one under the GPL) Many Intel software products are released under a BSD-like license. Consider the ACPI CA codebase we use. > > The driver will be committed to -CURRENT first and MFC'ed to > > -STABLE later. > > Really? What about the gx driver? The 'gx' driver was committed so that Jonathan's code would be on record, since he'd spent so much time and effort on it. Testing so far has indicated that the Intel driver is generally superior, but it's not a very BSD-like driver and under some circumstances this can be considered a bad thing. The Intel driver will be the preferred driver for these cards. = Mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: inet_pton(3) Does Not Replace inet_aton(3)
On Wed, Nov 28, 2001 at 12:31:09PM -0500, Garrett Wollman wrote: > < said: > > > Where inet_pton(3) will fail (return a 1). That is, inet_pton(3) only > > understands dotted quads. The comments in src/lib/libc/net/inet_pton.c > > clearly show this is the intended behavior. But is that what we want? > > Yes. The old format is deprecated, obsolete, legacy, however you want > to put it. OK. But I think it should be documented. Index: inet.3 === RCS file: /export/ncvs/src/lib/libc/net/inet.3,v retrieving revision 1.19 diff -u -r1.19 inet.3 --- inet.3 1 Oct 2001 16:08:55 - 1.19 +++ inet.3 29 Nov 2001 00:47:28 - @@ -203,6 +203,14 @@ otherwise, the number is interpreted as decimal). .Pp The +.Fn inet_pton +function only understands Internet addresses written as dotted quads. +Each +.Dq part +may only contain numeric characters and is always interpreted as a +decimal value. +.Pp +The .Fn inet_aton and .Fn inet_ntoa -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: netmask for aliased ip
On Wed, Nov 28, 2001 at 08:37:42AM -0800, [EMAIL PROTECTED] wrote: > > somebody told me that, when aliasing, the 2nd to ´n´ ipaddress netmask must not be >the regular one, but 0x instead. Example: > > rl0 = 200.200.200.200 netmask 255.255.0.0 > rl0:0 (the aliased) 200.200.220.200 netmask 0x > [lots more] > rl0:3000 200.200.255.200 netmask 0x > > is it for real?? what is the reason for this? Somebody told you wrong. When adding an alias _which is on the same logical network_ as other addresses, it should have an 0x mask. That is, only one address on an interface should have the "real" netmask for any one network. The simple explanation for this is that if you have, a.b.c.d/24 a.b.c.e/24 On an interface and you try to initiate a connection to another machine through this interface, should your connection use a.b.c.d or a.b.c.e as the source address? It is ambiguous and can make problems. In your case, the addresses lie on different networks. Each address should have the netmask of the network it is on. Note that you do not have the above problem in this case. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: FreeBSD performing worse than Linux?
[Redirecting to a more-appropriate mailing-list.]
< said:
> I spoke to him on the phone this morning. He replaced it with a 3Com
> card, but there was no significant difference in performance. He's
> currently upgrading to -STABLE, which seems to be a sensible thing to
> do, so we should wait to see what happens then.
We appear to have some big TCP problems in -stable (and presumably in
-current as well). Anyone wishing to look at traces is welcome to
retrieve http://khavrinen.lcs.mit.edu/test{,2,3,4}.tcpd and take a
look. Warning: these files are very, very large:
95Mtest.tcpd
108Mtest2.tcpd
107Mtest3.tcpd
15Mtest4.tcpd
Each trace shows a single large file transfer from a 4.4-stable
machine to my -current desktop over a local-area network. test4 was
aborted about 10% into the transfer so that you have a chance at
looking at the whole thing in xplot. There are multiple pathologies
visible in the results, but a good place to start would be around
:56.44 in test4.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Does 4.4 kernel supports TCP simultaneous open?
Hi, I am tracing the FreeBSD 4.4 kernel and I found that its
TCP seems NOT be able to do simultaneous open according to the source code.
In tcp_input.c, even though code near line #1750,
case TCPS_SYN_RECEIVED:
.
if (tp->t_flags & TF_NEEDFIN)
{ tp->t_state =
TCPS_FIN_WAIT_1; tp->t_flags &=
~TF_NEEDFIN; } else { tp->t_state =
TCPS_ESTABLISHED; callout_reset(tp->tt_keep,
tcp_keepidle,
tcp_timer_keep, tp); }
do change state from SYN_RCVD state to ESTABLISHED, however,
near line 1700 , the code fragment
if (thflags & TH_SYN) { tp = tcp_drop(tp,
ECONNRESET); rstreason = BANDLIM_UNLIMITED; goto
dropwithreset; }
drops a packet with SYN bit set in SYN_RCVD state. I
think this would break TCP's simultaneous open.
Since upon receiving a SYN segment in SYN_SENT state, TCP
switches to SYN_RCVD state and sends a (ACK,SYN) segment to the peer, if the
peer drops segments with SYN bit set during SYN_RCVD state, the simultaneous
open mechanism of TCP would break.
Am I correct?
David.
Does 4.4 FreeBSD kernel supports TCP simultaneous open?
Hi, I am tracing the FreeBSD 4.4 kernel and I found that its
TCP seems NOT be able to do simultaneous open according to the source code.
In tcp_input.c, even though code near line #1750,
case TCPS_SYN_RECEIVED:
.
if (tp->t_flags & TF_NEEDFIN)
{ tp->t_state =
TCPS_FIN_WAIT_1; tp->t_flags &=
~TF_NEEDFIN; } else { tp->t_state =
TCPS_ESTABLISHED; callout_reset(tp->tt_keep,
tcp_keepidle,
tcp_timer_keep, tp); }
do change state from SYN_RCVD state to ESTABLISHED, however,
near line 1700 , the code fragment
if (thflags & TH_SYN) { tp = tcp_drop(tp,
ECONNRESET); rstreason = BANDLIM_UNLIMITED; goto
dropwithreset; }
drops a packet with SYN bit set in SYN_RCVD state. I
think this would break TCP's simultaneous open.
Since upon receiving a SYN segment in SYN_SENT state, TCP
switches to SYN_RCVD state and sends a (ACK,SYN) segment to the peer, if the
peer drops segments with SYN bit set during SYN_RCVD state, the simultaneous
open mechanism of TCP would break.
Am I correct?
David.
Re: netmask for aliased ip
FWIW, the FreeBSD FAQ (10.9) sez this (it's a one-liner that shows the netmask 0x). Regards, Justin On Wednesday, November 28, 2001, at 05:08 , Crist J. Clark wrote: > On Wed, Nov 28, 2001 at 08:37:42AM -0800, [EMAIL PROTECTED] wrote: >> >> somebody told me that, when aliasing, the 2nd to ´n´ ipaddress netmask >> must not be the regular one, but 0x instead. Example: >> >> rl0 = 200.200.200.200 netmask 255.255.0.0 >> rl0:0 (the aliased) 200.200.220.200 netmask 0x >> [lots more] >> rl0:3000 200.200.255.200 netmask 0x >> >> is it for real?? what is the reason for this? > > Somebody told you wrong. When adding an alias _which is on the same > logical network_ as other addresses, it should have an 0x > mask. That is, only one address on an interface should have the "real" > netmask for any one network. > > The simple explanation for this is that if you have, > > a.b.c.d/24 > a.b.c.e/24 > > On an interface and you try to initiate a connection to another > machine through this interface, should your connection use a.b.c.d or > a.b.c.e as the source address? It is ambiguous and can make problems. > > In your case, the addresses lie on different networks. Each address > should have the netmask of the network it is on. Note that you do not > have the above problem in this case. > -- > Crist J. Clark | [EMAIL PROTECTED] >| [EMAIL PROTECTED] > http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message > > -- /~\ The ASCII Justin C. Walker, Curmudgeon-at-large \ / Ribbon Campaign X Against HTML / \ Email! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: netmask for aliased ip
On Thu, Nov 29, 2001 at 09:15:34AM +0500, Ahsan Ali wrote: > > Somebody told you wrong. When adding an alias _which is on the same > > logical network_ as other addresses, it should have an 0x > > mask. That is, only one address on an interface should have the "real" > > netmask for any one network. > > > > The simple explanation for this is that if you have, > > > > a.b.c.d/24 > > a.b.c.e/24 > > > > On an interface and you try to initiate a connection to another > > machine through this interface, should your connection use a.b.c.d or > > a.b.c.e as the source address? It is ambiguous and can make problems. > > > Surely this does not hold true for situations in which you're doing IP based > virtual hosting? Sure it does. > Or is it acceptable because most hosting requests will come > in through the gateway and thus be routed to this IP? Wouldn't that break > testing from local machines in the sense that traffic would HAVE to go > through the router? I am not sure what this means. The traffic will have to go through a gateway to get anywhere. > If all IP's have a /24 netmask and you set your default route through one > specific instance of an interface, wouldn't that be the one thats always > used? For TCP, that is what is always used by default when creating an outbound connection. For incoming connections, the machine will of course reply using the IP address the connection came in on. And a program can always request to use a specific address if it wants to. I am not sure where you see a problem. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Does 4.4 FreeBSD kernel supports TCP simultaneous open?
In article you write:
>-=-=-=-=-=-
>
>Hi, I am tracing the FreeBSD 4.4 kernel and I found that its TCP seems
>NOT be able to do simultaneous open according to the source code. In
>tcp_input.c, even though code near line #1750,
>
>case TCPS_SYN_RECEIVED:
> .
> if (tp->t_flags & TF_NEEDFIN) {
> tp->t_state = TCPS_FIN_WAIT_1;
> tp->t_flags &= ~TF_NEEDFIN;
> } else {
> tp->t_state = TCPS_ESTABLISHED;
> callout_reset(tp->tt_keep, tcp_keepidle,
> tcp_timer_keep, tp);
> }
>
>do change state from SYN_RCVD state to ESTABLISHED, however, near line
>1700 , the code fragment
>
>if (thflags & TH_SYN) {
> tp = tcp_drop(tp, ECONNRESET);
> rstreason = BANDLIM_UNLIMITED;
> goto dropwithreset;
> }
>
>
> drops a packet with SYN bit set in SYN_RCVD state. I think this would
>break TCP's simultaneous open.
>
>Since upon receiving a SYN segment in SYN_SENT state, TCP switches to
>SYN_RCVD state and sends a (ACK,SYN) segment to the peer, if the peer
>drops segments with SYN bit set during SYN_RCVD state, the simultaneous
>open mechanism of TCP would break.
>
>Am I correct?
No. In this case, there are 3 distinct state transitions:
A. send SYN.CLOSED -> SYN_SENT
B. recv SYN.SYN_SENT -> SYN_RECEIVED
C. recv ACK.SYN_RECIEVED -> ESTABLISHED
So dropping a connection when receiving a SYN packet in the SYN_RECEIVED
state is the correct thing to do; this is would be a duplicate SYN. For
a simultaneous open, the peer's SYN is received when the local state is
SYN_SENT.
The error in your logic above is that in step B, only an ACK is sent to
the peer, the SYN is not retransmitted as well.
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: Does 4.4 FreeBSD kernel supports TCP simultaneous open?
Thanks...I know where my problem is now...It's indeed a duplicate SYN. By the way, the tcp_input function is so long and large and there are several goto statements which make reading the code even more difficult. Is this intened to be like this? Even with Steven's TCP/IP Vol.2, it took me three whole days to draw a Visio flow chart of this function. Has anybody ever considered of reorganizing this module? David. > No. In this case, there are 3 distinct state transitions: > > A. send SYN. CLOSED -> SYN_SENT > B. recv SYN. SYN_SENT -> SYN_RECEIVED > C. recv ACK. SYN_RECIEVED -> ESTABLISHED > > So dropping a connection when receiving a SYN packet in the SYN_RECEIVED > state is the correct thing to do; this is would be a duplicate SYN. For > a simultaneous open, the peer's SYN is received when the local state is > SYN_SENT. > > The error in your logic above is that in step B, only an ACK is sent to > the peer, the SYN is not retransmitted as well. > -- > Jonathan > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: netmask for aliased ip
On Wed, Nov 28, 2001 at 10:24:28PM -0800, [EMAIL PROTECTED] wrote: > FWIW, the FreeBSD FAQ (10.9) sez this (it's a one-liner that shows the > netmask 0x). I'll send in a doc PR for this. The ifconfig(8) page gets it right. alias Establish an additional network address for this interface. This is sometimes useful when changing network numbers, and one wishes to accept packets addressed to the old interface. If the address is on the same subnet as the first network address for this interface, a netmask of 0x has to be specified. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: netmask for aliased ip
On Wednesday, November 28, 2001, at 11:52 , Crist J. Clark wrote: > On Wed, Nov 28, 2001 at 10:24:28PM -0800, [EMAIL PROTECTED] wrote: >> FWIW, the FreeBSD FAQ (10.9) sez this (it's a one-liner that shows the >> netmask 0x). > > I'll send in a doc PR for this. The ifconfig(8) page gets it right. > > alias Establish an additional network address for this > interface. This > is sometimes useful when changing network numbers, and one > wishes > to accept packets addressed to the old interface. If the > address > is on the same subnet as the first network address for this > interface, a netmask of 0x has to be specified. From the nitpick front: shouldn't that be "...on the same subnet as an existing network address..."? Regards, Justin --- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics| Men are from Earth. | Women are from Earth. | Deal with it. *--*---* To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Intel gigabit driver
All, Intel Corporation has released a gigabit driver for PRO/1000 series of adapters. The driver is available for download from the following url: http://appsr.intel.com/scripts-df/Product_Filter.asp?ProductID=415 The driver will be committed to -CURRENT first and MFC'ed to -STABLE later. Thanks, Prafulla To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Intel gigabit driver
A belated welcome to being a FreeBSD committer! We look forward eagerly to all contributions you and Intel's experience with networking can bring to us all! -matt On Wed, 28 Nov 2001, Prafulla Deuskar wrote: > All, > > Intel Corporation has released a gigabit driver for > PRO/1000 series of adapters. > > The driver is available for download from the following > url: > > http://appsr.intel.com/scripts-df/Product_Filter.asp?ProductID=415 > > > The driver will be committed to -CURRENT first and MFC'ed to > -STABLE later. > > > Thanks, > Prafulla > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
