Support for AXIP or AXUDP?

[kinzi-net]

Hello,

as far as I understand the KISS interface of this solution is not compatible with AXIP or AXUDP, am I right?

For AXIP, on both sides the partner has to be specified by his IP address. Communication runs on Port 93. It is possible to run piBayCom on port 93, of course - but how do I specify the partner?

For AXUDP, the partners IP address, the local source port and the remote destination port would have to be specified. I guess this isn't possible either?

So, how do you attach this KISS interface to common software?

Regards kinzi

[kinzi-net]

OK, temporarily solved, too. Using "socat" on the remote side does the job:

https://stackoverflow.com/questions/22624653/create-a-virtual-serial-port-connection-over-tcp

socat pty,link=/dev/virtualcom0,raw tcp:192.168.254.254:8080&

The the "remote" side (program) ca use /dev/virtualcom as KISS serial port.

[TAj-src]

Yes it's only kiss over tcp so you need a higher level program like BPQ or similar to do the axip or axudp connections. That is not what this modem is for. This modem you connect to other programs.

Im glad you got it working. I'd be interested in the c64 setup. Mail me direct?

Steve

On Sun, 19 Jun 2022, 14:04 kinzi-net, @.***> wrote:

OK, temporarily solved, too. Using "socat" on the remote side does the job:

https://stackoverflow.com/questions/22624653/create-a-virtual-serial-port-connection-over-tcp

socat pty,link=/dev/virtualcom0,raw tcp:192.168.254.254:8080&

The the "remote" side (program) ca use /dev/virtualcom as KISS serial port.

— Reply to this email directly, view it on GitHub https://github.com/TAj-src/piBayCom/issues/2#issuecomment-1159721116, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALBPCYJVAFEBBFJ6DDI42PLVP4LFFANCNFSM5ZGKTLVQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[kinzi-net]

Well, if this modem would support AXIp or AXUDP it could be directly attached to XNET or similar software, like other modems, TNCs, etc. Anyway, it's how it is. :-)

The C64 uses a modem almost identically to the BayCom modem, connected to its tapeport, only without the need for the "level shifter" (7414), since it's already TTL. So to connect the Pi directly to the C64, you'll want to omit both modems and connect the TTL level RX and TX lines directly - almost. The TXD line from C64 must be converted to 3V3 using a resistor voltage divider, of course.

My intention is to bring the C64 online in PR without the need for a modem and a TRX attached to it, since I'm running an "inhouse digipeater" using XNET. I have several devices to operate PR with and I do not want to attach TRXs to each one. A single TRX connected to the digipeater is sufficient, all the devices connect via AXIP, AXUDP or serial KISS interfaces and share the RF port. So you modem is the ideal solution for me ... in principal. :-)

The C64 receives packets from the Pi alreaedy. The Pi on the other hand does not decode any packets from the C64. TXD level from the C64 is 3.1 V, which should be perfectly fine. Still searching where I am doing whatever wrong ...

[TAj-src]

I don't know of any other modems that have axudp or axip functionality. This and they are all lacking the ax25 stack to be able to do that?

OK I see what you are trying to do. It should work fine. Good that it works tx but rx not so good. If you compile the baycom modem with debug it might throw more information / errors or partial frames.

Steve

On Sun, 19 Jun 2022, 21:57 kinzi-net, @.***> wrote:

Well, if this modem would support AXIp or AXUDP it could be directly attached to XNET or similar software, like other modems, TNCs, etc. Anyway, it's how it is. :-)

The C64 uses a modem almost identically to the BayCom modem, connected to its tapeport, only without the need for the "level shifter" (7414), since it's already TTL. So to connect the Pi directly to the C64, you'll want to omit both modems and connect the TTL level RX and TX lines directly - almost. The TXD line from C64 must be converted to 3V3 using a resistor voltage divider, of course.

