Activity for Brian
-
Brian committed [r3]
-
bug fixes found by K3CHB
-
-
Initial commit
-
Initial commit
-
Initial commit
-
Initial commit
-
Initial commit
-
Initial commit
-
Initial commit
-
Initial commit
-
Initial commit
-
Initial commit
-
Initial commit
-
Initial commit
-
Initial commit
-
Initial commit
-
Initial commit
-
Issue has been fixed in 7.0.11 as I've been testing for a couple months now. Ticket can be closed.
-
Dave; On Mon, 2021-06-21 at 16:59 +0000, Dave van der Locht wrote: Brian; I totally agree. With what I've seen in code and with testing the BIDs aren't saved with KILL result when passed through m_filter, but they should and were when HOLD. Still not sure why the previously HOLDed ones are getting through at yours, and I'm monitoring systems closely to see that happen with an m_filter in place now. I think the BID also should be saved with KILL result, but that's not happening 100% for sure. Will...
-
Dave; On Mon, 2021-06-21 at 13:15 +0000, Dave van der Locht wrote: PE1RRR's report is somewhat different than this ticket initially started with. Behaviour for killed messages is different. When killed due to m_filter's result changing status to 'K', these BIDs aren't stored currently. When another forwarding partner offers a message with the same BID as the previously killed one, it is accepted and getting killed by the filter (again) as a result of that. Should it be? Or should FBB also store the...
-
Dave, The bid is passed during the forward exchange of the batch of mail to be sent. Fbb should respond to the remote system with a N or - or if ascii NO and the remote should never send the message. If it passes bid checking prior to responding to the batch the proposal then should go to reject.sys. If it passes both then the BBS should respond with a Y or +. Once the message is received it at that point should go to m_filter where the contents will be scanned and the message handled accordingly....
-
Just a suggestion that somewhat would make logical sense (as if that ever worked ;-> ) Dave - in the flow of incoming messages, would it first hit m_filter and just go on hold or killed? If so then perhaps checking BIDs should come prior to m_filter as if a BID already exists, m_filter should never see it. On Sun, 2021-06-20 at 11:28 +0000, Dave van der Locht wrote: status: closed --> open Comment: Ticket reopened. PE1RRR reported he noticed similar issues after he installed and started using G0GLS's...
-
Dave; These were messages UNheld that duped today: From : K5DAT To : IPV6 @WW Type/Status : B$ Date/Time : 20-May 04:08 Bid : 11313_K5DAT Message # : 263486 Title : RE: IPV6 LU9DCE NODE R:210520/0309Z @:PI8DFT.#ZH1.NLD.EURO #:10699 [Delft] $:11313_K5DAT R:210520/0309Z 3765@PE2V.#OV1.NLD.EURO LinBPQ6.0.21 R:210520/0308Z 15273@PI8BDG.#ZH1.NLD.EURO LinBPQ6.0.21 R:210520/0308Z 3054@PI8LAP.#ZLD.NLD.EURO LinBPQ6.0.21 R:210520/0308Z 11313@K5DAT.#CWI.WI.USA.NOAM LinBPQ6.0.21 Unfortunately my ISP, which is...
-
Dave; I haven't found any in a while either. I'll keep watch though. On Tue, 2021-05-18 at 16:49 +0000, Dave van der Locht wrote: An update on this one because I haven't found a possible cause after some effort yet. BID check on duplicates of held messages doesn't seem to fail consistent here for some reason. Actually, still no fail at all. I also haven't been able to replicate the issue yet. On receiving a duplicate message which is on hold already, FBB keeps responding with an 'FS N' and the copy...
-
Dave; On Wed, 2021-05-19 at 15:15 +0000, Dave van der Locht wrote: Brian; I never mentioned, Maiko. You did in your first/initial post here. Also the 3rd party text is added. Please see the commit in SVN. I think you're replying to your own first post... Perhaps, Wednesdays I run a full clamAV scan and until it's finished my screens act up. Talk about a resource hog! -- My body IS a temple: Ancient and crumbling, probably cursed and haunted as well. 73 de Brian N1URO Linux Partner Developer Decades...
-
Dave; What does Maiko have to do with the patch I submitted? Also you should include the fact that the message may be 3rd party. SMTP receive is not enough... which is the full patch I submitted. On Wed, 2021-05-19 at 09:40 +0000, Dave van der Locht wrote: assigned_to: Dave van der Locht [tickets:#68] Mail received via SMTP Status: pending Milestone: 7.11 Created: Sat Dec 19, 2020 04:14 AM UTC by Brian Last Updated: Wed May 19, 2021 09:39 AM UTC Owner: Dave van der Locht In a recent discussion with...
-
Patch is in initfwd.c, line 244. Add a c infront of ommand :)
-
Issue 1 remains. Issue 2 is operator error for not closing each file with "-----"
-
Issues in forward file handling
-
Dave; On Fri, 2021-04-09 at 14:39 +0000, Dave van der Locht wrote: Still need to test and dive into some code, but did you notice if it was an incident, happens occasionally or happens constantly with a message held at first? There's no need to stall on this "for testing sake". Just as I helped find the segfaulting issue this issue is as consistent as well. If my co-sysop unholds the first message the others get rejected HOWEVER if he misses them then incoming dupes are NOT bidchecked. When you consider...
-
Dave; On Fri, 2021-04-09 at 11:36 +0000, Dave van der Locht wrote: I'm not sure if LinFBB's bid check actually skips messages already there with a particular state or flag. I'll check if I can replicate the issue on my test setup to see what/why things happen. 260869 0409/0218 BK 15551 HUMOUR @WW GM3YEW jokes 8/4 <-- 260816 0408/0320 BK 16230 HUMOUR @WW GM3YEW jokes 8/4 <-- 260810 0408/0220 BK 15920 HUMOUR @WW GM3YEW jokes 8/4 <-- 260807 0408/0218 BK 15874 HUMOUR @WW GM3YEW jokes 8/4 <-- 260802 0408/0211...
-
Msgs held - race condition
-
Dave; On Fri, 2021-03-05 at 17:34 +0000, Dave van der Locht wrote: This might be 'fixed' with the change in [r211] which will be in the 7.0.11 release version. When an underlying interface goes down for some reason / isn't accessible anymore by FBB, it could lead to a segfault of xfbbd. This was exactly the case. I reconfigured my ax25 interfaces and thought I correctly did so in port.sys to match. I was in error. -- Future news: Heard from a TV studio in Stamford, CT in the year 2050 "Jerry... atric!...
-
segfaulting in 7.0.10
-
FYI: To help find this bug to begin with, it was caused by another bug! Let me explain: I use a PacComm Tiny 2 Mk II as my user interface TNC. It has a 6pack eprom linked to the kernel via SPATTACH instead of KISSATTACH. Problem - SPATTACH does not appear to close it's initial connection as with NetRom which YO2LOJ made some kernel patches for. When this occurs, the interface vanishes and causes a conflict with port.sys. Since I switched the eprom in the TNC to a regular user eprom and put it in...
-
Dave, I received a few more panics between FBB and libax25 using fbb ver 7.0.10. Has there been any patches made available?
-
I wrote a script for debian (and based) systems that can start/stop/status/restart xfbbd. You may include it with the source/svn if you desire. It's: n1uro@n1uro:~$ cat /usr/local/bin/fbbcheck ! /bin/sh . /lib/lsb/init-functions MYFBB=ps ax|grep fbb|grep xfbbd|grep sbin|awk '{ print $1 }' PID=ps ax|grep fbb|grep xfbbd|grep sbin|awk '{ print $1 }' if [ -z "$1" ] then if [ -z $MYFBB ] then log_warning_msg "FBB BBS not found running" sleep 2 log_action_msg "Reloading FBB... " sleep 2 /usr/local/sbin/fbb...
-
Dave; On Sat, 2020-12-19 at 21:15 +0000, Dave van der Locht wrote: Brian; Thanks, that's useful info. I didn't really understand what you meant with 'drop in something mid-stream'. Say you have mail to forward that would take 4 frames to complete. Cut off the feed after 2 frames so 2 remain... by halting the transport not by using FU <chan> (although that may work too). When you try to connect again you'll get a denial and by logging into her node using the SEssions command you can see my fbb is...
-
Dave; On Sat, 2020-12-19 at 20:33 +0000, Dave van der Locht wrote: Brian; Do you know any factor/method whereby I can 'drop in something' to replicate that specific behaviour to see it happen and take a look at the issue? Set up two machines with axip between them. You'll need to poll Cathryn as she seems to use a separate shell script (which may be part of the problem) to call/spawn her FBB. In mid stream of forwarding mail, unplug the ethernet/wifi and flush the axip socket. Try to let things resync...
-
As one who forwards to KE6I, this is occurring on her patched system. If something drops in mid stream while forwarding, her socket remains open and I get denied attempting to connect to continue the feed. On Sat, 2020-12-19 at 20:09 +0000, Dave van der Locht wrote: I'm currently running LinFBB 7.0.10 for about 2 months steady on a patched 5.4 kernel without having any AX.25 w/netrom issues, sockets not closing or forwarding sessions/connections not closing. I also didn't encounter these issues with...
-
FYI: Dave if you sent me an email, I didn't receive it. Is gmail an option for you? That I get via IPv6 no problems.
-
Fixed my bug. In drv_pop.c around line 2377... I changed it to: sprintf(str, "\rSMTP Mail received, may be 3rd party mail.\rHeaders:\rFrom: %s\r", tport[port].tcan[can].mail_from->address); and in lzhuf.c around line 518 I changed it to just: sprintf (s, ""); This deletes DUPE headers while properly detecting mail received initially via SMTP and warns the reader that the preceding message may contain third party communications which is something hams really should be alarmed about before continuing....
-
scrap this ticket. I forgot to do one test that did fail.
-
The ticket system converted plus and minus symbols to bullets. should be -, -, +
-
Mail received via SMTP
-
Dave; On Fri, 2020-12-18 at 17:42 +0000, Dave van der Locht wrote: Brian, I think it has something to do with Rose. I have to setup Rose on my test system to see if I can reproduce the issue. This may be as I do run ROSE. For analysing purposes it would be helpful to receive your compiled libax25.so and preferably also the source which is used, to check which function is involved with a segfaulting xfbbd at the offset as shown in your dump in ticket #61. I'm using the devuan repo package. If you...
-
Guys; The last semi working version was 4.1.x. It stopped functioning in kernel 4.2.0. Since version 2.6 however ROSE is quite vulnerable and still is. I can easily take down any ROSE system. Even with the patch ROSE is still very vulnerable. I'm using a version of ax25-apps/tools/libs sent to me by DL9SAU last year or so that has some new features in them he wished me to test. FYI: 7.04j speed wise is 100 fold faster. -- Roses are reddish, Violets are bluish, If it wasn't for Christmas, We'd all...
-
While ascii stock comes with 4.9 it was an upgrade from jessie which saw I was using ax25 and kept 3.16 due to the issuses with the broken ax.25 stack in kernels 4.x+
-
I don't know if Cathryn still has that screenshot. That phone I took it on literally burned up. I've been getting those since kernel 3.16 and upgrading fbb. The OS I'm actually using is Devuan Ascii w/TrinityDesktop.
-
KERNEL OOPS/LOCK UPS
-
Another sample as of 9/16/2020: BBSURO:N1URO-4 > v 249707 249681 From : GM3YEW To : HUMOUR@WW Type/Status : B$ Date/Time : 16-Sep 06:56 Bid : 5645_GB7YEW Message # : 249707 Title : jokes 16/9 R:200916/0556Z @:GB7CIP.#32.GBR.EURO #:6210 [Caterham Surrey GBR] $:5645_GB7YEW R:200916/0555Z 3472@N7HPX.#BOI.ID.USA.NOAM BPQ6.0.20 R:200916/0554Z 59269@KF5JRV.#NWAR.AR.USA.NA BPQ6.0.20 R:200916/0554Z 45594@KE0GB.#SECO.CO.USA.NOAM LinBPQ6.0.20 R:200916/0554Z 5645@GB7YEW.#79.GBR.EURO LinBPQ6.0.18 bort <c>ontinue...
-
This can be closed.
-
BID check is failing.
-
Please close this ticket out as I'm no longer running a node or fbb.
1 >