headers
Greg Troxel | 1 Nov 2004 01:07
Picon

[quagga-dev 1748] Re: alignment faults in ospfd LSA processing on sparc64

  > OK - we will have a look.  I assume that means length can be not
  > multiple of 4, but that the space is ROUNDUP4(len).

  I dont follow the distinction..

A) It is an error for the length of an opaque lsa to be other than a
multiple of 4.  In our case, the ospf daemon should reject as
erroneous attempts to publish LSAs with length n s.t n%4 != 0.

B) Opaque LSAs may be any length.  When an LSA is placed in an ls-upd
packet, the actual length is placed in the length field, and then the
length rounded up to 4 ((n+3) & ~0x3) is used as the offset to the
start of the next lsa in the packet.

  Hmm, is that an interface bug?

If A, yes.  If B, implementation for not rounding up.

  > But I found that code _assumed_ alignment and didn't check.  i386 
  > disease (where you get away with such things)!

  Yes, true. Though, you were doing unusual stuff I guess ;) - I've not 
  seen any alignment faults on the Alpha here yet (normal OSPF, not 
  very busy though) (nor would I expect to see any).

I can certainly believe that for normal stuff there will be no
alignment faults.  My sparc64 box ran for over a year before having
trouble; it had never been presented with a non-aligned LSA [1].

[1] Previously, all LSAs had either been members of NATO or the Warsaw
(Continue reading)

Permalink | Reply | 2 comments |
headers
Greg Troxel | 1 Nov 2004 01:21
Picon

[quagga-dev 1749] Re: Permissions of /etc/quagga with/-out integrated config and multiuser vtysh

  Oh, we're mingling two discussions here I think:

  - management of config

  - secure command/control access

Yes, but they are linked, and having config management without
adequate security properties is no good.

  However, people do like the ability to remotely access their router's 
  CLI.

Yes, and other people like it that such access is not possible.
The only issue here is what the defaults are, and I am in favor of
defaulting to secure rather than convenient (no IP/IPv6 CLI access).

  telnet supports non-clear-text authentication mechanisms btw. (I use 
  telnet with krb5).

Telnet the protocol does, but I don't think the implementation in
quagga does.

  We could also tunnel the telnet interface inside some layer of 
  encryption, if we provided our own client.

We could, but then we would have invented sshing (or telneting with
krb5) into the system running quagga and invoking the AF_LOCAL-based
vtysh, and we'd have far more code to maintain and more bugs.

But we are mingling two issues that probably shouldn't be mingled.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Greg Troxel | 1 Nov 2004 01:23
Picon

[quagga-dev 1750] Re: Permissions of /etc/quagga with/-out integrated config and multiuser vtysh

  Ciscos can only do telnet (except some newer with special feature
  sets).

ok, but I hope they at least do krb5 enc/auth...

  And if there's a routing problem you sometimes have to connect to
  the neighbor router of a Cisco (e.g. our Quagga machine) because
  there's no route back to your linux desktop any more. So telnet is a
  must-be.

Sure, that's true with quagga, and I've been there numerous times, but
whether you ssh in and run vtysh or telnet to the 2600 port, it's the
exact same problem.  But if the daemon has crashed, then you have to
log in.
Permalink | Reply | 0 comments |
headers
Paul Jakma | 1 Nov 2004 03:46
Picon

[quagga-dev 1751] Re: alignment faults in ospfd LSA processing on sparc64

On Sun, 31 Oct 2004, Greg Troxel wrote:

> A) It is an error for the length of an opaque lsa to be other than a
> multiple of 4.  In our case, the ospf daemon should reject as
> erroneous attempts to publish LSAs with length n s.t n%4 != 0.

I get the impression this is the case, which function is it you 
publish new O-LSA's with? ospf_opaque_lsa_install()?

> If A, yes.  If B, implementation for not rounding up.

Given the wording of the RFC, I suspect A.

> I can certainly believe that for normal stuff there will be no 
> alignment faults.  My sparc64 box ran for over a year before having 
> trouble; it had never been presented with a non-aligned LSA [1].

