I have been experimenting with the bridge functionality on a linbpq system. The test bridge system has only 1 telnet port (so I can use QTT for testing) and 2 RF ports defined. The 2 RF ports (10m and 70cm) are bridged and for testing purposes are configured for 1200b with a maxframe of 3 and a paclen of 128.
The bridge functionality is working but with one odd behavior.
Both RF ports use QTSM 1200b ax25 no fx and no il2p. I can connect on either the 10m port or the 70cm port to the bridge system directly as a node and issue a command that will generate a bunch of output like the status command and both ports behave as I would expect. By that I mean I can monitor the ax25 packets and see the bridge system send 3 frames (MAXFRAME=3) and the connected system respond as it should with a single ACK. The bridge node sends the next 3 frames which is again ACK'd by the connected system with a single frame and so on until there is no remaining data to send. The bridge is active the entire time but in this test is not providing anything useful since I connected to the bridge system directly as a node specifically to verify that AX25 packet timing was acceptable on both RF ports given PERSIST and SLOTTIME settings. Both RF ports behaved well and I did not witness a single retry.
If I instead connect .eg. from a system on 10m "through the bridge" to a linbpq node on the 70cm side of the bridge the ax25 traffic is nicely bridged in both directions but now there is the odd to me behavior observed. With small bits of data that do not require more than a single frame the bridge works very well. If however there is a large block of data like the output from a BPQ status command?and both RF ports are trying to do the MAXFRAME=3 thing the timing goes bonkers and there are lots of retries that slow down the transfers significantly.
Short of forcing MAXFRAME=1 on the bridge ports is there anything I can do so that the bridge function does not muck so much with the packet timing?
73 de Rich WA3WLH
