From james at UnLambda.COM  Tue Jan  2 19:59:22 2001
From: james at UnLambda.COM (James A. Crippen)
Date: Tue, 2 Jan 2001 09:59:22 -0900 (AKST)
Subject: Stop forking
In-Reply-To: <3A4DAB96.A44548B0@compulan.de>
Message-ID: <Pine.LNX.4.21.0101020955230.17660-100000@gamma.unlambda.com>

On Sat, 30 Dec 2000, Michael Renzmann wrote:

> Hi James.
> 
> > > > Where should I look to find the code that forks bird into the
> > > > background on startup?  I don't want it to fork.  Instead I want
> > > > to fork it into the background myself from another program.
> > > Already tried the "-d" parameter?
> > Well, that would work but I don't want lots of debug messages.  Do they
> > all come out only on the console, or does this cause debugging info to
> > be written to the syslog as well?
> 
> Hmm, don?t know. I?m using bird since yesterday, so I don?t have much
> experience with it. But you might look at the source to find the code
> that processes the "-d" command line switch. Add another switch that
> does nearly the same, but leaves out the toggle for debug messages. I
> don?t have the source right now (and I?m at home at a windows pc), else
> I could send you a small piece of source that would achieve what you
> want.
> 
> > If this option only writes to the console then that's fine, I can
> > redirect it to /dev/null.  If it writes debugging stuff to the syslog
> > too then that's no good -- I'll choke my logs up with stuff that I
> > don't always need.
> 
> Just try it and you will see if it also writes lots of debug messages to
> the syslog. :)

So far I haven't had any problems with extra debug messages other than the
ones configurable via the conf file and birdc.  Not exactly sure what to
expect though, and I haven't had the time to examine the source closely
for what I want.  Right now I'm having problems with RIP, but I'm betting
that it's my fault and I've misconfigured things again.  Maybe I should
actually sit down and RTFM... :)

If I do find what I want and need to hack on the code I'll be sure to send
a patch to the list.

'james

-- 
James A. Crippen <james at unlambda.com> ,-./-.  Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us   |  |/  | USA, 61.2069 N, 149.766 W,
Y = \f.(\x.f(xx)) (\x.f(xx))         |  |\  | Earth, Sol System,
Y(F) = F(Y(F))                        \_,-_/  Milky Way.



From mj at ucw.cz  Wed Jan  3 00:08:00 2001
From: mj at ucw.cz (Martin Mares)
Date: Wed, 3 Jan 2001 00:08:00 +0100
Subject: Stop forking
In-Reply-To: <Pine.LNX.4.21.0012291059030.17660-100000@gamma.unlambda.com>; from james@UnLambda.COM on Fri, Dec 29, 2000 at 11:03:53AM -0900
References: <Pine.LNX.4.21.0012291059030.17660-100000@gamma.unlambda.com>
Message-ID: <20010103000800.D1390@albireo.ucw.cz>

Hello!

Happy new year to all people at the BIRD list. I've returned from holidays
and started processing the huge piles of mail which I've received, so it
will probably take a couple of days for me to get to your questions
and bug reports.

> Where should I look to find the code that forks bird into the background
> on startup?  I don't want it to fork.  Instead I want to fork it into the
> background myself from another program.

You can find it in sysdep/unix/main.c in main().

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj at ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
The first myth of management is that it exists.


From zyuan1 at cig.mot.com  Thu Jan  4 00:17:38 2001
From: zyuan1 at cig.mot.com (Zheng Yuan {ZYUAN1})
Date: Wed, 3 Jan 2001 17:17:38 -0600
Subject: Is this a typo
Message-ID: <Pine.SGI.4.21.0101031715390.2625-100000@debris63>

Line 64 in CLI.c

if (!(o = c->tx_write) || o->wpos + size > o->end) 

isnt that should be 

if (!(o == c->tx_write) || o->wpos + size > o->end)


BTW, is there anyone who is also interested in studying the source code? I
would be very interested if we could form a study group or something else?

Thanx!



From james at UnLambda.COM  Thu Jan  4 03:15:28 2001
From: james at UnLambda.COM (James A. Crippen)
Date: Wed, 3 Jan 2001 17:15:28 -0900 (AKST)
Subject: Parse error with OSPF area stmt?
Message-ID: <Pine.LNX.4.21.0101031711330.17660-100000@gamma.unlambda.com>

I'm getting consistent parse errors from bird while trying to configure
ospf.  I say something akin to the following:

  protocol ospf {
    ...
    area 0.0.0.0 {
      ...
    };
  }

And I've tried variations like "area 0 {" and "area {", but no luck with
anything.  I always get a parse error from bird on that particular
line.  I took a halfhearted look at the source and couldn't find anything
in particular.  Help!

And yes, I know that areas are somewhat borken, that you can't use more
than one.  I'm not trying to, I'm just trying to follow the documentation
which says to list an area section and put my chosen interfaces inside of
it.

Thanks
'james

-- 
James A. Crippen <james at unlambda.com> ,-./-.  Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us   |  |/  | USA, 61.2069 N, 149.766 W,
Y = \f.(\x.f(xx)) (\x.f(xx))         |  |\  | Earth, Sol System,
Y(F) = F(Y(F))                        \_,-_/  Milky Way.





From feela at ipex.cz  Thu Jan  4 09:51:05 2001
From: feela at ipex.cz (Ondrej Feela Filip)
Date: Thu, 4 Jan 2001 09:51:05 +0100 (CET)
Subject: Parse error with OSPF area stmt?
In-Reply-To: <Pine.LNX.4.21.0101031711330.17660-100000@gamma.unlambda.com>
Message-ID: <Pine.LNX.4.30.0101040950240.28306-100000@zuzana.cb.ipex.cz>

On Wed, 3 Jan 2001, James A. Crippen wrote:

> I'm getting consistent parse errors from bird while trying to configure
> ospf.  I say something akin to the following:
>
>   protocol ospf {
>     ...
>     area 0.0.0.0 {
>       ...
>     };
>   }
>
> And I've tried variations like "area 0 {" and "area {", but no luck with
> anything.  I always get a parse error from bird on that particular
> line.  I took a halfhearted look at the source and couldn't find anything
> in particular.  Help!

Please send me complete bird.conf, I hope I'll help you then.

> And yes, I know that areas are somewhat borken, that you can't use more
> than one.  I'm not trying to, I'm just trying to follow the documentation
> which says to list an area section and put my chosen interfaces inside of
> it.
>
> Thanks
> 'james
>
>

-- 
Ondrej Feela Filip


From mj at ucw.cz  Thu Jan  4 19:10:19 2001
From: mj at ucw.cz (Martin Mares)
Date: Thu, 4 Jan 2001 19:10:19 +0100
Subject: Is this a typo
In-Reply-To: <Pine.SGI.4.21.0101031715390.2625-100000@debris63>; from zyuan1@cig.mot.com on Wed, Jan 03, 2001 at 05:17:38PM -0600
References: <Pine.SGI.4.21.0101031715390.2625-100000@debris63>
Message-ID: <20010104191019.H617@albireo.ucw.cz>

Hello!

> Line 64 in CLI.c
> 
> if (!(o = c->tx_write) || o->wpos + size > o->end) 
> 
> isnt that should be 
> 
> if (!(o == c->tx_write) || o->wpos + size > o->end)

