Creating a KISS client, direwolf sends back TX-data

[isguarded]

I write a KISS client for direwolf and fldigi. I have this weird problem with direwolf, that when the soundcard is connect with some devices (not all though, a direct link between two computers (mic->line-out/line-out->mic) works for example), and my client writes something to direwolf (over TCP), the data gets mirrored somehow and is back in the reading pipe of my client.

I have a feeling, that is principally a hardware issue, but I don't have this problem with fldigi. I tried to set direwolf in half-duplex mode via KISS cmd 5, but it does not change anything.

How can I stop direwolf from writing back data to the tcp stream, which was just sent, even if there might be some sort of unwanted loopback in the audio-ware?

Some detail information which might be or be not related:

DireWolf 1.4
Audio Device in: plughw:0,3 (ch0)
Audio Device out: plughw:0,0 (ch0)
Channel 0 300 baud, AFSK 1000 & 1300, D, 48000 sample rate / 3
The clients just sends simple data-frames: c0 00 data c0
The client reads from the tcp stream non-blocking

[isguarded]

Maybe the difference to fldigi is, that fldigi has a software-squelch-function. That would most likely solve the issue.

[LongnoseRob]

1.it might be worth trying the latest release or the latest development build from source.
With the release 1.5 there were some fixes for KISS connections over TCP:
'Strange failures when trying to use multiple KISS client applications over TCP. Only Linux was affected.'
2. if you are connecting via TCP, then it might be also helpfull to log the traffic with wireshark or its brothers(tcpdump, etc)
3. you could compare the behavior of your new client with kissutil (from the direwolf package)

[isguarded]

1.it might be worth trying the latest release or the latest development build from source.
With the release 1.5 there were some fixes for KISS connections over TCP:
'Strange failures when trying to use multiple KISS client applications over TCP. Only Linux was affected.'

That might be worth a try. Although my design is single-client only.

2. if you are connecting via TCP, then it might be also helpfull to log the traffic with wireshark or its brothers(tcpdump, etc)

The tcp communication seems to be sane. Also the packets are processed as expected. Also the buffer is sane and free immediately, no bytes stuck.

3. you could compare the behavior of your new client with kissutil (from the direwolf package)

The issue is reproducable with the kissutil. As in #97 stated, it could be a questio of audio loopback bleeding through the hardware, where then the no squelch situation makes it unavoidable. I tend to believe in the bleeding explenation, since I realized that with the right settings for the soundcard the issue only appears on specific devices connected, which could bleed theoretically.

[isguarded]

As nothing moved here and with issue #97, I came up with a workaround:

You can put your KiSS client in a forced (pseudo) simplex mode by "blocking" the read from the tcp stream. You should discard all read bytes from the stream as long as direwolf is sending the data + a little delay afterwards. I used this "formula" successfully:
discardseconds = (sentbytes * 8 / baudrate).ceil + 1

For longer transmissions one want to include the time for transferring the data per TCP or UDP. Which should be negligible for anything < MBytes.
Keep in mind that you still have to read from the tcp stream while in simplex mode, otherwise the tcp buffer is not flushed and the data direwolf sends back will be transferred as soon as you read from the stream again.

[cb3rob]

isguarded

you don't know 'how long it takes direwolf to transmit the data' based on your calculation as for one thing you don't know how long it takes direwolf to wait for others to clear the channel so it can transmit. tnc's do not return statusses when 'done' ;) your calculation would (maybe) work on 2 tnc's or telephone modems connected back to back with noone else on any 'radio' in between but not irl. you know how long it takes to transmit the data. you don't know when it starts to do so. therefore you can't just say 'it takes x seconds'.

[cb3rob]

dealing with data coming back the wrong way in is easy. it'd have your callsign (or actually better the whole path specification already in use in a session) in the wrong spot ;P (incoming data should not have the same callsign as -source- as you sent it with anyway ;) but that's only if it runs a higher protocol such as ax.25 ;P

[cb3rob]

it is btw no problem at all to run ax.25 or ip or any protocol at that 'out in the open' over the speakers and microphone without any radios or wires and it is also no problem that each and every one of those stations also hear their own outgoing blips and blops. as the terminal software doesn't suddenly think it's the destination callsign as well. simple. could probably just connect the whole lot of it to just 2 wires. any higher protocol will have no issues with echo'ed packets. (ax.25 DOES have an issue with it in connected mode if it sees the same packet multiple times but not if it sees it's own packets). same goes for IP and basically anything that has the concept of 'source' and 'destination' addresses.

[wb2osz]

If a station is hearing itself, it is most likely audio cross talk. Try using separate shielded cables for audio in each direction.

[cb3rob]

If a station is hearing itself, it is most likely audio cross talk. Try using separate shielded cables for audio in each direction.

ehm. no the guy is connecting 2 computers together... quite a few sound chips (dell, others) have the tendency to just make whatever you put into the -microphone- input crack straight out the line out again if you 'overmodulate' the microphone input. which seriously isn't hard to do. considering that it's intended for microphones :P i'm sure there is some sort of flag on that interface to switch it to unamplified line in mode but linux can't find it ;P it's actually the sound'card' itself doing that... if you hook up the microphone input to some smartphone playing mp3's you'll also hear it cracking through your speakers regardless of mixer settings if your smartphone outputs it at more than just 25% of volume or so. :P... the 'correct' solution involves transformers, capacitors (it also sends phantom feed power to the mic jack) etc. OR figuring out how to switch the soundcard from microphone mode to line input mode (which i'm sure they all can do. after all the symbol label is half pink half blue so it can be switched ;) just that linux doesn't show it can.

and afsk 1200 and such are -not- very picky about some cracks and distortions.. as is the entire point of using it ;P so it'll happily decode it's own cracked-straight-through-the-chip sound back... which is where normally something like 'ax.25' jumps in to go 'hey, this packet has my adddress but as the source so i'm not doing anything with it' :P his main problem is: not runnning a higher level protocol. just putting raw data into kiss frames. ;P see wether you 'hear' your own tx signal really doesn't matter as long as anything like 'ip' or 'ax25' or 'x25' is in place. you can all nicely hook it up to the same canbus, rs485, or just some line transformers to a telephone wire and it'll all nicely hear itself and talk to itself and other stations as any decent protocol ignores packets not having its address as the -destination-. not the source. the fact that his microphone input probably won't like line level input long-term and it usually sounds like the magic smoke will come out is his choice ;P lol.

[cb3rob]

as for ax.25 'should allow self connects'. which now usually is arranged in things like l2.exe or tfpcx.exe or the client itself in some half broken manner. linux can't seem to do it at all, let alone if it is to -another- interface call or some program bound to that... (or maybe it can but the add route ioctl documentation kinda got lost in time ;) if they DID all have tx/rx looped back that would at least solve that part of it, in hardware no? LOL. (okno. clearly this belongs in the ax25 stack itself... not in the network interfaces.. especially not the analog part of a soundcard lol. just like with ip any interface or callsign you bind should just bring up an internal route to itself for stuff coming from other callsigns/ssids within that same computer to use automatically. like with ip ;) guess it's too late to make the bind() use an interface index number rather than a callsign-ssid on that interface. as those are not nessesarily either valid nor unique ;). still the whole thing lacks internal routes to it. it'll only connect to the outside world -from- said 'bind() by callsign' interface (and then just hope you don't have 20 interfaces with the same callsign ;)

[marrold]

Looking at the issues, these all seem related:

#401
#97
#288
#337

[wb2osz]

Fixed - same as 401.