If you just want the most minimal-effort setup guide on how to run ethernet and IP over packet radio TNCs, skip down to the section: "One to Many, Many to One".
The Old Ways
Running IP applications over packet radio TNCs and similar hardware has traditionally been possible, albeit in a somewhat limited form, using the Linux AX.25 kernel modules and utilities like kissattach. Recent bugs have prevented this method from working correctly in new versions of Debian (and derivatives), and there is even a discussion about removing kernel AX.25 support altogether.
While the kissattach method of IP networking over packet radio traditionally worked relatively well, it also has the drawback of having to encapsulate everything in AX.25 frames, and thus not supporting standard ethernet, while incurring overhead that is entirely unnecessary for IP networking.
A Cleaner Solution
With all that in mind, I found it was probably time to offer an alternative, so I wrote tncattach. It's a small program that replaces the functionality from kissattach, and doesn't require any special kernel modules.
With tncattach you can attach any KISS-compatible TNC as a fully ethernet-compatible network interface in Linux. It also supports more "lightweight" tunnel interfaces, for point-to-point links (where you don't need the overhead of ethernet). And it of course fully supports both RNode and OpenModem.
After writing tncattach, I optimised the buffering and queues in the device firmwares, so be sure to update your RNode to at least version 1.16, and your OpenModem to version 1.05 or above for the best results.
Creating an interface with tncattach
To create an interface with tncattach, you will first need to download the program to your system. Please read the download and install instructions here.
For the sake of this tutorial, we will go through creating two different setups, first a point-to-point link between two devices, and next a point-to-multipoint setup that can support many individual devices communicating on the same channel.
The tncattach program offers a range of options to be given on the command line, and I'd suggest you read about them by entering the command:
tncattach --help
I won't go over them all here, but I will explain the importance of some of them as we move through the tutorial.
It's also worth noting, that if you are using tncattach with RNodes, you should put them into TNC mode with the rnodeconf program before running tncattach, as tncattach will not configure radio parameters, but expects the hardware to be ready to receive and transmit when it attaches.
Point-to-Point Links
For tncattach to create an interface, it needs to know at minimum what serial port the TNC is connected to, and what the baud-rate of the port is. For the rest of this tutorial, I will assume that a TNC is connected to each system, and available on serial port /dev/ttyUSB0, using a baud-rate of 115200. A minimal command for achieving this could look like:
sudo tncattach /dev/ttyUSB0 115200
Which will create and bring up a point-to-point interface on our system:
ifconfig
tnc0: flags=337<UP,POINTOPOINT,RUNNING,PROMISC> mtu 329
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 500 (UNSPEC)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Great! We actually have a usable, although unconfigured interface. In most cases, we probably want to specify a few options, though. Let's enable the built-in IPv6 filter, so we don't spam the channel with router solicitations and similar, and also tell tncattach that we will manually bring up the interface after creation, which is useful when making point-to-point links.
The default MTU of 329 bytes should work on almost all TNCs, but in most cases it can be increased. Let's assume the connected TNC is an OpenModem, which supports an MTU of 576 bytes. We need to subtract any framing overhead from that, since that is the raw packet MTU of the device. For tncattach point-to-point interface the framing overhead is 4 bytes. For ethernet interfaces it is usually 18 bytes, but can be as high as 22, if you want to support VLAN tagging. So as a rule of thumb, subtract 4 bytes for point-to-point links and 22 bytes for ethernet links from the TNCs MTU. Aplpying this, we get an mtu of 572 bytes for OpenModem.
As a last consideration, we'll tell tncattach to daemonize it's process after creating the interface, so it will run in the background as a system process. This is achieved with the -d switch.
We can now put the above considerations together into the following command:
sudo tncattach /dev/ttyUSB0 115200 -d --noipv6 --noup --mtu 572
This will create the interface tnc0 as a point-to-point interface, but it will not yet be active. We'll configure the point-to-point link with 10.0.0.1 being the local IP address, and 10.0.0.2 being the remote address, and bring the interface up:
sudo ifconfig tnc0 10.0.0.1 pointopoint 10.0.0.2
The interface is now up and running, and ready to communicate with the remote end:
ifconfig
tnc0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 496
inet 10.0.0.1 netmask 255.255.255.255 destination 10.0.0.2
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 500 (UNSPEC)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
On the remote system, the configuration commands would be similar, with only the order of IP-addresses changed:
sudo tncattach /dev/ttyUSB0 115200 -d --noipv6 --noup --mtu 572
sudo ifconfig tnc0 10.0.0.2 pointopoint 10.0.0.1
In the next example, we'll setup a network that can support many devices communicating with each other on the same channel, using ethernet, which is suprisingly much simpler than point-to-point links.
One to Many, Many to One
Let's assume that we have 10 TNC devices, all connected to the same radio channel, and we want everyone to be able to talk to everyone else. Setting up point-to-point links between everyone will get tedious very fast, so let's use something else: Ethernet.
Setting up ethernet devices with tncattach is a surprisingly simple one-liner. Assuming we are still using OpenModems, and considering the MTU calculations from above, we can bring up an interface and configure it with the following command:
sudo tncattach /dev/ttyUSB0 115200 -d -e --noipv6 --mtu 554 --ipv4 10.91.0.1/24
The interface will now be created, have an IPv4 address configured and brought up. In this case we use the -e switch to specify we want a full ethernet device, not just a point-to-point link. We also use the --ipv4 switch to specify what IPv4 address the interface should be assigned. Please that you must supply addresses complete with a subnet mask in CIDR notation for the --ipv4 switch (hence the /24 at the end).
The interface is now up and running, and ready for use:
ifconfig
tnc0: flags=611<UP,BROADCAST,NOTRAILERS,RUNNING,ALLMULTI> mtu 554
inet 10.91.0.1 netmask 255.255.255.0 broadcast 10.91.0.255
ether 62:2a:60:89:a2:3a txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Repeat the same command on any other hosts, replacing the IP address with a unique address in the same subnet for every system, and every system can now talk to everyone else.
Since this is ethernet, you could easily set up a DHCP server on one system, and have that assign IP-addresses, instead of manually specifying them on each system. Or do anything you would normally be able to, really.
Notes on MTU
The MTU that is set with tncattach is the MTU for the kernel networking interface. That is, it is the MTU for the interface you see when you type for example "ifconfig tnc0". The MTU value set here tells the kernel how many bytes of payload data can be squeezed into a single physical-layer packet.
This value should not be set to the direct physical layer MTU of the TNC device! For example, even though OpenModem supports an MTU of 576 bytes, and RNode supports an MTU of 500 bytes, you need to take into account the overhead of any link-layer protocol that is transported with tncattach.
In practical terms, this means that if you just want to use point-to-point IP links with tncattach, the overhead will be 4 bytes. For full ethernet, the overhead will usually be 18 bytes, but if you also need to support 802.11q VLAN tags, it will be 22 bytes. You need to subtract this overhead from the device MTU and pass that value to tncattach.
For OpenModem, correct MTU values to use with tncattach would be 572, 558 and 554 respectively, for point-to-point IP links, Ethernet and Ethernet with VLAN tags.
For RNode, correct MTU values to use with tncattach would be 496, 482 and 478 respectively, for point-to-point IP links, Ethernet and Ethernet with VLAN tags.
Mark,
This is fantastic! I have been fooling around with this kissattach for some time and never really got anywhere. I am anxious to try tncattach.
Could you elaborate on how to use this with either Kantronics kpc3, or MFJ 1270 TNCs?
I can get them into kissmode, but am not sure if the mtu is preset. If the mtu is preset, then it sounds like I have to configure tncattach for the preset rate minus the 4 and 22 byte overheads…?
Thanks for a very interesting motivator in ham radio!
B
Hi Bruce,
If you can get the KPC3 into KISS mode you should more or less be good to go. I couldn’t find any documentation on what the maximum packet size it supports is, but the default that tncattach uses is relatively low, so maybe you don’t even have to specify it. I can’t remember what the default serial port speed of the KPC3 is, but lets assume it’s 9600 baud, and that it’s connected to a serial port called /dev/ttyUSB0. In that case, you could use the following command to get it up and running:
sudo tncattach /dev/ttyUSB0 9600 –ethernet –noipv6 –ipv4 192.168.1.10/24
That would bring up the tnc0 interface, disable ipv6 and set an ipv4 address for you. It should also set the MTU to 329 by default. If you find that it doesn’t work when sending large packets, you can try lowering the MTU to 250 for example:
sudo tncattach /dev/ttyUSB0 9600 –ethernet –noipv6 –ipv4 192.168.1.10/24 –mtu 250
It’s more or less the same procedure with the MFJ TNCs, as long as it’s in KISS mode and you know the right port and serial baud rate, it should more or less just work. Only caveat is you might have to adjust the MTU.
Unfortunately I couldn’t find anything in either the Kantronics or MFJ manuals specifying what their MTU actually is! It should be pretty safe to assume that they can support at least around 330 though, since that’s the minimum size required for full AX.25 support.
Where I can buy ready device?
simple plug to usb (program to change firmware, setup language, parameter etc) and working
In my opinion You must decide network similar Matrix or protocol mastodon
Hi there
I have two different devices for sale myself, RNode and OpenModem, you can take a look at them here on the page. Regarding software, I am working on a protocol called Reticulum, you might be interested in checking it out.
Thanks Mark,
Here is what I discovered so far….
I am using a RPi 3b+ with a ftdi USB to rs232 adapter cable going into a Kantronics kpc3, and out to an old Kenwood vhf radio.
I have had the setup working , both with the pUTTY/Kantronics interface, and set in kissmode using kissattach/axcall/axlisten. I
even have had a limited success sending pings between two pi/Kantronics tnc/radio setups.
So here are some of the foibles of using a set up like this,
A kpc3 tnc will not accept programming or queries after it is kissmode if one is using an ftdi converter cable because the converter chip doesn’t seem to be able to make the correct character, to change INTFACE back to COMMAND, or NEWUSER. The result is that, one must program all the parameters into the tnc before changing INTFACE to KISSMODE. Or do a hard reset.
Also because of the converter chip, there is no backspace key when in command mode, or while typing messages in the qso mode.
Finally, the kpc3 sometimes locks up or jams when sending ip/tcp packets in kissmode (requiring a hard reset to become usuable again).
Why write all this? Because, I have been trying this for some years now, and understand this can be a compound set of problems to over come.
Mark, I followed your instructions and went to the github site. I first, simply downloaded the binaries for RPi, but failed to get anything to happen. Next, I followed your instructions and compiled the program, and it worked immediately. I don’t know what I forgot to do, to use the precompiled binaries, but perhaps you can add some obvious instructions to help the forgetful.
Next, I would tell anyone trying this with an old tnc, to set up the tnc in kissmode first, with pUTTy or whatever command line editor, because once I initiated tncattach, I could no longer communicate with the tnc.
Also, is “control Z” the correct command to stop tncattach?
I used the tncattach parameters given in the example, for the openmodem. The internal baud rate was too fast, I believe, and so there was no communication between the RPi and the tnc. No problem, when I go try again, I will use 9600 as my internal baud rate, like you have directed.
So, let’s imagine, I configure everything correctly, and the tnc hears, and responds to tncattach. Let’s say I try point to point. In the example for an old tnc, you wrote the address 192.168.1.10/24. I assume that’s just a random static address for the example. So the other point could be 192.168.1.12/24. If this is right, then a fair test might be to ping each point from the other, or run nmap 192.168.1.1-20?
I want to get this far with my understanding before I commit to buying a pair of open modems.
One thing I want to discover is what happens to file transfers @9600 baud. Is there a time out problem because the baudrate is so slow? I want start by simply transferring an image captured from the pi camera (nothing hi-resolution).
Anyhow, thanks for doing this good work!
A labor of love.
Bruce
Thanks for writing up all of this Bruce. That’s some invaluable information for anyone else attempting to do it with a similar setup.
If you use Ctrl-Z, tncattach will just be suspended into the background, so to exit it, you should use Ctrl-C. That will tell tncattach to shut down nicely and release the serial port and network interface. You can also give the “-d” option to tncattach, which will make it a daemon process. This means that if it starts up successfully, it will go into the background but continue running. In this case, you won’t be able to exit it with Ctrl-C, you will have to use something like “killall tncattach”.
And you are right regarding IP-addresses, they are just random addresses I choose (that are within the same subnet). So anything should do, as long as they are in the same subnet, they will be able to communicate. You can of course get fancy with DHCP servers and routes and such, but for the sake of this, keeping it simple is probably easier.
The baud-rate specified to the tncattach command is the serial baudrate from the computer to the modem (and vice versa) only, so it will not affect on-air bitrate. But it must match what the modem expects (some TNCs can autodetect it, but most require a set rate, 9600 or 115200 for example).
I’ve successfully transferred files over FTP with OpenModem. It’s of course slow, but very functional and useful. Since FTP uses TCP and IP, the TCP layer will automatically adjust to the link characteristics, and you can actually reliably transfer even relatively large files, as long as you have the time to wait for it. So small low-res pictures should be perfectly doable.
I hope these comments clarified it even more.
Kind regards,
Mark
Also, I forgot to ask you, could it be that you downloaded the “amd64” zip file instead of the “armhf” zip file? For Raspberry Pi, you need the “armhf” one. If you did indeed get that one, could you please let me know what the output of the following command is:
cat /etc/os-release
That will help me figure out why it isn’t running 🙂
@Mark, is tncattach work with MicroModemGP firmware and MicroModem hardware ?
It will work, but probably not too well, since the limited RAM of the atmega328p means there is not much room for packet buffering. For this kind of stuff, the best option is really to use the OpenModem platform instead.
I remember long time ago i test with kissattach and two USB with 433Mhz (point to point)
https://quadmeup.com/wp-content/uploads/2016/04/HC-12-433MHz-wireless-module.jpg
I have success but normally very slow connection. First test was google.com and was worked. And there is where i stop 🙂
I have original MicroModem rev2.3 and i will build other just to make test with my radio.
Im not sure is it easy possible tncattach to work with OSX also.
It’s funny, because it was my original intention for tncattach to work on both Linux and OSX. In fact I wrote the first part of the program on OSX. And most of the code is actually compatible with OSX. But when I found out how badly documented the network interface control calls are in the OSX kernel, I decided to only make it for Linux for now.
I think it’s probably still possible to make it work on OSX, but I will need a few days of poking around at the kernel to figure out how all the undocumented stuff works 😉
Also, regarding the modems, even though there is a small packet buffer in the atmega328p modems, I did implement a “flow control” feature in the latest versions of the firmware. After receiving a packet over the serial port, the modem will send a READY command back, if it has room for another packet in the buffer. If the host does not get a READY, it should wait sending more packets to the modem until it receives a READY. Using this feature, the packet buffering can be moved to the host instead of the modem, and the ram limitation is no problem then. This method is not supported in tncattach yet, but could be implemented in the future.
Mark,
I cannot find the forums. I think it might be a good idea to move this to the forum. I know we need some “buzz” to get people interested in doing this, (and ultimately, buy an open modem). But, the comments will get pretty long…what ever you wish is fine with me.
I down loaded armf not amd64. I actually only use pi3s for packet…I am off grid and like the low power consumption, whereby I can leave everything on.
I will completely retry loading the software on a different sd card for a different Pi and get some output for you. I have to do my homework too, though, I need to remember how to load binaries and start them.
It’s very important to break the networking down to it’s simplest level, because hams of a certain age are amazingly tech adverse, and we need them to get interested in this.
I am located in grid EN57G and we have a huge legacy packet network, so this new protocol would lend itself well here. Open mesh, or microwave meshnetworking is a fail here because of the terrain. VHF, on the other hand, is very effective.
Thanks for your reply,
B
The forums are here: https://unsigned.io/forum/
There should also be a link up in the menu bar, but I recently redid the website, so it it’s not visible on your computer, let me know and I’ll try to figure out why.
But yeah, totally agree, this is better suited for a forum thread! After you register, your user will be locked (to prevent spam. So many spambots trying to post stuff). Just make a single post in the “Introductions” thread, and your user will be unlocked after a short time.
Yeah, I can imagine microwave links are a bit of a pain up there. I’ve spent 4 years doing microwave links here in Denmark, and even in our flat little land it can be a challenge.
Thanks for the info, I’ll check it out. I probably need to statically link everything for the Raspberry version then, I’ll try and update the binaries soon.
Android phones using Chrome, will not display the menu choices under the “Unsigned io” title.
This is why I could not find the Forum.
I found the forum when I used the browser on my Raspberry Pi.
If one clicks the Chrome menu bar, and chooses “desktop site”, then the forum menu choice is displayed.
KE8DCJ
Ah, so that’s what went wrong! Thank you very much for figuring it out for me. I’ll get that fixed.
I was working on something similar for my own project: https://www.curiouselectron.com/?p=595
Fantastic work Mark! Out of curiosity:
Have you explored using batman-adv with this?
Very cool work on Arrow. I hope you’ll find the time to add a PA and start selling them!
With regards to batman-adv, both no and yes. I haven’t used batman-adv with tncattach, but I do have some prior experience with it. In general I think most of the IP- and ethernet-based meshing protocols are a little on the heavy side for working over slow packet radio links, which was one of the motivations for starting the Reticulum project. If you don’t know about it, it’s a complete networking stack build from the ground up for zero-conf mesh networks over high-latency links with throughput down to around 1000 bits per second. It’s also designed to be very easy to get up and running 🙂
Thanks for complements! I think I made a mistake using the CC1200 and a custom PCB. :/ These SX1276 chips are sweet with their built in PA and LoRa support. I did a bit of digging and while the SX1276 doesn’t have an CFM mode like the the CC1200, I think it would still be possible to TX AFSK by sending a CW and adjusting the carrier, and RX AFSK by reading the AFC register.
Reticulum looks very cool. I’ll be spending some time looking into your code soon!
I tried tncattach during the week. The interface is very clean. I’m having an issue with Arrow receiving packets with it. I’ll have to study it a bit more, but I’m sure the issue is on my side. Transmission works just fine. It’s strange to me because kissattach works just fine?
Hmm, that’s very interesting. If you figure out whats up with it, I’m very interested to hear it. If there’s some issue in tncattach, I’d love to fix it obviously 🙂
Yep, the SX1276 chips are very nice. I’ve been thinking the same, and I’m going to attempt to get them de/modulating AFSK at some point as well. Next major version of the RNode firmware will have support for other modulations than LoRa as well, so it will be even more flexible.
This looks wonderful. Can i check, is there any “listen before transmit” feature as was the case with AX:25 – i.e. it won’t transmit if the frequency is in use? This is a critical license requirement for running data on the 70cms band in the UK.
Yes, but technically it’s not a part of the tncattach program itself. Listen before transmit, or “CDMA” as it’s technically called, is the responsibility of the modem (or other communications hardware). Actually AX.25 didn’t include any CDMA features either in the AX.25 protocol layer, it’s part of the physical layer specification. This is smart, since different physical layer implementations (AFSK and LoRa for example) will need different methods for establishing whether the channel is in use.
All the products I sell (OpenModem and RNode) adhere to the listen-before-transmit requirements, and have configurable CDMA parameters to suit various network types.
So, my slightly pedantic explanations aside, you can rest assured that this solution will not just barge in over other traffic. I can not vouch for all modems ever made, but any modem or TNC really should implement CDMA, and I think all modern ones do.
I also have a short question for understanding. Communication between two RNode devices via Lora is not encrypted unless it is encrypted using a higher protocol like HTTPs or SSH?
As I understand it, there is also no higher access control on the interface and you would have to establish some kind of VPN so that not everyone can participate in the communication?
Thank you
Correct, currently RNodes offer no encryption at the hardware level, although it is coming in the next major firmware version, along with infrastructure and managed modes of operation.
when i try to use tncattach with any arguments (e.g. sudo tncattach /dev/ttyUSB0 115200 -d –noipv6 –noup –mtu 572 ) it tell me this :
Usage: tncattach [OPTION…] port baudrate
Try `tncattach –help’ or `tncattach –usage’ for more information.
like i don’t type any arguments
This should be fixed in tncattach version 0.1.9, you can compile from the GitHub repository, or download binaries here: https://github.com/markqvist/tncattach/releases/tag/0.1.9
Is it possible to connect to a TNC that has a KISS TCP interface such as Direwolf or UZ7HO soundmodem?
Yes, tncattach support KISS over TCP, you just need to use the -T option along with -H and -P for host and port. Have a look in the documentation on GitHub, or via “tncattach –help”.
Thanks for making my dreams come true. Will reach out to IRC channel on 9k6 connection.
Awesome stuff! Have fun 😀
Hi
Greate write up, when will OpenModem be available for sale again ?
Thanks! OpenModem is back in stock now!
Hi! very interesting work ! I’m trying to make tnsattach work with a waveshare lora hat for raspberry that has a usb 2 uart interface but I’m not able to make the two modules see each other. The module I’m using is this
https://www.waveshare.com/sx1262-868m-lora-hat.htm. Am I doing something wrong? the module baud rate is 9600 and I already changed it in the command options. The module is in transmission mode so everything is written / read on uart transmitter / received through LoRa
Hello!
It wont work, unless you can somehow reprogram the hat with a custom firware. The waveshare hat is just a “dumb” bridge that takes unframed serial data and trasmits it. It’s fine for very simple stuff, but too unreliable for more complex stuff like IP. Tncattach needs a device that uses proper KISS framing, like RNode.
time to ditch the whole axports stuff (utterly useless crap considering that mtu, duplex, and speed and callsign are already interface settings). why even have a callsign on the interface, on some silly text file in /etc, AND in the terminal program or bbs. just put the callsigns on the interface or just set them all to nocall. (they are irrelevant to what’s set in the program anyway) make sure all interfaces can have the same callsign if so required. make sure all the tools work -without- having any ipv4 or ipv6 stacks or interfaces on the system (not the case when using sock_dgram for configuring interfaces). after all the least one can expect is for a linux system to run native ax.25 and ax.25 only and nothing else. oh. another thing that needs fixing: self connects. (and ssids, it seems to treat each ssid as a seperate call for some reason) you’ll find that baycom and graphic packet will happily connect to itself locally without even a modem or tnc attached. the linux stack cannot. 😉 linux only does that if you make one of the interfaces loop all packets back to itself but that’s kinda problematic for the rest of the network 😉 it would also seem those arps people kinda broke connect() in that it’ll only do it once for one call-ssid call-ssid pair per reboot (it never times out, properly disconnects, or rejects. it also doesn’t automatically assign the next ssid 😉 at least it did a couple of years ago. it could also do with a somewhat more decent cli terminal program comparable to baycom (not linpac. that’s one big collection of calling external crap over system() and execve().. now why did i get here again. owyeah. was looking if someone already modified kissattach to do kiss-over-tcp (but without the axports crap which we refuse to use or support 😉
Yes, completely agree in regards to ditching all the superfluous axports stuff, that is one of the reasons I wrote tncattach to begin with. The utility uses none of that, it is just a clean way of using Ethernet or IP over KISS-compatible TNCs, so you don’t need anything in /etc, just the command to run the program, which will attach and configure the interface.
But if you want something that deals away with IP completely, you should probably also take a look at Reticulum… You might find it interesting 😉
got connection refused. strace showed it was trying to connect to 0.0.0.0.
you got the memcpy source, destination for address the wrong way around. after that it works.
in TCP.c
memcpy(&serv_addr.sin_addr.s_addr,&server->h_addr,server->h_length);
latest version from github btw.
woops remove the & at the pointer there… server->h_addr already is a pointer. obviously.
Hah, how classy of me. Thanks for pointing it out. I implemented the KISS over TCP mode because of a request from someone else, and when they reported it working, I didn’t think further about that. I’ll make a release with the fix shortly, until then it seems like you will have no problem compiling it yourself 😉
Thanks again
hmm. something still seems odd. lol. it does nicely generate a tnc0 ‘ethernet’ interface. which for once (despite being tap, tap used to only support only 6 bytes out of the 7 byte callsign field – so setting an address on it used to be impossible) note that we use ethernet broadcast, not the dos multicast group for bpq.
19:56:53.002490 e0:86:84:66:a4:9e > 9c:9e:86:82:98:98, ethertype Unknown (0x8461), length 42:
0x0000: 13f0 4342 3352 4f42 2054 4143 5449 4341 ..CB3ROB.TACTICA
0x0010: 4c20 5359 5354 454d 530d 5836 L.SYSTEMS.X6
19:57:16.096165 3a:76:3e:a4:50:01 > ff:ff:ff:ff:ff:ff, ethertype Unknown (0x08ff), length 31:
0x0000: 1400 a486 8486 9a88 e086 8466 a49e 8461 ………..f…a
0x0010: 3f ?
19:57:32.476979 3a:76:3e:a4:50:01 > ff:ff:ff:ff:ff:ff, ethertype Unknown (0x08ff), length 31:
0x0000: 1400 a486 8486 9a88 e086 8466 a49e 8465 ………..f…e
0x0010: 3f ?
ehm… yeah..
Got 42 bytes from TNC, wrote 42 bytes to interface TNC FF FF FF FF FF FF EE 04 47 F0 B5 45 08 FF 14 00 A8 8A A6 A8 64 40 E0 A8 8A A6 A8 64 40 61 3F 00 00 00
pff. this thing is just trying to be to many things to to many people. and as it’s on github -right now- it can’t even connect to a kiss tcp tnc or concentrator as you got the memcopy parameters the wrong way around 😉
now. if tun/tap linux hasn’t been fixed yet there is no need in even trying it. as callsigns + ssid are 7 bytes. and mac addresses are 6 bytes. last time we tried to use TAP for such things it didn’t quite work. (despite their claim of being a ‘universal’ tunnel api it only handles 6 byte addresses correctly 😉 but with -e it does see yours as a normal ethernet interface, as such gives it a bpqX address, and as such gets picked up by our bridging software and -that- part works correctly. just that the data in the frames is not valid bpq
No idea about bpq. This utility was designed for more or less one thing only, attaching a KISS TNC as a generic network interface.
It is not meant to support ax.25 programs.
As far as I remember, bpq uses the native ax.25 support in the kernel. Interfaces created by tncattach are not ax.25 interfaces.