No, it's a real assignment.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj at ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
P.C.M.C.I.A. stands for `People Can't Memorize Computer Industry Acronyms'


From james at UnLambda.COM  Thu Jan  4 20:39:38 2001
From: james at UnLambda.COM (James A. Crippen)
Date: Thu, 4 Jan 2001 10:39:38 -0900 (AKST)
Subject: Is this a typo
In-Reply-To: <20010104191019.H617@albireo.ucw.cz>
Message-ID: <Pine.LNX.4.21.0101041038030.25388-100000@gamma.unlambda.com>

On Thu, 4 Jan 2001, Martin Mares wrote:

> Hello!
> 
> > Line 64 in CLI.c
> > 
> > if (!(o = c->tx_write) || o->wpos + size > o->end) 
> > 
> > isnt that should be 
> > 
> > if (!(o == c->tx_write) || o->wpos + size > o->end)
> 
> No, it's a real assignment.

I love C.  :P

-- 
James A. Crippen <james at unlambda.com> ,-./-.  Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us   |  |/  | USA, 61.2069 N, 149.766 W,
Y = \f.(\x.f(xx)) (\x.f(xx))         |  |\  | Earth, Sol System,
Y(F) = F(Y(F))                        \_,-_/  Milky Way.



From james at UnLambda.COM  Thu Jan  4 20:43:22 2001
From: james at UnLambda.COM (James A. Crippen)
Date: Thu, 4 Jan 2001 10:43:22 -0900 (AKST)
Subject: Parse error with OSPF area stmt?
In-Reply-To: <Pine.LNX.4.30.0101040950240.28306-100000@zuzana.cb.ipex.cz>
Message-ID: <Pine.LNX.4.21.0101041040320.25388-100000@gamma.unlambda.com>

On Thu, 4 Jan 2001, Ondrej Feela Filip wrote:

> On Wed, 3 Jan 2001, James A. Crippen wrote:
> 
> > I'm getting consistent parse errors from bird while trying to configure
> > ospf.  I say something akin to the following:
> >
> >   protocol ospf {
> >     ...
> >     area 0.0.0.0 {
> >       ...
> >     };
> >   }
> >
> > And I've tried variations like "area 0 {" and "area {", but no luck with
> > anything.  I always get a parse error from bird on that particular
> > line.  I took a halfhearted look at the source and couldn't find anything
> > in particular.  Help!
> 
> Please send me complete bird.conf, I hope I'll help you then.

Okay, here it is.

---8<--- cut here ---8<---

log syslog all;

# Turn on global debugging of all protocols
debug protocols all;

protocol direct {
  interface "*";
}

protocol kernel {
  learn yes;
  persist no;
  scan time 20;
  import all;
  export all;
}

protocol device {
  scan time 20;
}

protocol static {
  debug all;
}

#protocol rip {
#  debug all;
#  honor always;
#  authentication none;
#  interface "*" { mode broadcast; };
#  import all;
#  export all;
#}  

protocol ospf {
# old OSPFv2 compat
  rfc1583compat no;

  import all;
  export all;

  area 0.0.0.0 {
    tick 10;
  
    interface "eth0" {
      cost 10;
      stub no;
      hello 10;
      poll 20;
      retransmit 5;
      priority 1;
      wait 40;
      dead count 6;
      type broadcast;
      strict nonbroadcast no;
      authentication none;
      password "foobar";
#      neighbors { ... };
    };

    interface "eth1" {
      cost 10;
      stub no;
      hello 10;
      poll 20;
      retransmit 5;
      priority 1;
      wait 40;
      dead count 6;
      type broadcast;
      strict nonbroadcast no;
      authentication none;
      password "foobar";
#      neighbors { ... };
    };

    interface "eth2" {
      cost 10;
      stub no;
      hello 10;
      poll 20;
      retransmit 5;
      priority 1;
      wait 40;
      dead count 6;
      type broadcast;
      strict nonbroadcast no;
      authentication none;
      password "foobar";
#      neighbors { ... };
    };
  };
}

---8<--- cut here ---8<---

'james

-- 
James A. Crippen <james at unlambda.com> ,-./-.  Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us   |  |/  | USA, 61.2069 N, 149.766 W,
Y = \f.(\x.f(xx)) (\x.f(xx))         |  |\  | Earth, Sol System,
Y(F) = F(Y(F))                        \_,-_/  Milky Way.



From james at UnLambda.COM  Fri Jan  5 02:11:26 2001
From: james at UnLambda.COM (James A. Crippen)
Date: Thu, 4 Jan 2001 16:11:26 -0900 (AKST)
Subject: Parse error with OSPF area stmt?
In-Reply-To: <Pine.LNX.4.21.0101041040320.25388-100000@gamma.unlambda.com>
Message-ID: <Pine.LNX.4.21.0101041607160.25388-100000@gamma.unlambda.com>

On Thu, 4 Jan 2001, James A. Crippen wrote:

> On Thu, 4 Jan 2001, Ondrej Feela Filip wrote:
> 
> > On Wed, 3 Jan 2001, James A. Crippen wrote:
[...]
> > Please send me complete bird.conf, I hope I'll help you then.
> 
> Okay, here it is.
> 
> ---8<--- cut here ---8<---
> 
> log syslog all;
> 
> # Turn on global debugging of all protocols
> debug protocols all;
> 
> protocol direct {
>   interface "*";
> }
> 
> protocol kernel {
>   learn yes;
>   persist no;
>   scan time 20;
>   import all;
>   export all;
> }
> 
> protocol device {
>   scan time 20;
> }
> 
> protocol static {
>   debug all;
> }
> 
> #protocol rip {
> #  debug all;
> #  honor always;
> #  authentication none;
> #  interface "*" { mode broadcast; };
> #  import all;
> #  export all;
> #}  
> 
> protocol ospf {
> # old OSPFv2 compat
>   rfc1583compat no;
> 
>   import all;
>   export all;
> 
>   area 0.0.0.0 {
>     tick 10;
>   
>     interface "eth0" {
>       cost 10;
>       stub no;
>       hello 10;
>       poll 20;
>       retransmit 5;
>       priority 1;
>       wait 40;
>       dead count 6;
>       type broadcast;
>       strict nonbroadcast no;
>       authentication none;
>       password "foobar";
> #      neighbors { ... };
>     };
> 
>     interface "eth1" {
>       cost 10;
>       stub no;
>       hello 10;
>       poll 20;
>       retransmit 5;
>       priority 1;
>       wait 40;
>       dead count 6;
>       type broadcast;
>       strict nonbroadcast no;
>       authentication none;
>       password "foobar";
> #      neighbors { ... };
>     };
> 
>     interface "eth2" {
>       cost 10;
>       stub no;
>       hello 10;
>       poll 20;
>       retransmit 5;
>       priority 1;
>       wait 40;
>       dead count 6;
>       type broadcast;
>       strict nonbroadcast no;
>       authentication none;
>       password "foobar";
> #      neighbors { ... };
>     };
>   };
> }
> 
> ---8<--- cut here ---8<---

I removed the "rfc1583compat no;" line and it works fine.  The parser is
complaining about the line below where it seems to die, I think.  I just
tried with the following:

protocol ospf {
  rfc1583compat no;
*  import all;
  export all;
  ...
}

And the parser complained about the line marked (*).  Removal of the line
above this (the one containing "rfc1583compat no;") fixes the
problem.  Any idea what's happening here?  This is a completely repeatable
bug.

'james

-- 
James A. Crippen <james at unlambda.com> ,-./-.  Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us   |  |/  | USA, 61.2069 N, 149.766 W,
Y = \f.(\x.f(xx)) (\x.f(xx))         |  |\  | Earth, Sol System,
Y(F) = F(Y(F))                        \_,-_/  Milky Way.



From mrenzmann at compulan.de  Fri Jan  5 11:30:43 2001
From: mrenzmann at compulan.de (Michael Renzmann)
Date: Fri, 5 Jan 2001 11:30:43 +0100
Subject: Parse error with OSPF area stmt?
In-Reply-To: <Pine.LNX.4.21.0101041607160.25388-100000@gamma.unlambda.com>
References: <Pine.LNX.4.21.0101041040320.25388-100000@gamma.unlambda.com>
	<Pine.LNX.4.21.0101041607160.25388-100000@gamma.unlambda.com>
Message-ID: <20010105113043.04584ded.mrenzmann@compulan.de>

Hi.

> I removed the "rfc1583compat no;" line and it works fine.  The parser is
> complaining about the line below where it seems to die, I think.  I just
> tried with the following:
> 
> protocol ospf {
>   rfc1583compat no;
> *  import all;
>   export all;
>   ...
> }
> 
> And the parser complained about the line marked (*).  Removal of the line
> above this (the one containing "rfc1583compat no;") fixes the
> problem.  Any idea what's happening here?  This is a completely repeatable
> bug.

Did you try to move that line (rfc...) some lines below (for example between
"import all;" and "export all;")? Where does the parser die then?

> 'james

Bye, Mike
-- 
------------------------------------
  CompuLAN Europe GmbH
  Development - Wireless Solutions
------------------------------------


From james at UnLambda.COM  Fri Jan  5 20:29:25 2001
From: james at UnLambda.COM (James A. Crippen)
Date: Fri, 5 Jan 2001 10:29:25 -0900 (AKST)
Subject: Parse error with OSPF area stmt?
In-Reply-To: <20010105113043.04584ded.mrenzmann@compulan.de>
Message-ID: <Pine.LNX.4.21.0101051028190.25624-100000@gamma.unlambda.com>

On Fri, 5 Jan 2001, Michael Renzmann wrote:

> Hi.
> 
> > I removed the "rfc1583compat no;" line and it works fine.  The parser is
> > complaining about the line below where it seems to die, I think.  I just
> > tried with the following:
> > 
> > protocol ospf {
> >   rfc1583compat no;
> > *  import all;
> >   export all;
> >   ...
> > }
> > 
> > And the parser complained about the line marked (*).  Removal of the line
> > above this (the one containing "rfc1583compat no;") fixes the
> > problem.  Any idea what's happening here?  This is a completely repeatable
> > bug.
> 
> Did you try to move that line (rfc...) some lines below (for example between
> "import all;" and "export all;")? Where does the parser die then?

I moved it below the area stmt (below my interface declarations) and the
parser dies one line after the "rfc1583compat no;" line.  Totally
reliable.

I guess I could run it under gdb to see why it was dying.  I'll do that
when I get a chance.

'james

-- 
James A. Crippen <james at unlambda.com> ,-./-.  Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us   |  |/  | USA, 61.2069 N, 149.766 W,
Y = \f.(\x.f(xx)) (\x.f(xx))         |  |\  | Earth, Sol System,
Y(F) = F(Y(F))                        \_,-_/  Milky Way.



From james at UnLambda.COM  Fri Jan  5 23:51:00 2001
From: james at UnLambda.COM (James A. Crippen)
Date: Fri, 5 Jan 2001 13:51:00 -0900 (AKST)
Subject: OSPF "bad hello packet"
Message-ID: <Pine.LNX.4.21.0101051348530.25624-100000@gamma.unlambda.com>

I'm getting "bad hello packet from 10.1.1.23 received: bad netmask
255.255.255.0" even though there's really nothing wrong with this netmask
(I'm using 10.1.1.0/24 and 10.2.2.0/24 for some testing).

Is there any reason why ospf thinks this is a bad netmask?  Should I just
ignore it?

Thanks!
'james

-- 
James A. Crippen <james at unlambda.com> ,-./-.  Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us   |  |/  | USA, 61.2069 N, 149.766 W,
Y = \f.(\x.f(xx)) (\x.f(xx))         |  |\  | Earth, Sol System,
Y(F) = F(Y(F))                        \_,-_/  Milky Way.



From zyuan1 at cig.mot.com  Sat Jan  6 00:12:19 2001
From: zyuan1 at cig.mot.com (Zheng Yuan {ZYUAN1})
Date: Fri, 5 Jan 2001 17:12:19 -0600
Subject: Is this func correct?
Message-ID: <Pine.SGI.4.21.0101051709520.12469-100000@debris63>

Hi, All

Maybe i totally miss the point, is this func correct: int
password_same(struct password_item *old, struct password_item *new) {
  if (old == new)
    return 1;
  if ((!old) || (!new))
    return 0;
  return ((old->from == new->from) &&
	  (old->to == new->to) &&
	  (old->passive == new->passive) &&
	  password_same(old, new));
}

or the last line should be 
  return ((old->from == new->from) &&
          (old->to == new->to) &&
          (old->passive == new->passive) &&
          password_same(old->next, new->next)); or compare old->password
with new->password



From feela at ipex.cz  Sat Jan  6 01:06:55 2001
From: feela at ipex.cz (Ondrej Feela Filip)
Date: Sat, 6 Jan 2001 01:06:55 +0100 (CET)
Subject: OSPF "bad hello packet"
In-Reply-To: <Pine.LNX.4.21.0101051348530.25624-100000@gamma.unlambda.com>
Message-ID: <Pine.LNX.4.30.0101060105070.26271-100000@zuzana.cb.ipex.cz>

On Fri, 5 Jan 2001, James A. Crippen wrote:

> I'm getting "bad hello packet from 10.1.1.23 received: bad netmask
> 255.255.255.0" even though there's really nothing wrong with this netmask
> (I'm using 10.1.1.0/24 and 10.2.2.0/24 for some testing).

Are you sure, that all interfaces connected to network 10.1.1.0/24 have
the same netmask?

>
> Is there any reason why ospf thinks this is a bad netmask?  Should I just
> ignore it?

Probably 10.1.1.23 has a different netmask than the router running BIRD.

>
> Thanks!
> 'james
>

		Kind regards
				Feela

>

-- 
Ondrej Feela Filip


From feela at ipex.cz  Sat Jan  6 01:11:14 2001
From: feela at ipex.cz (Ondrej Feela Filip)
Date: Sat, 6 Jan 2001 01:11:14 +0100 (CET)
Subject: Parse error with OSPF area stmt?
In-Reply-To: <Pine.LNX.4.21.0101051028190.25624-100000@gamma.unlambda.com>
Message-ID: <Pine.LNX.4.30.0101060110260.26271-100000@zuzana.cb.ipex.cz>

On Fri, 5 Jan 2001, James A. Crippen wrote:

> On Fri, 5 Jan 2001, Michael Renzmann wrote:
>
> > Hi.
> >
> > > I removed the "rfc1583compat no;" line and it works fine.  The parser is
> > > complaining about the line below where it seems to die, I think.  I just
> > > tried with the following:
> > >
> > > protocol ospf {
> > >   rfc1583compat no;
> > > *  import all;
> > >   export all;
> > >   ...
> > > }
> > >
> > > And the parser complained about the line marked (*).  Removal of the line
> > > above this (the one containing "rfc1583compat no;") fixes the
> > > problem.  Any idea what's happening here?  This is a completely repeatable
> > > bug.
> >
> > Did you try to move that line (rfc...) some lines below (for example between
> > "import all;" and "export all;")? Where does the parser die then?
>
> I moved it below the area stmt (below my interface declarations) and the
> parser dies one line after the "rfc1583compat no;" line.  Totally
> reliable.
>
> I guess I could run it under gdb to see why it was dying.  I'll do that
> when I get a chance.

Hmm, to be true, rfc1583compat switch is not used now. So simple comment
it out. I'll look at it in next version.

				Feela


>
> 'james
>
>

-- 
Ondrej Feela Filip


From james at UnLambda.COM  Sat Jan  6 02:32:09 2001
From: james at UnLambda.COM (James A. Crippen)
Date: Fri, 5 Jan 2001 16:32:09 -0900 (AKST)
Subject: OSPF "bad hello packet"
In-Reply-To: <Pine.LNX.4.30.0101060105070.26271-100000@zuzana.cb.ipex.cz>
Message-ID: <Pine.LNX.4.21.0101051556330.25624-100000@gamma.unlambda.com>

On Sat, 6 Jan 2001, Ondrej Feela Filip wrote:

> On Fri, 5 Jan 2001, James A. Crippen wrote:
> 
> > I'm getting "bad hello packet from 10.1.1.23 received: bad netmask
> > 255.255.255.0" even though there's really nothing wrong with this netmask
> > (I'm using 10.1.1.0/24 and 10.2.2.0/24 for some testing).
> 
> Are you sure, that all interfaces connected to network 10.1.1.0/24 have
> the same netmask?

Yes, see below.
 
> > Is there any reason why ospf thinks this is a bad netmask?  Should I just
> > ignore it?
> 
> Probably 10.1.1.23 has a different netmask than the router running BIRD.

Both are bird routers.  They're both connected to an isolated network on
one 100Mbps hub.  The network looks like this:

                10.2.2.0/24 -----+-----
                                 |10.2.2.23
                                 B
                        10.1.1.23|10.10.10.23
  10.1.1.0/24 ----------+--------+---------+------------ 10.10.10.0/24
               10.1.1.42|                  |10.1.1.1
                        A                  C
           12.17.190.232|                  |12.17.190.220
  12.17.190.224/28 -----+--------+---------+------------ 12.17.190.208/28
                    12.17.190.225|12.17.190.209
                                 D
                                 |12.17.190.161
                                 |
                                \|/
                                 V
                           The Internet

(I apologize for the horrible ASCII art.)  Basically 12.17.190.224/28 and
12.17.190.208/28 are subnets on the same ethernet segment.  /D/ is the
primary router between them, as well as the default gateway to the rest of
the Internet.  /A/ and /C/ are connected to this ethernet segment but on
different subnets, /A/ on 12.17.190.224/28 and /C/ on 12.17.190.208/28.  
Neither /A/ nor /C/ communicate routing information to /D/, thus all the
10 networks are invisible to the Internet.  Both /A/ and /C/ are connected
to another ethernet segment which is also connected to /B/.  /A/, /B/, and
/C/ all have interfaces on 10.1.1.0/24.  /B/ also has another interface on
the same ethernet segment but on a different subnet, 10.10.10.0/24.  This
is just a stub so I can watch another route propagate.  /B/ is connected
to yet another segment, this having only the 10.2.2.0/24 subnet on it, and
/B/ is the only connected router.

BTW, /A/ does not run any routing protocols.  It's my workstation which is
connected to the two ethernet segments so I can see the network traffic.

With that, I'm seeing the "Bad OSPF hello packet from 10.1.1.23


From james at UnLambda.COM  Sat Jan  6 02:34:23 2001
From: james at UnLambda.COM (James A. Crippen)
Date: Fri, 5 Jan 2001 16:34:23 -0900 (AKST)
Subject: Parse error with OSPF area stmt?
In-Reply-To: <Pine.LNX.4.30.0101060110260.26271-100000@zuzana.cb.ipex.cz>
Message-ID: <Pine.LNX.4.21.0101051632260.25624-100000@gamma.unlambda.com>

On Sat, 6 Jan 2001, Ondrej Feela Filip wrote:

[...]
> Hmm, to be true, rfc1583compat switch is not used now. So simple comment
> it out. I'll look at it in next version.

I see, so it shows up in the parser but it's not actually working.  That's
my answer.  Thanks!  I'll just not use it.  The manual says that the
default is no, which is what I want.  I just wanted explicit control over
that if I needed it.  I presume that RFC 1538 compatibility hasn't been
implemented then?

'james

-- 
James A. Crippen <james at unlambda.com> ,-./-.  Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us   |  |/  | USA, 61.2069 N, 149.766 W,
Y = \f.(\x.f(xx)) (\x.f(xx))         |  |\  | Earth, Sol System,
Y(F) = F(Y(F))                        \_,-_/  Milky Way.




From usernameprom at earthlink.net  Sat Jan  6 19:59:55 2001
From: usernameprom at earthlink.net (usernameprom at earthlink.net)
Date: Sat, 6 Jan 2001 19:59:55
Subject: Your business needs to be At The TOP!!!
Message-ID: <332.783101.189563@modelnetworking.net>

Top Position Solutions For Your Site

We can list your website in all major Search Engines and achieve 
Top 10 positions. GUARANTEED! 


You pay only after results are shown to you.

Not only we submit or register your site,
We guarantee you Top 10 positions. 
If people cannot find your business in the first 
30 matches of a search, then designing and hosting your site was 
a waste of time, money and hopes.

* Properly Optimized Files Made For You!
* Your Optimized Files are completely cloaked!
* Surfers will go to your Home Page. We do not use any 
redirection technique.

We key on the following major search engines:
* Yahoo-Looksmart-AltaVista-Dogpile-WebCrawler-Lycos-
* Excite-iwon-AskJeeves-AOL Search-Netscape-HotBot-MSN-
* GO(Infoseek)-NBCi(Snap)-Google-BrainFox-
* Open Directory-Findwhat-Fast Search(alltheweb)-Goto-Canada.

Remember,You PAY only after results are shown to you. 
For more information please click here: 
mailto:fastinfo123 at earthlink.net?subject=More_Information


Or You may call at:


718-583-1771

Monday - Friday From 11:00 AM To 7:00 PM Eastern Time






------------------------------------------------------------

To be removed from this list, please mail to: 
mailto:usernameprom at earthlink.net?subject=Remove
subject line and you will be removed from our list.

------------------------------------------------------------
 
 
 
 
 
 


From pavel at ucw.cz  Mon Jan  8 11:53:56 2001
From: pavel at ucw.cz (Pavel Machek)
Date: Mon, 8 Jan 2001 11:53:56 +0100
Subject: Is this func correct?
In-Reply-To: <Pine.SGI.4.21.0101051709520.12469-100000@debris63>; from zyuan1@cig.mot.com on Fri, Jan 05, 2001 at 05:12:19PM -0600
References: <Pine.SGI.4.21.0101051709520.12469-100000@debris63>
Message-ID: <20010108115355.B15918@atrey.karlin.mff.cuni.cz>

Hi!

> Maybe i totally miss the point, is this func correct: int
> password_same(struct password_item *old, struct password_item *new) {
>   if (old == new)
>     return 1;
>   if ((!old) || (!new))
>     return 0;
>   return ((old->from == new->from) &&
> 	  (old->to == new->to) &&
> 	  (old->passive == new->passive) &&
> 	  password_same(old, new));
> }
> 
> or the last line should be 
>   return ((old->from == new->from) &&
>           (old->to == new->to) &&
>           (old->passive == new->passive) &&
>           password_same(old->next, new->next)); or compare old->password
> with new->password

That probably should be old->next, because otherwise it looks like
infinite loop to me.
								Pavel
-- 
The best software in life is free (not shareware)!		Pavel
GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+


From mj at ucw.cz  Mon Jan  8 12:13:02 2001
From: mj at ucw.cz (Martin Mares)
Date: Mon, 8 Jan 2001 12:13:02 +0100
Subject: Is this func correct?
In-Reply-To: <Pine.SGI.4.21.0101051709520.12469-100000@debris63>; from zyuan1@cig.mot.com on Fri, Jan 05, 2001 at 05:12:19PM -0600
References: <Pine.SGI.4.21.0101051709520.12469-100000@debris63>
Message-ID: <20010108121302.G396@albireo.ucw.cz>

Hi!

> Maybe i totally miss the point, is this func correct: int
> password_same(struct password_item *old, struct password_item *new) {
>   if (old == new)
>     return 1;
>   if ((!old) || (!new))
>     return 0;
>   return ((old->from == new->from) &&
> 	  (old->to == new->to) &&
> 	  (old->passive == new->passive) &&
> 	  password_same(old, new));
> }

Well spotted. Here is a fix:

diff -u -r1.7 password.c
--- password.c	2000/05/16 15:02:27	1.7
+++ password.c	2001/01/08 11:12:08
@@ -54,12 +54,19 @@
 int
 password_same(struct password_item *old, struct password_item *new)
 {
-  if (old == new)
-    return 1;
-  if ((!old) || (!new))
-    return 0;
-  return ((old->from == new->from) &&
-	  (old->to == new->to) &&
-	  (old->passive == new->passive) &&
-	  password_same(old, new));
+  for(;;)
+    {
+      if (old == new)
+	return 1;
+      if (!old || !new)
+	return 0;
+      if (old->from    != new->from    ||
+	  old->to      != new->to      ||
+	  old->passive != new->passive ||
+	  old->id      != new->id      ||
+	  strcmp(old->password, new->password))
+	return 0;
+      old = old->next;
+      new = new->next;
+    }
 }

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj at ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Light-year? One-third less calories than a regular year.


From james at UnLambda.COM  Fri Jan 12 08:00:26 2001
From: james at UnLambda.COM (James A. Crippen)
Date: Thu, 11 Jan 2001 22:00:26 -0900 (AKST)
Subject: Routing over aliases?
Message-ID: <Pine.LNX.4.21.0101112148190.1862-100000@gamma.unlambda.com>


From zyuan1 at cig.mot.com  Sat Jan 13 00:36:21 2001
From: zyuan1 at cig.mot.com (Zheng Yuan {ZYUAN1})
Date: Fri, 12 Jan 2001 17:36:21 -0600
Subject: About func in lists.c
Message-ID: <Pine.SGI.4.21.0101121730580.12469-100000@debris63>

Hi, all
 
i have a question about func as bellows

/**
 * add_head - prepend a node to a list
 * @l: linked list
 * @n: list node
 *
 * add_head() takes a node @n and prepends it at the start of the list @l.
 */ LIST_INLINE void add_head(list *l, node *n) {
  node *z = l->head;
  n->next = z;
  n->prev = (node *) &l->head;
  z->prev = n;
  l->head = n; }

isnt that we should change n->prev = (node *) &l->head to n->prev = (node
*) &l->null



From mj at ucw.cz  Sat Jan 13 22:22:33 2001
From: mj at ucw.cz (Martin Mares)
Date: Sat, 13 Jan 2001 22:22:33 +0100
Subject: About func in lists.c
In-Reply-To: <Pine.SGI.4.21.0101121730580.12469-100000@debris63>; from zyuan1@cig.mot.com on Fri, Jan 12, 2001 at 05:36:21PM -0600
References: <Pine.SGI.4.21.0101121730580.12469-100000@debris63>
Message-ID: <20010113222233.C626@albireo.ucw.cz>

Hi!

> isnt that we should change n->prev = (node *) &l->head to n->prev = (node
> *) &l->null

No.  I admit the list structure is very tricky and also somewhat awkward,
but it's both efficient and easy to manipulate once one understand the
basic trick: The list head always contains two synthetic nodes which are
always present in the list: the head and the tail. But because the `next'
entry of the tail and the `prev' entry of the head are both NULL, the
nodes can be overlayed over each other:

	head	head_node.next
	null	head_node.prev	tail_node.next
	tail			tail_node.prev

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj at ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
And God said: E = 1/2mv^2 - Ze^2/r ...and there *WAS* light!


From pavel at ucw.cz  Sun Jan 14 21:20:40 2001
From: pavel at ucw.cz (Pavel Machek)
Date: Sun, 14 Jan 2001 21:20:40 +0100
Subject: About func in lists.c
In-Reply-To: <20010113222233.C626@albireo.ucw.cz>; from mj@ucw.cz on Sat, Jan 13, 2001 at 10:22:33PM +0100
References: <Pine.SGI.4.21.0101121730580.12469-100000@debris63> <20010113222233.C626@albireo.ucw.cz>
Message-ID: <20010114212040.A20293@atrey.karlin.mff.cuni.cz>

Hi!

> > isnt that we should change n->prev = (node *) &l->head to n->prev = (node
> > *) &l->null
> 
> No.  I admit the list structure is very tricky and also somewhat awkward,
> but it's both efficient and easy to manipulate once one understand the
> basic trick: The list head always contains two synthetic nodes which are
> always present in the list: the head and the tail. But because the `next'
> entry of the tail and the `prev' entry of the head are both NULL, the
> nodes can be overlayed over each other:
> 
> 	head	head_node.next
> 	null	head_node.prev	tail_node.next
> 	tail			tail_node.prev
> 

Maybe this mail should be taken as a comment and pasted at begining of
lists.h?
								Pavel
-- 
The best software in life is free (not shareware)!		Pavel
GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+


From mj at ucw.cz  Mon Jan 15 10:24:47 2001
From: mj at ucw.cz (Martin Mares)
Date: Mon, 15 Jan 2001 10:24:47 +0100
Subject: About func in lists.c
In-Reply-To: <20010114212040.A20293@atrey.karlin.mff.cuni.cz>; from pavel@ucw.cz on Sun, Jan 14, 2001 at 09:20:40PM +0100
References: <Pine.SGI.4.21.0101121730580.12469-100000@debris63> <20010113222233.C626@albireo.ucw.cz> <20010114212040.A20293@atrey.karlin.mff.cuni.cz>
Message-ID: <20010115102447.C605@albireo.ucw.cz>

Hi!

> Maybe this mail should be taken as a comment and pasted at begining of
> lists.h?

Good idea, done that.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj at ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
God is real, unless declared integer.


From zyuan1 at cig.mot.com  Tue Jan 16 18:57:40 2001
From: zyuan1 at cig.mot.com (Zheng Yuan {ZYUAN1})
Date: Tue, 16 Jan 2001 11:57:40 -0600
Subject: About func in mempool.c
In-Reply-To: <20010113222233.C626@albireo.ucw.cz>
Message-ID: <Pine.SGI.4.21.0101161151490.12469-100000@debris63>

in 

void * lp_alloc(linpool *m, unsigned size) {
  byte *a = (byte *) ALIGN((unsigned long) m->ptr, CPU_STRUCT_ALIGN);
  byte *e = a + size;
  if (e <= m->end)
    {
      m->ptr = e;
      return a;
    }
  else
    {
      struct lp_chunk *c;
      if (size >= m->threshold)
	{
	  /* Too large => allocate large chunk */
	  c = xmalloc(sizeof(struct lp_chunk) + size);
	  m->total_large += size;
	  c->next = m->first_large;
	  m->first_large = c->next;
	  c->size = size;
	}
      else
	{
	  if (m->current)
	    {
	      /* Still have free chunks from previous incarnation (before
lp_flush()) */
	      c = m->current;
	      m->current = c->next;
	    }
	  else
	    {
	      /* Need to allocate a new chunk */
	      c = xmalloc(sizeof(struct lp_chunk) + m->chunk_size);
	      m->total += m->chunk_size;
	      *m->plast = c;
	      m->plast = &c->next;
	      c->next = NULL;
	      c->size = m->chunk_size;
	    }
	  m->ptr = c->data + size;
	  m->end = c->data + m->chunk_size;
	}
      return c->data;
    }
}

for large allocation, if u add new allocated block in front of old
m->first_large do u have to set m->first_large = c instead of
m->first_large = c->next



From mj at ucw.cz  Wed Jan 17 09:32:00 2001
From: mj at ucw.cz (Martin Mares)
Date: Wed, 17 Jan 2001 09:32:00 +0100
Subject: About func in mempool.c
In-Reply-To: <Pine.SGI.4.21.0101161151490.12469-100000@debris63>; from zyuan1@cig.mot.com on Tue, Jan 16, 2001 at 11:57:40AM -0600
References: <20010113222233.C626@albireo.ucw.cz> <Pine.SGI.4.21.0101161151490.12469-100000@debris63>
Message-ID: <20010117093200.C481@albireo.ucw.cz>

Hello!

> for large allocation, if u add new allocated block in front of old
> m->first_large do u have to set m->first_large = c instead of
> m->first_large = c->next

Well spotted. I've just commited a fix to our CVS. Thanks.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj at ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"It's a lemon tree, my dear Watson." -- Sherlock Holmes (?)


From james at UnLambda.COM  Tue Jan  2 19:59:22 2001
From: james at UnLambda.COM (James A. Crippen)
Date: Tue, 2 Jan 2001 09:59:22 -0900 (AKST)
Subject: Stop forking
In-Reply-To: <3A4DAB96.A44548B0@compulan.de>
Message-ID: <Pine.LNX.4.21.0101020955230.17660-100000@gamma.unlambda.com>

On Sat, 30 Dec 2000, Michael Renzmann wrote:

> Hi James.
> 
> > > > Where should I look to find the code that forks bird into the
> > > > background on startup?  I don't want it to fork.  Instead I want
> > > > to fork it into the background myself from another program.
> > > Already tried the "-d" parameter?
> > Well, that would work but I don't want lots of debug messages.  Do they
> > all come out only on the console, or does this cause debugging info to
> > be written to the syslog as well?
> 
> Hmm, don?t know. I?m using bird since yesterday, so I don?t have much
> experience with it. But you might look at the source to find the code
> that processes the "-d" command line switch. Add another switch that
> does nearly the same, but leaves out the toggle for debug messages. I
> don?t have the source right now (and I?m at home at a windows pc), else
> I could send you a small piece of source that would achieve what you
> want.
> 
> > If this option only writes to the console then that's fine, I can
> > redirect it to /dev/null.  If it writes debugging stuff to the syslog
> > too then that's no good -- I'll choke my logs up with stuff that I
> > don't always need.
> 
> Just try it and you will see if it also writes lots of debug messages to
> the syslog. :)

So far I haven't had any problems with extra debug messages other than the
ones configurable via the conf file and birdc.  Not exactly sure what to
expect though, and I haven't had the time to examine the source closely
for what I want.  Right now I'm having problems with RIP, but I'm betting
that it's my fault and I've misconfigured things again.  Maybe I should
actually sit down and RTFM... :)

If I do find what I want and need to hack on the code I'll be sure to send
a patch to the list.

'james

-- 
James A. Crippen <james at unlambda.com> ,-./-.  Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us   |  |/  | USA, 61.2069 N, 149.766 W,
Y = \f.(\x.f(xx)) (\x.f(xx))         |  |\  | Earth, Sol System,
Y(F) = F(Y(F))                        \_,-_/  Milky Way.



From mj at ucw.cz  Wed Jan  3 00:08:00 2001
From: mj at ucw.cz (Martin Mares)
Date: Wed, 3 Jan 2001 00:08:00 +0100
Subject: Stop forking
In-Reply-To: <Pine.LNX.4.21.0012291059030.17660-100000@gamma.unlambda.com>; from james@UnLambda.COM on Fri, Dec 29, 2000 at 11:03:53AM -0900
References: <Pine.LNX.4.21.0012291059030.17660-100000@gamma.unlambda.com>
Message-ID: <20010103000800.D1390@albireo.ucw.cz>

Hello!

Happy new year to all people at the BIRD list. I've returned from holidays
and started processing the huge piles of mail which I've received, so it
will probably take a couple of days for me to get to your questions
and bug reports.

> Where should I look to find the code that forks bird into the background
> on startup?  I don't want it to fork.  Instead I want to fork it into the
> background myself from another program.

You can find it in sysdep/unix/main.c in main().

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj at ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
The first myth of management is that it exists.


From zyuan1 at cig.mot.com  Thu Jan  4 00:17:38 2001
From: zyuan1 at cig.mot.com (Zheng Yuan {ZYUAN1})
Date: Wed, 3 Jan 2001 17:17:38 -0600
Subject: Is this a typo
Message-ID: <Pine.SGI.4.21.0101031715390.2625-100000@debris63>

Line 64 in CLI.c

if (!(o = c->tx_write) || o->wpos + size > o->end) 

isnt that should be 

if (!(o == c->tx_write) || o->wpos + size > o->end)


BTW, is there anyone who is also interested in studying the source code? I
would be very interested if we could form a study group or something else?

Thanx!



From james at UnLambda.COM  Thu Jan  4 03:15:28 2001
From: james at UnLambda.COM (James A. Crippen)
Date: Wed, 3 Jan 2001 17:15:28 -0900 (AKST)
Subject: Parse error with OSPF area stmt?
Message-ID: <Pine.LNX.4.21.0101031711330.17660-100000@gamma.unlambda.com>

I'm getting consistent parse errors from bird while trying to configure
ospf.  I say something akin to the following:

  protocol ospf {
    ...
    area 0.0.0.0 {
      ...
    };
  }

And I've tried variations like "area 0 {" and "area {", but no luck with
anything.  I always get a parse error from bird on that particular
line.  I took a halfhearted look at the source and couldn't find anything
in particular.  Help!

And yes, I know that areas are somewhat borken, that you can't use more
than one.  I'm not trying to, I'm just trying to follow the documentation
which says to list an area section and put my chosen interfaces inside of
it.

Thanks
'james

-- 
James A. Crippen <james at unlambda.com> ,-./-.  Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us   |  |/  | USA, 61.2069 N, 149.766 W,
Y = \f.(\x.f(xx)) (\x.f(xx))         |  |\  | Earth, Sol System,
Y(F) = F(Y(F))                        \_,-_/  Milky Way.





From feela at ipex.cz  Thu Jan  4 09:51:05 2001
From: feela at ipex.cz (Ondrej Feela Filip)
Date: Thu, 4 Jan 2001 09:51:05 +0100 (CET)
Subject: Parse error with OSPF area stmt?
In-Reply-To: <Pine.LNX.4.21.0101031711330.17660-100000@gamma.unlambda.com>
Message-ID: <Pine.LNX.4.30.0101040950240.28306-100000@zuzana.cb.ipex.cz>

On Wed, 3 Jan 2001, James A. Crippen wrote:

> I'm getting consistent parse errors from bird while trying to configure
> ospf.  I say something akin to the following:
>
>   protocol ospf {
>     ...
>     area 0.0.0.0 {
>       ...
>     };
>   }
>
> And I've tried variations like "area 0 {" and "area {", but no luck with
> anything.  I always get a parse error from bird on that particular
> line.  I took a halfhearted look at the source and couldn't find anything
> in particular.  Help!

Please send me complete bird.conf, I hope I'll help you then.

> And yes, I know that areas are somewhat borken, that you can't use more
> than one.  I'm not trying to, I'm just trying to follow the documentation
> which says to list an area section and put my chosen interfaces inside of
> it.
>
> Thanks
> 'james
>
>

-- 
Ondrej Feela Filip


From mj at ucw.cz  Thu Jan  4 19:10:19 2001
From: mj at ucw.cz (Martin Mares)
Date: Thu, 4 Jan 2001 19:10:19 +0100
Subject: Is this a typo
In-Reply-To: <Pine.SGI.4.21.0101031715390.2625-100000@debris63>; from zyuan1@cig.mot.com on Wed, Jan 03, 2001 at 05:17:38PM -0600
References: <Pine.SGI.4.21.0101031715390.2625-100000@debris63>
Message-ID: <20010104191019.H617@albireo.ucw.cz>

Hello!

> Line 64 in CLI.c
> 
> if (!(o = c->tx_write) || o->wpos + size > o->end) 
> 
> isnt that should be 
> 
> if (!(o == c->tx_write) || o->wpos + size > o->end)

No, it's a real assignment.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj at ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
P.C.M.C.I.A. stands for `People Can't Memorize Computer Industry Acronyms'