And we need to check LSA header length for alignment before 
dereferencing it. I'll stick that on my TODO list.

> [1] Previously, all LSAs had either been members of NATO or the Warsaw
> pact, for you old timers.

Boom, boom!

regards,
--

-- 
Paul Jakma	paul <at> clubi.ie	paul <at> jakma.org	Key ID: 64A2FF6A
Fortune:
The linuX Files -- The Source is Out There.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Paul Jakma | 1 Nov 2004 04:01
Picon

[quagga-dev 1752] Re: Permissions of /etc/quagga with/-out integrated config and multiuser vtysh

On Sun, 31 Oct 2004, Greg Troxel wrote:

> Yes, but they are linked, and having config management without 
> adequate security properties is no good.

Yes.

> Yes, and other people like it that such access is not possible. The 
> only issue here is what the defaults are, and I am in favor of 
> defaulting to secure rather than convenient (no IP/IPv6 CLI 
> access).

I think most distros ship with telnet CLI limited to 127.1/::1.

> Telnet the protocol does, but I don't think the implementation in 
> quagga does.

Krb5 support actually wouldnt be /that/ difficult to add in. However, 
how many people have Krb5 KDCs setup to be able to make use of it?

> We could, but then we would have invented sshing (or telneting with 
> krb5) into the system running quagga and invoking the 
> AF_LOCAL-based vtysh, and we'd have far more code to maintain and 
> more bugs.

Hmm, possibly yes. However, permissions on the local vtysh thingy are 
difficult to get right too.

> But we are mingling two issues that probably shouldn't be mingled. 
> vtysh right now serves two purposes.  One is connecting from a
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hasso Tepper | 1 Nov 2004 10:25
Picon

[quagga-dev 1753] Re: daemon writes to vtysh need to be buffered or forked

Andrew J. Schorr wrote:
> For the moment, I am attaching a new version of the patch that makes
> the 2 changes suggested above, and I tightened up the code a bit
> and removed the (unused) buffer_send function that I had added.
>
> To summarize the current state of the patch: basically, for vtysh
> connections, the write call in vty_out has been replaced with
> buffer_write, so all the output is accumulated in buffers.  Once the
> command has completed, a flush is attempted, and if that is not able to
> flush out all the buffers, further flushes are scheduled.  So the current
> patch is really quite simple, the only significant change is to add the
> buffer_flush_available function to buffer.c.
>
> For those running bgp, perhaps you can test the existing patch using
> vtysh with the bgp_route stuff to see if it works OK?  If it does,
> that would suggest that we can safely remove the VTY_CONTINUE features
> in bgp_show_table.

I'm going to look at it in the evening, but for now I must say - really good 
work. I'm impressed. Preliminary performance test with bgpd with full feed:

Before applying patch
*********************
time vtysh -c "sho ip bgp" > /dev/null
   25.91s real     1.46s user    21.47s system

After applying patch
********************
time vtysh -c "sho ip bgp" > /dev/null
    5.27s real     0.13s user     0.37s system
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andrew J. Schorr | 1 Nov 2004 15:11
Favicon

[quagga-dev 1754] Re: daemon writes to vtysh need to be buffered or forked

On Sun, Oct 31, 2004 at 02:57:23PM +0000, Paul Jakma wrote:
> On Sun, 31 Oct 2004, Andrew J. Schorr wrote:
> >OK, I decreased the minimum buffer size to 4096.
> 
> That could be less than one page. Keep your getpagesize() call :)

No worries, that's still there.  The code will round up from 4096 to
the closest page boundary.

> Does the telnet path use your 'gathering' additions? (that would be 
> interesting too, though, mostly not relevant due to the telnet 
> psuedo-pager).

I didn't touch the telnet path.  As I understand it, the telnet path
has always buffered all of the command output first (as vty_out 
calls buffer_write), and then it parcels out the data bit by bit.

