Activity for Sven Olaf Kamphuis
-
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'...
-
-
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 ;)
-
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...
-
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
1