From james at UnLambda.COM  Thu Jan  4 20:39:38 2001
From: james at UnLambda.COM (James A. Crippen)
Date: Thu, 4 Jan 2001 10:39:38 -0900 (AKST)
Subject: Is this a typo
In-Reply-To: <20010104191019.H617@albireo.ucw.cz>
Message-ID: <Pine.LNX.4.21.0101041038030.25388-100000@gamma.unlambda.com>

On Thu, 4 Jan 2001, Martin Mares wrote:

> Hello!
> 
> > Line 64 in CLI.c
> > 
> > if (!(o = c->tx_write) || o->wpos + size > o->end) 
> > 
> > isnt that should be 
> > 
> > if (!(o == c->tx_write) || o->wpos + size > o->end)
> 
> No, it's a real assignment.

I love C.  :P

-- 
James A. Crippen <james at unlambda.com> ,-./-.  Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us   |  |/  | USA, 61.2069 N, 149.766 W,
Y = \f.(\x.f(xx)) (\x.f(xx))         |  |\  | Earth, Sol System,
Y(F) = F(Y(F))                        \_,-_/  Milky Way.



From james at UnLambda.COM  Thu Jan  4 20:43:22 2001
From: james at UnLambda.COM (James A. Crippen)
Date: Thu, 4 Jan 2001 10:43:22 -0900 (AKST)
Subject: Parse error with OSPF area stmt?
In-Reply-To: <Pine.LNX.4.30.0101040950240.28306-100000@zuzana.cb.ipex.cz>
Message-ID: <Pine.LNX.4.21.0101041040320.25388-100000@gamma.unlambda.com>