My intention is to bring the C64 online in PR without the need for a modem and a TRX attached to it, since I'm running an "inhouse digipeater" using XNET. I have several devices to operate PR with and I do not want to attach TRXs to each one. A single TRX connected to the digipeater is sufficient, all the devices connect via AXIP, AXUDP or serial KISS interfaces and share the RF port. So you modem is the ideal solution for me ... in principal. :-)

The C64 receives packets from the Pi alreaedy. The Pi on the other hand does not decode any packets from the C64. TXD level from the C64 is 3.1 V, which should be perfectly fine. Still searching where I am doing whatever wrong ...

— Reply to this email directly, view it on GitHub https://github.com/TAj-src/piBayCom/issues/2#issuecomment-1159809417, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALBPCYM4HFOO2REGEWLG7BDVP6CSLANCNFSM5ZGKTLVQ . You are receiving this because you commented.Message ID: @.***>

[kinzi-net]

RX problem solved. C64 TXD line is not TTL but +6.5 V level (motor control line), so I had to use a series 3V3 Zener and 470R to GND to generate a valid 3V3-signal for the GPIOs. The C64's signal has unclean negative edges, a simple voltage divider isn't enough, the signal drops to 0 V too slowly.

Works now ... sort of.

Using "socat" you can connect the piBayCom to a virtual serial port, i. e. /dev/virtualcom0 and use this virtual serial port as a KISS interface in XNET, for example.

The problem is, once the piBayCom is shut down socat terminates and the virtual interface is gone. Maybe I'll find a solution for this problem, too.

Thanks so far for your efforts!

Regards kinzi

[kinzi-net]

Hi again,

RFC 1226 describes AXIP. The design lacks a possibility to configure the modem (TXD, etc.), as it was not developed with modems being attached in mind. However, it does a simple AX.25-in-IP-encapsulation, just like KISS over RS232.

The XNET digipeater software has overcome this problem, it can use AXIP (and AXUDP) to attach TNC3 TNCs in "IPKISS" mode.

See http://xnet.swiss-artg.ch/pdf/tnc.pdf page 33/34 for implementation details. I have no clue how difficult this would be to implement in piBayCom.

73 kinzi

[TAj-src]

Kiss can configure the modem.

On Mon, 27 Jun 2022, 18:20 kinzi-net, @.***> wrote:

Hi again,

RFC 1226 describes AXIP. The design lacks a possibility to configure the modem (TXD, etc.), as it was not developed with modems being attached in mind. However, it does a simple AX.25-in-IP-encapsulation, just like KISS over RS232.

The XNET digipeater software has overcome this problem, it can use AXIP (and AXUDP) to attach TNC3 TNCs in "IPKISS" mode.

See http://xnet.swiss-artg.ch/pdf/tnc.pdf page 33/34 for implementation details. I have no clue how difficult this would be to implement in piBayCom.

73 kinzi

— Reply to this email directly, view it on GitHub https://github.com/TAj-src/piBayCom/issues/2#issuecomment-1167394515, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALBPCYJ5HRV3BJ4D7BKHM73VRHPG7ANCNFSM5ZGKTLVQ . You are receiving this because you commented.Message ID: @.***>

[kinzi-net]

Yes, KISS can.

But neither Flexnet nor XNET offer "KISS over TCP" (aka. "AXTCP" in BPQ if I understand correctly), nor does TheNetNode. And that's the most common software here in DL/OE/HB. They only provide AXIP and AXUDP. KISS is only supported over serial devices there. At least XNET provides an enhanced AXIP with the possibility to configure a modem, as mentioned above.

No one uses BPQ or similar here, it's totally unknown, so this is not an option. That's the reason why I asked for AXIP/AXUDP support. I would have asked the XNET developer for an AXTCP implementation (I guess it would only be a minor extension) but XNET hasn't been actively developed for almost 15 years now.

Anyway, thanks for your efforts.

73 kinzi

[TAj-src]

Socat pty, link=virtualcom0, raw tcp:127.0.0.1:1234

On Wed, 29 Jun 2022, 14:51 kinzi-net, @.***> wrote:

Yes, KISS can.

