Re: Is AX.25 UI frame destination address case-sensitive?
On Sun, Jan 20, 2019 at 08:22:32AM -0800, Martin Cooper wrote: > Hi Stuart, > > > A silly question, is the destination address in a UI frame case-sensitive? > > From the AX.25 2.2 spec, section 2.2.13, Address-Field Encoding: > > "Except for the Secondary Station Identifier (SSID), the address field > should be made up of upper-case alpha and numeric ASCII characters > only." And: The HDLC address field is extended beyond one octet by assigning the least-significant bit of each octet to be an "extension bit". The extension bit of each octet is set to zero, to indicate the next octet contains more address information, or one, to indicate this is the last octet of the HDLC address field. To make room for this extension bit, the amateur Radio call sign information is shifted one bit left. https://tapr.org/pub_ax25.html => Even if you try to use lowercase characters (what will break supposely every existing packet-radio-software), due to the left shift, you won't be able to encode letters p-z. > > 1. Using the reserved bits. There's two bits in the last octet of each > >SSID, which are normally set to '1'. I could use one of those to > >indicate this is a "unicast" address; setting that to 0 would mean > >the message is being "multicasted" or "broadcasted". > > I'll note that the AX.25 'listen' source code uses these two bits in > decoding. One is used to identify "EAX25" and the other "DAMA". It > might be worth looking into what those are all about before reusing > either or both of these bits. Btw, Destination QST-0 (and in many implementations NODES-0 (for netrom protocol) is defined as multicast address. vy 73, - Thomas dl9sau
Re: [PATCH v2] ax25-tools: mheard
Thank you for your comment. > my i asc why you use strcpy/ctime in the first place ? It's old code, written abt 20-25 years ago. > strftime(lh, sizeof(lh),"%Y-%m-%d %H:%M:%S",tm); Yes, it's nicer than "Thu Jul 14 19:08:49 2016", and more economic to read. I hope such a change would not break any script users may have written during the last decades. vy 73, - Thomas dl9sau -- To unsubscribe from this list: send the line "unsubscribe linux-hams" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ax25-tools: mheard
Hello,
On Sun, Jul 17, 2016 at 04:53:13PM +0200, Guido Trentalancia wrote:
> The following patch prevents fatal segmentation faults errors
> on strcpy() in the mheard tool when the result of ctime() is
> zero and it also avoids printing inconsistent log entries.
thank you for your patch.
Never heard about a problem with mheard before.
Please keep in mind to send patches for the git head, not for ancient
versions.
ctime() == NULL: well, the man page is unclear about this. I can't imagine
a case where it could fail (how ever garbled the argument is), because
no second in time_t fails in a time hole, at least in this universe.
But let's look at the sources in glibc:
ctime() is actually asctime(localtime(t)).
There might be a case where localtime returns NULL, and thus asctime_internal()
returns NULL; there's also a check:
if (__builtin_expect (tp->tm_year > INT_MAX - 1900, 0))
{
eoverflow:
__set_errno (EOVERFLOW);
return NULL;
}
Unfortunately, your fix is incomplete.
Perhaps you had a garbled time that triggered one of those two conditions.
But I have another one. It was fun testing:
time_t t = 36028797018963968; /* this is 2**55) ! */
-> Sun Jun 13 07:26:08 1141709097
We are save for the next tons of years.
time_t t = 72057594037927936; /* 2**56 */
Segmentation fault
the segmentation fault is caused by ctime(&f), not by the later printf (!).
=> Linux is capable of 64 bit times (time_t), but glibc's ctime() has a problem.
Anyone likes to do a bugfix in the next milliards of years? ;)
We have proved ctime() works up to 2**56.
We could check for < 2**33 (year 2242):
if (pr->entry.last_heard < 0 || pr->entry.last_heard > 2**33-1)
return;
This should give us 200 years time to observe how glibc is evolving.
In this range, ctime() should always print a correct, non-NULL datestamp.
Apart from this, length of time.ctime(2**55) is 31 (30 + (\0)).
But we have a defined char lh[30]; strcpy(lh, ctime(&pr->entry.last_heard));
As we can see, there's also a buffer overflow issue if we had a garbled time.
Year 585672138 (2**34) is safe. My proposed limit prevents this buffer overflow.
But I suggest to also enlarge lh to 33 for being save for regressions.
ax25_ntoa() always returns a pointer to its internal static char buf,
thus never returns NULL (see libax25/axutils.c). -> No check needed.
the check if (!pkt_count):
well, this leads to a false positive every 4294967296's packet.
If it helps preventing errornous output on garbled mheard data, well, ok,
we can go this way.
Another thing:
libax25/netax25/mheard.h struct mheard_struct defines:
unsigned int count;
unsigned int sframes;
unsigned int uframes;
unsigned int iframes;
unsigned int ndigis;
=> I'd prefer to change printf's %d to %u.
vy 73,
- Thomas dl9sau
> Signed-off-by: Guido Trentalancia
> ---
> ax25/mheard.c | 39 ---
> 1 file changed, 32 insertions(+), 7 deletions(-)
>
> --- ax25-tools-0.0.10-rc2-orig/ax25/mheard.c 2016-07-17 16:15:14.810986323
> +0200
> +++ ax25-tools-0.0.10-rc2/ax25/mheard.c 2016-07-17 16:14:15.332363054
> +0200
> @@ -57,27 +57,39 @@ static void PrintHeader(int data)
>
> static void PrintPortEntry(struct PortRecord *pr, int data)
> {
> - char lh[30], fh[30], *call, *s;
> + char lh[30], fh[30], *call, *s, *ctime_out;
> char buffer[80];
> - int i;
> + int i, pkt_count;
>
> switch (data) {
> case 0:
> - strcpy(lh, ctime(&pr->entry.last_heard));
> + ctime_out = ctime(&pr->entry.last_heard);
> + if (!ctime_out)
> + break;
> + strcpy(lh, ctime_out);
> lh[19] = 0;
> call = ax25_ntoa(&pr->entry.from_call);
> + if (!call)
> + break;
> if ((s = strstr(call, "-0")) != NULL)
> *s = '\0';
> + pkt_count = pr->entry.count;
> + if (!pkt_count)
> + break;
> printf("%-10s %-5s %5d %s\n",
> - call, pr->entry.portname, pr->entry.count, lh);
> + call, pr->entry.portname, pkt_count, lh);
> break;
> case 1:
> buffer[0] = '\0';
> call = ax25_ntoa(&pr->entry.from_call);
> + if (!call)
> + break;
> if ((s = strstr(call, "-0")) != NULL)
> *s = '\0';
> strcat(buffer, call);
> call = ax25_ntoa(&pr->entry.to_call);
> + if (!call)
> + break;
> if ((s = strstr(call, "-0")) != NULL)
>
Re: PATCH 1/1] AX.25: Close socket connection on session completion
> > socket. Symptom occurs in kernels >= 4.2.0 [..] > What changed in 4.2.x that broke this? 3.x'er kernel had also this problem; but there it happens rarely. vy 73, - Thomas dl9sau -- To unsubscribe from this list: send the line "unsubscribe linux-hams" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can only connect to RMS gateway once
> Am 03.06.2016 um 02:01 schrieb David Ranch : > > > Hey Basil, > > Good to hear from you.. hope all is well. > > Yes.. it's been reported and Thomas verified it but I haven't heard of any > fixes yet ( I did send out a prod last month but no response) In another thread (Message-Id: <56fad2ca.5060...@trinnet.net> you answered my question, that those machines are running with an smp-kernel. Have you tried to disable smp (in grub, boot the kernel with the cmdline option nosmp)? Did then the problem still occur? Those bugs are very hard to trace, because you cannot really provoke them; they occur suddenly. With kernel ax25 on smp machines I have discovered other severe bugs (ax25 data corruption), that also needs to be fixed. Imho, our greatest problem is that there too few kernel ax25 developers around in our ham community. In the meantime, I encourage to disable SMP to minimize the problems with kernel ax25. Also look at my posting Message-Id: <20160215140035.gf24...@x-berg.in-berlin.de> from 2016-02-15. There was no response on the list, and nothing got into the kernel (as far as I can see - my approach is to look at https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable/+/master/drivers/net/hamradio ; perhaps I'm wrong with that ). And on 2016-02-17 I asked for submitting my patch to mkiss.c that fixes a race condition that leads to kernel panic (): when the kernel ax25 stack sends data to the interface right after you plugged off your usb-serial-adapter. It took me hours to discover, test and submit that, but nothing happens. (David, it was in my mail to you with Message-Id: <9e57f6d5-9bfc-4c64-b2e4-7c332c502...@osterried.de> ) Thus, those problems are discussed here year after year, again and again, and periodically people spend time to develop fixes others have already done (but never made it into the mainline kernel). I'm very frustrated in that, and in a review of my past efforts I simply have to say now "sorry, I cannot help". vy 73, - Thomas dl9sau > --David > KI6ZHD > > > > Forwarded Message > Subject: Re: AX.25 / ax25d socket close issue on Ubuntu 14.04 but not on > 12.04 > Date: Tue, 29 Mar 2016 09:00:37 +0200 > From: Thomas Osterried > To: David Ranch > CC: Ralf Bächle DL5RB , Bernard, f6bvp > > > >> Am 28.03.2016 um 22:21 schrieb David Ranch : >> >> Hey Ralf, Thomas, Bernard, >> >> I've been helping a user here who is running the LinuxRMS gateway on his >> Ubuntu 14.04 machine and when the remote station terminates the session, it >> leaves an AX.25 session on his computer *forever*.. never times out: >> >> Active AX.25 sockets >> Dest Source Device StateVr/VsSend-Q Recv-Q >> WA7FPV-0 WA7FPV-10 ax0 LISTENING001/003 0 0 >> >> He built up an Ubuntu 12.04 machine with the same LinuxRMS/ax25d service and >> this does NOT happen. He then sent me the below strace. Any thoughts on >> where this issue is coming from? > > Hello David, > > just for a quick answer (I'm on journey): it's coming from a kernel bug in > the ax25 part. > You already have Cc'ed Ralf . > If I remember correctly, he spoke some weeks ago also about this issue. > I also know of those problems, which are very rare. > > My question is: does it happen on SMP (multiprocessor-machine)? > > vy 73, > - Thomas dl9sau > >> >> --David >> >> >> >> Forwarded Message >> Subject: Re: AX.25 Help... >> Date:Mon, 28 Mar 2016 12:52:25 -0700 >> From:Josh Gibbs >> To: David Ranch >> >> Confirmed that starting Direwolf on the Ubuntu 14 box with your script made >> no difference. Socket still hangs up. I connected to the rmsgw process with >> strace, and then sent the bye command: >> >> select(5, [0 4], NULL, NULL, NULL) = 1 (in [0]) >> read(0, "b\r", 8192)= 2 >> write(4, "b\r", 2) = 2 >> read(0, 0x8058180, 8192)= -1 EAGAIN (Resource temporarily >> unavailable) >> select(5, [0 4], NULL, NULL, NULL) = 1 (in [4]) >> recv(4, "D", 1, MSG_PEEK|MSG_DONTWAIT) = 1 >> recv(4, "Disconnecting...\r", 8192, 0) = 17 >> write(1, "Disconnecting...\r", 17) = 17 >> recv(4, 0x8058180, 8192, 0) = -1 EAGAIN (Resource temporarily >> unavailable) >> select(5, [0 4], NULL, NULL, NULL) = 1 (in [4]) >> recv(4, "", 1, MSG_PEEK|MSG_DONTWAIT) = 0 >> time(
Re: TAP device & ax25 call
sorry, just overseen forgot to paste the line where I increased the call sign length to 6(+ssid): root@db0fhn:~# ifconfig -a |grep bpq bpq0 Link encap:AMPR AX.25 HWaddr LINUX-1 bpq1 Link encap:AMPR AX.25 HWaddr DB0FHN-10 root@db0fhn:~# axparms -setcall bpq0 TE1ST-15 root@db0fhn:~# ifconfig -a |grep bpq bpq0 Link encap:AMPR AX.25 HWaddr TE1ST-15 bpq1 Link encap:AMPR AX.25 HWaddr DB0FHN-10 root@db0fhn:~# axparms -setcall bpq0 TE1STA-15 root@db0fhn:~# ifconfig -a |grep bpq bpq0 Link encap:AMPR AX.25 HWaddr TE1STA-15 bpq1 Link encap:AMPR AX.25 HWaddr DB0FHN-10 root@db0fhn:~# uname -a Linux db0fhn 3.2.0-4-amd64 #1 SMP Debian 3.2.73-2+deb7u2 x86_64 GNU/Linux On Wed, Jun 01, 2016 at 03:47:29PM +0200, Thomas Osterried wrote: > On Wed, Jun 01, 2016 at 02:31:00PM +0200, Alejandro Santos wrote: > > Hi all, > > > > I've just double checked this and I agree, I'm unable to set the SSID. > > > > Also tried manually with ifconfig and axparms, the SSID is ignored: > > > > em0 is a TAP device. > > > > # axparms -setcall em0 "LU4EXT-15" > > # LANG=C ifconfig em0 > > em0 Link encap:AMPR AX.25 HWaddr LU4EXT > > BROADCAST MULTICAST MTU:256 Metric:1 > > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > > collisions:0 txqueuelen:500 > > RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) > > > > # ifconfig em0 hw ax25 "LU4EXT-15" mtu 256 > > # LANG=C ifconfig em0 > > em0 Link encap:AMPR AX.25 HWaddr LU4EXT > > BROADCAST MULTICAST MTU:256 Metric:1 > > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > > collisions:0 txqueuelen:500 > > RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) > > > > 73 > > Alejandro > > > > > > > > On Tue, May 31, 2016 at 7:58 PM, folkert wrote: > > > Hi, > > > > > > While trying to use tap-devices for ax.25 I noticed some issues. > > > Biggest issue being that I could not get it to work. Now some guy on > > > stackoverflow dug a bit further and apparently something goes wrong > > > with the ssid. > > > http://stackoverflow.com/questions/22465138/creating-a-tun-network-device-with-ax-25-encapsulation/37534385#37534385 > > > I thought you may wanted to know this. > > > -- > > > To unsubscribe from this list: send the line "unsubscribe linux-hams" in > > > the body of a message to majord...@vger.kernel.org > > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > bpq0 is a tap device: > > root@db0fhn:~# ifconfig -a |grep bpq > bpq0 Link encap:AMPR AX.25 HWaddr LINUX-1 > bpq1 Link encap:AMPR AX.25 HWaddr DB0FHN-10 > root@db0fhn:~# axparms -setcall bpq0 TE1ST-15 > root@db0fhn:~# ifconfig -a |grep bpq > bpq0 Link encap:AMPR AX.25 HWaddr TE1ST-15 > bpq1 Link encap:AMPR AX.25 HWaddr DB0FHN-10 > root@db0fhn:~# ifconfig -a |grep bpq > bpq0 Link encap:AMPR AX.25 HWaddr TE1STA-15 > bpq1 Link encap:AMPR AX.25 HWaddr DB0FHN-10 > root@db0fhn:~# uname -a > Linux db0fhn 3.2.0-4-amd64 #1 SMP Debian 3.2.73-2+deb7u2 x86_64 GNU/Linux > > axparms / libax25: git master at http://git.linux-ax25.org/ > > vy 73, > - Thomas dl9sau > -- To unsubscribe from this list: send the line "unsubscribe linux-hams" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TAP device & ax25 call
On Wed, Jun 01, 2016 at 02:31:00PM +0200, Alejandro Santos wrote: > Hi all, > > I've just double checked this and I agree, I'm unable to set the SSID. > > Also tried manually with ifconfig and axparms, the SSID is ignored: > > em0 is a TAP device. > > # axparms -setcall em0 "LU4EXT-15" > # LANG=C ifconfig em0 > em0 Link encap:AMPR AX.25 HWaddr LU4EXT > BROADCAST MULTICAST MTU:256 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:500 > RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) > > # ifconfig em0 hw ax25 "LU4EXT-15" mtu 256 > # LANG=C ifconfig em0 > em0 Link encap:AMPR AX.25 HWaddr LU4EXT > BROADCAST MULTICAST MTU:256 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:500 > RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) > > 73 > Alejandro > > > > On Tue, May 31, 2016 at 7:58 PM, folkert wrote: > > Hi, > > > > While trying to use tap-devices for ax.25 I noticed some issues. > > Biggest issue being that I could not get it to work. Now some guy on > > stackoverflow dug a bit further and apparently something goes wrong > > with the ssid. > > http://stackoverflow.com/questions/22465138/creating-a-tun-network-device-with-ax-25-encapsulation/37534385#37534385 > > I thought you may wanted to know this. > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-hams" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html bpq0 is a tap device: root@db0fhn:~# ifconfig -a |grep bpq bpq0 Link encap:AMPR AX.25 HWaddr LINUX-1 bpq1 Link encap:AMPR AX.25 HWaddr DB0FHN-10 root@db0fhn:~# axparms -setcall bpq0 TE1ST-15 root@db0fhn:~# ifconfig -a |grep bpq bpq0 Link encap:AMPR AX.25 HWaddr TE1ST-15 bpq1 Link encap:AMPR AX.25 HWaddr DB0FHN-10 root@db0fhn:~# ifconfig -a |grep bpq bpq0 Link encap:AMPR AX.25 HWaddr TE1STA-15 bpq1 Link encap:AMPR AX.25 HWaddr DB0FHN-10 root@db0fhn:~# uname -a Linux db0fhn 3.2.0-4-amd64 #1 SMP Debian 3.2.73-2+deb7u2 x86_64 GNU/Linux axparms / libax25: git master at http://git.linux-ax25.org/ vy 73, - Thomas dl9sau -- To unsubscribe from this list: send the line "unsubscribe linux-hams" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TAP device & ax25 call
Hello, I know of no kernel problems with ax25 over tap. Actually, we use it for years, i.e. with ax25ipd. I also thought you may wanted to know this ;) vy 73, - Thomas dl9sau On Tue, May 31, 2016 at 07:58:02PM +0200, folkert wrote: > Hi, > > While trying to use tap-devices for ax.25 I noticed some issues. > Biggest issue being that I could not get it to work. Now some guy on > stackoverflow dug a bit further and apparently something goes wrong > with the ssid. > http://stackoverflow.com/questions/22465138/creating-a-tun-network-device-with-ax-25-encapsulation/37534385#37534385 > I thought you may wanted to know this. > -- > To unsubscribe from this list: send the line "unsubscribe linux-hams" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-hams" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wrong packet size
On Sat, Feb 27, 2016 at 04:05:14PM +0100, folkert wrote: > > As far as I know, AX.25 MTU is only take care of on transmitting. > > There are no trunked buffer sizes on the rx-routines in the kernel. > > => larger packets, even beyond the ax25 protocol spec (>256 bytes) > > could be handled. > > > > On transmission, the MTU is respected. > > But if you read my last posts on this list, that's not always true (IP): > > I proposed a fix for packets leaving the interface that are much > > larger than the configured MTU or / and the max-mtu of 256. > > For normal PID=text packets, data sent with write() is adjusted to the > > MTU, and data tried to send with syscall sendto() and a size > MTU are > > rejected. > > check > In which kernel is this implemented? What of the things I described? write(): afaik, since ever. segmentation happens (but not as PID=segment as for IP - just a simple split of the data at the length) sendto(): for ax25-I: sendto() with len > MTU fails. for ax25-UI: see my proposal in https://marc.info/?l=linux-hams&m=145554737504304&w=2 section 2.1 > > Btw, in your line: > > > 2311.08432FH4GOU-01 TRDS01-01 AX.25-NoL3 271 Text > > > > => 271 is beyond the standard. You'll might find many old software, > > TNCs, etc. that would even not be capable to decode such a packet. > > Yes, that's how I found it out :-) > > > On the other hand I wonder what packet that was. > > "NoL3" => I assume PID=text (not IP, ARP, etc.). > > It was a conversation between "axcall" and "ax25-node" (or "node"). In > that packet was the result of "M ax0" (or "mheard ax0"). ax25-node was the sender? I'd be glad if you could provide: 1. listen -a -h AND 2. an strace of node ( strace -tt -s 2048 -xx -p PIDofNODE ) ..at the point it gets the command it to send the result of "M ax0". > > Sender is FH4GOU-1 (but that's not a call of one of the two sides in > > your test setup). How does that callsign comes to the line and what > > computer / os / pr-program / userspacesprogram sends this data? > > It should be correct, I checked it moments ago. > > Ok setup: > > - laptop with a tnc and a radio running linux kernel 4.2.1-2 from debian > - raspberry pi with a tnc and a radio running kernel 4.1.18+ (raspbian) > > Both are connected to the TNCs via USB to serial converters. Both TNCs > run the same software. And I assume, raspberry pi is FH4GOU-0 running "node" with call FH4GOU-1 ? And the program connecting with call is your laptop? > The TNCs are arduinos and the radios are LoRa modules connected to them. > https://www.vanheusden.com/radio/arduino-tnc.php We talked about it on Jan, 30 ;) vy 73, - Thomas dl9sau -- To unsubscribe from this list: send the line "unsubscribe linux-hams" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wrong packet size
As far as I know, AX.25 MTU is only take care of on transmitting. There are no trunked buffer sizes on the rx-routines in the kernel. => larger packets, even beyond the ax25 protocol spec (>256 bytes) could be handled. On transmission, the MTU is respected. But if you read my last posts on this list, that's not always true (IP): I proposed a fix for packets leaving the interface that are much larger than the configured MTU or / and the max-mtu of 256. For normal PID=text packets, data sent with write() is adjusted to the MTU, and data tried to send with syscall sendto() and a size > MTU are rejected. Btw, in your line: > 2311.08432FH4GOU-01 TRDS01-01 AX.25-NoL3 271 Text => 271 is beyond the standard. You'll might find many old software, TNCs, etc. that would even not be capable to decode such a packet. On the other hand I wonder what packet that was. "NoL3" => I assume PID=text (not IP, ARP, etc.). Sender is FH4GOU-1 (but that's not a call of one of the two sides in your test setup). How does that callsign comes to the line and what computer / os / pr-program / userspacesprogram sends this data? vy 73, - Thomas dl9sau On Sat, Feb 27, 2016 at 12:42:04AM +0100, folkert wrote: > Hi, > > I have a radio link between two systems. > The maximum packet size in this link is 254 bytes. > On both sides this limit is set: > > root@travelmate:~# uname -r > 4.2.0-1-amd64 > > root@travelmate:~# ifconfig ax0 > ax0 Link encap:AMPR AX.25 HWaddr FH4GOU-1 > UP BROADCAST RUNNING MTU:254 Metric:1 > RX packets:245 errors:0 dropped:0 overruns:0 frame:0 > TX packets:67 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:10 > RX bytes:6492 (6.3 KiB) TX bytes:8810 (8.6 KiB) > > root@travelmate:~# grep ax0 /etc/ax25/axports > ax0 FH4GOU-1115200 254 1 AX25 over LoRa > > > root@tardis:/usr/src/sketches/mkiss# uname -r > 4.1.18+ > > root@tardis:/usr/src/sketches/mkiss# ifconfig ax0 > ax0 Link encap:AMPR AX.25 HWaddr TRDS01-1 > UP BROADCAST RUNNING MTU:254 Metric:1 > RX packets:569 errors:1 dropped:0 overruns:0 frame:0 > TX packets:212 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:10 > RX bytes:14033 (13.7 KiB) TX bytes:4987 (4.8 KiB) > > root@tardis:/usr/src/sketches/mkiss# grep ax0 /etc/ax25/axports > ax0 TRDS01-19600254 1 AX.25 over LoRa > > > Transmitting/receiving packets < 254 bytes works fine; e.g. IDENT with > not too large texts and also "axcall"-sessions with small pieces of > texts. > But if I invoke "mheard" which returns quite a bit of text, > communication fails. I checked with wireshark and I saw that even > though there's that 254 bytes MTU, I still get packets way larger: > > nr timesource target protocol length info > 2311.08432FH4GOU-01 TRDS01-01 AX.25-NoL3 271 Text > > What can I do to prevent these overly large packets? > -- > To unsubscribe from this list: send the line "unsubscribe linux-hams" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-hams" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux kernel-ax25 - some patches
Hello,
a small update: Please disregard my oservation #3.
Explanation:
IP framents have, by protocol standard, a size of n * 8 (8 is a fixed
defined blocksize).
IP header is not part of the fragmentation blocks (of course) and counts 20.
=> division (256-20)/8.0 = 29.5 has a rest => length of packet:
29*8+20 = 252. That's the observed value.
Btw, on netrom, the rest is 0 (netrom overhead 20 => netrom iface mtu 236):
(236-20)/8.0 = 27.0
=> Netrom payload with IP fragmented packets match exact the mtu length.
vy 73,
- Thomas dl9sau
On Mon, Feb 15, 2016 at 03:00:36PM +0100, Thomas Osterried wrote:
[..]
> 3. IP fragmentation in Mode DG and VC
> -
>
>
> MTU of interface is 256 (== paclen).
>
[..]
> # ifconfig bpq2 mtu 256
>
> bpq2: fm DL9SAU to DL9SAU-15 ctl I00^ pid=CC(IP) len 252
> IP: len 252 44.128.128.1->44.128.128.10 ihl 20 ttl 64 id 52882 offs 0 MF prot
> ICMP
> ICMP: type Echo Request id 5113 seq 1
> ...V !"#$%&'()*+,-./0123456789:;<=>?
> 0040 @ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~.
> 0080
> 00C0
> bpq2: fm DL9SAU to DL9SAU-15 ctl I01+ pid=CC(IP) len 25
> IP: len 25 44.128.128.1->44.128.128.10 ihl 20 ttl 64 id 52882 offs 232
> .
>
> => On both, Mode VC and Mode DG, the IP fragmentation makes packets 252 bytes
> long.
> IP packets with length of 256 pass the interface with len 256, which is
> correct.
[..]
--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
linux kernel-ax25 - some patches
Hello,
I'd like to suggest the following patches to the linux kernel ax25.
If the MTU of the iface is > 256, then AX.25 segmentation feature is available.
Currently, AX.25 segmentation is only available for AX25_I (I-Frames), i.E. IP
mode VC (aka as ka9q fragmentation).
1. AX.25 segmentation on I-Frames
-
If the iface has an mtu of 256, it's not segmented and passes normally through
the iface.
# axparms --route add bpq2 dl9sau-15 --ipmode V
# 228 bytes payload + 8 bytes icmp + 20 bytes IP = 256
$ ping -s 228 -c1 44.128.128.10
bpq2: fm DL9SAU to DL9SAU-15 ctl I00^ pid=CC(IP) len 256
IP: len 256 44.128.128.1->44.128.128.10 ihl 20 ttl 64 DF prot ICMP
ICMP: type Echo Request id 8042 seq 1
Y}.V !"#$%&'()*+,-./0123456789:;<=>?
0040 @ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~.
0080
00C0
Now, we switch the mtu of the iface to 1500:
# ifconfig bpq1 mtu 1500
$ ping -c1 -s 1200 44.128.128.10
PING 44.128.128.10 (44.128.128.10) 1200(1228) bytes of data.
bpq2: fm DL9SAU to DL9SAU-15 ctl I36^ pid=8(segment) len 255 First seg; remain
4
IP: len 1228 44.128.128.1->44.128.128.10 ihl 20 ttl 64 DF prot ICMP
ICMP: type Echo Request id 6151 seq 1
...Vuj.. !"#$%&'()*+,-./0123456789:;<=>?
0040 @ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~.
0080
00C0 .
Problem: We see that the length of the packet is 255 instead of 256.
The segmenter uses the value "paclen" for the segmentation size.
Patch:
--- net/ax25/ax25_out.c.orig 2016-02-14 00:03:57.0 +0100
+++ net/ax25/ax25_out.c 2016-02-14 00:04:08.0 +0100
@@ -134,7 +134,7 @@ void ax25_output(ax25_cb *ax25, int pacl
skb_pull(skb, 1); /* skip PID */
ka9qfrag = 0;
} else {
- paclen -= 2;/* Allow for fragment control info */
+ paclen -= 1;/* Allow for fragment control info */
ka9qfrag = 1;
}
Argue:
The skb holds the PID in the first position, follewed by the payload.
The routine that builds the ax25-packet takes the first byte and puts it in the
PID header-field.
If segmentation should take place, two bytes are prepended: AX25_P_SEGMENT (for
the later PID header field) and the fragment-number, which becomes the first
byte in the ax25 data packet.
At the first segment-frame, the PID (i.E. 0xCC at IP) becomes part of of the
payload (behind the fragment-number).
But that additional byte is now regarded as normal payload (length of payload
+= 1).
Then, this whole payload is split over multibple packets. These packets need
one byte left in front for the fragmentation number. => We have to assume
packlen -=1 (not -= 2).
Prove:
$ ping -s 227 -c1 44.128.128.10
PING 44.128.128.10 (44.128.128.10) 227(255) bytes of data.
bpq2: fm DL9SAU to DL9SAU-15 ctl I21^ pid=CC(IP) len 255
IP: len 255 44.128.128.1->44.128.128.10 ihl 20 ttl 64 DF prot ICMP
ICMP: type Echo Request id 3885 seq 1
5..V !"#$%&'()*+,-./0123456789:;<=>?
0040 @ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~.
0080
00C0 ...
$ ping -s 228 -c1 44.128.128.10
PING 44.128.128.10 (44.128.128.10) 228(256) bytes of data.
bpq2: fm DL9SAU to DL9SAU-15 ctl I32^ pid=CC(IP) len 256
IP: len 256 44.128.128.1->44.128.128.10 ihl 20 ttl 64 DF prot ICMP
ICMP: type Echo Request id 3886 seq 1
H..V.f.. !"#$%&'()*+,-./0123456789:;<=>?
0040 @ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~.
0080
00C0
$ ping -s 229 -c1 44.128.128.10
bpq2: fm DL9SAU to DL9SAU-15 ctl I00^ pid=8(segment) len 256 First seg; remain
1
IP: len 257 44.128.128.1->44.128.128.10 ihl 20 ttl 64 DF prot ICMP
ICMP: type Echo Request id 3888 seq 1
Y..V !"#$%&'()*+,-./0123456789:;<=>?
0040 @ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~.
0080
00C0 ..
bpq2: fm DL9SAU to DL9SAU-15 ctl I01+ pid=8(segment) len 4 remain 0
...
$ ping -s 230 -c1 44.128.128.10
PING 44.128.128.10 (44.128.128.10) 230(258) bytes of data.
bpq2: fm DL9SAU to DL9SAU-15 ctl I12^ pid=8(segment) len 256 First seg; remain
1
IP: len 258 44.128.128.1->44.128.128.10 ihl 20 ttl 64 DF prot ICMP
ICMP: type Echo Request id 3889 seq 1
m..VB... !"#$%&'()*+,-./0123456789:;<=>?
0040 @ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]
Re: kernel ax25: lost and out-of-order data
Hello, 1. New findings: if the kernel runs on a single CPU machine, everything is ok. I transferred the 2MB testfile three times and it has been always received ok. => I suppose it's an SMP issue. 2. The affected system is debian wheezy with standard kernel Linux db0fhn 3.2.0-4-amd64 #1 SMP Debian 3.2.73-2+deb7u2 x86_64 GNU/Linux vy 73, - Thomas dl9sau On Fri, Feb 12, 2016 at 07:12:12PM +0100, Thomas Osterried wrote: > Hello, > > this is a bug report for the kernel ax25 outqueue: > > - some packets with different content are transmitted with the same AX.25 > sequence-number. > - some data is sent twice; we also observe out-of-order data > > I generated a file with testpatterns, which consists of a line number > (aligned to 256 bytes) in the form "007811 deadbeefde...\n". The file size is > 2MB. > > I downloaded the file via an AX.25 connection from db0fhn's linux to db0fhn's > linux via db0fhn's xnet ( call -r -s dl9sau bpq1 db0fhn-9 db0fhn ). > > I traced the packets with listen -a and stored the trace (for being able to > see what happened). > > The files differ (/tmp/testfile.raw is the original file, > /var/ax25/testfile.raw is the file downloaded with call): > diff /tmp/testfile.raw /var/ax25/testfile.raw > < 000699 > deadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdea > dbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbee > fdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef > ... > > > # grep 000699 /tmp/testfile.raw /var/ax25/testfile.raw > /tmp/testfile.raw:000699 > deadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdea > dbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbee > fdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef > > => Line number 000699 was not received. > > > > listen -a shows the packets from linux to the xnet program: > > bpq1: fm DB0FHN-9 to DL9SAU via DB0FHN ctl I50^ pid=F0(Text) len 256 > 000697 deadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefd > 0040 eadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefd > 0080 eadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefd > 00C0 eadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef. > bpq1: fm DB0FHN-9 to DL9SAU via DB0FHN ctl I51^ pid=F0(Text) len 256 > 000698 deadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefd > 0040 eadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefd > 0080 eadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefd > 00C0 eadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef. > bpq1: fm DB0FHN-9 to DL9SAU via DB0FHN ctl I51^ pid=F0(Text) len 256 > 000699 deadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefd > 0040 eadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefd > 0080 eadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefd > 00C0 eadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef. > bpq1: fm DB0FHN-9 to DL9SAU via DB0FHN ctl I52^ pid=F0(Text) len 256 > 000700 deadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefd > .. > > You see the different content (000698 und 00069) in the SAME AX.25 > sequenze-Number (I51)? > > > This came back from the xnet digi: > > bpq1: fm DB0FHN-9 to DL9SAU via DB0FHN* ctl I46^ pid=F0(Text) len 256 > 000697 deadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefd > 0040 eadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefd > 0080 eadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefd > 00C0 eadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef. > bpq1: fm DB0FHN-9 to DL9SAU via DB0FHN* ctl I47^ pid=F0(Text) len 256 > 000698 deadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefd > 0040 eadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefd > 0080 eadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefd > 00C0 eadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef. > bpq1: fm DB0FHN-9 to DL9SAU via DB0FHN* ctl I40^ pid=F0(Text) len 256 > 000700 deadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefd > 0040 eadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefd > 0080 eadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefd > 00C0 eadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef. > bpq1: fm DB0FHN-9 to DL9SAU via DB0FHN* ctl I41^ pid=F0(Text) len 256 > 000702 deadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefd > > => Packet 000699 is missing. > > xnet di
kernel ax25: lost and out-of-order data
Hello,
this is a bug report for the kernel ax25 outqueue:
- some packets with different content are transmitted with the same AX.25
sequence-number.
- some data is sent twice; we also observe out-of-order data
I generated a file with testpatterns, which consists of a line number (aligned
to 256 bytes) in the form "007811 deadbeefde...\n". The file size is 2MB.
I downloaded the file via an AX.25 connection from db0fhn's linux to db0fhn's
linux via db0fhn's xnet ( call -r -s dl9sau bpq1 db0fhn-9 db0fhn ).
I traced the packets with listen -a and stored the trace (for being able to see
what happened).
The files differ (/tmp/testfile.raw is the original file,
/var/ax25/testfile.raw is the file downloaded with call):
diff /tmp/testfile.raw /var/ax25/testfile.raw
< 000699
deadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdea
dbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbee
fdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef
...
# grep 000699 /tmp/testfile.raw /var/ax25/testfile.raw
/tmp/testfile.raw:000699
deadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdea
dbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbee
fdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef
=> Line number 000699 was not received.
listen -a shows the packets from linux to the xnet program:
bpq1: fm DB0FHN-9 to DL9SAU via DB0FHN ctl I50^ pid=F0(Text) len 256
000697 deadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefd
0040 eadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefd
0080 eadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefd
00C0 eadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef.
bpq1: fm DB0FHN-9 to DL9SAU via DB0FHN ctl I51^ pid=F0(Text) len 256
000698 deadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefd
0040 eadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefd
0080 eadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefd
00C0 eadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef.
bpq1: fm DB0FHN-9 to DL9SAU via DB0FHN ctl I51^ pid=F0(Text) len 256
000699 deadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefd
0040 eadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefd
0080 eadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefd
00C0 eadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef.
bpq1: fm DB0FHN-9 to DL9SAU via DB0FHN ctl I52^ pid=F0(Text) len 256
000700 deadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefd
..
You see the different content (000698 und 00069) in the SAME AX.25
sequenze-Number (I51)?
This came back from the xnet digi:
bpq1: fm DB0FHN-9 to DL9SAU via DB0FHN* ctl I46^ pid=F0(Text) len 256
000697 deadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefd
0040 eadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefd
0080 eadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefd
00C0 eadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef.
bpq1: fm DB0FHN-9 to DL9SAU via DB0FHN* ctl I47^ pid=F0(Text) len 256
000698 deadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefd
0040 eadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefd
0080 eadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefd
00C0 eadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef.
bpq1: fm DB0FHN-9 to DL9SAU via DB0FHN* ctl I40^ pid=F0(Text) len 256
000700 deadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefd
0040 eadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefd
0080 eadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefd
00C0 eadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef.
bpq1: fm DB0FHN-9 to DL9SAU via DB0FHN* ctl I41^ pid=F0(Text) len 256
000702 deadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefd
=> Packet 000699 is missing.
xnet did not complain about the packets with the different data and same
sequence number (and silently dropped the second packet).
A verification if data corruption has happened (loss of characters):
root@db0fhn:/home/thomas# grep ^0 /var/ax25/testfile.raw | awk '{print $2}'
|sort -u
deadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef
root@db0fhn:/home/thomas# grep ^0 /tmp/testfile.raw | awk '{print $2}' |sort -u
deadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef
root@db0fhn:/home/thomas#
=> We do not have shortened lines or wrong characte
Re: [PATCH 1/1] Add poll method to mkiss let notify hangup to the user process.
Hello,
unfortunately, I cannot get my mail to Jean-Christian's ISP
(Deferred: Connection timed out with mail.eclis.ch.).
That's why I try it now on this list.
In short:
- Jean-Christian's patch depends on both:
a patched kissattach program AND the mentioned kernel patch below.
- Unfotunately, it does not work: kissattach does not terminate
(in order to prevent the panic) and the kernel still panics.
- If we get it work, 6pack.c sould also be patched the same way as mkiss.c.
- 6pack.c does not panic. The reason is the pre-initializiation of some
variables (6pack.c usefule values, mkiss.c zero).
I tried to use the correct values from 6pack.c in mkiss.c and this fixes
the panic.
- I'd like Jean's patch to get running, because it's good if kissattach
gets notified that the usb device is not present anymore. Only if it's
terminating, /dev/ttyUSB0 will be freed (otherwise, someone who plugs
off-and-in will have an unsable /dev/ttyUSB0 and a new /dev/ttyUSB1).
Here's my mail to Jean-Christian whith my request to verify - now to
everyone who likes to test.
Hello,
has anybody tried it?
I've tried it on debian kernel 3.16.0-4-amd64 with a patched+recompiled
mkiss.ko and the modified kissattach program.
It does not work.
kissattach does not get notified in his poll(). Thus still keeps alive after
the usb plug-off event. Because it's not terminating, the mkiss race condition
is not prevented.
Interesting: if I plug usb of and then strace to the pid of kissattach, it
terminates.
Btw, when pre-initializing
dev->hard_header_len= AX25_MAX_HEADER_LEN;
dev->addr_len = AX25_ADDR_LEN;
in ax_setup() (like sp_setup() in 6pack.c does), the kernel does not panic
anymore.
Anyway, it would be nice if kissattach could get notice if something with the
ax25 interface happened and would to the appropriate action (termination) -
something Jean-Christian intended with his patch.
Also, I like the idea of the blocking poll() instead of the previous while (1)
{ sleep(... )} construct. Furthermore, it's still backwards-compatible to an
unpatched mkiss.ko and 6pack.ko (tested).
If we can manage his patch to work, keep in mind that we have also to patch
6pack.c, because the kissattach program is the same for spattach.
Test scenario:
plug-in the usb device
kissattach /dev/ttyUSB0 ax0
ifconfig ax0 44.128.128.1
plug-off the usb device
ps axwww| grep kissattach # -> still running
ifconfig ax0 44.128.128.1 up
ping 44.128.128.2
PANIC
vy 73,
- Thomas dl9sau
On Fri, Oct 02, 2015 at 05:29:47PM -0700, David Ranch wrote:
>
> Hello Jean-Christian, Everyone,
>
> Thanks for working on this as I'm pretty sure I've bit hit by this panic as
> well though I wasn't able to reproduce it more readily. Anyway, if this is
> the proper fix moving forward, will the kernel not panic even if kissattach
> is not updated? Can you also include the needed patch for the kissattach
> program to complete this solution?
>
> --David
>
>
> On 10/02/2015 02:46 PM, Jean-Christian de Rivaz wrote:
> >Without this the application that use the mkiss line discipline have
> >no way to terminate in case the corresponding serial device is
> >removed, for example when a USB TNC is unplugged. The application must
> >wait on poll().
> >
> >The kissattach application must be patched to take advantage of this
> >feature.
> >
> >Signed-off-by: Jean-Christian de Rivaz
> >---
> > drivers/net/hamradio/mkiss.c | 15 +++
> > 1 file changed, 15 insertions(+)
> >
> >diff --git a/drivers/net/hamradio/mkiss.c b/drivers/net/hamradio/mkiss.c
> >index fba41e9..50cd36c 100644
> >--- a/drivers/net/hamradio/mkiss.c
> >+++ b/drivers/net/hamradio/mkiss.c
> >@@ -893,6 +893,20 @@ static long mkiss_compat_ioctl(struct tty_struct *tty,
> >struct file *file,
> > #endif
> > /*
> >+ * Waiting until hangup is the only allowed operation. This is used
> >+ * to notify the application in case the serial deivce is removed
> >+ * (ex. USB). The tty_ldisc_hangup() will wake up the process.
> >+ */
> >+static unsigned int mkiss_poll(struct tty_struct *tty, struct file *file,
> >+poll_table *wait)
> >+{
> >+poll_wait(file, &tty->read_wait, wait);
> >+poll_wait(file, &tty->write_wait, wait);
> >+
> >+return 0;
> >+}
> >+
> >+/*
> > * Handle the 'receiver data ready' interrupt.
> > * This function is called by the 'tty_io' module in the kernel when
> > * a block of data has been received, which can now be decapsulated
> >@@ -969,6 +983,7 @@ static struct tty_ldisc_ops ax_ldisc = {
> > #ifdef CONFIG_COMPAT
> > .compat_ioctl = mkiss_compat_ioctl,
> > #endif
> >+.poll = mkiss_poll,
> > .receive_buf= mkiss_receive_buf,
> > .write_wakeup = mkiss_write_wakeup
> > };
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-hams" in
> the body of a message to majord...@vger.kernel.org
> More majordomo in