On Thu, 4 Jan 2001, Ondrej Feela Filip wrote:

> On Wed, 3 Jan 2001, James A. Crippen wrote:
> 
> > I'm getting consistent parse errors from bird while trying to configure
> > ospf.  I say something akin to the following:
> >
> >   protocol ospf {
> >     ...
> >     area 0.0.0.0 {
> >       ...
> >     };
> >   }
> >
> > And I've tried variations like "area 0 {" and "area {", but no luck with
> > anything.  I always get a parse error from bird on that particular
> > line.  I took a halfhearted look at the source and couldn't find anything
> > in particular.  Help!
> 
> Please send me complete bird.conf, I hope I'll help you then.

Okay, here it is.

---8<--- cut here ---8<---

log syslog all;

# Turn on global debugging of all protocols
debug protocols all;

protocol direct {
  interface "*";
}

protocol kernel {
  learn yes;
  persist no;
  scan time 20;
  import all;
  export all;
}

protocol device {
  scan time 20;
}

protocol static {
  debug all;
}

#protocol rip {
#  debug all;
#  honor always;
#  authentication none;
#  interface "*" { mode broadcast; };
#  import all;
#  export all;
#}  

protocol ospf {
# old OSPFv2 compat
  rfc1583compat no;

  import all;
  export all;

