lcdpd-users

[lcdpd-users] This thing still kicking?

[Nick E. <gr...@ni...>]

Looking for a solution to allow a Linux host (working on Windows as well) 
to identify itself to a Cisco switch via CDP. Just like the CDP driver of 
any Cisco based appliance does.  I do not need to sniff CDP traffic (hence 
WireShark, etc are not what I need)

This sounds just about right, and lets me watch what CDP I get as well.

Is this code valid for 2.6.21+

Nick


-- 
Nick Ellson
Dad
CCDA, CCNP, CCSP, CCAI,
MCSE 2000, Security+, Network+
Network Hobbyist, VFR Private Pilot.

Re: [lcdpd-users] What's the status

[Josiah R. <jri...@bi...>]

On Fri, 15 Oct 2004 10:53:24 +1000 (EST)
tom burkart <to...@au...> wrote:

> On Oct 14, Josiah Ritchie wrote:
> 
> > I'm noticing a lack of posting on this mailing list. Is there any
> > current status? I'm mostly curious if this patch can be applied to a
> > 2.6 kernel or if another project took this over has something that
> > would work.
> Little has happened as there was no request thus far and quite reasonable
> support for the CDP protocol is in "ethereal".

Really? I hadn't heard about ethereal w/ cdp. I'll check on that. I'm
surprised that interest in this hasn't been more keen.

JSR/

Re: [lcdpd-users] What's the status

[tom b. <to...@au...>]

On Oct 14, Josiah Ritchie wrote:

> I'm noticing a lack of posting on this mailing list. Is there any current
> status? I'm mostly curious if this patch can be applied to a 2.6 kernel or
> if another project took this over has something that would work.
Little has happened as there was no request thus far and quite reasonable
support for the CDP protocol is in "ethereal".

tom.
Consultant

AUSSEC    Phone: 61 4 1768 2202
339 Blaxland Rd., Ryde NSW 2112
Email: to...@au...

[lcdpd-users] What's the status

[Josiah R. <jri...@bi...>]

I'm noticing a lack of posting on this mailing list. Is there any current
status? I'm mostly curious if this patch can be applied to a 2.6 kernel or
if another project took this over has something that would work.

Thanks,
JSR/

Re: [lcdpd-users] lcdpd details

[tom b. <to...@au...>]

Today, Madhavi(sony) wrote:

> i want to know in detail about this lcdpd.
Have you tried <http://lcdpd.sourceforge.net/>?
They are most of the details.

tom.
Consultant

AUSSEC    Phone: 61 4 1768 2202
339 Blaxland Rd., Ryde NSW 2112
Email: to...@au...

[lcdpd-users] lcdpd details

[Madhavi\(sony\) <so...@re...>]

hi,

i want to know in detail about this lcdpd.

regards
madhavi


_______________________________________________________________________
Odomos - the only  mosquito protection outside 4 walls -
Click here to know more!
http://r.rediff.com/r?http://clients.rediff.com/odomos/Odomos.htm&&odomos&&wn

Re: [lcdpd-users] stupid user can't get lcdp to work

[tom b. <to...@au...>]

On Aug 12, James S. Johnson wrote:

> This would be a nice tool to have, if I could get it to work.  Have I missed
> anything in setting lcdp up?
Doesn't appear to be.

> (6) look at Cisco switch for CDP neighbors - there are none
Remember though that lcdp will only receive and decode CDP packets - it
will not send any.

set debug to 8 and send your logs to me (not to the list please as this
is very verbose).  You should need 2 minutes at most.  Preferably only
send lines with "cdp" in them.  Also let me know if there are none (which
would mean that the cdp packets do not get to the handler).  I vaguely
remember having that problem on a machine with unusual hardware (so maybe
sending me a hardware profile may be useful).

tom.
Consultant

AUSSEC    Phone: 61 4 1768 2202
339 Blaxland Rd., Ryde NSW 2112
Email: to...@au...

[lcdpd-users] stupid user can't get lcdp to work

[James S. J. <jjo...@ec...>]

