Skip to content

Commit 979fdf1

Browse files
committed
Issue 102 - PACLEN should not apply to received frame length.
1 parent f358c62 commit 979fdf1

File tree

1 file changed

+24
-3
lines changed

1 file changed

+24
-3
lines changed

ax25_link.c

+24-3
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
//
22
// This file is part of Dire Wolf, an amateur radio packet TNC.
33
//
4-
// Copyright (C) 2016 John Langner, WB2OSZ
4+
// Copyright (C) 2016, 2017 John Langner, WB2OSZ
55
//
66
// This program is free software: you can redistribute it and/or modify
77
// it under the terms of the GNU General Public License as published by
@@ -1011,6 +1011,13 @@ void dl_disconnect_request (dlq_item_t *E)
10111011

10121012
case state_2_awaiting_release:
10131013
{
1014+
// We have previously started the disconnect sequence and are waiting
1015+
// for a UA from the other guy. Meanwhile, the application got
1016+
// impatient and sent us another disconnect request. What should
1017+
// we do? Ignore it and let the disconnect sequence run its
1018+
// course? Or should we complete the sequence without waiting
1019+
// for the other guy to ack?
1020+
10141021
// Erratum. Flow chart simply says "DM (expedited)."
10151022
// This is the only place we have expedited. Is this correct?
10161023

@@ -1021,6 +1028,13 @@ void dl_disconnect_request (dlq_item_t *E)
10211028
packet_t pp = ax25_u_frame (S->addrs, S->num_addr, cr, frame_type_U_DM, p, nopid, NULL, 0);
10221029
lm_data_request (S->chan, TQ_PRIO_0_HI, pp); // HI means expedited.
10231030

1031+
// Erratum: Shouldn't we inform the user when going to disconnected state?
1032+
// Notifying the application, here, is my own enhancement.
1033+
1034+
text_color_set(DW_COLOR_INFO);
1035+
dw_printf ("Stream %d: Disconnected from %s.\n", S->stream_id, S->addrs[PEERCALL]);
1036+
server_link_terminated (S->chan, S->client, S->addrs[PEERCALL], S->addrs[OWNCALL], 0);
1037+
10241038
STOP_T1;
10251039
enter_new_state (S, state_0_disconnected, __func__, __LINE__);
10261040
}
@@ -2209,7 +2223,14 @@ static void i_frame (ax25_dlsm_t *S, cmdres_t cr, int p, int nr, int ns, int pid
22092223
// Look carefully. The original had two tiny differences between the two states.
22102224
// In the 2006 version, these differences no longer exist.
22112225

2212-
if (info_len >= 0 && info_len <= S->n1_paclen) {
2226+
// Erratum: SDL asks: Is information field length <= N1 (paclen).
2227+
// (github issue 102 - Thanks to KK6WHJ for pointing this out.)
2228+
// Just because we are limiting the size of our transmitted data, it doesn't mean
2229+
// that the other end will be doing the same. With v2.2, the XID frame can be
2230+
// used to negotiate a maximum info length but with v2.0, there is no way for the
2231+
// other end to know our paclen value.
2232+
2233+
if (info_len >= 0 && info_len <= AX25_MAX_INFO_LEN) {
22132234

22142235
if (is_good_nr(S,nr)) {
22152236

@@ -2286,7 +2307,7 @@ static void i_frame (ax25_dlsm_t *S, cmdres_t cr, int p, int nr, int ns, int pid
22862307
// Wouldn't even get to CRC check if not octet aligned.
22872308

22882309
text_color_set(DW_COLOR_ERROR);
2289-
dw_printf ("Stream %d: AX.25 Protocol Error O: Information part length, %d, not in range of 0 thru %d.\n", S->stream_id, info_len, S->n1_paclen);
2310+
dw_printf ("Stream %d: AX.25 Protocol Error O: Information part length, %d, not in range of 0 thru %d.\n", S->stream_id, info_len, AX25_MAX_INFO_LEN);
22902311

22912312
establish_data_link (S);
22922313
S->layer_3_initiated = 0;

0 commit comments

Comments
 (0)