  area 0.0.0.0 {
    tick 10;
  
    interface "eth0" {
      cost 10;
      stub no;
      hello 10;
      poll 20;
      retransmit 5;
      priority 1;
      wait 40;
      dead count 6;
      type broadcast;
      strict nonbroadcast no;
      authentication none;
      password "foobar";
#      neighbors { ... };
    };

    interface "eth1" {
      cost 10;
      stub no;
      hello 10;
      poll 20;
      retransmit 5;
      priority 1;
      wait 40;
      dead count 6;
      type broadcast;
      strict nonbroadcast no;
      authentication none;
      password "foobar";
#      neighbors { ... };
    };

    interface "eth2" {
      cost 10;
      stub no;
      hello 10;
      poll 20;
      retransmit 5;
      priority 1;
      wait 40;
      dead count 6;
      type broadcast;
      strict nonbroadcast no;
      authentication none;
      password "foobar";
#      neighbors { ... };
    };
  };
}

---8<--- cut here ---8<---

'james

-- 
James A. Crippen <james at unlambda.com> ,-./-.  Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us   |  |/  | USA, 61.2069 N, 149.766 W,
Y = \f.(\x.f(xx)) (\x.f(xx))         |  |\  | Earth, Sol System,
Y(F) = F(Y(F))                        \_,-_/  Milky Way.