This would be a nice tool to have, if I could get it to work.  Have I missed 
anything in setting lcdp up?

(1) patched 2.4.18 kernel - appears to have taken patches correctly
(2) compiled kernel with CDP as a module
(3) rebooted with new kernel and loaded module - lsmod shows cdp is installed 
but is unused
everything else in my kernel is compiled in, so cdp is the only module loaded
/lib/modules/2.4.18-lcdp/modules.dep shows cdp has no dependencies
/var/log/sys.log shows cdp loads correctly
(4) after several minutes cat /proc/net/cdp_neighbors shows no information
(5) set up sniffer on the line - sure enough, my Cisco switch is sending out 
CDP packets once every minute
(6) look at Cisco switch for CDP neighbors - there are none
(7) recompile kernel with CDP debugging turned on
(8) reboot, load the module, wait a few minutes, and look in /var/log/sys.log 
- no debug messages
(9) look at /proc/net/cdp_neighbors - still no neighbors reported
(10) look at sniffer and still see CDP packets on the line


Is there a userland tool or sysctl flag that I need to set in order to tell 
cdp.o to start running?  Or have I overlooked something else?

James Johnson

[lcdpd-users] lcdpd-0.2.3 patch available

[tom b. <to...@au...>]

The 0.2.3 kernel patch is a maintenance release fixing the following
issues:
- patches against 2.4.18 (not tested against others)
- prints IPX and Appletalk addresses properly

The web page has been updated, with a TODO list added.

tom.
Consultant

AUSSEC    Phone: 61 4 1768 2202
339 Blaxland Rd., Ryde NSW 2112
Email: to...@au...

Re: [lcdpd-users] Lcdp bugs?

[tom b. <to...@au...>]

> JM: Are you sure there will never be elements that consist of TL only?
Initially - yes because we don't use malformed packets.
When the code becomes more usable we will test for bad packets as well.

> JM: FIXME - make sure, that length is <= number of bytes remaining in the packet
Yes -> TODO

> JM: I don't know enough about procfs, but what happens, when there are a few
>     Elements with 64000 Bytes? Is the buffer big enough? Just looked at
>     kernel/module.c: they make sure they don't overflow any buffers!
Yes this is a bug -> TODO

> +	while ( p ) {
> +		if ( (p->timestamp.tv_sec+p->cdp_ttl) < sometime.tv_sec ) {
> +			if ( p->next ) {
> +				p = p->next;
> +				cdp_delete_neighbor( p->prev );
> JM: what is the idea behind this? why not cdp_delete_neighbor(p)?
Remeber you have to put "p" onto the next item first and then free the
item else the loop will terminate early.

Web site has been updated.

tom.
Consultant

AUSSEC    Phone: 61 4 1768 2202
339 Blaxland Rd., Ryde NSW 2112
Email: to...@au...

Re: [lcdpd-users] Lcdp bugs?

[Chris C. <ch...@sh...>]

On Sat, 26 Jan 2002, Joerg Mayer wrote:

> Hello,

Hey,

> annotated patchfile below). The more I think about it, the more I am conv=
inced that
> cdp should *not* be implemented as a kernel module but as a user space da=
emon. One

=09I'm working on creating a userspace version atm (currently it's
nothing more than a rough sketch out).

> more thing about the module: cisco recently published a security advisory=
 about a
> DOS on cdp that would work against your code too: Take a machine that sen=
ds out faked
> cdp packets from many faked senders. If you add long version strings etc =
then it's

=09*nod* - I've heard the exploit, someone mentioned it to me a while
ago; but I completly forgot about it, I'll read-over your patch and
probably add it to the CVS version of the code today or tommorow.

> a thing of a few seconds and there will be no memory left - and the more =
I looked at
> the code, the more I'm conviced that cdp should be done in a userspace da=
emon instead
> of a kernel module. That way the normal resource limiting mechanism can b=
e used.

=09This is going to be done - the kernel patch will probably end up
an item of historic interest to the project; and used by me because I like
being able to cat a proc entry to get a quick list :)  Of course that
could just as easily be done by domain sockets or FIFO's...which is
probably what I'll do on the daemon.