Now that it's been patched, vty_out always calls buffer_write (except
for VTY_SHELL connections, which are not really interesting),
whereas it used to have a special exception for vtysh (VTY_SHELL_SERV)
connections to call the write system call directly. 

So the only way that telnet connections have been affected is by
having the buffer size increase from 100 bytes to 4096.  That could
be a nice performance benefit.

I just tried a couple of tests using the telnet connection (first 
using the pager, second with "term len 0"), and it seems to work OK,
but I wouldn't be shocked if there were some scenarios where the
daemon could block.  If you're aware of any blocking problems with
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew J. Schorr | 1 Nov 2004 15:13
Favicon

[quagga-dev 1755] Re: daemon writes to vtysh need to be buffered or forked

On Mon, Nov 01, 2004 at 11:25:29AM +0200, Hasso Tepper wrote:
> I'm going to look at it in the evening, but for now I must say - really good 
> work. I'm impressed. Preliminary performance test with bgpd with full feed:
> 
> Before applying patch
> *********************
> time vtysh -c "sho ip bgp" > /dev/null
>    25.91s real     1.46s user    21.47s system
> 
> After applying patch
> ********************
> time vtysh -c "sho ip bgp" > /dev/null
>     5.27s real     0.13s user     0.37s system

Of course, the real question is whether the output is the same. :-)
But I'm not surprised by the speedup, the old code used to make a
write system call for every line of output, that was very
inefficient.

-Andy
Permalink | Reply | 0 comments |
headers
Marcio Gomes | 1 Nov 2004 15:43
Picon

[quagga-dev 1756] Re: [quagga-users 3081] Re: feedback -> ospfd oversized lsa / ospf_write fragmentation

Paul,

> Is not clear to me, if this issue has been solved in your 2004-10-31 
> cvs updates..
>
cvs-0.97.2 from 2004-11-01 are with same problems.

2004/11/01 11:41:21 OSPF: *** ospf_write_frags: sendmsg failed to 
224.0.0.6, id 1480, off 0, len 1500 failed with Message too long
2004/11/01 11:41:21 OSPF: *** ospf_write_frags: sendmsg failed to 
224.0.0.6, id 1480, off 0, len 1500 failed with Message too long
2004/11/01 11:41:21 OSPF: *** ospf_write_frags: sendmsg failed to 
224.0.0.6, id 1480, off 0, len 1500 failed with Message too long
2004/11/01 11:41:21 OSPF: *** ospf_write_frags: sendmsg failed to 
224.0.0.6, id 1480, off 0, len 1500 failed with Message too long

>
> Ps. If possible help me in the other question about stub and nssa code 
> in different
> quagga versions.
>

Regards,
Permalink | Reply | 0 comments |
headers
Hasso Tepper | 1 Nov 2004 15:47
Picon

[quagga-dev 1757] Re: [quagga-users 3081] Re: feedback -> ospfd oversized lsa / ospf_write fragmentation

Marcio Gomes wrote:
> Paul,
>
> > Is not clear to me, if this issue has been solved in your 2004-10-31
> > cvs updates..
>
> cvs-0.97.2 from 2004-11-01 are with same problems.
>
> 2004/11/01 11:41:21 OSPF: *** ospf_write_frags: sendmsg failed to
> 224.0.0.6, id 1480, off 0, len 1500 failed with Message too long
> 2004/11/01 11:41:21 OSPF: *** ospf_write_frags: sendmsg failed to
> 224.0.0.6, id 1480, off 0, len 1500 failed with Message too long
> 2004/11/01 11:41:21 OSPF: *** ospf_write_frags: sendmsg failed to
> 224.0.0.6, id 1480, off 0, len 1500 failed with Message too long
> 2004/11/01 11:41:21 OSPF: *** ospf_write_frags: sendmsg failed to
> 224.0.0.6, id 1480, off 0, len 1500 failed with Message too long

Paul is working on it AFAIK.

--

-- 
Hasso Tepper
Elion Enterprises Ltd.
WAN administrator
Permalink | Reply | 0 comments |

Gmane