But neither Flexnet nor XNET offer "KISS over TCP" (aka. "AXTCP" in BPQ if I understand correctly), nor does TheNetNode. And that's the most common software here in DL/OE/HB. They only provide AXIP and AXUDP. KISS is only supported over serial devices there. At least XNET provides an enhanced AXIP with the possibility to configure a modem, as mentioned above.

No one uses BPQ or similar here, it's totally unknown, so this is not an option. That's the reason why I asked for AXIP/AXUDP support. I would have asked the XNET developer for an AXTCP implementation (I guess it would only be a minor extension) but XNET hasn't been actively developed for almost 15 years now.

Anyway, thanks for your efforts.

73 kinzi

— Reply to this email directly, view it on GitHub https://github.com/TAj-src/piBayCom/issues/2#issuecomment-1170008507, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALBPCYKSMWX4JEIHKG7NNRLVRRIHTANCNFSM5ZGKTLVQ . You are receiving this because you commented.Message ID: @.***>

[kinzi-net]

Been there, done that.

But socat exits if the remote device becomes unavailable for a short time. Yes, you might want to enclose it in a "while true"-loop, ... did already try that, too. But when socat exists the virtual device vanishes, leaving the node software which an unattached port. Would have to restart the node software, too.

[TAj-src]

A couple of socat instances might be a work around.

1st one creates a pair that doesn't dissappear so xnet won't complain.

Socat -d -d PTY, raw, echo=0,link=virtualcom0_input PTY, raw, echo=0,link=virtualcom0

2nd opens input of 1st pty and connects to the kiss modem. This one will need to be in a loop so that it restarts if the kiss modem faults.and has to be started after the modem (or the loop has to wait for it)

Socat -d -d open:Virtualcom0_input, raw, nonblock, echo=0 tcp:127.0.0.1:1234

I've tested and that seems to work.

Use virtualcom0 in xnet me know what happens!

Steve

On Wed, 29 Jun 2022, 16:04 kinzi-net, @.***> wrote:

Been there, done that.

But socat exits if the remote device becomes unavailable for a short time. Yes, you might want to enclose it in a "while true"-loop, ... did already try that, too. But when socat exists the virtual device vanishes, leaving the node software which an unattached port. Would have to restart the node software, too.

— Reply to this email directly, view it on GitHub https://github.com/TAj-src/piBayCom/issues/2#issuecomment-1170097046, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALBPCYJBXHPEQWKS7A7RQVDVRRQZRANCNFSM5ZGKTLVQ . You are receiving this because you commented.Message ID: @.***>

[TAj-src]

I'm still not 100% on what it is you are trying to do / connect? Is it the baycom output from the pi to another machine via IP, which is running xnet?

Could you not use socat or/and netcat to make a virtual com port for xnet to connect to, which in turn sends it to the ip of the baycom? Using KISS, it would think its a real hardware modem?

Steve

On Wed, 29 Jun 2022, 14:51 kinzi-net, @.***> wrote:

Yes, KISS can.

But neither Flexnet nor XNET offer "KISS over TCP" (aka. "AXTCP" in BPQ if I understand correctly), nor does TheNetNode. And that's the most common software here in DL/OE/HB. They only provide AXIP and AXUDP. KISS is only supported over serial devices there. At least XNET provides an enhanced AXIP with the possibility to configure a modem, as mentioned above.

No one uses BPQ or similar here, it's totally unknown, so this is not an option. That's the reason why I asked for AXIP/AXUDP support. I would have asked the XNET developer for an AXTCP implementation (I guess it would only be a minor extension) but XNET hasn't been actively developed for almost 15 years now.

Anyway, thanks for your efforts.

73 kinzi

— Reply to this email directly, view it on GitHub https://github.com/TAj-src/piBayCom/issues/2#issuecomment-1170008507, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALBPCYKSMWX4JEIHKG7NNRLVRRIHTANCNFSM5ZGKTLVQ . You are receiving this because you commented.Message ID: @.***>

[TAj-src]

Original AXIP / AXUDP was not in the scope of this project as it is a KISS driver.