RTEMS Network Stack and Managed Switch

[Joel Sherrill]

You didn't reply to the entire list so I am adding it back.

You are using the legacy stack (cpukit/libnetworking) which is 20+ years
old and IPV4 only.

There could be a packet which the older stack doesn't like the format of.
Perhaps a number pushes something out of range.

Any possibility there is IPV6 on the network? I don't know how this stack
reacts to that.

Another simple thing to try is increasing the size of the stacks and
turning on the stack checker.

--joel

On Thu, Oct 8, 2020 at 10:39 AM <Richard.Glossop at l3harris.com> wrote:

> Hi Joel,
>
>
>
> We are using Gaisler’s rc7 release for RTEMS 5.1.  I don’t see libbsd in
> the map file at all, but not really sure how to tell.
>
>
>
> We do have an FPU and our tasks are all FP enabled.  Not sure on the
> network stack.
>
>
>
> *From:* users <users-bounces at rtems.org> *On Behalf Of *Joel Sherrill
> *Sent:* Thursday, October 8, 2020 11:29 AM
> *To:* Thomas Doerfler <Thomas.Doerfler at imd-systems.de>
> *Cc:* rtems-users at rtems.org <users at rtems.org>
> *Subject:* [EXTERNAL] Re: RTEMS Network Stack and Managed Switch
>
>
>
>
>
>
>
> On Thu, Oct 8, 2020 at 10:25 AM Thomas Doerfler <
> Thomas.Doerfler at imd-systems.de> wrote:
>
> Richard,
>
> what hardware/BSP are you running on?
>
>
>
> Thomas beat me on this. :)
>
>
>
> Also the RTEMS version and network stack (legacy vs libbsd).
>
>
> Just a shot in the dark: It seems the system crashes in arplookup -> ...
> -> svfprintf. Can it be that some networking routine tries to print a
> message with floating point, but the FPU is disabled for the
> corresponding task?
>
>
>
> Since I recall you are using a LEON, this is indeed a very likely culprit.
>
>
>
> The stack trace is a bit odd since nothing in libc would call
> _Internal_XXX.
>
>
>
> --joel
>
>
> wkr,
>
> Thomas.
>
> Am 08.10.20 um 17:15 schrieb Richard.Glossop at L3Harris.com:
> > We have discovered a problem with the RTEMS network stack reaching the
> > RTEMS _Terminate function when the interfaces are attached to a managed
> > switch (in this case a Cisco 3560).
> >
> >
> >
> > This does not occur with direct connections or when attached to a layer
> > 2 unmanaged switch (NetGear or SMC).  Of course the 3560 puts out a lot
> > of traffic that a layer 2 switch does not (spanning tree, CDP etc….)
> >
> >
> >
> > So it seems the managed switch is putting out traffic that is bringing
> > RTEMS down.
> >
> >
> >
> > Has anyone seen this behavior?  Have you determined the root cause?
> >
> >
> >
> >
> >
> > I set a break point and caught the following backtrace:
> >
> >
> >
> >   #0   0x6006ec90   0x60200180   <_Terminate+0x4>
> >
> >   #1   0x6006ece0   0x602001e8   <_Internal_error+0x8>
> >
> >   #2   0x600da250   0x60200248   <_svfprintf_r+0x14>
> >
> >   #3   0x600d5810   0x60200420   <snprintf+0x58>
> >
> >   #4   0x60073bac   0x60200508   <inet_ntop4+0x24>
> >
> >   #5   0x60073e70   0x60200580   <inet_ntop+0x280>
> >
> >   #6   0x60073b78   0x60200630   <inet_ntoa_r+0x1c>
> >
> >   #7   0x60076340   0x60200698   <arplookup+0x78>
> >
> >   #8   0x60076e34   0x60200710   <arpintr+0x20c>
> >
> >   #9   0x6008861c   0x602007c0   <networkDaemon+0xa0>
> >
> >   #10  0x60088164   0x60200828   <taskEntry+0x20>
> >
> >   #11  0x6006d210   0x60200888   <_Thread_Entry_adaptor_numeric+0x8>
> >
> >   #12  0x6006c464   0x602008e8   <_Thread_Handler+0x60>
> >
> >   #13  0x6006c404   0x60200948   <_Thread_Handler+0>
> >
> >
> >
> >
> >
> > CONFIDENTIALITY NOTICE: This email and any attachments are for the sole
> > use of the intended recipient and may contain material that is
> > proprietary, confidential, privileged or otherwise legally protected or
> > restricted under applicable government laws. Any review, disclosure,
> > distributing or other use without expressed permission of the sender is
> > strictly prohibited. If you are not the intended recipient, please
> > contact the sender and delete all copies without reading, printing, or
> > saving.
> >
> >
> > _______________________________________________
> > users mailing list
> > users at rtems.org
> > http://lists.rtems.org/mailman/listinfo/users
> >
>
> --
> IMD Ingenieurbuero fuer Microcomputertechnik
> Thomas Doerfler           Herbststrasse 8
> D-82178 Puchheim          Germany
> email:    Thomas.Doerfler at imd-systems.de
> PGP public key available on request
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users
>
>
>
> CONFIDENTIALITY NOTICE: This email and any attachments are for the sole
> use of the intended recipient and may contain material that is proprietary,
> confidential, privileged or otherwise legally protected or restricted under
> applicable government laws. Any review, disclosure, distributing or other
> use without expressed permission of the sender is strictly prohibited. If
> you are not the intended recipient, please contact the sender and delete
> all copies without reading, printing, or saving.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20201008/96e067fd/attachment-0001.html>