>   Ciao
>            J=F6rg

--=20
Chris "_Shad0w_" Crowther
ch...@sh...
http://www.shad0w.org.uk/

[lcdpd-users] Lcdp bugs?

[Joerg M. <jm...@lo...>]

Hello,

I recently downloaded lcdp 0.2.2 - it's really nice that there is a cdp i=
mplementation
for Linux now. Then I looked at the code in detail and found some problem=
s (see the
annotated patchfile below). The more I think about it, the more I am conv=
inced that
cdp should *not* be implemented as a kernel module but as a user space da=
emon. One
more thing about the module: cisco recently published a security advisory=
 about a
DOS on cdp that would work against your code too: Take a machine that sen=
ds out faked
cdp packets from many faked senders. If you add long version strings etc =
then it's
a thing of a few seconds and there will be no memory left - and the more =
I looked at
the code, the more I'm conviced that cdp should be done in a userspace da=
emon instead
of a kernel module. That way the normal resource limiting mechanism can b=
e used.

  Ciao
           J=F6rg

+/* update a neighbor entry with newer values */
+int cdp_update_neighbor( struct sk_buff *skb, struct s_cdp_neighbor *p )=
 {

[...]

JM: Are you sure there will never be elements that consist of TL only?

+	while ( (skb->tail-skb->data) > 4 ) {
+		type =3D 0;
+		length =3D 0;
+
+		memcpy( &type, (skb->data)++, 2 ); (skb->data)++;
+		memcpy( &length, (skb->data)++, 2 ); (skb->data)++;
+		/* make sure the byte order is right */
+		type =3D ntohs( type );
+		/* total length includes the type field and length field */
+		length =3D ntohs( length ) - 4;

JM: FIXME - make sure, that length is <=3D number of bytes remaining in t=
he packet

		if (skb->tail-skb->data < length) {
				someone is sending broken packets! (trying to
				make us copy data beyond end of packet)
				handle error...
				return 0;
		}
+
+		data =3D (unsigned char *)kmalloc(
+				sizeof(unsigned char)*length,
+				GFP_ATOMIC );

[...]
+
+
+/* do the data display for /proc/net/cdp_neighbors query */
+int cdp_get_neighbor_info( char *buffer, char **start, off_t offset, int=
 length ) {
[...]
+			break;
+	}
+
+	restore_flags( flags );
+
+	*start =3D buffer + (offset-begin);
+	len -=3D offset - begin;
+	if ( len > length )
+		len=3Dlength;
+
+	return len;

JM: I don't know enough about procfs, but what happens, when there are a =
few
    Elements with 64000 Bytes? Is the buffer big enough? Just looked at
    kernel/module.c: they make sure they don't overflow any buffers!

+}
+
+
+
+/********************************************************************
+	network functions
+ ********************************************************************/
+
+/* deletes timed out neighbor entries (ie TTL expired) */
+static void SMP_TIMER_NAME(cdp_check_expire)( unsigned long unused ) {
+	struct timeval sometime;
+	struct s_cdp_neighbor *p =3D cdp_neighbors.head;
+	unsigned	long	flags;
+
+	mod_timer( &cdp_poll_neighbors_timer, jiffies + CDP_POLL /* now + CDP_P=
OLL */ );
+
+	get_fast_time( &sometime );
+	save_flags( flags );
+	cli();
+
+	/* now go through the neighbor list */
+	while ( p ) {
+		if ( (p->timestamp.tv_sec+p->cdp_ttl) < sometime.tv_sec ) {
+			if ( p->next ) {
+				p =3D p->next;
+				cdp_delete_neighbor( p->prev );

JM: what is the idea behind this? why not cdp_delete_neighbor(p)?

+			}
+			else {
+				cdp_delete_neighbor( p );
+				break;
+			}
+		}
+		else
+			p =3D p->next;
+	}
+	restore_flags( flags );
+}
--
Joerg Mayer                                          <jm...@lo...>
I found out that "pro" means "instead of" (as in proconsul). Now I know
what proactive means.