NOTICE-WARNING- TIME BOMB!!

[crompton@nadc.nadc.navy.mil (D. Crompton)]

Ok Now that I have gotten your attention - there is a potential time
bomb in the JN108DFF code that needs to be fixed. The following code
was added in IP.C by me. Unfortunately The "free_p(bp);" line was
entered as "free_p(bp1);" What this has the effect of doing is causing
an "invalid free warning" whenever an IP packet that is short on bytes
arrives. This apparently is a rare happenning but in many cases it
causes a system crash after one or more invalids free. Obviously not
a good thing and since it is sitting there waiting to happen it is
really a "time bomb"!

I have corrected this in the source and exe files at crompton.nadc.navy.mil
and at wa3dsp.ampr.org. Please download a new copy if you use this code.
If you already have the source just make the change - "bp1" to "bp" as
outlined above and shown below.

Sorry for any inconvenience this may have caused. I would also be interested
if this condition has been experienced by anyone else. Awhile back I sent
a note into the group about extremely random "invalid free warnings". I
suspected a gremlin because it had no real pattern - weeks could go by
and then all of the sudden I could not keep a system going. Everytime
I would reboot it would crash within minutes or hours. Apparently the
problem of IP len vs. defined header length is very rare but some systems
must do this. When I was having the severe problem this weekend I caught
it in a trace "checksum error" just before the "invalid free" - For 
what it is worth it was coming from - 44.20.0.196 and was an ACK PSH FIN
to a non existent socket on my system  - tcp port 23 and had the following
text - "checksum error (1)   gracilis nos302  gw.k0yum  callsign / login:"
        
If VE3DTE is around I would like to have his comments on why this was done
again. Apparently he had some problems that prompted him to write this. 
>From my experiance with the errors occuring it seems that it seldom
happens (the IF statement is TRUE). I think what he is saying here
is if the IP packet is not good then don't pass it onto the higher
level function - the next thing called in the code after this segment.
Normally the error would be trapped by checksum in TCP. Since it would
never see this packet could this break something else?


I think this was a typo by me when entering it into my JNOS code        
version. I do not think it is a problem with other versions. I checked
110H and it was correct. The correct code segment is:
        
        /* Following code added to improve reliability
           check to see that length field matches packet length
           from VE3DTE
        */
        if ((IPLEN + ip->optlen + len_p(bp)) != ip->length) {
                /* then we lost some bytes somewhere - VE3DTE */
                free_p(bp);
                return;
        }


This should return the DFF code to the stable base it always was!!


73 Doug