Activity for LinFBB
-
Yarda created ticket #90
Build failure with recent X11
-
Dave van der Locht posted a comment on ticket #89
I'll have some thoughts about this one. The idea of doing some kind of alerting / notification for sysop's personal mail is good. But I think the suggested method, (over)writing the beacon to a flat file, is not the preferenced method to do so. Having a Raspberry Pi to flash a LED when there's personal mail awaiting for the sysop is already relatively easily possible by using (reading and parsing) the message database (dirmes.sys) with an external script or executable scheduled. Just make sure you...
-
Chris posted a comment on ticket #89
I could possibly look for the object code in the source directory, and patch it too. But would be nice as a feature for all to use.
-
Mailfor Beacon -> Flat file
-
I can send the patch to you directly. It did fix the issue. Thanks, Chris Maness -Sent from my iPhone On Wed, Apr 9, 2025 at 2:19 AM Dave van der Locht davevdl@users.sourceforge.net wrote: labels: 7plus --> 7plus, m_filter [tickets:#88] https://sourceforge.net/p/linfbb/tickets/88/ m_filter error to stdout kills forward session Status: accepted Milestone: 7.0.12 Labels: 7plus m_filter Created: Tue Apr 08, 2025 12:15 PM UTC by Chris Last Updated: Wed Apr 09, 2025 09:18 AM UTC Owner: Dave van der Locht...
-
m_filter error to stdout kills forward session
-
m_filter error to stdout kills forward session
-
m_filter error to stdout kills forward session
-
Ah, it's regarding the M_FILTER example in the 7plus 'addon' in the files section. I'll repackage that one with your patch applied. Sourceforge is stripping stuff (no code block used?) but that's fine. I see the issue and your suggestion to fix it seems to be good too.
-
It is a separate package here on the sourceforge site: https://sourceforge.net/projects/linfbb/files/7plus/7plus.tar.bz2/download This is to provide 7plus compression in the file server. One sends a message like this 7pserv@km6jtd Subject:gtjbios.com and you get 7plus message in return. If it is big, it is automatically broken into parts.
-
It is a separate package here on the sourceforge site: https://sourceforge.net/projects/linfbb/files/7plus/7plus.tar.bz2/download This is to provide 7plus compression in the file server. One sends a message like this 7pserv@km6jtd Subject:gtjbios.com and you get 7plus message in return. If it is big, it is automatically broken into parts. -73 de Chris KQ6UP On Tue, Apr 8, 2025 at 7:41 AM Dave van der Locht davevdl@users.sourceforge.net wrote: I thought message filters aren't part of the LinFBB package...
-
I thought message filters aren't part of the LinFBB package itself as they're external tools invoked by LinFBB. For which message filter is this patch intended? I can't find a packaged m_filter.c.
-
Here is a patch: --- m_filter.c.dist 2025-04-08 05:25:34.045019283 -0700 +++ m_filter.c 2025-04-08 05:32:23.175029662 -0700 @@ -50,13 +50,13 @@ hptr_m = open (av[1], O_RDONLY, S_IREAD|S_IWRITE); if (hptr_m == -1) { / DEBUG F6BVP / - printf ("m_filter : could not open file '%s'\n", av[1]); + fprintf(stderr, "m_filter : could not open file '%s'\n", av[1]); return (0); } / DEBUG F6BVP / - printf ("m_filter : file '%s' opened\n", av[1]); + fprintf(stderr, "m_filter : file '%s' opened\n", av[1]); nb =...
-
m_filter error to stdout kills forward session
-
Ah, ok. That makes sense. Thanks, Chris Maness -Sent from my iPhone On Thu, May 30, 2024 at 7:00 AM Dave van der Locht davevdl@users.sourceforge.net wrote: No, I think you're misunderstanding me... There's a config parameter in one of LinFBB's C header files to force support for FBB data files generated/used by a 32-bit version of FBB. That parameter needs to be set ONLY if you need to use FBB datafiles from a 32-bit FBB version in a 64-bit version of FBB... It makes LinFBB on a 64-bit OS compatible...
-
No, I think you're misunderstanding me... There's a config parameter in one of LinFBB's C header files to force support for FBB data files generated/used by a 32-bit version of FBB. That parameter needs to be set ONLY if you need to use FBB datafiles from a 32-bit FBB version in a 64-bit version of FBB... It makes LinFBB on a 64-bit OS compatible with FBB datafiles coming from / generated with a 32-bit version of FBB. Nothing more, nothing less...
-
Did you have to do anything different to your 64bit Slackware-current to make sure there is 32 bit support? I did not with Slack15 release. It all works fine here. But what you are explaining does sound like a reasonable explanation with what is going on.
-
Did you have to do anything different to your 64bit Slackware-current to make sure there is 32 bit support? I did not with Slack15 release. It all works fine here. But what you are explaining does sound like a reasonable explanation with what is going on. -Chris KQ6UP On Thu, May 30, 2024 at 2:31 AM Dave van der Locht davevdl@users.sourceforge.net wrote: As mentioned earlier I've tested with the 7.0.11 release of LinFBB (see Files section). With the latest development (SVN) source there shouldn't...
-
As mentioned earlier I've tested with the 7.0.11 release of LinFBB (see Files section). With the latest development (SVN) source there shouldn't be any difference. There doesn't seem to be any changes since 7.0.11 which might affect satupdat. Regarding the scrambled satellite list... It's likely you've copied that manually from a 32-bit to a 64-bit system. Those are incompatible as several data types differ in size. You CAN compile LinFBB on a 64-bit system with 32-bit data support. This ensures...
-
Dave, did you pull the latest source off of sourceforge for your test? I tried something. I pulled my satel.dat file that was working on my system at work, and installed it on the slack-current system. The satellite list was all scrambled in FBB. That is really weird, and I have never seen that before. I have been able to use those files even on WinFBB from that system. -Chris KQ6UP
-
Just to make sure I was not going crazy, I tried the same keps (downloaded from amsat.org) on my Slack14.1 system at work. Worked like a charm! I am doing the EXACT same thing on the system at home. The system at home is a fresh build with the iso that you linked too. I built a freshly downloaded source from sourceforge, and did a completely new install. See the output below: satupdat dailytle.txt /n /s Update of F6FBB's BBS satellite data base orbital parameters Version 1.89 - February 2015 - Bernard...
-
Dave, did you pull the latest source off of sourceforge for your test? I tried something. I pulled my satel.dat file that was working on my system at work, and installed it on the slack-current system. The satellite list was all scrambled in FBB. That is really weird, and I have never seen that before. I have been able to use those files even on WinFBB from that system. -Chris KQ6UP On Thu, May 23, 2024 at 12:17 PM Chris kq6up@users.sourceforge.net wrote: Just to make sure I was not going crazy,...
-
Just to make sure I was not going crazy, I tried the same keps (downloaded from amsat.org) on my Slack14.1 system at work. Worked like a charm! I am doing the EXACT same thing on the system at home. The system at home is a fresh build with the iso that you linked too. I built a freshly downloaded source from sourceforge, and did a completely new install. See the output below: satupdat dailytle.txt /n /s Update of F6FBB's BBS satellite data base orbital parameters Version 1.89 - February 2015 - Bernard...
-
I'm downloading the file directly on Linux with 'wget https://www.amsat.org/tle/current/nasabare.txt' No browser or other transfer method involved there. I'm also using the 64-bit slackware-current version.
-
Ok. I will update it and test satupdate on the new EXT4 system.
-
Wow, fresh install Slackware-current and still getting the same error. What browser are you using to download the keps? This has got to be something obvious, and thank you for your patients. Are you also using a x86_64 system? I am doing satupdat with /n (and tried all three other possible flags and get the same problem).
-
You can test both... Before and after, just to see where things go (or already are) wrong at yours.
-
But doing the slackpkg update/upgrade first, or no? Thanks, Chris Maness -Sent from my iPhone
-
Wow, fresh install Slackware-current and still getting the same error. What browser are you using to download the keps? This has got to be something obvious, and thank you for your patients. Are you also using a x86_64 system? I am doing satupdat with /n (and tried all three other possible flags and get the same problem). On Wed, May 22, 2024 at 1:40 PM Dave van der Locht davevdl@users.sourceforge.net wrote: You can test both... Before and after, just to see where things go (or already are) wrong...
-
You can test both... Before and after, just to see where things go (or already are) wrong at yours. Op 22-05-2024 21:57 CEST schreef Chris kq6up@users.sourceforge.net: But doing the slackpkg update/upgrade first, or no? Thanks, Chris Maness -Sent from my iPhone On Wed, May 22, 2024 at 12:46 PM Dave van der Locht davevdl@users.sourceforge.net mailto:davevdl@users.sourceforge.net wrote: Ok, so you did something else before testing on a fresh install. Please also try without patching the kernel (or...
-
But doing the slackpkg update/upgrade first, or no? Thanks, Chris Maness -Sent from my iPhone On Wed, May 22, 2024 at 12:46 PM Dave van der Locht davevdl@users.sourceforge.net wrote: Ok, so you did something else before testing on a fresh install. Please also try without patching the kernel (or doing any other things) before testing satupdat initially. Just to verify if something in the steps in between is or isn't messing things up big time. One step at a time... [tickets:#87] https://sourceforge.net/p/linfbb/tickets/87/...
-
Ok, so you did something else before testing on a fresh install. Please also try without patching the kernel (or doing any other things) before testing satupdat initially. Just to verify if something in the steps in between is or isn't messing things up big time. One step at a time...
-
Strange issue you (still) have... Compiling without X support is done with ./configure --disable-x-utils, see ./configure --help. Will do that. How do you download or transfer the input file onto the system? Are you sure the input file isn't corrupted somehow? You're sure you haven't done anything else besides installing the OS and compiling linfbb to test? Although higly unlikely, things that could break the standard C library? No. I only patched the kernel for the AX.25 bug, and I have downloaded...
-
CRC Error with Satellite Database Update
-
Strange issue you (still) have... Compiling without X support is done with ./configure --disable-x-utils, see ./configure --help. How do you download or transfer the input file onto the system? Are you sure the input file isn't corrupted somehow? You're sure you haven't done anything else besides installing the OS and compiling linfbb to test? Although higly unlikely, things that could break the standard C library? And last but not least... Do you build and install LinFBB with any parameters? Or...
-
Now on EXT4. No difference. How do you compile without X support in Slackware-current? I remove motif library while compiling, am not sure if that would make a difference (I doubt it). I have done that on other systems where having X configured causes compile to fail. Is there a variable I can set before running ./configure that will turn of X? -Chris KQ6UP
-
Now on EXT4. No difference. How do you compile without X support in Slackware-current? I remove motif library while compiling, am not sure if that would make a difference (I doubt it). I have done that on other systems where having X configured causes compile to fail. Is there a variable I can set before running ./configure that will turn of X? -Chris KQ6UP On Wed, May 22, 2024 at 5:12 AM Chris kq6up@users.sourceforge.net wrote: Ok. I will update it and test satupdate on the new EXT4 system. On Tue,...
-
Ok. I will update it and test satupdate on the new EXT4 system. On Tue, May 21, 2024 at 11:52 PM Dave van der Locht davevdl@users.sourceforge.net wrote: My slackware-current test system is using the 6.9.1 kernel. I've tested satupdat with this kernel version using an EXT4 filesystem. [tickets:#87] CRC Error with Satellite Database Update Status: open Milestone: 7.0.11 Labels: satelite CRC error Created: Mon May 20, 2024 02:33 AM UTC by Chris Last Updated: Tue May 21, 2024 01:40 PM UTC Owner: nobody...
-
My slackware-current test system is using the 6.9.1 kernel. I've tested satupdat with this kernel version using an EXT4 filesystem.
-
Did you do slackpkg update/upgrade-all? The image you linked to me had 6.6.25 kernel. I did the slackpkg update which brought me to the current and most recent stable fork off the mainline tree. That is 6.9.1. That way we are comparing apples to apples. I just built the system with that image using ext4, but wanted to see if the filesystem is what makes the difference because that would be odd to me. So if you get yours up to 6.9.1, and it still works for you, I will proceed with my experiment here....
-
Did you do slackpkg update/upgrade-all? The image you linked to me had 6.6.25 kernel. I did the slackpkg update which brought me to the current and most recent stable fork off the mainline tree. That is 6.9.1. That way we are comparing apples to apples. I just built the system with that image using ext4, but wanted to see if the filesystem is what makes the difference because that would be odd to me. So if you get yours up to 6.9.1, and it still works for you, I will proceed with my experiment here....
-
I am having issues with BTRFS on this system, but it is related to making tarballs from snapshots. The / file system goes to 100% even though I am writing the tarball to nfs or even another mounted drive. BTRFS has been how I do backups, as it is easy to take reliable snapshots of a live system. However those snapshots are not as useful if I can’t dump them to a tarball for offline safe keeping. -I will have to build a new system as I am having issues with uronode connecting on the NETROM layer....
-
I've used the exact same command parameters as you did: satupdat amsat.txt /n /s To test if BTRFS causes issues you can create a clean slackware-current system and compile + install libax25 and linfbb. Eventually you can compare with creating a clean slackware-current system on an EXT4 filesystem. I've used EXT4 (default slackware-current). Satupdat also doesn't rely on any other libraries other than the standard C library. I suggest to NOT test on the system which is having issues for now, to keep...
-
It is still doing it for me. What commands are you issuing it? I am also using the bulletin keps found here (tho I tried the ones from the link you sent me and had the same problem): https://www.amsat.org/tle/daily-bulletin.txt I am using BTRFS for my filesystem, but I am not thinking that should affect anything. -Chris KQ6UP
-
Good to know. I am wondering if I should try to rebuild it against the new libraries and try it again. I can also send you a kernel patch that makes 6.9.1 stable for use with AX.25 if you are interested. 6.9.1 crashes with incoming connections without it. -Chris KQ6UP
-
It is still doing it for me. What commands are you issuing it? I am also using the bulletin keps found here (tho I tried the ones from the link you sent me and had the same problem): https://www.amsat.org/tle/daily-bulletin.txt I am using BTRFS for my filesystem, but I am not thinking that should affect anything. -Chris KQ6UP On Tue, May 21, 2024 at 5:09 AM Chris kq6up@users.sourceforge.net wrote: Good to know. I am wondering if I should try to rebuild it against the new libraries and try it again....
-
Good to know. I am wondering if I should try to rebuild it against the new libraries and try it again. I can also send you a kernel patch that makes 6.9.1 stable for use with AX.25 if you are interested. 6.9.1 crashes with incoming connections without it. -Chris KQ6UP On Tue, May 21, 2024 at 1:54 AM Dave van der Locht davevdl@users.sourceforge.net wrote: I've just installed a (64-bit) slackware-current test system using this night's ISO. After compiling and installing VE7FET's libax25 I started compiling...
-
I've just installed a (64-bit) slackware-current test system using this night's ISO. After compiling and installing VE7FET's libax25 I started compiling and installing LinFBB 7.0.11 from the tar.gz package. Unfortunately I'm not getting any CRC errors using satupdat, it seems to function as expected.
-
For what it is worth, I have never seen this on any other slackware or Debian based system before. This only happens in Slackware-current. It is a brand new system with only FBB and VE7FET's packet stuff installed on it. I only mentioned the kernel patches to explain why I am running Slackware-current instead of a stable release. I just applied a patch manually this morning (the only one that I have done) to the stock 6.9.1 kernel. It is supposed to make the system stable when incoming connections...
-
No, there is some issue with the OS satupdate. Even the keps from your link do the same thing. Do you want this system? I can post it on google drive for you. It is a virtual system running in VirtualBox. I have been testing the new kernel that they have been working on the AX.25 stack. -73 de Chris KQ6UP
-
For what it is worth, I have never seen this on any other slackware or Debian based system before. This only happens in Slackware-current. It is a brand new system with only FBB and VE7FET's packet stuff installed on it. I only mentioned the kernel patches to explain why I am running Slackware-current instead of a stable release. I just applied a patch manually this morning (the only one that I have done) to the stock 6.9.1 kernel. It is supposed to make the system stable when incoming connections...
-
Thanks for the reply Chris. I prefer to (initially) test on a clean Slackware installation with the latest LinFBB release (7.0.11). If I encounter the same issue I'll need to check what's causing this. It doesn't seem to have any 'strings' with the kernel's AX.25 fixes/patches. Satupdat only relies on standard C libs. Otherwise, when I'm getting errors too, your image could be helpful to figure out what's different / causing this at yours.
-
No, there is some issue with the OS satupdate. Even the keps from your link do the same thing. Do you want this system? I can post it on google drive for you. It is a virtual system running in VirtualBox. I have been testing the new kernel that they have been working on the AX.25 stack. -73 de Chris KQ6UP On Mon, May 20, 2024 at 12:46 AM Dave van der Locht davevdl@users.sourceforge.net wrote: Are you sure you're input file isn't corrupted / wrong? The satupdat source only relies on some standard...
-
Are you sure your input file isn't corrupted / wrong? The satupdat source only relies on some standard C libraries. Unfortunately I haven't got a Slackware-current install / VM running (yet) to test. With testing on Debian 11 + 12 and Ubuntu 22.04 + 24.04 I haven't noticed any issues with parsing a NASA formatted amsat file and CRC calculation. Used the one from this location: https://www.amsat.org/tle/current/nasabare.txt Update of F6FBB's BBS satellite data base orbital parameters Version 1.89...
-
Are you sure you're input file isn't corrupted / wrong? The satupdat source only relies on some standard C libraries. Unfortunately I haven't got a Slackware-current install / VM running (yet) to test. With testing on Debian 11 + 12 and Ubuntu 22.04 + 24.04 I haven't noticed any issues with parsing a NASA formatted amsat file and CRC calculation. Used the one from this location: https://www.amsat.org/tle/current/nasabare.txt Update of F6FBB's BBS satellite data base orbital parameters Version 1.89...
-
CRC Error with Satellite Database Update
-
Mail List Support Page
-
News Groups (NNTP)
-
High CPU usage with Linux port definition (DED or Serial)
-
Changes are committed [r239].
-
Fixed problem where high CPU usage was seen when using one or more DED ports.
-
Red Tuby posted a comment on ticket #83
Steve also applied the patch on my system even though I didn't have the high CPU issue, it is working well even so. Just thought I'd let you know its good.
-
Boudewijn Tenty posted a comment on ticket #84
Thanks Dave Boudewijn, VE3TOK On 2023-06-11 02:23, Dave van der Locht wrote: Clear, LinFBB indeed needs some minor modifications to support IPv6. **[tickets:#84] https://sourceforge.net/p/linfbb/tickets/84/ Adding IPv6 support to FBB, feature request. ** Status: open Milestone: 7.0.12 Created: Thu Jun 08, 2023 10:35 PM UTC by Boudewijn Tenty Last Updated: Sun Jun 11, 2023 06:17 AM UTC Owner: nobody Several of my packet programs like BPQ, Dx Spider, URONode can handle IPv6. I could convince Maiko,...
-
Clear, LinFBB indeed needs some minor modifications to support IPv6.
-
I know that it relies on the Linux tcp/ip stack but you still need a modification in the FBB source code to make use of it, so that FBB signals the kernel an acknowledgement that it is happy to accept the incoming traffic (over tcp6), so that the kernel can open an IPv6 socket for FBB. No doubt, it works something along these lines. FBB can't handle forwarding over IPv6 as it has to signal the kernel to open preferable an IPv6 socket and if that fails an IPv4 as it has traffic.
-
Adding IPv6 support to FBB, feature request.
-
I know that it relies on the Linux tcp/ip stack but you still need a modification in the FBB source code to make use of it, so that FBB signals the kernel an acknowledgement that it is happy to accept the incoming traffic (over tcp6), so that the kernel can open an IPv6 socket for FBB. No doubt, it works something along these lines. FBB can't handle forwarding over IPv6 as it has to signal the kernel to open preferable an IPv6 socket and if that fails an IPv4 as it has traffic. On 2023-06-09 01:18,...
-
Steve posted a comment on ticket #83
Thank you for the patch. I have added it and tested and all seem good , CPU is 0 -> 1.3ish now
-
A patch is available for testing for anyone who's interested. After doing some more testing with DED emulation software and hardware I'll commit the patch to SVN. If anyone would like to test please send me a message and you'll receive the patch file. You need to manually apply the patch, recompile and install.
-
LinFBB relies on the Linux TCP/IP stack for its IP communications, like URONode does. With that there's no need to add IPv6 to FBB itself as the kernel handles that. One thing I can think of is that LinFBB might not support IPv6 addresses in its config files (for forwarding over telnet for example). I've never tested that though. Or are there any other things FBB does handle with IPv4 but can't with IPv6?
-
Adding IPv6 to FBB, feature request.
-
High CPU usage with Linux port definition (DED or Serial)
-
Correct, it possibly affects all serial I/O comms (when used) and I think its doing that for a very very long time now. I even think the Windows version of 2 decades ago, before FBB became Linux only, must have had a relative high CPU usage when a DED port was used, and possibly with some other protocol drivers over serial I/O too (anything between slightly less or much less CPU usage).
-
Dave, The issue was occuring with serial as well as DED but as all are just files the issue is probably the same. Good news on finding the place . Will be interested to see the fix.
-
Replicated the issue and found 'the place to be'... A 'quick and dirty fix' reduced the CPU load from 20% on my system to about 1% without negative functional and performance side-effects as far as I have (limited) tested and able to test now. Due to its complexity I'll have to take a good look at how things are done regarding the handling of serial I/O to make a good and solid fix.
-
High CPU usage with Linux port definition (DED or Serial)
-
These functions are constantly being invoked by LinFBB's main program in a tight loop. Therefore gproc will show high numbers of calls when there are AX.25 communication ports configured like DED, Linux AX.25 etc.. That's just normal as it seems. However... High CPU usage when using communication ports I'm not recognizing and haven't seen or heard about it before. I'll have a look at it when my BPQ+LinFBB setup is ready for testing/debugging regarding ticket #82. Some brain cells suggest me it might...
-
High CPU usage with Linux port definition (DED or Serial)
-
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...
-
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...
-
UNPROTO frames monitored & mishandled by FBB causes SEGFAULT
-
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...
-
UNPROTO frames monitored & mishandled by FBB causes SEGFAULT
-
Stop All Forward (FS 1) keeps BBS ‘Still connected’
-
I've just verified the issue and can confirm it's a bug. Need to do some debugging to see why reporting is wrong or why LinFBB thinks it's still forwarding and pinpoint + fix the exact cause. The 'already connected' part of the message looks to be wrong too as the checking mechanism seems to look at a forwarding flag, not a connection state. Which explains why it isn't shown with the % command.
-
fs 1 Stopping forwarding on port 1 --0 new/1 old msgs--matrix--> fr ei2gyb BBS EI2GYB already connected --0 new/1 old msgs--matrix--> fr ei2gyb --0 new/1 old msgs--matrix--> BBS EI2GYB already connected --0 new/1 old msgs--matrix--> % LinFBB version 7.0.11 (Linux) compiled on Dec 7 2022 Bid:32000 Lang:1 Ports:4 Ch:44 FBB Ok BIN Ok Uptime : 63 days, 14 hours 58 minutes Load average : 1.04, 1.37, 1.57 Available disks: C: MiB Mem : 3837.9 total, 1440.9 free, 1326.3 used, 1070.7 buff/cache MiB Swap:...
-
Stop All Forward (FS 1) keeps BBS ‘Still connected’
-
Messages getting stuck in Fwd loop
-
Problem 'solved' for now by clearing the messages (dirmes.sys / mail dirs / wfbid.sys) and importing messages back into FBB. For reference: Messages database (dirmes.sys), and specifically the masks below, got corrupted/mangled due to a change in BBS.SYS. When in-place changing non-empty BBS entries, things can go wrong when using a mask related to the numbering in BBS.SYS without proper dealing with those kind of changes or registering forward statusses of messages another way. char fbbs[NBMASK]...
-
I noticed that clue too... I don't have your @amsat.org email address, only 2 @gmail.com ones. I'll send you an email later today or tomorrow there, if you reply with your @amsat.org address we can use that route to attack and resolve the issue.
-
Yes no problem @amsat.org mail works for me if you havent got my addy already. I’ve tired the restarts, housekeeping, and killing the message doesnt stop it either. There is a clue I found, my BBS thinks it has already forwarded the message to the remote BBS because the message is showing as “Ok” in the provided list of “FL” output, it is not in the pending queue “Fwd:” It looks like my BBS has got a mismatch between two types of list. One for the pending Fwd: list which FL checks against. One that...
-
Sorry Red! I've overlooked the FD you've already tried. Can you send me the output of the command: v 47609 You also might try to FD right after a restart of FBB. If that works it might help sending me in the right direction. Some other tests might help too to get some information about the issue, perhaps I may contact you by e-mail to try help further?
-
Sorry Red! I've overlooked the FD you've already tried. Can you send me the output of the command: v 47609 If you have any mods done in source, have you already tried with compiling and running the original 7.0.11 version? You also might try to FD right after a restart of FBB. If that works it might help sending me in the right direction. Some other tests might help too to get some information about the issue, perhaps I may contact you by e-mail to try help further?
-
Take a closer look at the report above, the FD command isn't working in this scenario which is why I am puzzled. There are no modifications other than the version name which helps me ID which instance I am using, just the string.
-
Take a closer look at the report above, the FD command isn't working in this scenario which is why I am puzzled.
-
Take a closer look at the report above, the FD command isn't working in this scenatio which is why I am puzzled.
-
Messages getting stuck in Fwd loop
-
Remote BBS doesn't want the message (FS -) according to the FBB forward protocol. I'm not sure why your FBB still seems to ignore the answer and does the same proposal over and over again. I need to take a look in source code to see if I can find a possible condition which might result in this behaviour. As the remote BBS doesn't want the message, for now you can delete the message from the BBS forwarding queue with the FD command like: FD [#msg] [BBS] I see you've compiled the 7.0.11 version with...
-
Messages getting stuck in Fwd loop
1 >
