Portmaster 3 Network performance

Retronetworking
,
#1

Hey,

a while ago, we’ve noticed that the PortMaster 3 (RAS, used in the OCTOI hub in Nuremburg) will exhibit bad performance when used in TCP termination mode.

When using X.75, V.120, etc. to connect to a phone number, which is then (through RADIUS) pointed to a TCP socket, the performance is limited to something like 2kByte/s aka 20kBit/s, instead of the correct 64kBit/s.

Using PPP (for internet access), either directly or through the L2TP tunnel feature works perfectly and you can reach 64kbit/s (or even more with bonding).

Curiously, after fixing the OCTOI link issues, I was now able to establish high-speed modem connections reliably for the first time. Interestingly, here the problem also occurs, but to my surprise the exact behaviour also happens to PPP connections!

Analog modem connections are always limited to ~20kbit/s, when connecting to a TCP target or using PPP.

I also thought we already had a bug report for this somewhere, but I couldn’t find it…

I’ve skimmed the PM3 manual for any options like TCP settings, MTU/MSS, compression, etc. but could not find anything that looked immediately suspicious.

@laforge Any insight into firmware versions for the PM3’s? Were there firmware updates? Are our PM3’s running the latest one?

To the community: Ideas? Where would you take a closer look? Network side? ISDN side?
Did something fundamental change in TCP flow control in the past 30 years? (this is 30 year old equipment talking to Linux 6.0 after all)…

#2

Clearly this is very unusual. For sure “Back in the day” the internet connections speeds (whether ISDN or analog) was not limited to the observed 20kbit/s. I know that from my personal experience, and I’m sure many other people can attest to that (franken.de had about 800 dial-up members at some point). AFAIR this was all IP over PPP/X.75 back then, terminating the PPP locally in the PM3 (no L2TP) and using OSPF to route every subscribers 6 static IP addresses to the specific dial-up session after authentication. For PPP, the ancient BSD TCP implementation of the PM3 doesn’t matter, as it simply decapsulates IP frames from PPP and puts them into Ethenet frames and vice-versa.

We are running the latest firmware that was published (pm3_3.9.1c1), you can find all of them at in our nextcloud at ras/livingston-portmaster3/livingston/os/ including related changelogs like release391c1.txt

I could understand connection speed issues if they were restricted to the telnet/rlogin/pmnet type of sessions. In this case, the local TCP stack of the PM3 is actually used. We didn’t use those at franken.de back in the day, at least only for UUCP (pmnet to a SunOS or Solaris SPARCstation 20, AFAIR). It might not have been relevant if the speed of those was somehow limited.

When I first looked into this issue with “telnet style forwarding” of the PM3 in OCTOI, I did look at pcap files and the TCP window was not constrained, AFAIR. At least not in the uplink (subscriber → PM3) direction, where the TCP window is wide open from the “telnetd” side. For the downlink (subscriber ← PM3) direction, I think the PM3 uses the TCP window to rate-limit transmission from the telnetd side. Basically to avoid overflows in the PM3, it puts back-pressure on the TCP sender. That’s how I would have expected it to work.

We also observed the same problems (limited rates of isdn calls forwarded via telnet) in the “local PM3” setup )the one used at last CCC congress in 2019, or VCFB last year). So it’s not constrained to a single specific PM3 unit. And it also occurs if no OCTOI is in place. Plus, we’re using FreeSwitch there, and not yate…

#3

some old notes from IRC logs:

11:31  * LaF0rge is currently wondering why even via ISDN no more than 4036 cps via zmodem - whether V.120 or X.75. but no CRC errors or other errors reported.                                                    
11:39 <@roox> LaF0rge: I started the zmodem download ~10 minutes ago with peaks up to 5200cps (via ELSA/Devolo MicroLink Fun II)                                                                                  
14:01 <@manawyrm> LaF0rge: your random test download is doing ~2048cps with ZModem on my Windows HyperTerminal via Fritz!ISDN. Not really fast, I wonder what's going on there. Retry and Error counters aren't risin
14:01 <@manawyrm> (in X.75 mode without compression)                                                                                                                                                                 
14:13 <@manawyrm> I mean, there's a lot of knobs to fiddle with                                                                                                                                                      
14:13 <@manawyrm> or if the TCP encap feature of the PM3 is just slow (I haven't tested it's speed yet)

When testing with the cisco AS5400:

20:31 <@LaF0rge> but when I manually telnet to a service, I'm getting 7580 cps
20:32 <@LaF0rge> if somebody wants to test: 030-1234-4001 should support V.120 + X75 for async access, as well as V.90 modem calls and drop you to  the VTY
20:32 <@LaF0rge> you can then run the above-mentioned telnet command to get that zmodem test I set up
20:33 < marrold> CPS?                                  
20:33 <@LaF0rge> characters per second
20:33 <@LaF0rge> where the PM3 sucked all the time

also:

03:02 < W|MPy> I just tried Z-modem on a Max and got around 7500cps.

and:

19:46 <@LaF0rge> so, I now have the second PM3 connected in parallel to the "usual" PM3. let's see if that has different ZModem CPS
20:14 <@LaF0rge> same lame throguhput here with the other PM3. so whatever it is, it is not a problem with a specific hardware unit.             
20:15 <@LaF0rge> So I have this TA (https://osmocom.org/projects/retronetworking/wiki/US_Robotics_Sportster_ISDN_TA_Ext) connected to the Auerswald COMmander Basic2 connected to the OCTOI hub connected to a PM3. A
20:16 <@LaF0rge> this is with the PM3 doing TCP-clear forwarding          
20:58 <@LaF0rge> lol, I now dialed in with an analog modem into the same PM3 with the same telnet forwarding and I'm getting 3000cps ;)