From james at UnLambda.COM  Fri Jan  5 02:11:26 2001
From: james at UnLambda.COM (James A. Crippen)
Date: Thu, 4 Jan 2001 16:11:26 -0900 (AKST)
Subject: Parse error with OSPF area stmt?
In-Reply-To: <Pine.LNX.4.21.0101041040320.25388-100000@gamma.unlambda.com>
Message-ID: <Pine.LNX.4.21.0101041607160.25388-100000@gamma.unlambda.com>

On Thu, 4 Jan 2001, James A. Crippen wrote:

> On Thu, 4 Jan 2001, Ondrej Feela Filip wrote:
> 
> > On Wed, 3 Jan 2001, James A. Crippen wrote:
[...]
> > Please send me complete bird.conf, I hope I'll help you then.
> 
> Okay, here it is.
> 
> ---8<--- cut here ---8<---
> 
> log syslog all;
> 
> # Turn on global debugging of all protocols
> debug protocols all;
> 
> protocol direct {
>   interface "*";
> }
> 
> protocol kernel {
>   learn yes;
>   persist no;
>   scan time 20;
>   import all;
>   export all;
> }
> 
> protocol device {
>   scan time 20;
> }
> 
> protocol static {
>   debug all;
> }
> 
> #protocol rip {
> #  debug all;
> #  honor always;
> #  authentication none;
> #  interface "*" { mode broadcast; };
> #  import all;
> #  export all;
> #}  
> 
> protocol ospf {
> # old OSPFv2 compat
>   rfc1583compat no;
> 
>   import all;
>   export all;
> 
>   area 0.0.0.0 {
>     tick 10;
>   
>     interface "eth0" {
>       cost 10;
>       stub no;
>       hello 10;
>       poll 20;
>       retransmit 5;
>       priority 1;
>       wait 40;
>       dead count 6;
>       type broadcast;
>       strict nonbroadcast no;
>       authentication none;
>       password "foobar";
> #      neighbors { ... };
>     };
> 
>     interface "eth1" {
>       cost 10;
>       stub no;
>       hello 10;
>       poll 20;
>       retransmit 5;
>       priority 1;
>       wait 40;
>       dead count 6;
>       type broadcast;
>       strict nonbroadcast no;
>       authentication none;
>       password "foobar";
> #      neighbors { ... };
>     };
> 
>     interface "eth2" {
>       cost 10;
>       stub no;
>       hello 10;
>       poll 20;
>       retransmit 5;
>       priority 1;
>       wait 40;
>       dead count 6;
>       type broadcast;
>       strict nonbroadcast no;
>       authentication none;
>       password "foobar";
> #      neighbors { ... };
>     };
>   };
> }
> 
> ---8<--- cut here ---8<---

I removed the "rfc1583compat no;" line and it works fine.  The parser is
complaining about the line below where it seems to die, I think.  I just
tried with the following:

protocol ospf {
  rfc1583compat no;
*  import all;
  export all;
  ...
}

And the parser complained about the line marked (*).  Removal of the line
above this (the one containing "rfc1583compat no;") fixes the
problem.  Any idea what's happening here?  This is a completely repeatable
bug.

'james

-- 
James A. Crippen <james at unlambda.com> ,-./-.  Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us   |  |/  | USA, 61.2069 N, 149.766 W,
Y = \f.(\x.f(xx)) (\x.f(xx))         |  |\  | Earth, Sol System,
Y(F) = F(Y(F))                        \_,-_/  Milky Way.



From mrenzmann at compulan.de  Fri Jan  5 11:30:43 2001
From: mrenzmann at compulan.de (Michael Renzmann)
Date: Fri, 5 Jan 2001 11:30:43 +0100
Subject: Parse error with OSPF area stmt?
In-Reply-To: <Pine.LNX.4.21.0101041607160.25388-100000@gamma.unlambda.com>
References: <Pine.LNX.4.21.0101041040320.25388-100000@gamma.unlambda.com>
	<Pine.LNX.4.21.0101041607160.25388-100000@gamma.unlambda.com>
Message-ID: <20010105113043.04584ded.mrenzmann@compulan.de>

Hi.

> I removed the "rfc1583compat no;" line and it works fine.  The parser is
> complaining about the line below where it seems to die, I think.  I just
> tried with the following:
> 
> protocol ospf {
>   rfc1583compat no;
> *  import all;
>   export all;
>   ...
> }
> 
> And the parser complained about the line marked (*).  Removal of the line
> above this (the one containing "rfc1583compat no;") fixes the
> problem.  Any idea what's happening here?  This is a completely repeatable
> bug.

Did you try to move that line (rfc...) some lines below (for example between
"import all;" and "export all;")? Where does the parser die then?

> 'james

Bye, Mike
-- 
------------------------------------
  CompuLAN Europe GmbH
  Development - Wireless Solutions
------------------------------------


From james at UnLambda.COM  Fri Jan  5 20:29:25 2001
From: james at UnLambda.COM (James A. Crippen)
Date: Fri, 5 Jan 2001 10:29:25 -0900 (AKST)
Subject: Parse error with OSPF area stmt?
In-Reply-To: <20010105113043.04584ded.mrenzmann@compulan.de>
Message-ID: <Pine.LNX.4.21.0101051028190.25624-100000@gamma.unlambda.com>

On Fri, 5 Jan 2001, Michael Renzmann wrote:

> Hi.
> 
> > I removed the "rfc1583compat no;" line and it works fine.  The parser is
> > complaining about the line below where it seems to die, I think.  I just
> > tried with the following:
> > 
> > protocol ospf {
> >   rfc1583compat no;
> > *  import all;
> >   export all;
> >   ...
> > }
> > 
> > And the parser complained about the line marked (*).  Removal of the line
> > above this (the one containing "rfc1583compat no;") fixes the
> > problem.  Any idea what's happening here?  This is a completely repeatable
> > bug.
> 
> Did you try to move that line (rfc...) some lines below (for example between
> "import all;" and "export all;")? Where does the parser die then?

I moved it below the area stmt (below my interface declarations) and the
parser dies one line after the "rfc1583compat no;" line.  Totally
reliable.

I guess I could run it under gdb to see why it was dying.  I'll do that
when I get a chance.

'james

-- 
James A. Crippen <james at unlambda.com> ,-./-.  Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us   |  |/  | USA, 61.2069 N, 149.766 W,
Y = \f.(\x.f(xx)) (\x.f(xx))         |  |\  | Earth, Sol System,
Y(F) = F(Y(F))                        \_,-_/  Milky Way.



From james at UnLambda.COM  Fri Jan  5 23:51:00 2001
From: james at UnLambda.COM (James A. Crippen)
Date: Fri, 5 Jan 2001 13:51:00 -0900 (AKST)
Subject: OSPF "bad hello packet"
Message-ID: <Pine.LNX.4.21.0101051348530.25624-100000@gamma.unlambda.com>

