Linpac Activity
Amateur Radio AX.25 chat and PBBS program using Linux's AX.25 stack
Brought to you by:
dranch
Activity for Linpac
-
David Ranch committed [f30b4f] on git
Added various improvements
-
David Ranch posted a comment on ticket #34
It seems either I missed several bugs reports or a whole bunch of issues just were released from limbo. Super sorry about the delay here. alt-x choice came from the original author and hasn't been any issue from anyone else. You can also use ":sys" which is what I personally use. Are you having an explicit conflict with this key sequence?
-
Sven Olaf Kamphuis posted a comment on ticket #33
there appears to be no check on the length of mon_line ;P (no that's not what the '1' in strncat does - that function has no total length limitation ;) so either mon_line itself is overflowed. or printf overflows at not seeing a terminating '0' to the overflowed string ;) windows.h: char mon_line[256]; /Downloads/linpac-0.28/src# less windows.cc if (ev.type == EV_NONE) { if (listpid >= 0) { char buf[512]; int rc = read(list, buf, 512); if (rc > 0) { int i; for (i=0; i < rc; i++) { if (buf[i] == '\r'...
-
Chris posted a comment on ticket #35
Nope -- still fails. Had to do the autoreconf bit too. That was a first for me. Here is the output: g++ -DHAVE_CONFIG_H -I. -I../../.. -g -O2 -MT mail_screen.o -MD -MP -MF .deps/mail_screen.Tpo -c -o mail_screen.o mail_screen.cc mail_screen.cc: In function ‘void init_main_screen()’: mail_screen.cc:39:16: error: invalid use of incomplete type ‘WINDOW’ {aka ‘struct _win_st’} 39 | maxx = stdscr->_maxx; | ^~ In file included from mail_screen.cc:13: /usr/include/curses.h:456:16: note: forward declaration...
-
Hello Chris, where did you get your Linpac source code? From the SourceForge .tar.gz file (master branch), from the Git Master branch, or the Git Develop Branch? Please try the Develop branch from Git at https://sourceforge.net/p/linpac/linpac/ci/develop/tree/ and let us know if that works.
-
Compile Failure Slackware-current
-
David Ranch committed [3ca649] on git
Marked segfault on missing axports file issue as resolved
-
David Ranch committed [ff6871] on git
updated the TXT version from the manual.html file
-
David Ranch committed [793f92] on git
updated the TXT version from the manual.html file
-
David Ranch committed [f4eefb] on git
update the packaging files to reflect the new version
-
David Ranch committed [570509] on git
Update the build details to reflect new build date, it's changes, etc
-
David Ranch committed [5edcba] on git
Changes to manage disruptive ncurses library change to make ncurses internal variables opaque aka not available for external use
-
David Ranch committed [3d6a55] on git
Updated version, copyright date
-
David Ranch committed [a042ee] on git
Updated the info when the axports file isnt found
-
John Wilson posted a comment on discussion LinPac discussion
Thank you David - that's done the trick.
-
Hello John, The files are stored in the "LinPac" directory of the user that started the Linpac process. So, if you were running it as root, look in /root/LinPac. If you want to completed start over as if Linpac was never run, run the command "rm -Rf /root/LinPac" and that directory and all contents will be removed.
-
Sorry for a very non-technical question but I've just installed LinPac on a Raspberry Pi Model B running Raspbian 11 (bullseye). I realised after starting LinPac that I put the wrong parameters in at this point. As a completely non-technical person, can someone tell me where the default parameters are stored and/or what file I can remove/rename in order to re-start LinPac from the beginning again? Thanks for your help.
-
Your newest post has nothing to due with Linpac and is a general Direwolf question. Please post that on the direwolf@groups.io email list and the team can help resolve that issue.
-
Maximo Barawid Jr. posted a comment on discussion LinPac discussion
I thought I have AX.25 stack installed. I edited /etc/ax25/axports; vhfp DU2UXH-2 9600 255 2 VHF Packet 1200 bps I did also run kissattach: $ sudo kissattach /dev/pts/2 vhfp AX.25 port vhfp bound to device ax0 $ sudo kissparms -p radio -t 100 -s 100 -r 25 Running direwolf: $ direwolf -t 0 -p Dire Wolf DEVELOPMENT version 1.7 E (Jun 14 2022) Includes optional support for: hamlib cm108-ptt Reading config file direwolf.conf Audio input device for receive: stdin (channel 0) Audio out device for transmit:...
-
That is correct. For your previous post above stating : "I am using Hamlib for rig control (not sure if I need it but as I said, I followed some instruction on other site), Direwolf as a software TNC, and Linpac. It looks like Direwolf is not used as I don't see any activity when trying to connect to my bbs via the linpac." To use Linpac, you must configure Linux's AX.25 stack for it to function. The setup is radio --> direwolf --> Linux AX.25 stack --> Linpac. If you're looking for a complete setup...
-
I would recommend to join the direwolf@groups.io email list at https://github.com/wb2osz/direwolf where myself and others can better help you and stay on topic. In that post, please mention how your Linux computer is connected to your IC-7100, etc. Thanks David. So.. what you want to do is run: git clone git://git.code.sf.net/p/linpac/linpac linpac cd linpac autoreconf --install ./configure Ok, let me try that. Thanks again.
-
Hello Maximo, You are mixing discussions and your keying issue has nothing to do with LInpac. I would recommend to join the direwolf@groups.io email list at https://github.com/wb2osz/direwolf where myself and others can better help you and stay on topic. In that post, please mention how your Linux computer is connected to your IC-7100, etc. --David
-
It's looking like the README needs a cleanup as it's giving some misleading detail. The issue you're seeing here is that you're in the "~/Downloads/linuxax25" directory used for the AX25 stuff but then you're trying to follow the Linpac compilation instructions. They are very different things! The missing line is it was assumed you already have the Linpac sources and you're in that directory. That makes sense if you're reading the README from within the downloaded Linpac source directory but not...
-
Update: Looks like I got the linpac installed and working. How did I do it? Well, I followed different sites on installing linpac on raspberry pi until I got what I need to install BEFORE compiling linpac 0.29, or even 0.28. Having said that, I am still having problems keying my IC-7100. I am using Hamlib for rig control (not sure if I need it but as I said, I followed some instruction on other site), Direwolf as a software TNC, and Linpac. It looks like Direwolf is not used as I don't see any activity...
-
Ok, I think I am getting there. It's trial and error process. So bear with me. Trying to learn. Max
-
Ok. I have read the README many times and, I did the following: pi@linpac:~$ git clone https://github.com/ve7fet/linuxax25.git. Then, pi@linpac:~/Downloads $ sudo apt install libax25 ax25-apps libncurses5-dev perl That went ok. Then, install of automake autoconf - done. Then, sudo apt-get install libtool libtoolize autoreconf --install pi@linpac:~/Downloads/linuxax25 $ autoreconf --install autoreconf: 'configure.ac' or 'configure.in' is required Question, am I installing only dependencies? Where...
-
Right.. per the README, you need to install the following other packages: libax25 ax25-apps libncurses5-dev perl I think I should also delete the INSTALL file as it's not very helpful here. --David
-
Hi. Thank you for the reply. It's past 9PM here and I will try it tomorrow and update you. Max
-
Jeb Baker posted a comment on discussion LinPac discussion
Howdy. I recently loaded this on a Raspberry Pi 4B. Ran into the same problem. Hit this link and read this install guide. It will tell you what Ncurses Library you need. https://sourceforge.net/p/linpac/linpac/ci/develop/tree/README Jeb
-
I am running Buster on a Raspberry pi 3B and trying to install linpac-0.28. Here is where it stops after ./configure. pi@bagiw:~/Downloads/linpac-0.28 $ ./configure checking build system type... armv7l-unknown-linux-gnueabi checking host system type... armv7l-unknown-linux-gnueabi checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking...
-
Hello Neil, There is the following Linpac bug report at https://sourceforge.net/p/linpac/bugs/31/ where I did some analysis and found one work around using YAPP but it's not perfect. That said, I would be great if both methods could be analyzed and fixed.
-
Neil posted a comment on discussion LinPac discussion
Hello all. I have a pair of LinPac instances that are communicating across the house to each other. I can send text, and it works perfectly. From what I can tell from reading the LinPac manual, to use YAPP to send a file through LinPac, I only need to use the yput command with a file. The peer will start downloading automatically. For example, my first test case is sending LinPac's manual.txt from my home directory. From a connected channel I type :yput /home/neil/manual.txt or :yput manual.txt and...
-
David Ranch committed [57ec2b]
Updated the Changelog based upon recent Git commit comments
-
David Ranch committed [7b4166]
new development version
-
David Ranch committed [a0ee36]
Updated version, copyright date, other contributors
-
Fix spelling errors
-
Fix segfault if /etc/ax25/axports not configured
-
Draft: build on docker
-
David Ranch committed [be1770]
Merge commit 'd838e60a576589a3808702cbafda9cf843cebbbc' into develop
-
David Ranch committed [3e58c9]
Fix segfault if /etc/ax25/axports not configured
-
David Ranch committed [1dd00b]
Merge commit 'f9f9bd831aedbecbb167b61495bfdce3e3668dad' into develop
-
dforsi created merge request #18
Fix spelling errors
-
BJnsn posted a comment on discussion LinPac discussion
Ahaaa wasn't that. I went through my whole file system and pulled all linpac stuff out, then reinstalled everything. This time I got a SELinux Alerts notification as soon as a connection attempt happened. Don't know how I missed the previous ones. Guessing all audio was pipped to RigBlaster and didn't hear it. It was nice of them to suggest the following because it worked. ***** Plugin catchall (2.93 confidence) suggests ************************** If you believe that linpac should be allowed read...
-
It sounds like you haven't configured Linpac to answer incoming connections. In the LinPac/macro/init.mac file under the ";; Callsign setup" area, what do you have? You need at LEAST one entry there such as "mycall@1 KI6ZHD". Also, what version of Linpac are you running. It's recommended to be running at least 0.28. --David
-
I spent a few hours digging in manuals with Ctl-F and google looking for why linpac will auto disconnect an attempt from another station connecting in. I noticed it once after I got up and running on HF. RK station, got kicked right way. Thought it was weird, but OK. Next I setup 2 VHF stations for playing and learning. One KPC3+ and one Direwolf Linpac. I can connect to the KPC3+, but get booted any time I try a connect with the linpac side. Any advice would be appreciated. BJ
-
according to the manpage on pipe() pipe's buffer size can simply be set to PIPE_BUF (mon_line=PIPE_BUF;) (#include<limits.h> as there appear to be 2 diffent ones one for posix (512) and one for gnu (4096) and then, at least with with O_DIRECT it'll never fail on that bit ;)</limits.h> Writes of greater than PIPE_BUF bytes (see pipe(7)) will be split into multiple packets. The constant PIPE_BUF is defined in <limits.h>.</limits.h> * If a read(2) specifies a buffer size that is smaller than the next...
-
works fine after changing mon_line to 512 in src/windows.h ... could be a bit overkill... the way it is done highly depends on pre-existing termios settings etc anyway. (as in if it even is one line of text at a time that gets read() in the first place ) think that whole part could well do with a rewrite... for one thing... instead of pipe dup2 exec ( axlisten )
-
axlisten seems to write() it actually line by line. (not just one write() with a lot of \n's in it ;) but how many bytes you get from a read() on a redirected terminal depends on the termios settings of that terminal. and is not per-se one line at a time... (especially not since it is also in non blocking mode ;) anyway the problem is in that strncat(bla,mon_line,1) bit which doesn't check the length of mon_line at all. just that it appends one byte at a time to it. ;) also the newlines, carriage...
-
axlisten seems to write() it actually line by line. (not just one write() with a lot of \n's in it ;) but how many bytes you get from a read() on a redirected terminal depends on the termios settings of that terminal. and is not per-se one line at a time... anyway the problem is in that strncat(bla,mon_line,1) bit which doesn't check the length of mon_line at all. just that it appends one byte at a time to it. ;)
-
works fine after changing mon_line to 512 in src/windows.h ... could be a bit overkill... the way it is done highly depends on pre-existing termios settings etc anyway. (as in if it even is one line of text at a time that gets read() in the first place ) think that whole part could well do with a rewrite... for one thing... instead of pipe dup2 exec ( axlisten ) (there is popen for that? , also it seems to dup both STDOUT_FILENO and STDERR_FILENO to the same filedescriptor ;) or actually just STDERR...
-
with axlisten broken on the box i tried to update that axlibrary stuff on at least it no longer crashes ;) no monitor tho. not that a monitor is needed per-se on a multi user multi tasking os... if they want axlisten they can just run one in another terminal.
-
with axlisten broken on the box i tried to update that axlibrary stuff on at least it no longer crashes ;) no monitor tho. not that a monitor is needed per-se on a multi user multi tasking os... if they want axlisten they can just run one in another terminal.
-
(and yes it is quite common for the linux ax.25 stack to receive and clearly also acknowledge a shitload of packets by itself before passing them onto recv() ;) thats why nothing is shown above. ;P funny part is. if your server closes() immediately afterwards they'll never get processed at all ;) you never notice that at 1200 baud ;) you do at 1000mbit/s or more ;) but then again gp isn't exactly 'real time multitasking' either ;) connect, server sends a shitload of packets, then it suddenly goes...
-
(and yes it is quite common for the linux ax.25 stack to receive and clearly also acknowledge a shitload of packets by itself before passing them onto recv() ;) thats why nothing is shown above. ;P funny part is. if your server closes() immediately afterwards they'll never get processed at all ;) you never notice that at 1200 baud ;) you do at 1000mbit/s or more ;)
-
it occurs at exactly 256 bytes. and yes in that silly old axports file it is also set to 256 (not 255). it doesn't -have- to be one of linpac's own connections. just 'seeing 2 other hosts do it on the network' in the monitor suffices. (so it's not related to linpac's own mtu). think it's purely in the parsing of the output of axlisten and displaying it. axlisten itself by itself works fine.
-
i'll just code an increment counter on it just sending packets until it crashes... should be able to see the last one it passed before the coredump ;)
-
Have you tried lowering your Linux /etc/ax25/axports MTU to a level that Linpac doesn't have an issue with? Yes.. Linpac should deal with with it but knowing the limit would be useful
-
can just test it yourself... kiss-tcp server at 208.109.9.123:8001 ... connect to 'MUTINY'.. it'll give a few short lines and then move on to transferring a huge blob of text 20 times in a row. it crashes on the first packet of that. source code for both the mutiny node as a kissattach for tcp here: https://github.com/cb3rob/CB3ROB-AX25-TOOLS-LINUX
-
so far for the attempt to just install that by running the ./ax25upd thing in his repository ;) (ubuntu 16 lts with all 'dev' stuff installed ;) - nope ldconfig didn't fix axlisten either ;) anyway. don't quite see the point in using that old ax25lib stuff -at all-... getifaddrs() will happily return all ax_25 interfaces AND their mtu's (which seriously should be 256 anyway, most definately not 255 such as in the default axports file ;)... SOCK_PACKET will happily give you a monitor (it needs to...
-
Thank you for the report. Few ideas here. 1) Have you tried VE7FET's ax25 repo ( https://github.com/ve7fet/linuxax25 ) or possibly a newer version of listen from the official ax25 sources maintained at DL5RB ( https://www.linux-ax25.org/wiki/Main_Page ) . Both repos have lots of fixes compared to the old versions pre-packaged by various distros. If the issue is really in listen itself, the fix needs to be reported to say DL5RB and/or VE7FET so a fix can be mainlined. As a work around, maybe try lowering...
-
also happens on ubuntu 18 LTS desktop with it's axlisten... looks like linpac takes the output of axlisten and 'does stuff to it' (ansi color?) causing it somehow. pretty sure the axlisten of ubuntu is fairly old. linpac itself was packaged at 0.24 or so (yes it is 0.28 now ;).., still. should not happen. ;)
-
the whole thing works fine until that first long packet out of a lot... it connects it talks it does everything... but then poof ;) even worse after it dies the termios settings are still set to \r so you have to type 'reset' to the terminal blindly AND remove that silly good-for-nothing lockfile ;) (but guess that just comes with a core dump ;)
-
note that the bufferoverflow actually seems to be caused by axlisten. which works fine when run on its own outside of linpac (ubuntu 16 lts)... as linpac also bufferoverflows on line 181 of /usr/bin/linpac when its not even receiving the 'long' (for 1960s standards, maybe) packets not terminated by \r itself. it just hears another station doing so (or rather, axlisten does so ;)
-
program exit method userinterface
-
bufferoverflow upon receive at mtu 256
-
bufferoverflow upon receive at mtu 256
-
David Ranch committed [5567a6]
Added two issues around the monitor.screen / window[1-8].screen files size not getting managed properly
-
David Ranch committed [59aa22]
Added a new bug around the listen area and line wraps
-
David Ranch committed [6213aa]
Added new possible mail bug
-
The autobin protocol seems to have some deeper issues with the client and also the server is doing some form of file truncation that also needs investigation. YAPP transfers seem to work 100% but in an "alternating" way. Please try again on your setup as it should work: YAPP protocol 1. The requesting client will request a file using the command: //yput services-1k.txt-test4 The server will respond with what seems a binary string that's displayed on the client as the string "EA" in inverted colored...
-
Unable to create deb on debian 10 amd64 (2)
-
Sound for connected/disconnected/bell alsa support!
-
Other known issues and enhancements tracked in the linpac-todo.txt file
-
I've had a working solution for native sound support in Linpac using external scripts for some time but have been lax in committing it. My solution allows users to use their own desired sound player (default is aplay) and also even use their own sound clips for connect, disconnect, KNAX, etc. I hope to commit this soon.
-
New personnal mail alert
-
Please see some of the included scripts in the contrib/ directory of how to get notifications of new packet messages, etc.
-
Other known issues and enhancements tracked in the linpac-todo.txt file
-
Unable to create deb on debian 10 amd64
-
Added missing debian packaging file in commit e52d8a1229529f30fbd1adc234dfefbf40a3beef
-
Fixed with help from KD6YAM via commit 5fdb023ca4611789fa1d758a150774be65c2d693
-
Compiling on i386 Debian Stable 2020-12-25
-
Language selection bug
-
High cpu load due to spinwaiting
-
KD6YAM resolved much of this issue on Fri Dec 8 19:54:24 2017 -0800 with commit d438590045da6b5aa15b3ac133b3631114533f28
-
David Ranch committed [d494c5]
typo fixes
-
David Ranch committed [4a2104]
Added the mention of send and receive directories for Linpac file transfer. Added mention that the 7plus program is EXTERNAL to Linpac
-
David Ranch committed [6c9d11]
A little more clarity around file transfers
-
David Ranch committed [72ce72]
More clarity around file send and receive paths, how to use YAPP, etc
-
Vladislav M Fomitchev posted a comment on ticket #31
David, Very interesting findings, thanks for doing this. It's interesting to me that you seem to have been able to transfer a file at all with YAPP. I have never been able to get it to transfer a file no matter how many times I requested or tried to send it. Your Auto in results however, exactly mirror mine. In any case, as before, I've never been able to transfer a file with linpac. Save for text maybe. As for the user permission issue, it could be a problem. I've given up running linpac as a regular...
-
I've done some testing and while things work (with issues), I'm seeing some strange behaviors: Plain text transfer: If I issue the command: //read services-1k.txt-test4 I am only getting the last 2.5 lines from the end of the source file. I've seen something similar to this when issuing the //mheard command to the remote Linpac station. There seems to be some sort of a buffering issue but it's rather rare and I think it might be due to larger amounts of data coming in at a fast rate. This needs more...
-
I had to work (day job) over the weekend but I did make some progress here. I hope to troubleshoot this during the week.
-
Any luck or findings? I appreciate your time on this. I imagine I could be doing something wrong, but I'm not sure what.
-
I will try to reproduce your issue this weekend and report back what I find.
-
Unable to Transfer Files With Autobin or YAPP
-
David Ranch committed [352008]
improved stale lock detection
-
Michael Nadler created merge request #17
Fix segfault if /etc/ax25/axports not configured
-
Claude M posted a comment on ticket #29
Thanks David for your nice works Le dim. 7 févr. 2021 à 19:05, David Ranch dranch@users.sourceforge.net a écrit : I have added a debian/rules file to the "develop" branch but I would like to add the new sound support into Linpac before releasing 0.29. [bugs:#29] https://sourceforge.net/p/linpac/bugs/29/ Unable to create deb on debian 10 amd64* Status: open Group: Created: Tue Feb 02, 2021 04:26 PM UTC by Claude M Last Updated: Tue Feb 02, 2021 09:07 PM UTC Owner: nobody Try to create debian package...
-
I have added a debian/rules file to the "develop" branch but I would like to add the new sound support into Linpac before releasing 0.29.
-
David Ranch committed [725149]
adding basic man page
-
David Ranch committed [bc5e5e]
updated changelog for debian packaging
1 >