• CPU Hog

    From deon@VERT/ALTERANT to Digital Man on Fri Aug 5 16:52:02 2022
    Howdy,

    Today I discovered SBBS with 2 threads both running at 98% CPU - having stopped and restarted SBBS, its all back to normal.

    At the same time, my fido hub alerted me to my system being "slow" and refusing packets. Curious, I looked through the logs and indeed it seems that when I polled my fsxhub, mail flowed normally, but when I polled my fido hub, it was stuck there receiving a file:

    Authentication successful:
    Attempting poll for node 3:633/280@fidonet
    JSBinkP/4 callout to 3:633/280@fidonet started
    Connecting to 3:633/280@fidonet at ftn633.vk3heg.net:24554
    Peer version: binkd/1.1a-115/Linux
    Will encrypt session.Authentication successful: secure
    Receiving file: /opt/sbbs/temp/e8c38a06.pkt (1.4KB)
    [no more output]

    It doesnt appeaer that this thread dies - (and it should time out after 5 minutes right?) I ran "binkit -p" and it's still stuck on this node after 20 mins.

    My fido hub is set to "Poll: Yes", so I'm suspecting everytime my system was polling, the old thread hadnt died yet, so eventually I end up with many threads tied up polling my fido hub.

    So, shouldnt it ultimately time out after 5 mins?

    Is there a way to "busy out" the polled node, so another thread doesnt try and call it again?




    ...ëîåï

    ---
    þ Synchronet þ Alterant | an SBBS in Docker on Pi!
  • From Digital Man@VERT to deon on Fri Aug 5 13:07:16 2022
    Re: CPU Hog
    By: deon to Digital Man on Fri Aug 05 2022 04:52 pm

    Howdy,

    Today I discovered SBBS with 2 threads both running at 98% CPU - having stopped and restarted SBBS, its all back to normal.

    At the same time, my fido hub alerted me to my system being "slow" and refusing packets. Curious, I looked through the logs and indeed it seems that when I polled my fsxhub, mail flowed normally, but when I polled my fido hub, it was stuck there receiving a file:

    Authentication successful:
    Attempting poll for node 3:633/280@fidonet
    JSBinkP/4 callout to 3:633/280@fidonet started
    Connecting to 3:633/280@fidonet at ftn633.vk3heg.net:24554
    Peer version: binkd/1.1a-115/Linux
    Will encrypt session.Authentication successful: secure
    Receiving file: /opt/sbbs/temp/e8c38a06.pkt (1.4KB)
    [no more output]

    It doesnt appeaer that this thread dies - (and it should time out after 5 minutes right?) I ran "binkit -p" and it's still stuck on this node after 20 mins.

    My fido hub is set to "Poll: Yes", so I'm suspecting everytime my system was polling, the old thread hadnt died yet, so eventually I end up with many threads tied up polling my fido hub.

    So, shouldnt it ultimately time out after 5 mins?

    It "should" timeout, yes (I don't know the expected timeout duration), but I also didn't write binkit/binkp.js, so I'd have to track down that bit of code and see what its doing to be sure.

    Is there a way to "busy out" the polled node, so another thread doesnt try and call it again?

    The SBBS event thread is a single thread. BinkIt polling is normally done as a timed event, which is run as in the foreground of that single event thread. So I'm not clear what "another thread" would be.
    --
    digital man (rob)

    Rush quote #66:
    He's old enough to know what's right, but young enough not to choose it
    Norco, CA WX: 89.6øF, 37.0% humidity, 6 mph SSW wind, 0.00 inches rain/24hrs ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From deon@VERT/ALTERANT to Digital Man on Sat Aug 6 12:34:17 2022
    Re: CPU Hog
    By: Digital Man to deon on Fri Aug 05 2022 01:07 pm

    Is there a way to "busy out" the polled node, so another thread doesnt try and call it again?

    The SBBS event thread is a single thread. BinkIt polling is normally done as a timed event, which is run as in the foreground of
    that single event thread. So I'm not clear what "another thread" would be.

    OK, so I have BINKPOLL (binkit -p) set to run 2 times per day.

    So are you suggesting that when SBBS runs it, it can never run a subsequent time, if the previous run never completes?

    My logs show it does run twice a day (not 12 hrs apart, ergo 2 times a day - but...)

    Aug 5 00:35:54 d-11-1 synchronet: evnt BINKPOLL Running native timed event: BINKPOLL
    Aug 5 14:36:58 d-11-1 synchronet: evnt BINKPOLL Running native timed event: BINKPOLL

    So if the first question is yes, then that would imply that binkit -p does eventually exit.

    I'm wondering then, what else could cause the CPU goes to 100% on 2 threads for an extend period of time? (I havent monoitored the time, but my vmware logs show it was pegged for 2 hrs before I intervened.)

    Since my fido link identified the cause (it seemed it was in his end), CPU is backed to < 5%.


    ...ëîåï

    ---
    þ Synchronet þ Alterant | an SBBS in Docker on Pi!
  • From Nightfox@VERT/DIGDIST to deon on Sat Aug 6 13:24:08 2022
    Re: CPU Hog
    By: deon to MRO on Sat Aug 06 2022 12:35 pm

    rig up a daily reboot. I do it for all my bbses. that will fix a lot
    of issues that may pop up.

    Nah, I doubt it.

    I'm not a "reboot fixes it" guy. That may have been a windows strategy in the day, but I never thought that was the solution to issue.

    Yeah, a daily reboot seems like a band-aid. I'd think the true cause of the issue is elsewhere.

    ---
    þ Synchronet þ Digital Distortion: digitaldistortionbbs.com
  • From Tracker1@VERT/TRN to DOVE-Net.Synchronet_Discussion on Sat Aug 6 18:09:42 2022
    As a minor followup... here's the docker stats for my running system, I
    think it's been up for about a few weeks since I last touched it.

    NAME CPU % MEM USAGE MEM % NET I/O BLOCK I/O
    sbbs 0.09% 185.1MiB 4.71% 540MB / 666MB 100MB / 2.44GB
    mail 0.03% 59.86MiB 1.52% 213MB / 347MB 2.82MB / 90.1kB
    ftp 0.00% 6.477MiB 0.16% 8.41MB / 10.6MB 8.19kB / 90.1kB
    svcs 0.08% 114.1MiB 2.90% 304MB / 48.3MB 6.38MB / 3.22MB
    irc 0.07% 271.7MiB 6.91% 162MB / 739MB 20.5kB / 90.1kB
    bbsweb 0.11% 9.023MiB 0.23% 42.3MB / 110MB 500kB / 90.1kB
    ecweb 0.06% 282.9MiB 7.20% 205MB / 3.14GB 105MB / 467kB
    rmweb 0.06% 67.22MiB 1.71% 36.8MB / 246MB 28.1MB / 90.1kB
    doorparty 0.00% 5.055MiB 0.13% 29.2MB / 25MB 6.37MB / 0B

    System is mostly idle, most of the time. Nothing is really crazy, the
    web instances seem to use the most resources, which are kind of
    expected... Slightly surprised how much memory the IRC service uses on
    its' own, but not crazy either. I'd thought about breaking nntp off
    from the rest of the misc services, since it's what I'm using myself
    most of the time, and was a little curious.

    VM Ram is 4GB total, and this is all that's running other than basic
    services and the OS ssh, etc.
    --
    Michael J. Ryan - tracker1@roughneckbbs.com
    ---
    þ Synchronet þ Roughneck BBS - roughneckbbs.com
  • From Tracker1@VERT/TRN to deon on Sat Aug 6 18:20:07 2022
    On 8/4/22 23:52, deon wrote:

    Today I discovered SBBS with 2 threads both running at 98% CPU
    - having stopped and restarted SBBS, its all back to normal.

    What did your RAM usage look like? I've seen a similar issue a couple
    times, where I couldn't connect on the mail service port... I don't know
    what part of Synchronet was causing the issue... there was definitely
    some kind of memory leak as I was getting a lot of out of memory errors.

    I bumped the server to a higher memory option, then separated each
    service into a separate running instance... I haven't seen the issue
    since, though so no idea.
    --
    Michael J. Ryan - tracker1@roughneckbbs.com
    ---
    þ Synchronet þ Roughneck BBS - roughneckbbs.com
  • From dragon@VERT/IPTIA to Nightfox on Sat Aug 6 20:43:57 2022
    On 8/6/2022 18:44, Nightfox wrote:
    Re: CPU Hog
    By: MRO to Nightfox on Sat Aug 06 2022 04:33 pm

    MR> but don't listen to me, i have great uptime for decades and my shit always
    MR> works.

    If you have it reboot every day, then it's not up continuously for more than a day. I wouldn't call that great uptime.

    I've been running a BBS since 1994 (with DOS at the time), and I didn't have to reboot my BBS machine every day to keep things working (and still don't).

    ---
    ¨ Synchronet ¨ Digital Distortion: digitaldistortionbbs.com

    Awww, I was going to say almost all of that!

    ---
    ­ Synchronet ­ IPTIA - bbs2.ipingthereforeiam.com:2323
  • From Jas Hud@VERT to Belly on Sun Aug 7 17:15:45 2022
    Re: CPU Hog
    By: MRO to Nightfox on Sat Aug 06 2022 04:33 pm

    I can't believe I'm actually replying to your drivel, but how do you have great uptime if you reboot nightly? Get your story straight.

    o
    (O)
    BeLLy



    I can't believe I'm replying back to YOU, a clown who can't even keep his bbs up longer than a month or so.

    i have great uptime because I'm always up. my reboot is 3 mins and then it's back up. unlike people like you who come and go or don't know how to configure your routers. i know how to keep things running smoothly. i also backup, unlike 99% of you idiots.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Jas Hud@VERT to Gamgee on Sun Aug 7 17:18:30 2022
    i use linux and windows.

    but if you're running a bbs, and you have dos games and shit you should be running it on windows 32bit instead of emulating shit in a linux environment. it's easier and it's the right tool for the job.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Jas Hud@VERT to Gamgee on Sun Aug 7 17:23:17 2022
    Hahahaha! "Troubleshooting" by rebooting. HAR! Freakin clueless n00b.

    ... Facts cannot prevail against faith, or adamant folly.
    --- MultiMail/Linux v0.52
    þ Synchronet þ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL


    OHH poor tryhard with the mail order bride angry at mro. he comment at every post! ooooh
    reboot so bad! ooooh! gamgee never reboot! never! reboot bad!

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From deon@VERT/ALTERANT to Tracker1 on Mon Aug 8 09:54:45 2022
    Re: Re: CPU Hog
    By: Tracker1 to deon on Sat Aug 06 2022 06:20 pm

    What did your RAM usage look like? I've seen a similar issue a couple
    times, where I couldn't connect on the mail service port... I don't know what part of Synchronet was causing the issue... there was definitely
    some kind of memory leak as I was getting a lot of out of memory errors.

    Yeah, I am confident RAM wasnt the issue.

    I've been running the same container config for 2+ years now, with the only different being an image update every now and again. (I can see from docker stats, that its happy with 168MB of 2G available to it.)

    The problem started when I switched to a new ISP, that uses PPPoE. As a result all of my IPv6 traffic was affected by the lower MTU, and while I addressed that for my server LAN, I'm assuming it is affecting the docker lan (havent definitively confirmed that yet, but it seems likely).

    Resetting the host (and the container) saw the CPU get back to 100% after a short while (with my fido hub trying to deliver me mail over IPv6). When he switched to IPv4, problem disappeared and CPU stays normal (< 5%).

    My initial report of this was due to the fact that when I polled him with binkit, it didnt time out after 5 minutes (which IIRC is the "normal" timeout - and I'm assuming since he is using binkd his side would have) and I was thinking that subsequent binkit -p polls were "adding" to the issue (together with him polling me as well).

    (And I dont think my side would have closed down when his side sent the TCP_FIN as a result of the binkd timeout, since there was (probably) other defragged packets that werent successfully delivered yet.)

    What's also strange, I've learnt that his side is also PPPoE, and I was only having this issue with his system - my other IPv6 connections were not affected.

    Not sure why a hung poll would also peg 2 cores as technically my side is waiting to receive - perhaps the repeated system call to check if there is data on the wire does result in this?


    ...ëîåï

    ---
    þ Synchronet þ Alterant | an SBBS in Docker on Pi!
  • From Stephen Walsh@VERT to deon on Mon Aug 8 11:11:24 2022
    Hello deon!

    08 Aug 22 09:54, you wrote to Tracker1:

    What's also strange, I've learnt that his side is also PPPoE, and I
    was only having this issue with his system - my other IPv6 connections were not affected.

    Correction: This hub system sits in a data centre as a VM. So no PPoE.

    My home connection is PPoE (3:633/281) and has no issues to the hub system.



    Stephen


    --- GoldED+/LNX 1.1.5-b20220409
    * Origin: Dragon's Lair BBS, Telnet: dragon.vk3heg.net (3:633/280)
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Gamgee@VERT/PALANT to Jas Hud on Sun Aug 7 21:16:00 2022
    Jas Hud wrote to Gamgee <=-

    i use linux and windows.

    Right.

    but if you're running a bbs, and you have dos games and shit you
    should be running it on windows 32bit instead of emulating shit
    in a linux environment. it's easier and it's the right tool for
    the job.

    "Should be"...? LOL, says who? YOU? Hahahaha

    It's quite easy to run that stuff on Linux if you know what you're
    doing, which you clearly don't. It's simple. It works perfectly. It
    doesn't require a daily reboot to keep it running.... Hahahahahaha

    You make me laugh!



    ... Ignorance can be cured. Stupid is forever.
    --- MultiMail/Linux v0.52
    þ Synchronet þ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
  • From Gamgee@VERT/PALANT to Jas Hud on Sun Aug 7 21:19:00 2022
    Jas Hud wrote to Gamgee <=-

    Hahahaha! "Troubleshooting" by rebooting. HAR! Freakin clueless n00b.

    OHH poor tryhard with the mail order bride angry at mro.

    "mail order bride"? What? Are you on drugs? And no, not 'angry' at
    MRO, just laughing at your cluelessness and incompetence. Hahahaha

    reboot so bad! ooooh! gamgee never reboot! never! reboot bad!

    Never said I never reboot. I said I rarely do, which is the truth.

    You're the n00b who "fixes problems" by rebooting DAILY! Hahahahaha!



    ... Ignorance can be cured. Stupid is forever.
    --- MultiMail/Linux v0.52
    þ Synchronet þ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
  • From deon@VERT/ALTERANT to Stephen Walsh on Mon Aug 8 14:11:10 2022
    Re: CPU Hog
    By: Stephen Walsh to deon on Mon Aug 08 2022 11:11 am

    08 Aug 22 09:54, you wrote to Tracker1:

    What's also strange, I've learnt that his side is also PPPoE, and I
    was only having this issue with his system - my other IPv6 connections were not affected.

    Correction: This hub system sits in a data centre as a VM. So no PPoE.

    Ahh, OK - I understood that incorrectly. Not sure what the issue is between your sytem and mine then.

    I've done lots of reading regarding PPPoE and IPv6 and challenges are known. They are exacerbated by firewall rules that drop ICMP messages - since IPv6 routers are not allowed to defrag packets (if I have read that correctly), so send back an ICMP packet too big, which some intermediatories drop.

    A common thread that I've also read, especially if your "data center" has multiple inbound paths (ECMP) is the ICMP packet comes back via a different path and isnt matched to the source, so is dropped.

    Anyway, IPv4 works, so we can stick with that I guess.


    ...ëîåï

    ---
    þ Synchronet þ Alterant | an SBBS in Docker on Pi!
  • From Nightfox@VERT/DIGDIST to Gamgee on Mon Aug 8 08:52:37 2022
    Re: Re: CPU Hog
    By: Gamgee to Jas Hud on Sun Aug 07 2022 09:16 pm

    but if you're running a bbs, and you have dos games and shit you
    should be running it on windows 32bit instead of emulating shit
    in a linux environment. it's easier and it's the right tool for
    the job.

    It's quite easy to run that stuff on Linux if you know what you're
    doing, which you clearly don't. It's simple. It works perfectly. It doesn't require a daily reboot to keep it running.... Hahahahahaha

    I switched my BBS over to Linux not too long ago, and to be fair, it seems there are some DOS doors (in particular, TradeWars 2002) that don't run in DOSEMU 1.x. I've heard it does run in DOSEMU 2, though I have yet to successfully get DOSEMU 2 working with Synchronet.

    However, regarding mro's statement about emulating stuff, I think even a 32-bit Windows uses some kind of emulated environment anyway. Windows has its NTVDM, the Virtual DOS Machine, though I don't know all the details of how it works. I do know that 64-bit x86 processors are able to run 16-bit binaries when running in 32-bit mode though..

    ---
    þ Synchronet þ Digital Distortion: digitaldistortionbbs.com
  • From Ryan Fantus@VERT to Nightfox on Mon Aug 8 12:13:17 2022
    I switched my BBS over to Linux not too long ago, and to be fair, it
    seems there are some DOS doors (in particular, TradeWars 2002) that
    don't run in DOSEMU 1.x. I've heard it does run in DOSEMU 2, though I have yet to successfully get DOSEMU 2 working with Synchronet.

    DOSEMU 2 has some better compatibility with some games, and some worse. For example, I was able to run DPMI TW2002, pkunzip, darklands, etc., just fine. But some games have odd issues, particularly I can remember LORD 2 behaving strangely.

    At the end of the day if you want maximum compatibility with few/no issues, running 32 bit Windows is your best bet. Kind of unfortunate. :(

    However, regarding mro's statement about emulating stuff, I think even a 32-bit Windows uses some kind of emulated environment anyway. Windows
    has its NTVDM, the Virtual DOS Machine, though I don't know all the details of how it works. I do know that 64-bit x86 processors are able
    to run 16-bit binaries when running in 32-bit mode though..

    Yep, ntvdm runs any time I launch a DOS program. It creates some overhead but seems to work more or less fine. *shrug*

    --- Mystic BBS v1.12 A48 2022/07/11 (Linux/64)
    * Origin: m O N T E R E Y b B S . c O M (1:218/820)
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Gamgee@VERT/PALANT to Nightfox on Mon Aug 8 13:43:00 2022
    Nightfox wrote to Gamgee <=-

    but if you're running a bbs, and you have dos games and shit you
    should be running it on windows 32bit instead of emulating shit
    in a linux environment. it's easier and it's the right tool for
    the job.

    It's quite easy to run that stuff on Linux if you know what you're
    doing, which you clearly don't. It's simple. It works perfectly. It doesn't require a daily reboot to keep it running.... Hahahahahaha

    I switched my BBS over to Linux not too long ago, and to be fair,
    it seems there are some DOS doors (in particular, TradeWars 2002)
    that don't run in DOSEMU 1.x. I've heard it does run in DOSEMU
    2, though I have yet to successfully get DOSEMU 2 working with
    Synchronet.

    Yes, I'll agree on that door. I haven't tried to set it up myself but certainly have seen where others say it doesn't work with dosemu. Not a
    huge deal for me, anyway.

    However, regarding mro's statement about emulating stuff, I think
    even a 32-bit Windows uses some kind of emulated environment
    anyway. Windows has its NTVDM, the Virtual DOS Machine, though I
    don't know all the details of how it works. I do know that 64-bit
    x86 processors are able to run 16-bit binaries when running in
    32-bit mode though..

    Yes, NTVDM (which MRO even mentioned he uses, LOL) is indeed a DOS
    emulator for Windows. Hahahaha, and yet he whines about emulating
    things in Linux. He's a know-it-all, and doesn't like getting called
    out on his bullshit. ;-)



    ... So easy, a child could do it. Child sold separately.
    --- MultiMail/Linux v0.52
    þ Synchronet þ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
  • From fusion@VERT/CFBBS to Ryan Fantus on Mon Aug 8 17:12:00 2022
    On 08 Aug 2022, Ryan Fantus said the following...

    details of how it works. I do know that 64-bit x86 processors are abl to run 16-bit binaries when running in 32-bit mode though..

    Yep, ntvdm runs any time I launch a DOS program. It creates some
    overhead but seems to work more or less fine. *shrug*

    the ntvdm pretends to be dos, emulates bios calls and all that.. but the 16-bit code runs on a virtualized hardware cpu much like the modern vt-x extensions virtualbox uses to speed up emulating newer oses. that 16bit virtualized cpu mode is only accessable when the cpu itself is in 32bit mode.

    ntvdm64 is a software emulator they borrowed from windows for.. powerpc? it emulates both an intel cpu AND all the dos/bios stuff. i kinda wonder how well it worked over there. could run a powerpc bbs? heh

    another neat thing is each ntvdm gets it's own "640k" of ram, it's own
    EMS/XMS, etc.. it's really the scaffolding of the single-pc multinode bbs.

    it's neat stuff. bit of a shame the 16bit mode is not accessable from 64bit oses.. but we're lucky it works in 32bit mode. in theory it should be faster than the ntvdm64 one, but with modern cpus i don't know if you could measure that difference anymore

    ... I think I am, therefore, I am... I think.

    --- Mystic BBS v1.12 A47 2021/12/25 (Windows/32)
    * Origin: cold fusion - cfbbs.net - grand rapids, mi
  • From fusion@VERT/CFBBS to Gamgee on Mon Aug 8 17:17:00 2022
    On 08 Aug 2022, Gamgee said the following...

    Yes, NTVDM (which MRO even mentioned he uses, LOL) is indeed a DOS emulator for Windows. Hahahaha, and yet he whines about emulating
    things in Linux. He's a know-it-all, and doesn't like getting called
    out on his bullshit. ;-)

    as you'll see in my other post, it's a bit more complex than that. for the
    time being it's still far superior to dosemu/dosbox for bbs doors

    ... You can learn many things from children... like how much patience you have

    --- Mystic BBS v1.12 A47 2021/12/25 (Windows/32)
    * Origin: cold fusion - cfbbs.net - grand rapids, mi
  • From Nightfox@VERT/DIGDIST to fusion on Mon Aug 8 15:38:20 2022
    Re: Re: CPU Hog
    By: fusion to Ryan Fantus on Mon Aug 08 2022 05:12 pm

    ntvdm64 is a software emulator they borrowed from windows for.. powerpc?

    As far as I can tell, NTVDM64 is meant to work on 64-bit Intel/AMD processors. Where did you see that it was for PowerPC?

    ---
    þ Synchronet þ Digital Distortion: digitaldistortionbbs.com
  • From fusion@VERT/CFBBS to Nightfox on Mon Aug 8 19:49:00 2022
    On 08 Aug 2022, Nightfox said the following...

    As far as I can tell, NTVDM64 is meant to work on 64-bit Intel/AMD processors. Where did you see that it was for PowerPC?

    an excerpt from the ntvdm wiki:

    Since virtual 8086 mode is not available on non-x86-based processors (more specifically, MIPS, DEC Alpha, and PowerPC) NTVDM was instead implemented as a full emulator in these versions of NT, using code licensed from Insignia's SoftPC.

    this is what ntvdm64 was ported from.

    ... Help! I can't find the "ANY" key.

    --- Mystic BBS v1.12 A47 2021/12/25 (Windows/32)
    * Origin: cold fusion - cfbbs.net - grand rapids, mi
  • From Digital Man@VERT to deon on Mon Aug 8 17:34:23 2022
    Re: CPU Hog
    By: deon to Digital Man on Sat Aug 06 2022 12:34 pm

    Re: CPU Hog
    By: Digital Man to deon on Fri Aug 05 2022 01:07 pm

    Is there a way to "busy out" the polled node, so another thread doesnt try and call it again?

    The SBBS event thread is a single thread. BinkIt polling is normally done as a timed event, which is run as in the foreground of that single event thread. So I'm not clear what "another thread" would be.

    OK, so I have BINKPOLL (binkit -p) set to run 2 times per day.

    So are you suggesting that when SBBS runs it, it can never run a subsequent time, if the previous run never completes?

    Correct. The exception would be fore timed events where you have "background execution" set to "Yes", but that can only be done for native programs (e.g. jsexec), not for the direct invocation of a script (e.g. binkit.js).

    My logs show it does run twice a day (not 12 hrs apart, ergo 2 times a day - but...)

    Aug 5 00:35:54 d-11-1 synchronet: evnt BINKPOLL Running native timed event: BINKPOLL
    Aug 5 14:36:58 d-11-1 synchronet: evnt BINKPOLL Running native timed event: BINKPOLL

    So if the first question is yes, then that would imply that binkit -p does eventually exit.

    Yes.

    And for ever foreground "Running" log entry there should be a corresponding log entry like this:

    BINKPOLL Timed event: BINKPOLL returned 0

    Giving you an indication of exactly how long that event took to run to completion.

    I'm wondering then, what else could cause the CPU goes to 100% on 2 threads for an extend period of time?

    Looking at the CPU utilization of *threads* of sbbs would give you a good indication:
    http://wiki.synchro.net/monitor:index#threads

    The threads are named and events are run in the "sbbs/events" thread.

    (I havent monoitored the time, but my vmware
    logs show it was pegged for 2 hrs before I intervened.)

    Since my fido link identified the cause (it seemed it was in his end), CPU is backed to < 5%.

    Well if you figure out how to reproduce the problem, let me know.
    --
    digital man (rob)

    Breaking Bad quote #8:
    I want Shania Twain to give me a tuggy. Guess what? That ain't happening either Norco, CA WX: 89.9øF, 39.0% humidity, 8 mph SSE wind, 0.00 inches rain/24hrs ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Gamgee@VERT/PALANT to fusion on Mon Aug 8 21:43:00 2022
    fusion wrote to Gamgee <=-

    Yes, NTVDM (which MRO even mentioned he uses, LOL) is indeed a DOS emulator for Windows. Hahahaha, and yet he whines about emulating
    things in Linux. He's a know-it-all, and doesn't like getting called
    out on his bullshit. ;-)

    as you'll see in my other post, it's a bit more complex than
    that.

    I'm sure it is, and from your other post, it's clear that you understand
    all that better than I do, but...

    for the time being it's still far superior to dosemu/dosbox
    for bbs doors

    Well, as long as your definition of "far superior" is: "it'll run
    TW2002", okay.

    Other than that though, I haven't had any trouble with any other doors
    that I'm using it (dosemu) with. <SHRUG>


    ... Gone crazy, be back later, please leave message.
    --- MultiMail/Linux v0.52
    þ Synchronet þ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
  • From Belly@VERT/BRAZINET to Jas Hud on Mon Aug 8 22:10:40 2022
    Re: CPU Hog
    By: Jas Hud to Belly on Sun Aug 07 2022 05:15 pm

    I can't believe I'm replying back to YOU, a clown who can't even keep his bb up longer than a month or so.

    i have great uptime because I'm always up. my reboot is 3 mins and then it' back up. unlike people like you who come and go or don't know how to config your routers. i know how to keep things running smoothly. i also backup, unlike 99% of you idiots.

    LOL. It was down because I upgraded the motherboard and CPU in the machine that hosts my VMs. If you have any great ideas for hot-swapping CPUs and motherboards, I'd love to hear them.

    o
    (O)
    BeLLy

    ---
    þ Synchronet þ bbs.brazi.net þ www.brazi.net þ WARNING: May contain nuts
  • From deon@VERT/ALTERANT to Digital Man on Tue Aug 9 15:04:26 2022
    Re: CPU Hog
    By: Digital Man to deon on Mon Aug 08 2022 05:34 pm

    My logs show it does run twice a day (not 12 hrs apart, ergo 2 times a day - but...)

    Aug 5 00:35:54 d-11-1 synchronet: evnt BINKPOLL Running native timed event: BINKPOLL
    Aug 5 14:36:58 d-11-1 synchronet: evnt BINKPOLL Running native timed event: BINKPOLL

    So if the first question is yes, then that would imply that binkit -p does eventually exit.

    Yes.

    And for ever foreground "Running" log entry there should be a corresponding log entry like this:

    BINKPOLL Timed event: BINKPOLL returned 0

    Ahh, OK - so it ran for 2hrs and 1 min the first time:

    Aug 5 02:36:58 d-11-1 synchronet: evnt BINKPOLL Timed event: BINKPOLL returned 0
    Aug 5 14:37:26 d-11-1 synchronet: evnt BINKPOLL Timed event: BINKPOLL returned 0

    And the 2nd time it finished after 30s - because when it did poll my fido uplink, it was stuck already (the uplink polled me at 14:33 - and thus my connect to them got a "busy" message):

    Aug 5 14:37:19 d-11-1 synchronet: evnt BINKPOLL Attempting poll for node 3:633/280@fidonet
    Aug 5 14:37:19 d-11-1 synchronet: evnt BINKPOLL JSBinkP/4 callout to 3:633/280@fidonet started
    Aug 5 14:37:20 d-11-1 synchronet: evnt BINKPOLL Connecting to 3:633/280@fidonet at ftn633.vk3heg.net:24554
    Aug 5 14:37:20 d-11-1 synchronet: evnt BINKPOLL Peer version: binkd/1.1a-115/LinuxAug 5 14:37:20 d-11-1 synchronet: evnt BINKPOLL BinkP got non-fatal error 'Secure AKA 3:633/509@fidonet busy' from remote: 3:633/280@fidonet,3:633/0@fidonet,21:1/195@fsxnet,39:901/280@amiganet,39:901/0@amiganet,46:3/101@agoranet

    It appeared my fido polled me roughly every hour or so, and what I did notice is the absense of a corresponding:

    BINKP service thread terminated (4 clients remain, 4 total, 60 served)

    for his polls, when his poll would have ended.

    Checking through my logs I see often "[3-6] clients remain" for the BINKP service thread - so that indicates binkp sessions that havent yet exited?

    Aug 5 00:11:16 d-11-1 synchronet: srvc 0107 BINKP service thread terminated (5 clients remain, 4 total, 2973 served)
    Aug 5 00:12:14 d-11-1 synchronet: srvc 0108 BINKP service thread terminated (6 clients remain, 5 total, 2975 served)
    Aug 5 00:12:19 d-11-1 synchronet: srvc 0110 BINKP service thread terminated (5 clients remain, 4 total, 2975 served)
    Aug 5 00:15:52 d-11-1 synchronet: srvc 0108 BINKP service thread terminated (5 clients remain, 4 total, 2976 served)
    Aug 5 00:16:19 d-11-1 synchronet: srvc 0108 BINKP service thread terminated (5 clients remain, 4 total, 2977 served)
    Aug 5 00:16:38 d-11-1 synchronet: srvc 0108 BINKP service thread terminated (5 clients remain, 4 total, 2978 served)
    Aug 5 00:20:53 d-11-1 synchronet: srvc 0109 BINKP service thread terminated (5 clients remain, 4 total, 2979 served)
    Aug 5 00:21:27 d-11-1 synchronet: srvc 0109 BINKP service thread terminated (6 clients remain, 5 total, 2981 served)
    Aug 5 00:21:59 d-11-1 synchronet: srvc 0111 BINKP service thread terminated (5 clients remain, 4 total, 2981 served)
    Aug 5 00:22:20 d-11-1 synchronet: srvc 0109 BINKP service thread terminated (5 clients remain, 4 total, 2982 served)
    Aug 5 00:22:39 d-11-1 synchronet: srvc 0109 BINKP service thread terminated (5 clients remain, 4 total, 2983 served)

    Well if you figure out how to reproduce the problem, let me know.

    I might be able to, as I think it is MTU related - and I can revert my MTU configuration back to 1500 to try and get it to happen again. I'm not too worried about fixing it, as it's no longer an issue over IPv4 - so I copied the above for you in case there is another underlying issue with the BINKP service thread and not exiting that you are interested in.



    ...ëîåï

    ---
    þ Synchronet þ Alterant | an SBBS in Docker on Pi!
  • From Ryan Fantus@VERT to fusion on Tue Aug 9 00:30:20 2022
    another neat thing is each ntvdm gets it's own "640k" of ram, it's own EMS/XMS, etc.. it's really the scaffolding of the single-pc multinode
    bbs.

    Wow, I had no idea. That's pretty neat. Honestly, I use Windows 7 32 bit for my doorgame host and it works astonishingly well. No slowdowns or any other apparent issues. Only some games like Yankee Trader don't work; everything else seems to hum along as expected.

    it's neat stuff. bit of a shame the 16bit mode is not accessable from 64bit oses.. but we're lucky it works in 32bit mode. in theory it should be faster than the ntvdm64 one, but with modern cpus i don't know if you could measure that difference anymore

    Yeah, agree. I understand the reasons to delete legacy code but it does really put a thorn in my side, hehe.

    --- Mystic BBS v1.12 A48 2022/07/11 (Linux/64)
    * Origin: m O N T E R E Y b B S . c O M (1:218/820)
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Tony Langdon@VERT to fusion on Tue Aug 9 19:52:00 2022
    On 08-08-22 19:49, fusion wrote to Nightfox <=-

    On 08 Aug 2022, Nightfox said the following...

    As far as I can tell, NTVDM64 is meant to work on 64-bit Intel/AMD processors. Where did you see that it was for PowerPC?

    an excerpt from the ntvdm wiki:

    Since virtual 8086 mode is not available on non-x86-based processors
    (more specifically, MIPS, DEC Alpha, and PowerPC) NTVDM was instead implemented as a full emulator in these versions of NT, using code licensed from Insignia's SoftPC.

    I was led to believe that it was possible to create a DOS VM, using the hardware virtualisation capabilities of modern processors, so theoretically there is a way around the lack of virtual 8086 mode in 64 bit mode at the hardware level, if I'm right.


    ... Does the name Pavlov ring a bell?
    === MultiMail/Win v0.52
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Tony Langdon@VERT to Ryan Fantus on Tue Aug 9 19:58:00 2022
    On 08-09-22 00:30, Ryan Fantus wrote to fusion <=-

    another neat thing is each ntvdm gets it's own "640k" of ram, it's own EMS/XMS, etc.. it's really the scaffolding of the single-pc multinode
    bbs.

    Wow, I had no idea. That's pretty neat. Honestly, I use Windows 7 32
    bit for my doorgame host and it works astonishingly well. No slowdowns
    or any other apparent issues. Only some games like Yankee Trader don't work; everything else seems to hum along as expected.

    That's the magic of virtual 8086 mode. Same happened with DESQview on a 386, every session got its own 60k (less any OS/TSR overhead loaded before DV). And OS/2 really made good use of virtual 8086 mode with its DOS subsystem - the "better DOS than DOS".

    it's neat stuff. bit of a shame the 16bit mode is not accessable from 64bit oses.. but we're lucky it works in 32bit mode. in theory it should be faster than the ntvdm64 one, but with modern cpus i don't know if you could measure that difference anymore

    As I said in another message, I'm sure I read it's possible to spin up a DOS VM in 64 bit mode, by using the hardware virtualisation capabilities of modern AMD64 CPUs, which would result in similar functionality.


    ... Any safety factor set as a result of practical experience will be exceeded === MultiMail/Win v0.52
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Digital Man@VERT to deon on Tue Aug 9 12:09:23 2022
    Re: CPU Hog
    By: deon to Digital Man on Tue Aug 09 2022 03:04 pm

    Aug 5 00:35:54 d-11-1 synchronet: evnt BINKPOLL Running native timed event: BINKPOLL
    Aug 5 14:36:58 d-11-1 synchronet: evnt BINKPOLL Running native timed event: BINKPOLL

    So if the first question is yes, then that would imply that binkit -p does eventually exit.

    Yes.

    And for ever foreground "Running" log entry there should be a corresponding log entry like this:

    BINKPOLL Timed event: BINKPOLL returned 0

    Ahh, OK - so it ran for 2hrs and 1 min the first time:

    Aug 5 02:36:58 d-11-1 synchronet: evnt BINKPOLL Timed event: BINKPOLL returned 0
    Aug 5 14:37:26 d-11-1 synchronet: evnt BINKPOLL Timed event: BINKPOLL returned 0

    And the 2nd time it finished after 30s - because when it did poll my fido uplink, it was stuck already (the uplink polled me at 14:33 - and thus my connect to them got a "busy" message):

    Okay, cool. But now you see how to determine how long an event took to run.

    Aug 5 14:37:19 d-11-1 synchronet: evnt BINKPOLL Attempting poll for node 3:633/280@fidonet
    Aug 5 14:37:19 d-11-1 synchronet: evnt BINKPOLL JSBinkP/4 callout to 3:633/280@fidonet started
    Aug 5 14:37:20 d-11-1 synchronet: evnt BINKPOLL Connecting to 3:633/280@fidonet at ftn633.vk3heg.net:24554
    Aug 5 14:37:20 d-11-1 synchronet: evnt BINKPOLL Peer version: binkd/1.1a-115/LinuxAug 5 14:37:20 d-11-1 synchronet: evnt BINKPOLL BinkP got non-fatal error 'Secure AKA 3:633/509@fidonet busy' from remote: 3:633/280@fido net,3:633/0@fidonet,21:1/195@fsxnet,39:901/280@amiganet,39:90 1/0@amiganet,46:3/ 101@agoranet

    It appeared my fido polled me roughly every hour or so, and what I did notice is the absense of a corresponding:

    BINKP service thread terminated (4 clients remain, 4 total, 60 served)

    for his polls, when his poll would have ended.

    Checking through my logs I see often "[3-6] clients remain" for the BINKP service thread - so that indicates binkp sessions that havent yet exited?

    Correct. You can also set a limit for incoming connections ("MaxClients") for each service, if you wished.

    Well if you figure out how to reproduce the problem, let me know.

    I might be able to, as I think it is MTU related - and I can revert my MTU configuration back to 1500 to try and get it to happen again. I'm not too worried about fixing it, as it's no longer an issue over IPv4 - so I copied the above for you in case there is another underlying issue with the BINKP service thread and not exiting that you are interested in.

    If it requires IPv6 or a custom MTU to reproduce, I'm unlikely to pursue the problem. Deuce might, I suppose, but he's been AWOL here for quite a while. Hopefully you can find a suitable solution with what you've learned.
    --
    digital man (rob)

    This Is Spinal Tap quote #4:
    David St. Hubbins: He died in a bizarre gardening accident...
    Norco, CA WX: 91.9øF, 29.0% humidity, 9 mph SSE wind, 0.00 inches rain/24hrs ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Digital Man@VERT to Tony Langdon on Tue Aug 9 12:10:51 2022
    Re: Re: CPU Hog
    By: Tony Langdon to fusion on Tue Aug 09 2022 07:52 pm

    On 08-08-22 19:49, fusion wrote to Nightfox <=-

    On 08 Aug 2022, Nightfox said the following...

    As far as I can tell, NTVDM64 is meant to work on 64-bit Intel/AMD processors. Where did you see that it was for PowerPC?

    an excerpt from the ntvdm wiki:

    Since virtual 8086 mode is not available on non-x86-based processors (more specifically, MIPS, DEC Alpha, and PowerPC) NTVDM was instead implemented as a full emulator in these versions of NT, using code licensed from Insignia's SoftPC.

    I was led to believe that it was possible to create a DOS VM, using the hardware virtualisation capabilities of modern processors, so theoretically there is a way around the lack of virtual 8086 mode in 64 bit mode at the hardware level, if I'm right.

    Unfortunately, no. 64-bit x86 processors, when operating in "long mode" (64-bit mode) do not support the "virtual 86" mode that they have in 32-bit mode.
    --
    digital man (rob)

    Breaking Bad quote #39:
    Vacuum cleaner repair? What did you expect? Haji's quick vanish? - Saul
    Norco, CA WX: 91.9øF, 29.0% humidity, 9 mph SSE wind, 0.00 inches rain/24hrs ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Tony Langdon@VERT to Digital Man on Wed Aug 10 19:06:00 2022
    On 08-09-22 12:10, Digital Man wrote to Tony Langdon <=-

    Unfortunately, no. 64-bit x86 processors, when operating in "long mode" (64-bit mode) do not support the "virtual 86" mode that they have in 32-bit mode. --

    While not "virtual 8086 mode" as we've known it, from https://en.wikipedia.org/wiki/Virtual_8086_mode#64-bit_and_VMX_support

    "Virtual 8086 mode is not available in x86-64 long mode, although it is still present on x86-64 capable processors running in legacy mode.

    Intel VT-x brings back the ability to run virtual 8086 mode from x86-64 long mode, but it has to be done by transitioning the (physical) processor to VMX root mode and launching a logical (virtual) processor itself running in virtual 8086 mode.[14]

    Westmere and later Intel processors usually[15] can start the virtual processor directly in real mode using the "unrestricted guest" feature (which itself requires Extended Page Tables); this method removes the need to resort to the nested virtual 8086 mode simply to run the legacy BIOS for booting.[16][17]

    AMD-V can do virtual 8086 mode in guests, too, but it can also just run the guest in "paged real mode" using the following steps: you create a SVM (Secure Virtual Machine) mode guest with CR0.PE=0, but CR0.PG=1 (that is, with protected mode disabled but paging enabled), which is ordinarily impossible, but is allowed for SVM guests if the host intercepts page faults.[18] "



    ... Bit: The increment by which programmers slowly go mad
    === MultiMail/Win v0.52
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Daryl Stout@VERT to Tony Langdon on Tue Aug 9 16:22:00 2022
    Tony,

    That's the magic of virtual 8086 mode. Same happened with DESQview on
    a 386, every session got its own 60k (less any OS/TSR overhead loaded before DV). And OS/2 really made good use of virtual 8086 mode with
    its DOS subsystem - the "better DOS than DOS".

    That was fun running a DOS based dial-up BBS under DOS 5 with DESQView,
    and experimenting with the QEMM Memory Utility. :P

    I used the DeadPaint program (Dead for short) to do simple RIP Menus
    when I ran GT Power. Yet, a former Sysop believed "RIP is what you do
    to a fart". <G>

    However, Quarterdeck Software (which made DESQView and QEMM), as well
    as TeleGraphix (which pioneered RIP Graphics), are both long gone now.

    Daryl

    ... "It's a living." -Motto for US Army, suggested by Mort Sahl
    === MultiMail/Win v0.52
    --- SBBSecho 3.15-Win32
    * Origin: The Thunderbolt BBS - Little Rock, Arkansas (1:2320/33)
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Tony Langdon@VERT to Daryl Stout on Thu Aug 11 19:59:00 2022
    On 08-09-22 16:22, Daryl Stout wrote to Tony Langdon <=-

    That was fun running a DOS based dial-up BBS under DOS 5 with
    DESQView, and experimenting with the QEMM Memory Utility. :P

    Yeah DV and QEMM were a big thing then, and tweaking QEMM was an art form. The automatic coinfiguration would get it close, but it was possible to get a few more kB with a tweak.

    However, Quarterdeck Software (which made DESQView and QEMM), as well
    as TeleGraphix (which pioneered RIP Graphics), are both long gone now.

    A bygone era, definitely.


    ... The Lab called... Your brain is ready!
    === MultiMail/Win v0.52
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Jared@VERT/JUMPLEFT to Daryl Stout on Thu Aug 11 12:19:13 2022
    Re: Re: CPU Hog
    By: Daryl Stout to Tony Langdon on Tue Aug 09 2022 16:22:00

    That's the magic of virtual 8086 mode. Same happened with DESQview on a 386, every session got its own 60k (less any OS/TSR overhead loaded before DV). And OS/2 really made good use of virtual 8086 mode with its DOS subsystem - the "better DOS than DOS".

    That was fun running a DOS based dial-up BBS under DOS 5 with DESQView, and experimenting with the QEMM Memory Utility. :P

    However, Quarterdeck Software (which made DESQView and QEMM), as well
    as TeleGraphix (which pioneered RIP Graphics), are both long gone now.


    DESQView and DOS 5 and while originally RA later Ezy was the pinacle of my 90s board time and ran Oglaroon (my original BBS name) for years, but I have to say nothing ever came close to the pre-emptive multitasking of my beloved Amiga 500.. not for many years. :D

    de VK2WAY

    ---
    þ Synchronet þ It's just a jump to the left (and a step the right)...
  • From Tracker1@VERT/TRN to deon on Thu Aug 11 16:25:28 2022
    On 8/7/22 16:54, deon wrote:

    The problem started when I switched to a new ISP, that uses PPPoE.
    As a result all of my IPv6 traffic was affected by the lower MTU,
    and while I addressed that for my server LAN, I'm assuming it is
    affecting the docker lan (havent definitively confirmed that yet,
    but it seems likely).

    Wild... I just resorted to configuring everything IPv4 on my end because
    it was too much of a pain... started down the path of setting it up, but decided to just nuke and stick to ipv4.
    --
    Michael J. Ryan - tracker1@roughneckbbs.com
    ---
    þ Synchronet þ Roughneck BBS - roughneckbbs.com
  • From Tony Langdon@VERT to Jared on Fri Aug 12 19:58:00 2022
    On 08-11-22 12:19, Jared wrote to Daryl Stout <=-

    DESQView and DOS 5 and while originally RA later Ezy was the pinacle of
    my 90s board time and ran Oglaroon (my original BBS name) for years,

    My journey started with RA on DOS, then DOS/QEMM/DV, and finally OS/2, which I totally loved.

    but I have to say nothing ever came close to the pre-emptive
    multitasking of my beloved Amiga 500.. not for many years. :D

    The Amiga was way ahead of its time with smooth multitasking and hardware acceleration that was unheard of at the time. The OS wasn't bad, though predating modern security concerns, it was prone to viruses and DoS.

    A friend had an A1000 in the mid 80s. loved it and used to talk about the viruses that were around. A bit later, I used to work on an A2000 with a PC/286 card. I got that machine, because no one else knew how to use it. While the DOS side was for work, I did play with the Amiga side in my downtime, or while waiting for a PCB design to autorpute. Along the way, I found a file (probably on some BBS or newsgroup) that described countless ways to bring on a "Guru Meditation" - what would be called DoS today. From memory, the easiest one was simply to issue the command "run run", which I think corrupted the stack.

    Mind you, at the same time (and considerably later), DOS had some clangers as well, like attempting to access the file "CLOCK$" on a DOS machine would crash it (that's a reserved device name). Same for Windows up to at least Windows 95 (e.g. start -> run -> \\target\con\con to remotely crash a Windows 95 machine with file sharing enabled).




    ... Sow your wild oats on Saturday night, then on Sunday pray for crop failure === MultiMail/Win v0.52
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From deon@VERT/ALTERANT to Tracker1 on Fri Aug 12 21:02:46 2022
    Re: Re: CPU Hog
    By: Tracker1 to deon on Thu Aug 11 2022 04:25 pm

    Wild... I just resorted to configuring everything IPv4 on my end because
    it was too much of a pain... started down the path of setting it up, but decided to just nuke and stick to ipv4.

    Actually, IPv6 is pretty easy, and I've configured everything to use it.

    I did have NAT64 running as well - I was hoping to do away with IPv4 (dont want to manage both address schemes) - but the switch to PPPoE messed that up.

    Everything works fine now with IPv6 - except NAT64 - the MTU threw me for a bit, but I recall MTU issues in the paste (with VPNs) so it was easy to validate and fix once I picked that as the issue.


    ...ëîåï

    ---
    þ Synchronet þ Alterant | an SBBS in Docker on Pi!
  • From Tony Langdon@VERT to deon on Sat Aug 13 11:10:00 2022
    On 08-12-22 21:02, deon wrote to Tracker1 <=-

    Actually, IPv6 is pretty easy, and I've configured everything to use
    it.

    I've been running native IPv6 since 2011. It "just works". :)


    I did have NAT64 running as well - I was hoping to do away with IPv4
    (dont want to manage both address schemes) - but the switch to PPPoE messed that up.

    Yeah I'm not ready to ditch IPv4 yet, too many things still depend on it that need full connectivity (no NAT!).

    Everything works fine now with IPv6 - except NAT64 - the MTU threw me
    for a bit, but I recall MTU issues in the paste (with VPNs) so it was
    easy to validate and fix once I picked that as the issue.

    Yeah, MTU issues are always a possibility where tunnels and PPPoE are concerned, but provided everyone does as they should (not blocking ICMP!), it should "just work", once the proper endpoint MTUs are set.


    ... My dream is to open a photo processing store in a developing country
    === MultiMail/Win v0.52
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net