I'm getting "bad hello packet from 10.1.1.23 received: bad netmask
255.255.255.0" even though there's really nothing wrong with this netmask
(I'm using 10.1.1.0/24 and 10.2.2.0/24 for some testing).

Is there any reason why ospf thinks this is a bad netmask?  Should I just
ignore it?

Thanks!
'james

-- 
James A. Crippen <james at unlambda.com> ,-./-.  Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us   |  |/  | USA, 61.2069 N, 149.766 W,
Y = \f.(\x.f(xx)) (\x.f(xx))         |  |\  | Earth, Sol System,
Y(F) = F(Y(F))                        \_,-_/  Milky Way.



From zyuan1 at cig.mot.com  Sat Jan  6 00:12:19 2001
From: zyuan1 at cig.mot.com (Zheng Yuan {ZYUAN1})
Date: Fri, 5 Jan 2001 17:12:19 -0600
Subject: Is this func correct?
Message-ID: <Pine.SGI.4.21.0101051709520.12469-100000@debris63>

Hi, All

Maybe i totally miss the point, is this func correct: int
password_same(struct password_item *old, struct password_item *new) {
  if (old == new)
    return 1;
  if ((!old) || (!new))
    return 0;
  return ((old->from == new->from) &&
	  (old->to == new->to) &&
	  (old->passive == new->passive) &&
	  password_same(old, new));
}

or the last line should be 
  return ((old->from == new->from) &&
          (old->to == new->to) &&
          (old->passive == new->passive) &&
          password_same(old->next, new->next)); or compare old->password
with new->password



From feela at ipex.cz  Sat Jan  6 01:06:55 2001
From: feela at ipex.cz (Ondrej Feela Filip)
Date: Sat, 6 Jan 2001 01:06:55 +0100 (CET)
Subject: OSPF "bad hello packet"
In-Reply-To: <Pine.LNX.4.21.0101051348530.25624-100000@gamma.unlambda.com>
Message-ID: <Pine.LNX.4.30.0101060105070.26271-100000@zuzana.cb.ipex.cz>

On Fri, 5 Jan 2001, James A. Crippen wrote:

> I'm getting "bad hello packet from 10.1.1.23 received: bad netmask
> 255.255.255.0" even though there's really nothing wrong with this netmask
> (I'm using 10.1.1.0/24 and 10.2.2.0/24 for some testing).

Are you sure, that all interfaces connected to network 10.1.1.0/24 have
the same netmask?

>
> Is there any reason why ospf thinks this is a bad netmask?  Should I just
> ignore it?

Probably 10.1.1.23 has a different netmask than the router running BIRD.

>
> Thanks!
> 'james
>

		Kind regards
				Feela

>

-- 
Ondrej Feela Filip


From feela at ipex.cz  Sat Jan  6 01:11:14 2001
From: feela at ipex.cz (Ondrej Feela Filip)
Date: Sat, 6 Jan 2001 01:11:14 +0100 (CET)
Subject: Parse error with OSPF area stmt?
In-Reply-To: <Pine.LNX.4.21.0101051028190.25624-100000@gamma.unlambda.com>
Message-ID: <Pine.LNX.4.30.0101060110260.26271-100000@zuzana.cb.ipex.cz>

On Fri, 5 Jan 2001, James A. Crippen wrote:

> On Fri, 5 Jan 2001, Michael Renzmann wrote:
>
> > Hi.
> >
> > > I removed the "rfc1583compat no;" line and it works fine.  The parser is
> > > complaining about the line below where it seems to die, I think.  I just
> > > tried with the following:
> > >
> > > protocol ospf {
> > >   rfc1583compat no;
> > > *  import all;
> > >   export all;
> > >   ...
> > > }
> > >
> > > And the parser complained about the line marked (*).  Removal of the line
> > > above this (the one containing "rfc1583compat no;") fixes the
> > > problem.  Any idea what's happening here?  This is a completely repeatable
> > > bug.
> >
> > Did you try to move that line (rfc...) some lines below (for example between
> > "import all;" and "export all;")? Where does the parser die then?
>
> I moved it below the area stmt (below my interface declarations) and the
> parser dies one line after the "rfc1583compat no;" line.  Totally
> reliable.
>
> I guess I could run it under gdb to see why it was dying.  I'll do that
> when I get a chance.

Hmm, to be true, rfc1583compat switch is not used now. So simple comment
it out. I'll look at it in next version.

				Feela


>
> 'james
>
>

-- 
Ondrej Feela Filip


From james at UnLambda.COM  Sat Jan  6 02:32:09 2001
From: james at UnLambda.COM (James A. Crippen)
Date: Fri, 5 Jan 2001 16:32:09 -0900 (AKST)
Subject: OSPF "bad hello packet"
In-Reply-To: <Pine.LNX.4.30.0101060105070.26271-100000@zuzana.cb.ipex.cz>
Message-ID: <Pine.LNX.4.21.0101051556330.25624-100000@gamma.unlambda.com>

On Sat, 6 Jan 2001, Ondrej Feela Filip wrote:

> On Fri, 5 Jan 2001, James A. Crippen wrote:
> 
> > I'm getting "bad hello packet from 10.1.1.23 received: bad netmask
> > 255.255.255.0" even though there's really nothing wrong with this netmask
> > (I'm using 10.1.1.0/24 and 10.2.2.0/24 for some testing).
> 
> Are you sure, that all interfaces connected to network 10.1.1.0/24 have
> the same netmask?

Yes, see below.
 
> > Is there any reason why ospf thinks this is a bad netmask?  Should I just
> > ignore it?
> 
> Probably 10.1.1.23 has a different netmask than the router running BIRD.

Both are bird routers.  They're both connected to an isolated network on
one 100Mbps hub.  The network looks like this:

                10.2.2.0/24 -----+-----
                                 |10.2.2.23
                                 B
                        10.1.1.23|10.10.10.23
  10.1.1.0/24 ----------+--------+---------+------------ 10.10.10.0/24
               10.1.1.42|                  |10.1.1.1
                        A                  C
           12.17.190.232|                  |12.17.190.220
  12.17.190.224/28 -----+--------+---------+------------ 12.17.190.208/28
                    12.17.190.225|12.17.190.209
                                 D
                                 |12.17.190.161
                                 |
                                \|/
                                 V
                           The Internet

(I apologize for the horrible ASCII art.)  Basically 12.17.190.224/28 and
12.17.190.208/28 are subnets on the same ethernet segment.  /D/ is the
primary router between them, as well as the default gateway to the rest of
the Internet.  /A/ and /C/ are connected to this ethernet segment but on
different subnets, /A/ on 12.17.190.224/28 and /C/ on 12.17.190.208/28.  
Neither /A/ nor /C/ communicate routing information to /D/, thus all the
10 networks are invisible to the Internet.  Both /A/ and /C/ are connected
to another ethernet segment which is also connected to /B/.  /A/, /B/, and
/C/ all have interfaces on 10.1.1.0/24.  /B/ also has another interface on
the same ethernet segment but on a different subnet, 10.10.10.0/24.  This
is just a stub so I can watch another route propagate.  /B/ is connected
to yet another segment, this having only the 10.2.2.0/24 subnet on it, and
/B/ is the only connected router.

BTW, /A/ does not run any routing protocols.  It's my workstation which is
connected to the two ethernet segments so I can see the network traffic.

With that, I'm seeing the "Bad OSPF hello packet from 10.1.1.23


From james at UnLambda.COM  Sat Jan  6 02:34:23 2001
From: james at UnLambda.COM (James A. Crippen)
Date: Fri, 5 Jan 2001 16:34:23 -0900 (AKST)
Subject: Parse error with OSPF area stmt?
In-Reply-To: <Pine.LNX.4.30.0101060110260.26271-100000@zuzana.cb.ipex.cz>
Message-ID: <Pine.LNX.4.21.0101051632260.25624-100000@gamma.unlambda.com>

On Sat, 6 Jan 2001, Ondrej Feela Filip wrote:

[...]
> Hmm, to be true, rfc1583compat switch is not used now. So simple comment
> it out. I'll look at it in next version.

I see, so it shows up in the parser but it's not actually working.  That's
my answer.  Thanks!  I'll just not use it.  The manual says that the
default is no, which is what I want.  I just wanted explicit control over
that if I needed it.  I presume that RFC 1538 compatibility hasn't been
implemented then?

'james

-- 
James A. Crippen <james at unlambda.com> ,-./-.  Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us   |  |/  | USA, 61.2069 N, 149.766 W,
Y = \f.(\x.f(xx)) (\x.f(xx))         |  |\  | Earth, Sol System,
Y(F) = F(Y(F))                        \_,-_/  Milky Way.




From usernameprom at earthlink.net  Sat Jan  6 19:59:55 2001
From: usernameprom at earthlink.net (usernameprom at earthlink.net)
Date: Sat, 6 Jan 2001 19:59:55
Subject: Your business needs to be At The TOP!!!
Message-ID: <332.783101.189563@modelnetworking.net>

Top Position Solutions For Your Site

We can list your website in all major Search Engines and achieve 
Top 10 positions. GUARANTEED! 


You pay only after results are shown to you.

Not only we submit or register your site,
We guarantee you Top 10 positions. 
If people cannot find your business in the first 
30 matches of a search, then designing and hosting your site was 
a waste of time, money and hopes.

* Properly Optimized Files Made For You!
* Your Optimized Files are completely cloaked!
* Surfers will go to your Home Page. We do not use any 
redirection technique.

We key on the following major search engines:
* Yahoo-Looksmart-AltaVista-Dogpile-WebCrawler-Lycos-
* Excite-iwon-AskJeeves-AOL Search-Netscape-HotBot-MSN-
* GO(Infoseek)-NBCi(Snap)-Google-BrainFox-
* Open Directory-Findwhat-Fast Search(alltheweb)-Goto-Canada.

Remember,You PAY only after results are shown to you. 
For more information please click here: 
mailto:fastinfo123 at earthlink.net?subject=More_Information


Or You may call at:


718-583-1771

Monday - Friday From 11:00 AM To 7:00 PM Eastern Time






------------------------------------------------------------

To be removed from this list, please mail to: 
mailto:usernameprom at earthlink.net?subject=Remove
subject line and you will be removed from our list.

------------------------------------------------------------
 
 
 
 
 
 


From pavel at ucw.cz  Mon Jan  8 11:53:56 2001
From: pavel at ucw.cz (Pavel Machek)
Date: Mon, 8 Jan 2001 11:53:56 +0100
Subject: Is this func correct?
In-Reply-To: <Pine.SGI.4.21.0101051709520.12469-100000@debris63>; from zyuan1@cig.mot.com on Fri, Jan 05, 2001 at 05:12:19PM -0600
References: <Pine.SGI.4.21.0101051709520.12469-100000@debris63>
Message-ID: <20010108115355.B15918@atrey.karlin.mff.cuni.cz>

Hi!

> Maybe i totally miss the point, is this func correct: int
> password_same(struct password_item *old, struct password_item *new) {
>   if (old == new)
>     return 1;
>   if ((!old) || (!new))
>     return 0;
>   return ((old->from == new->from) &&
> 	  (old->to == new->to) &&
> 	  (old->passive == new->passive) &&
> 	  password_same(old, new));
> }
> 
> or the last line should be 
>   return ((old->from == new->from) &&
>           (old->to == new->to) &&
>           (old->passive == new->passive) &&
>           password_same(old->next, new->next)); or compare old->password
> with new->password

That probably should be old->next, because otherwise it looks like
infinite loop to me.
								Pavel
-- 
The best software in life is free (not shareware)!		Pavel
GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+


From mj at ucw.cz  Mon Jan  8 12:13:02 2001
From: mj at ucw.cz (Martin Mares)
Date: Mon, 8 Jan 2001 12:13:02 +0100
Subject: Is this func correct?
In-Reply-To: <Pine.SGI.4.21.0101051709520.12469-100000@debris63>; from zyuan1@cig.mot.com on Fri, Jan 05, 2001 at 05:12:19PM -0600
References: <Pine.SGI.4.21.0101051709520.12469-100000@debris63>
Message-ID: <20010108121302.G396@albireo.ucw.cz>

Hi!

> Maybe i totally miss the point, is this func correct: int
> password_same(struct password_item *old, struct password_item *new) {
>   if (old == new)
>     return 1;
>   if ((!old) || (!new))
>     return 0;
>   return ((old->from == new->from) &&
> 	  (old->to == new->to) &&
> 	  (old->passive == new->passive) &&
> 	  password_same(old, new));
> }

Well spotted. Here is a fix:

diff -u -r1.7 password.c
--- password.c	2000/05/16 15:02:27	1.7
+++ password.c	2001/01/08 11:12:08
@@ -54,12 +54,19 @@
 int
 password_same(struct password_item *old, struct password_item *new)
 {
-  if (old == new)
-    return 1;
-  if ((!old) || (!new))
-    return 0;
-  return ((old->from == new->from) &&
-	  (old->to == new->to) &&
-	  (old->passive == new->passive) &&
-	  password_same(old, new));
+  for(;;)
+    {
+      if (old == new)
+	return 1;
+      if (!old || !new)
+	return 0;
+      if (old->from    != new->from    ||
+	  old->to      != new->to      ||
+	  old->passive != new->passive ||
+	  old->id      != new->id      ||
+	  strcmp(old->password, new->password))
+	return 0;
+      old = old->next;
+      new = new->next;
+    }
 }

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj at ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Light-year? One-third less calories than a regular year.


From james at UnLambda.COM  Fri Jan 12 08:00:26 2001
From: james at UnLambda.COM (James A. Crippen)
Date: Thu, 11 Jan 2001 22:00:26 -0900 (AKST)
Subject: Routing over aliases?
Message-ID: <Pine.LNX.4.21.0101112148190.1862-100000@gamma.unlambda.com>


From zyuan1 at cig.mot.com  Sat Jan 13 00:36:21 2001
From: zyuan1 at cig.mot.com (Zheng Yuan {ZYUAN1})
Date: Fri, 12 Jan 2001 17:36:21 -0600
Subject: About func in lists.c
Message-ID: <Pine.SGI.4.21.0101121730580.12469-100000@debris63>

Hi, all
 
i have a question about func as bellows

/**
 * add_head - prepend a node to a list
 * @l: linked list
 * @n: list node
 *
 * add_head() takes a node @n and prepends it at the start of the list @l.
 */ LIST_INLINE void add_head(list *l, node *n) {
  node *z = l->head;
  n->next = z;
  n->prev = (node *) &l->head;
  z->prev = n;
  l->head = n; }

isnt that we should change n->prev = (node *) &l->head to n->prev = (node
*) &l->null



From mj at ucw.cz  Sat Jan 13 22:22:33 2001
From: mj at ucw.cz (Martin Mares)
Date: Sat, 13 Jan 2001 22:22:33 +0100
Subject: About func in lists.c
In-Reply-To: <Pine.SGI.4.21.0101121730580.12469-100000@debris63>; from zyuan1@cig.mot.com on Fri, Jan 12, 2001 at 05:36:21PM -0600
References: <Pine.SGI.4.21.0101121730580.12469-100000@debris63>
Message-ID: <20010113222233.C626@albireo.ucw.cz>

Hi!

> isnt that we should change n->prev = (node *) &l->head to n->prev = (node
> *) &l->null

No.  I admit the list structure is very tricky and also somewhat awkward,
but it's both efficient and easy to manipulate once one understand the
basic trick: The list head always contains two synthetic nodes which are
always present in the list: the head and the tail. But because the `next'
entry of the tail and the `prev' entry of the head are both NULL, the
nodes can be overlayed over each other:

	head	head_node.next
	null	head_node.prev	tail_node.next
	tail			tail_node.prev

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj at ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
And God said: E = 1/2mv^2 - Ze^2/r ...and there *WAS* light!


From pavel at ucw.cz  Sun Jan 14 21:20:40 2001
From: pavel at ucw.cz (Pavel Machek)
Date: Sun, 14 Jan 2001 21:20:40 +0100
Subject: About func in lists.c
In-Reply-To: <20010113222233.C626@albireo.ucw.cz>; from mj@ucw.cz on Sat, Jan 13, 2001 at 10:22:33PM +0100
References: <Pine.SGI.4.21.0101121730580.12469-100000@debris63> <20010113222233.C626@albireo.ucw.cz>
Message-ID: <20010114212040.A20293@atrey.karlin.mff.cuni.cz>

Hi!

> > isnt that we should change n->prev = (node *) &l->head to n->prev = (node
> > *) &l->null
> 
> No.  I admit the list structure is very tricky and also somewhat awkward,
> but it's both efficient and easy to manipulate once one understand the
> basic trick: The list head always contains two synthetic nodes which are
> always present in the list: the head and the tail. But because the `next'
> entry of the tail and the `prev' entry of the head are both NULL, the
> nodes can be overlayed over each other:
> 
> 	head	head_node.next
> 	null	head_node.prev	tail_node.next
> 	tail			tail_node.prev
> 

Maybe this mail should be taken as a comment and pasted at begining of
lists.h?
								Pavel
-- 
The best software in life is free (not shareware)!		Pavel
GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+


From mj at ucw.cz  Mon Jan 15 10:24:47 2001
From: mj at ucw.cz (Martin Mares)
Date: Mon, 15 Jan 2001 10:24:47 +0100
Subject: About func in lists.c
In-Reply-To: <20010114212040.A20293@atrey.karlin.mff.cuni.cz>; from pavel@ucw.cz on Sun, Jan 14, 2001 at 09:20:40PM +0100
References: <Pine.SGI.4.21.0101121730580.12469-100000@debris63> <20010113222233.C626@albireo.ucw.cz> <20010114212040.A20293@atrey.karlin.mff.cuni.cz>
Message-ID: <20010115102447.C605@albireo.ucw.cz>

Hi!

> Maybe this mail should be taken as a comment and pasted at begining of
> lists.h?

Good idea, done that.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj at ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
God is real, unless declared integer.


From zyuan1 at cig.mot.com  Tue Jan 16 18:57:40 2001
From: zyuan1 at cig.mot.com (Zheng Yuan {ZYUAN1})
Date: Tue, 16 Jan 2001 11:57:40 -0600
Subject: About func in mempool.c
In-Reply-To: <20010113222233.C626@albireo.ucw.cz>
Message-ID: <Pine.SGI.4.21.0101161151490.12469-100000@debris63>

in 

void * lp_alloc(linpool *m, unsigned size) {
  byte *a = (byte *) ALIGN((unsigned long) m->ptr, CPU_STRUCT_ALIGN);
  byte *e = a + size;
  if (e <= m->end)
    {
      m->ptr = e;
      return a;
    }
  else
    {
      struct lp_chunk *c;
      if (size >= m->threshold)
	{
	  /* Too large => allocate large chunk */
	  c = xmalloc(sizeof(struct lp_chunk) + size);
	  m->total_large += size;
	  c->next = m->first_large;
	  m->first_large = c->next;
	  c->size = size;
	}
      else
	{
	  if (m->current)
	    {
	      /* Still have free chunks from previous incarnation (before
lp_flush()) */
	      c = m->current;
	      m->current = c->next;
	    }
	  else
	    {
	      /* Need to allocate a new chunk */
	      c = xmalloc(sizeof(struct lp_chunk) + m->chunk_size);
	      m->total += m->chunk_size;
	      *m->plast = c;
	      m->plast = &c->next;
	      c->next = NULL;
	      c->size = m->chunk_size;
	    }
	  m->ptr = c->data + size;
	  m->end = c->data + m->chunk_size;
	}
      return c->data;
    }
}

for large allocation, if u add new allocated block in front of old
m->first_large do u have to set m->first_large = c instead of
m->first_large = c->next



From mj at ucw.cz  Wed Jan 17 09:32:00 2001
From: mj at ucw.cz (Martin Mares)
Date: Wed, 17 Jan 2001 09:32:00 +0100
Subject: About func in mempool.c
In-Reply-To: <Pine.SGI.4.21.0101161151490.12469-100000@debris63>; from zyuan1@cig.mot.com on Tue, Jan 16, 2001 at 11:57:40AM -0600
References: <20010113222233.C626@albireo.ucw.cz> <Pine.SGI.4.21.0101161151490.12469-100000@debris63>
Message-ID: <20010117093200.C481@albireo.ucw.cz>

Hello!

> for large allocation, if u add new allocated block in front of old
> m->first_large do u have to set m->first_large = c instead of
> m->first_large = c->next

Well spotted. I've just commited a fix to our CVS. Thanks.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj at ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"It's a lemon tree, my dear Watson." -- Sherlock Holmes (?)