#82 UNPROTO frames monitored & mishandled by FBB causes SEGFAULT

[Red Tuby]

This ticket is a collection of the data gathered so far by G7TAJ / GB7BEX

The issue I have been seeing with fbb v11 and latest linbpq is that it
(fbb) crashes when it monitors the BPQ node traffic.
Tracking this down, it's on UI frames, specifically the unproto of messages
like this -> 12345 !!
when FBB falls over, it is thinking the frame is a "NET/ROM from" as the monitor
frame has a PID of 0xcf

fm G7TAJ-2 to FBB ctl UI pid CF

As this is happening on the loopback port as well as other ports, I can only
assume this is FBB sending the wrong PID for this frame. I can't understand
how this is not causing issues everywhere else / for others if this is the case.

I will try to see if I can work out if FBB is sending the wrong PID. It doesnt
on it's mail beacons.

(On latest LinBPQ 6.0.23.74, DED interface):

10:40 G7TAJ  Steve_44 : to answer your question, YES, it still crashes. same issue it appears.
10:41 G7TAJ  Steve_44 : easily reproduced if you send an unproto with 'NET/ROM ' in it.
10:42 G7TAJ  Steve_44 : or 'Nodesbr'. I think possibly I'm trying to break it here but if that text appears anywhere in a message or the like, it will crash it.
10:44 G7TAJ  Steve_44 : as the PID gets set wrong. [Regarding a slightly different issue reported and fixed in LinBPQ]- It probably is fixed regarding the null termination which is actually what I said the problem was, but it's a bit more than that it apepars.
12:13 G8BPQ  John : Steve, I see that as a bug in FBB. It shouldn't crash if if gets a pid cf message with unexpected format.
12:43 G7TAJ  Steve_44 : rgr John, I agree as well. I think Red has already pushed it to FBB people.
12:45 G7TAJ  Steve_44 : but it might need a bit of fleshing out from my side in what exactly it's doing/seeing

Some more:

"26745  !!\r" frame from itself, which it gets back through loopback
It detects it as a NETROM frame and of type IP.
Which sets the length to 20, when its only 10 long, so goes to -10
that then breaks it, obviously.
in GDB it comes out like this
1: chaine = "(NRom: \031\033\033\032\032\020-0 \020\020\006\000\000\000-0 0 0 0 IP)", '\000'

Decoded=0xf30fe790 "11:45:26T G7TAJ-2>FBB Port=6 <UI C>:\r26745 !!\r NET/ROM\r G7TAJ-9 to GB7BEX-7 ttl 25 cct=030D <INFO ACK R9> \r", Len=47

FBB parses the words "NET/ROM" and classifies the packet as pid=0xcf and then FBB segfaults.

[Dave van der Locht]

Red, do you know if Steve G7TAJ is the only person with the issue. Or are others with similar/same setup also having the issue?

Is the reported monitor data coming from FBB's monitor? Or BPQ's monitor? Or maybe both showing the same?

Strange thing as I would expect many more sysops having (and reported) issues when FBB sends a wrong PID with unproto messages.

As far as I know, and searched in source a bit just yet, FBB doesn't classify packets based on payload content like the phrase 'NET/ROM'.

When time is allowing me I'll setup a test environment with LinBPQ and will try to see what's happening and hopefully being able to replicate the issue to be debugged.

Can you ask Steve G7TAJ for his BPQ32.cfg and FBB's ports.sys files and email them to me please?

[Dave van der Locht]

Additional info received from Steve G7TAJ:

---

The issue with fbb is with it assuming a netrom packet is correct and not corrupt. BPQ unfortunately seems to detect the types of packets by words contained in them so a packet with the chars 'NET/ROM ' in it will have its PID set to 0xCF. Fbb then assumes the packet is correct, which it isn't and segs.
There was a problem with the string not being null terminated in BPQ and so the phrase was appearing after valid data but that has been patch. But you can still make it crash as fbb assumes the packet is 100% correct.

---

Together with the earlier received info I think I've got the problem description clear/complete now.

BPQ seems to alter a received UI frame wrongly, by setting the PID to 0xCF, due to the presence of the string 'NET/ROM' in its payload.

When LinFBB receives such corrupted frame it segfaults instead of ignoring/dropping it completely. That needs to be debugged and resolved, LinFBB should not segfault on any kind of corrupted frame.