Re: Question, was; [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
On Sun, 14 May 2000, Stewart Wilkinson wrote: > Gerd wrote: > > > > > > Do you have a case where this leads to actual problems so we can see if > > > something needs to be fixed? > > > > Yes, I am aware of such a case. You run into problems when a > > user enters a node on L2, goes out on L2 again on the same port > > to another node where he also enters and goes out on a L2 > > connection. If everything here happens on the same port the > > second node sends out frames that seem to come from the original > > user (i.e., they have the same SSID as the user). If the user's TNC > > receives such a frame by accident, it either sends out DM- or > > reports protocol errors (FRMR). > > But that applies for other NODE software too. As the SSID gets > inverted twice. (ie: -0 > -15 > -0 ) Exactly. I guess I could come up with some other scheme for the SSID change but then it would probably cause problems elsewhere. Not worth the trouble IMO... > I recall sometime ago, having another problem (perhaps in earlier > versions), whereby Linux NODE used the wrong callsign in outgoing > connects. > > (I seem to recall this occured when one Linux NODE linked to another > at L3/4 and then on again at L2, but I am not currently able to > reproduce the problem). Never heard of such a problem. If you can reproduce it please send me a bug report. -- Tomi Manninen Internet: [EMAIL PROTECTED] OH2BNS AX.25: [EMAIL PROTECTED] KP20ME04Amprnet: [EMAIL PROTECTED]
Re: Question, was; [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
Gerd wrote: > > Hello Tomi, hello all, > > > LinuxNode only inverts the callsign if the user is coming in via a L2 > > connection and going out again on a L2 connection and on the _same_port_. > > In all other cases users callsign-ssid is left untouched. When I coded > > this I tried to think of all the possible cases and only saw inverting > > necessary in that one particular case. > > > > Do you have a case where this leads to actual problems so we can see if > > something needs to be fixed? > > Yes, I am aware of such a case. You run into problems when a > user enters a node on L2, goes out on L2 again on the same port > to another node where he also enters and goes out on a L2 > connection. If everything here happens on the same port the > second node sends out frames that seem to come from the original > user (i.e., they have the same SSID as the user). If the user's TNC > receives such a frame by accident, it either sends out DM- or > reports protocol errors (FRMR). But that applies for other NODE software too. As the SSID gets inverted twice. (ie: -0 > -15 > -0 ) I recall sometime ago, having another problem (perhaps in earlier versions), whereby Linux NODE used the wrong callsign in outgoing connects. (I seem to recall this occured when one Linux NODE linked to another at L3/4 and then on again at L2, but I am not currently able to reproduce the problem). -- Stewart G0LGS
RE: Question, was; [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
Hello Tomi, hello all, > LinuxNode only inverts the callsign if the user is coming in via a L2 > connection and going out again on a L2 connection and on the _same_port_. > In all other cases users callsign-ssid is left untouched. When I coded > this I tried to think of all the possible cases and only saw inverting > necessary in that one particular case. > > Do you have a case where this leads to actual problems so we can see if > something needs to be fixed? Yes, I am aware of such a case. You run into problems when a user enters a node on L2, goes out on L2 again on the same port to another node where he also enters and goes out on a L2 connection. If everything here happens on the same port the second node sends out frames that seem to come from the original user (i.e., they have the same SSID as the user). If the user's TNC receives such a frame by accident, it either sends out DM- or reports protocol errors (FRMR). Cheers, 73 Gerd
Re: [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
> As a SysOp and an User I think if the YAM driver was ported to work with > this new AX.25 package, many persons would be tempted to try it out. > That's because it is a modem widely used. > I would like to test it at home but I only have 1 Baycom and 2 YAMs. Ummm... does that mean that the port I did does not work? I could not really test it since I'm lacking the hardware. What specifically does not work? -- Jens
Re: [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
On Wed, 26 Apr 2000, Jens David wrote: > I definetely do not think I know the answers to everything. In fact I love > to say "I know that I know nothing". I´m studying ee, not cs, so there are > surely a lot people who have more knowledge and better ideas than me. That´s > why I did that posting revealing my intentions. If somebody has other ideas > I´d like him to speak up now, or leave it completely. > Fact is, nobody else but Jan and Joerg came up with any concrete, factual > ideas/founded bug reports/patches. This is _very_ irritating, especially > if you spend most of your spare time on this stuff while the download > counter reaches the "100" mark. I really need more feedback. As a SysOp and an User I think if the YAM driver was ported to work with this new AX.25 package, many persons would be tempted to try it out. That's because it is a modem widely used. I would like to test it at home but I only have 1 Baycom and 2 YAMs. Regards, Jorge Matias
Re: [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
[Still catching up on e-mail] > This is surely an interesting idea as long as things are concerned > which are not updated very frequently (i.e. not speed critical stuff). > But all routing stuff should be done via netlink interface, shouldn´t it? I'd like to be able to add and remove static routes through procfs. > Then we could do all routing stuff in user space with good performance. > If the kernel needs a route, it can ask the user space program. Yes, that's one concept I've been thinking about for quite a while, but we still need static routes in case the daemon is not running and surely we want to cache routes for a while (think of datagram mode: asking for the AX.25 path for every datagram will hurt performance quite badly). The concept, in one sentence, is: do jobs like this in user space, but remain operational without the daemon. > The user > space program can gather its information from all sorts of sources as > static (user) entry, listening to traffic ^^^ "static to the daemon" > (also via netlink interface, not via AF_PACKET socket monitoring; *nods* > however, we need to do some filtering > in kernel space to avoid performance problems Latency is the word here. AFAIK the netlink code drops events on congestion, but I'd need to read the code again to be sure. > flexnet internode protocol routing information. Definately one of the most interesting uses. And an interface for other applications to request routes directly from the daemon rather than requesting the table from the kernel. > As I said, listen is already done, but net2kiss really puzzles me. > Maybe AF_AX25, SOCK_DGRAM orientated? The problem is that the MAC is now performed by the kernel AX.25. We probably need a kernel module that just does some basic CDMA and emulate a KISS TNC to the application. > You were the one to tell me that the unix way is to have little small > programs rather than big ones. Programs, not configuration files. Many small programs can share one configuration file. BTW, XML can help to avoid conflicts caused by additions. > One big central configuration file also differs > from most I have seen before on the network front. Does any other protocol > suite do something like this? As I wrote, it's mainly for a startup script. In this regard it is not much different than /etc/rc.config on SuSE. Of course no tool (especially basic ones like kissattach) should _depend_ on any configuration file -- think of embeded systems. I made this proposal to get the ball rolling for a distribution-independend and flexible start script. > I know of none. Take slattach for example, > it allows to specify all relevant pieces of information on the command line. Indeed -- I wish kissattach would allow that. > If I want to attach a simple KISS or 6pack port for test purposes I first > need to edit a configuration file? I do not know if this is right. It isn't. > As I see it, it´s the task of the distros to centralize the configuration > information (compare IP interface setup on RedHat for example). It would make life much easier if we were able to do this independend of the distribution. For example, every distrib has its own way to implement IP interface setup, routing and firewalling. It is a pain in the *rse if you have to administrate a lot of boxes with different distributions installed (unless you're using DHCP). > I really don´t know... In my opinion even the bind8 scheme is by > far too complex to be understood by the majority of people. I liked > more the /proc/sys-approach. This is more flexible. Then somebody > can implement a menu-based configuration program like HP did which > generates simple shell scripts for setup which are more transparent. With XML you have a tree structure -- and it is an open standard, even a good one. XML support for perl, python, etc exist and only those who _do_ understand XML will edit that thing by hand. > Because I do not have the time to maintain everything on my own. You don't have to. We will see what needs adjustments and what not. The library will need some tweaks to make use of the new features, but if you need to change it in a way it breaks operability with existing applications you are doing something wrong. > I do not yet understand why an application programmer (e.g. terminal program > writer) has to access the axports file at all. For the symbolic port name / device mapping. We can tweak axlib in a way that it returns the real name instead of the symbolic one by completely ignoring axports -- but this needs further investigation and isn't *that* important right now. > As I understood it the axports file was created to give kernel-ax25 a little > bit the touch of a NOS-app? Yes. 73, Joerg Reuter http://poboxes.com/jreuter/ And I make my way to where the warm scent of soil fills the evening air. Everything is waiting quietly out there (Anne Clark) PGP sign
Re: [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
> > there is no prepending KISS command byte anymore. That's > > annoying, but only affects very few tools: AFAIK only listen, net2kiss > > and ax25rtd. The later will use the netlink interface, I don't know > > And some applications -- aprsdigi, aprsmon, aprsd at least. Hmm, I don't know anything about APRS -- is it using normal UI frames, sent to a fixed destination? Why does it have to monitor all traffic on the channel? If it really has to use the AF_PACKET socket interface, you can easily detect the environment it is running in: the first octet in an AX.25 frame is part of the destination address, thus it has to be in [0-9A-Z ] shifted by one. If you receive a frame beginning with it it's likely the new DDI, if you receive one with a value of 0-31 it is almost certainly the old interface. Of course only with a certain probability, as you may have received a faulty frame or using KISS extensions (CRC, multiport), but this shouldn't be too common. Anyway, autodetection should work in 99% of all cases, for the rest a command line switch can take care of it. 73, Joerg Reuter http://poboxes.com/jreuter/ And I make my way to where the warm scent of soil fills the evening air. Everything is waiting quietly out there (Anne Clark) PGP signature
Re: [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
Tomi wrote: > The original reason for axports was that interfaces could only be > differentiated by the interface callsign. There was no way to tell the > kernel to "open a connection through device ax0". It needed to be done > by telling the kernel to "open a connection through the interface having > hardware address N0CALL". And this still is the default method. IIRC we didn't have a way to get the MAC address easily from an interface back then. > Now we have bind-to-device and settable interface names so we can start > thinking whether all this is needed. (This btw raises another question: > with the current state of things do we still need unique interface > HW-addresses? If we could get rid of that restriction, it would help a > lot.) With SO_BINDTODEVICE (BTW, I think this still needs to get implemented in NET/ROM and Rose) we need unique addresses only for applications that don't use it yet (so far none uses it, though). I don't know whether NET/ROM or Rose rely on it, though. 73, Joerg Reuter http://poboxes.com/jreuter/ And I make my way to where the warm scent of soil fills the evening air. Everything is waiting quietly out there (Anne Clark) PGP signature
Re: Question, was; [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
On Tue, 2 May 2000, Kjell Jarl wrote: > bpq can be set up to give welcome text to the node call as well, usually > set off though. Some thenet nodes also gives welcome texts, debending on > the set up, also over long distance (already established link level). Ok, maybe I shouldn't have stressed this issue too much, it's not the point. The fact is that traditionally those systems have avoided sending welcome texts, and the reason (or one of the reasons) is what I explained. I know some systems do send them and that those systems also do things like check the list of known NET/ROM neighbours to see if the connectee is a user or not. That last mentioned thing is something you will never see on Linux, it is just too ugly and even as such it's not at all foolproof. Some implementations wait for the first information frame from the user before deciding what to do (the frame will have a protocol ID so the system knows exactly what it is for). Now this hack could be implemented at kernel or ax25d level I think and it wouldn't be all that ugly. Maybe some day... -- Tomi Manninen Internet: [EMAIL PROTECTED] OH2BNS AX.25: [EMAIL PROTECTED] KP20ME04Amprnet: [EMAIL PROTECTED]
Re: Question, was; [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
bpq can be set up to give welcome text to the node call as well, usually set off though. Some thenet nodes also gives welcome texts, debending on the set up, also over long distance (already established link level). Depending on the program used, it has to be taken into account when provideng the connect scripts. 73 kjell > > I think that the two lines above is my welcome message. I use BPQ. > > Try doing the same connecting to the node _callsign_, not the alias.
Re: Question, was; [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
Hi Tomi, Thanks, I think this explains to me. I have not noticed any problems though, and my users have not said anything - about not getting in at least. I have seen that welcome message, some time ago, but the connection has went through. I cannot easilly test this as I almost all the time has some one connected to the cluster so the link is established. Next time I notice no link (my outgoing are over plain ax.25 not netrom so there should be oportunities) I will try and see what the response really is. 73 Kjell axports: scc0SM7GVF 9600255 7 Radio port nrports: netrom SM7GVF-5 LINUX 235 Switch Port netdx SM7GVF-6 DX 235 Dx port netconv SM7GVF-3 CONV 235 Convers port ax25d.conf: [SM7GVF-5 VIA scc0] NOCALL * * * * * * L default * * * * 14400 * - root /usr/sbin/nodenode # NOCALL * * * * * * L default * * * * * * - root /usr/sbin/nodenode # [SM7GVF-6 VIA scc0] NOCALL * * * * * * L default * * * * * * - clx_us /usr/local/clx/bin/net_usr net_usr -x %s # NOCALL * * * * * * L default * * * * * * - clx_us /usr/local/clx/bin/net_usr net_usr -x %s Tomi Manninen wrote: > > On Mon, 1 May 2000, Kjell Jarl wrote: > > > I do the same, have both netrom and port call the same, and letting node > > respond to ax.25 user connects to the same SSID. > > It seems to work, and makes it obviuos for users what to connect to. > > Maybe some one could elaborate on why not to do it? > > If you let an application like LinuxNode answer to L2 requests with the > same callsign that is used for internode NET/ROM traffic you can have > problems like this: > > Your neighbor node wants to send NET/ROM traffic to you. It needs to open > a L2 connection to you and it uses the callsign shown on your NODES > broadcasts (== first nrports callsign == HWaddr for nr0). But now you have > configured ax25d to listen for that callsign and to lauch "node". Linux > has no way of knowing so it does what it is told and node is lauched. Node > then sends it's welcome text and the trouble begins... > > What happens next depends on what is at the other end of the connection > (the neighbor) and it ranges from a minor inconvenience through lots of L2 > disconnetions and lost L3 frames to an avalanche of "invalid command" > messages flooding the band. > > Ever wondered why node software like BPQ and TheNet never send a welcome > message...? :-) (And no, just dropping the welcome text from LinuxNode is > not a solution though I have been thinking of adding that as an option > to node.) > > The same thing applies to AX.25 interface callsigns (those in axports) if > you expect to have incoming TCP/IP traffic using Virtual Circuit mode. > > -- > Tomi Manninen Internet: [EMAIL PROTECTED] > OH2BNS AX.25: [EMAIL PROTECTED] > KP20ME04Amprnet: [EMAIL PROTECTED]
Re: Question, was; [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
Howdy, Richard: This doesn't answer your question, but... It is really a 'remainder' rather than a decrement. :-| Outbound SSID = (15 minus inboundSSID) -0 yields -15 -1 yields -14 -2 yields -13 ... -15 yields -0 Richard Bown wrote: > While on the subject of SSID's being used, and while there is plenty of > responses. > Has there been a fix in this release to decrement the SSID of a either a L2 > or L3 connection to the node, i.e. I login as g8jvm on someone else's > system then do an outgoing L2 connection to another > station what I see going out is g8jvm and not g8jvm-15, as I understand it > should be. > What it does cause problems with is , if someone logs into a neighbouring > BBS running linux node, this appears on my mheard list as a direct connect. > Has this been fixed?, if so can someone point me in the direction of the > fix. > TIA > Richard g8jvm
RE: Question, was; [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
RE: Question, was; [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
On Tue, 2 May 2000, Richard Bown wrote: > While on the subject of SSID's being used, and while there is plenty of > responses. > Has there been a fix in this release to decrement the SSID of a either a L2 > or L3 connection to the node, i.e. I login as g8jvm on someone else's > system then do an outgoing L2 connection to another > station what I see going out is g8jvm and not g8jvm-15, as I understand it > should be. > What it does cause problems with is , if someone logs into a neighbouring > BBS running linux node, this appears on my mheard list as a direct connect. > Has this been fixed?, if so can someone point me in the direction of the > fix. This of course has nothing to do with the kernel implementation of AX.25, it's a LinuxNode "problem". LinuxNode only inverts the callsign if the user is coming in via a L2 connection and going out again on a L2 connection and on the _same_port_. In all other cases users callsign-ssid is left untouched. When I coded this I tried to think of all the possible cases and only saw inverting necessary in that one particular case. Do you have a case where this leads to actual problems so we can see if something needs to be fixed? -- Tomi Manninen Internet: [EMAIL PROTECTED] OH2BNS AX.25: [EMAIL PROTECTED] KP20ME04Amprnet: [EMAIL PROTECTED]
RE: Question, was; [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
While on the subject of SSID's being used, and while there is plenty of responses. Has there been a fix in this release to decrement the SSID of a either a L2 or L3 connection to the node, i.e. I login as g8jvm on someone else's system then do an outgoing L2 connection to another station what I see going out is g8jvm and not g8jvm-15, as I understand it should be. What it does cause problems with is , if someone logs into a neighbouring BBS running linux node, this appears on my mheard list as a direct connect. Has this been fixed?, if so can someone point me in the direction of the fix. TIA Richard g8jvm
Re: Question, was; [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
On Mon, 1 May 2000, Charles E. Gelm wrote: > "c 4 ctnode-9 > DAYLAN:NC8Q-1} Connected to CTNODE-9 > r > CTNODE:N8PS-2} Routes: > Port Neighbor Node Call Quality Dests HeardDigipeater(s) >3 DAYLAN:NC8Q-1 192 31 20:04 > Node cmd? > c3 daylan-9 > CTNODE:N8PS-2} Connected to DAYLAN-9 > Welcome to NC8Q's Packet Switch in Dayton > Type ? for list of available commands.New I message 4/6/97" > > I think that the two lines above is my welcome message. I use BPQ. Try doing the same connecting to the node _callsign_, not the alias. -- Tomi Manninen Internet: [EMAIL PROTECTED] OH2BNS AX.25: [EMAIL PROTECTED] KP20ME04Amprnet: [EMAIL PROTECTED]
Re: Question, was; [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
Tomi Manninen wrote: > "c 4 ctnode-9 DAYLAN:NC8Q-1} Connected to CTNODE-9 r CTNODE:N8PS-2} Routes: Port Neighbor Node Call Quality Dests HeardDigipeater(s) 3 DAYLAN:NC8Q-1 192 31 20:04 Node cmd? c3 daylan-9 CTNODE:N8PS-2} Connected to DAYLAN-9 Welcome to NC8Q's Packet Switch in Dayton Type ? for list of available commands.New I message 4/6/97" I think that the two lines above is my welcome message. I use BPQ. ? Chuck nc8q > Ever wondered why node software like BPQ and TheNet never send a welcome > message...? :-) (And no, just dropping the welcome text from LinuxNode is > not a solution though I have been thinking of adding that as an option > to node.) > > The same thing applies to AX.25 interface callsigns (those in axports) if > you expect to have incoming TCP/IP traffic using Virtual Circuit mode. > > -- > Tomi Manninen Internet: [EMAIL PROTECTED] > OH2BNS AX.25: [EMAIL PROTECTED] > KP20ME04Amprnet: [EMAIL PROTECTED]
Re: Question, was; [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
On Mon, 1 May 2000, Kjell Jarl wrote: > I do the same, have both netrom and port call the same, and letting node > respond to ax.25 user connects to the same SSID. > It seems to work, and makes it obviuos for users what to connect to. > Maybe some one could elaborate on why not to do it? If you let an application like LinuxNode answer to L2 requests with the same callsign that is used for internode NET/ROM traffic you can have problems like this: Your neighbor node wants to send NET/ROM traffic to you. It needs to open a L2 connection to you and it uses the callsign shown on your NODES broadcasts (== first nrports callsign == HWaddr for nr0). But now you have configured ax25d to listen for that callsign and to lauch "node". Linux has no way of knowing so it does what it is told and node is lauched. Node then sends it's welcome text and the trouble begins... What happens next depends on what is at the other end of the connection (the neighbor) and it ranges from a minor inconvenience through lots of L2 disconnetions and lost L3 frames to an avalanche of "invalid command" messages flooding the band. Ever wondered why node software like BPQ and TheNet never send a welcome message...? :-) (And no, just dropping the welcome text from LinuxNode is not a solution though I have been thinking of adding that as an option to node.) The same thing applies to AX.25 interface callsigns (those in axports) if you expect to have incoming TCP/IP traffic using Virtual Circuit mode. -- Tomi Manninen Internet: [EMAIL PROTECTED] OH2BNS AX.25: [EMAIL PROTECTED] KP20ME04Amprnet: [EMAIL PROTECTED]
Re: Question, was; [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
On Sun, 30 Apr 2000, Charles E. Gelm wrote: > I thought Naylor & Manninen said that it is 'dirty' code to allow > L3 & L2 connect requests to the same CALLSIGN-SSID. > I thought this couldn't be done in linux. Nope. Never said that. It would be 'dirty' to add that kind of hackery to Linux which allows an application answer on the same callsign that is used for the two NET/ROM 'entities' to talk to each other. In linux that would be the callsign used for the first nrports entry (== the one shown with "ifconfig nr0"). Actually Linux allows you to do that but you _SHOULD_NOT_ do that unless you are completely aware of the consequences. The way around this is the "dummy node" setup well explained on John's web page. -- Tomi Manninen Internet: [EMAIL PROTECTED] OH2BNS AX.25: [EMAIL PROTECTED] KP20ME04Amprnet: [EMAIL PROTECTED]
Re: Question, was; [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
Hi! I do the same, have both netrom and port call the same, and letting node respond to ax.25 user connects to the same SSID. It seems to work, and makes it obviuos for users what to connect to. Maybe some one could elaborate on why not to do it? 73/Kjell > The paragraph below is what I thought could not be done: > Have the node ALIAS:CALLSIGN-SSID respond to an AX.25 connect.
Re: Question, was; [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
Chuck Gelm wrote: > It seems that there is a lot of configuration to be done > and a lot of useless CALLSIGN-SSID assignments. > > The paragraph below is what I thought could not be done: > Have the node ALIAS:CALLSIGN-SSID respond to an AX.25 connect. I think there are two crucial points: First, there is no relationship between the node name used for NetROM routing and the alias used to establish layer 2 connections. They can be the same, or different; they don't interact with one another. So it's OK to have a NetROM node "MVFMA" and on the same machine use an AX.25 alias of "MVFMA" for the same, or a totally different, purpose. Second, there is no relationship between the call/SSID used for layer 2 user access and the call/SSID used for NetROM inter-node layer 3 traffic. All inter-node traffic uses the call/SSID that has been assigned to the first NetROM port defined for the system (here, that's node "#MVFMA" with call/SSID W8APR-13). But users never see that call/SSID and don't need to know about it; it's used only for inter-node traffic. The separate NetROM ports configured for access to FBB and the node software are like the BBS port that sits behind BPQ. To NetROM neighbors, they appear as remote nodes reached via #MVFMA. The aliases and call/SSIDs that are used to reach them via AX.25 are simply a more flexible extension of the separate application alias and SSID (but not call) in BPQ. You're right that the Linux AX.25 system uses a lot of call/SSIDs and is complex to configure (though once you figure it out, it's actually pretty easy -- understanding the structure is a lot more difficult than configuring it). That's a result of the Unix networking model that defined how the Linux AX.25 code had to be written to integrate into the kernel. I understand that the newest kernels may make it possible to get rid of the call-per-interface requirement, but I don't know when that might actually be implemented. (And I really don't know the details behind this, so I'm sure it's a lot more complicated than I've described.) 73, John -- John Ackermann N8UR Dayton, Ohio, USA [EMAIL PROTECTED] -- http://www.febo.com -BEGIN PGP PUBLIC KEY BLOCK- Version: 2.6.3a mQBtAzgI9hgAAAEDAMiMQDZTVVuVIS0AscJ0Wy63oK4+Q5xvtxbX/ZoG1qCOuYDI Fph4/RqL9vVEItWBy6ISk+zbkATzPgy84nrI7+GBtld4F9DoHWARQXjC1I8cFZjY TSe16ffqO/ba1ukLnQAFEbQlSm9obiBSLiBBY2tlcm1hbm4gTjhVUiA8anJhQGZl Ym8uY29tPokAdQMFEDgI9hjqO/ba1ukLnQEBtYIC/AxJ2RqT0/9TqY8JGEkPx2sw +W5Z6Tu4UI654t9diGdCcIEPjOG1qUvwH2Xop0Yj9QGoM4NnHIw6qUSN5VH7hHKA bGnpuTxinuW/gKaI3bt2MC8QZZq0gy2de26907lE2A== =UHWl -END PGP PUBLIC KEY BLOCK-
Re: Question, was; [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
Hi, John: I thought Naylor & Manninen said that it is 'dirty' code to allow L3 & L2 connect requests to the same CALLSIGN-SSID. I thought this couldn't be done in linux. Thanks a bunch. I'll give linux another look see. It seems that there is a lot of configuration to be done and a lot of useless CALLSIGN-SSID assignments. The paragraph below is what I thought could not be done: Have the node ALIAS:CALLSIGN-SSID respond to an AX.25 connect. > John Ackermann wrote: > > If the NetROM system and applications are set up properly, users could > do an AX.25 connection to, for example, FBB, using the call/SSID that > appears in the "MVFMA:W8APR-0" entry of the NetROM nodes list -- it > will respond to both that alias and call/SSID via AX.25, or to the > MVFMA node via NetROM. However, you don't *have* to do it that way, so > there's no guarantees.
Re: Question, was; [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
Following up on Chuck's questions about the apparent call/SSID used by Linux AX.25: When a station has established a connection to any Linux AX.25 service that I'm aware of, including node, FBB, and the CLX cluster software, the FROM callsign matches the callsign used to establish the connection, so I believe that meets your criteria for "manifest." It'll save a bit of confusion to mention now that the low-level Linux networking components, like NetROM network layer configuration, are completely separate from the programs that users interact with. For example, the "node" program provides a G8BPQ-like front end for user interface. "node" is launched by a daemon program called ax25d, which listens on all the AX.25 ports. When it sees an incoming connect request it matches the FROM and TO callsigns, as well as the port, to values in a configuration file and launches the appropriate application. So, when you connect to W8APR-1 or BBROOK on 145.61 at my station, ax25d sees that request and knows that any connection to that callsign is intended for the node program, so it launches that program, passing to it the TO and FROM callsigns of the incoming connect request. node than takes over the connection, using those callsigns. Most applications launch in this way, though some (like FBB) listen to the AX.25 ports directly rather than via ax25d. What's key is that the combination of ax25d and the program's own coding defines what callsigns are used, so there's tremendous flexibility in configuration. The call/SSID combinations assigned to the hardware ports have nothing to do with it, and they can be totally different, or even dummy calls. Moving on to the NetROM subsystem... When the Linux NetROM system sends its node table, the FROM call is the call/SSID assigned to the first NetROM port defined in the system. That may or may not make the user access call/SSID "manifest" but it will identify the port used for layer 2 NetROM-to-NetROM connects. (It may help to explain that the Linux "node" program that provides the BPQ-like user interface isn't an integral part of the NetROM subsystem -- it's a stanalone program that is configured separately. Its call/SSID don't have anything to do with what's defined for the NetROM ports.) Note that to make the NetROM user interaction similar to what BPQ users expect, you ordinarily configure two or more NetROM ports, each with its own alias and call/ssid combination. One is a "system" alias/call/ssid that can be hidden with a "#" character and is only used for NetROM-to-NetROM connections, while the others are used for user interaction. At W8APR, #MVFMA:W8APR-14 is the system node, BBROOK:W8APR-1 conencts you to the "node" front end, and MVFMA:W8APR-0 provides access to the FBB software. All these appear in neighboring node tables. (My web page explains the details of setting this up.) If the NetROM system and applications are set up properly, users could do an AX.25 connection to, for example, FBB, using the call/SSID that appears in the "MVFMA:W8APR-0" entry of the NetROM nodes list -- it will respond to both that alias and call/SSID via AX.25, or to the MVFMA node via NetROM. However, you don't *have* to do it that way, so there's no guarantees. The only other traffic I can think of where a passer-by would pick up a callsign/SSID is from some sort of beacon. As you've already seen, FBB sends its mail beacon using the call/ssid that it responds to. By itself, the node program doesn't generate any beacons or status messages to let a passer-by know that it's there. However, there's a separate "beacon" program that allows you to send one or more beacons on whatever ports you want, using whatever FROM and TO callsigns you want. With that tool, you can make the call/SSID of whatever services you like visible. I hope this helps. 73, John > Hi, John: > > No. I am not asking that if Joe Packet uses a TNC2 and attempts to connect to > W8APR-1, > that a station will respond using a CALLSIGN-SSID of W8APR-1. It would have to. > If I use a TNC2 and transmit connect requests to W8APR-1, it will not accept a > > from any other CALLSIGN-SSID. I think it would return a to any other > CALLSIGN-SSID's frame. > > What I am asking is: > How does a network neighbor pbbs sysop know what CALLSIGN-SSID > to try to AX.25 forward? > > (I know how to do a AX.25 connect to a NETROM, THENET, BPQ, MSYS node > by looking at its neighbor's node list. In the case of MSYS or a BPQ/BBS > I know what CALLSIGN-SSID & ALIAS-SSID to use to establish an AX.25 > circuit with the BBS.) > > Does Joe Packet see AX.25 packets transmitted by W8APR-1? > > Does the callsign-ssid assigned to the linux node transmit AX.25 frames using the > callsign-ssid > that is accepting AX.25 connects? > > Does the callsign-ssid assigned to the linux bbs transmit AX.25 frames using the > callsign-ssid > that is accepting AX.25 connec
Re: Question, was; [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
Hi, John: No. I am not asking that if Joe Packet uses a TNC2 and attempts to connect to W8APR-1, that a station will respond using a CALLSIGN-SSID of W8APR-1. It would have to. If I use a TNC2 and transmit connect requests to W8APR-1, it will not accept a from any other CALLSIGN-SSID. I think it would return a to any other CALLSIGN-SSID's frame. What I am asking is: How does a network neighbor pbbs sysop know what CALLSIGN-SSID to try to AX.25 forward? (I know how to do a AX.25 connect to a NETROM, THENET, BPQ, MSYS node by looking at its neighbor's node list. In the case of MSYS or a BPQ/BBS I know what CALLSIGN-SSID & ALIAS-SSID to use to establish an AX.25 circuit with the BBS.) Does Joe Packet see AX.25 packets transmitted by W8APR-1? Does the callsign-ssid assigned to the linux node transmit AX.25 frames using the callsign-ssid that is accepting AX.25 connects? Does the callsign-ssid assigned to the linux bbs transmit AX.25 frames using the callsign-ssid that is accepting AX.25 connects? If I monitored your 145.61 MHz port with a TNC2 would the callsign-ssid you used to transmit AX.25 frames (MyHEARD) be the same callsign-ssid that would accept AX.25 connects? If I monitored your NETWORK port with a THENET, NETROM, BPQ, MSYS node, would it be manifest what callsign-ssid to use to establish an AX.25 circuit with your node? Would it be manifest what callsign-ssid to use to establish an AX.25 circuit with your bbs? Without the person who configured the linux node telling me and by only monitoring or checking a node list, how do I know what CALLSIGN-SSID to use to establish an AX.25 circuit to a linux node? how do I know what CALLSIGN-SSID to use to establish an AX.25 circuit to a linux bbs? I am assuming that by looking at a node list, that I will see only the CALLSIGN-SSIDs that are accepting node level circuit requests and not AX.25 connect requests. Does the default configuration of linux node transmit (an ID frame?) in AX.25 using the callsign-ssid that is accepting AX.25 circuits? Is it manifest to the user? Is it manifest to the neighbor pBBS sysop? I think we are about 6 miles apart. I've dialed in 145.61 MHz and will check my heard list and node list in a few minutes to see if I can figure out what CALLSIGN-SSID would be accepting AX.25 circuits. Result after about one hour: The only CALLSIGN-SSID heard was W8APR-0. (OBTW, you have mail.) If you hadn't told me, I'd never have known that a node W8APR-1 was available for an AX.25 circuit on that channel. Thanks, again. Chuck nc8q John Ackermann wrote: > > Hi, John: > > > > Thanks. > > > > I think that you are answering my question (1.) with a 'yes', but I am not > > sure. > > > > I've read all my new mail today and see no answer regarding making > > the 'AX.25 accepting CALLSIGN-SSID' manifest. > > > > I think an ALIAS-* can be configured though and this should be good enough. > > > > 73, Chuck > > Chuck, I think what you're asking is whether the call/SSID that's used > as the destination address for inbound packets is used as the source > address for outbound packets in that same connection. I would need to > do some monitoring to be sure, but I believe that the answer is "yes, > probably". I believe that most of the Linux AX.25 tools and > applications will reflect the address used to establish the connection > as the apparent "FROM" address in the return packets. > > I say "probably" because an application can assign a "FROM" address at > will if it wants to, so there's no system-wide guarantee what every > conceivable application might due. (As an aside, at least one version > of the "call" program that you use to establish an outgoing > plain-old-packet keyboard session allows you to specify the FROM > callsign in the command syntax. > > If you want to check for yourself, you can connect to W8APR-0, W8APR-1, > MVFMA, or BBROOK on 156.61 (I think you're close enough to me to reach > directly) and see what the FROM/TO callsigns are. W8APR-0 and MVFMA > connect to the FBB software, while W8APR-1 and BBROOK are used for the > node software. The hardware address of the 145.61 port is actually > W8APR-13, and I don't think you'll see many packets with that FROM > address. > > 73, > John > -- > John Ackermann N8UR > Dayton, Ohio, USA > [EMAIL PROTECTED] -- http://www.febo.com > > -BEGIN PGP PUBLIC KEY BLOCK- > Version: 2.6.3a > > mQBtAzgI9hgAAAEDAMiMQDZTVVuVIS0AscJ0Wy63oK4+Q5xvtxbX/ZoG1qCOuYDI > Fph4/RqL9vVEItWBy6ISk+zbkATzPgy84nrI7+GBtld4F9DoHWARQXjC1I8cFZjY > TSe16ffqO/ba1ukLnQAFEbQlSm9obiBSLiBBY2tlcm1hbm4gTjhVUiA8anJhQGZl > Ym8uY29tPokAdQMFEDgI9hjqO/ba1ukLnQEBtYIC/AxJ2RqT0/9TqY8JGEkPx2sw > +W5Z6Tu4UI654t9diGdCcIEPjOG1qUvwH2Xop0Yj9QGoM4NnHIw6qUSN5VH7hHKA > bGnpuTxinuW/gKaI3bt2MC8QZZq0gy2de26907lE2A== > =UHWl > -END PGP PUBLIC KEY BLOCK-
Re: Question, was; [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
> Hi, John: > > Thanks. > > I think that you are answering my question (1.) with a 'yes', but I am not > sure. > > I've read all my new mail today and see no answer regarding making > the 'AX.25 accepting CALLSIGN-SSID' manifest. > > I think an ALIAS-* can be configured though and this should be good enough. > > 73, Chuck Chuck, I think what you're asking is whether the call/SSID that's used as the destination address for inbound packets is used as the source address for outbound packets in that same connection. I would need to do some monitoring to be sure, but I believe that the answer is "yes, probably". I believe that most of the Linux AX.25 tools and applications will reflect the address used to establish the connection as the apparent "FROM" address in the return packets. I say "probably" because an application can assign a "FROM" address at will if it wants to, so there's no system-wide guarantee what every conceivable application might due. (As an aside, at least one version of the "call" program that you use to establish an outgoing plain-old-packet keyboard session allows you to specify the FROM callsign in the command syntax. If you want to check for yourself, you can connect to W8APR-0, W8APR-1, MVFMA, or BBROOK on 156.61 (I think you're close enough to me to reach directly) and see what the FROM/TO callsigns are. W8APR-0 and MVFMA connect to the FBB software, while W8APR-1 and BBROOK are used for the node software. The hardware address of the 145.61 port is actually W8APR-13, and I don't think you'll see many packets with that FROM address. 73, John -- John Ackermann N8UR Dayton, Ohio, USA [EMAIL PROTECTED] -- http://www.febo.com -BEGIN PGP PUBLIC KEY BLOCK- Version: 2.6.3a mQBtAzgI9hgAAAEDAMiMQDZTVVuVIS0AscJ0Wy63oK4+Q5xvtxbX/ZoG1qCOuYDI Fph4/RqL9vVEItWBy6ISk+zbkATzPgy84nrI7+GBtld4F9DoHWARQXjC1I8cFZjY TSe16ffqO/ba1ukLnQAFEbQlSm9obiBSLiBBY2tlcm1hbm4gTjhVUiA8anJhQGZl Ym8uY29tPokAdQMFEDgI9hjqO/ba1ukLnQEBtYIC/AxJ2RqT0/9TqY8JGEkPx2sw +W5Z6Tu4UI654t9diGdCcIEPjOG1qUvwH2Xop0Yj9QGoM4NnHIw6qUSN5VH7hHKA bGnpuTxinuW/gKaI3bt2MC8QZZq0gy2de26907lE2A== =UHWl -END PGP PUBLIC KEY BLOCK-
Re: Question, was; [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
Hi, John: Thanks. I think that you are answering my question (1.) with a 'yes', but I am not sure. I've read all my new mail today and see no answer regarding making the 'AX.25 accepting CALLSIGN-SSID' manifest. I think an ALIAS-* can be configured though and this should be good enough. 73, Chuck John Ackermann wrote: > Hi Chuck -- > > I think that you can configure Linux AX.25 to do what you want. > > The secret is that although you do need to assign a unique call/SSID to > each physical port, those calls do not have to be used by the application > or its users. If I recall correctly, you can configure so that the only > place the "hardware" callsign is used is on outbound TCP/IP packets. > > You can define the callsign that applications listen for within each > application, or using the ax25d.conf configuration file for programs > that are launched by the ax25d daemon program. > > For example, using the ax25d.conf configuration file, you can define > by interface what callsign the node (BPQ-like front end) program will > respond to. You can have multiple calls for one interface, or the > same call for several interfaces. You can also select what happens > based on the *source* callsign of a packet, which opens up some > interesting possibilities. You can also define the NetROM callsign and > alias for incoming connects separately from the NetROM "hardware" callsign. > (By the way, FBB uses its own configuration file to set the callsign > and interfaces it uses, but it can be made to coexist with the node front- > end.) > > In short, the various configuration files allow you to use pretty much > whatever callsigns you want for whatever services and ports you want, > and the unique call/SSIDs that you assign to each port can be ignored > in the real world. At worst, they will be seen on oubound UI frames > containing TCP/IP data and NetROM layer 2 packets (and I'm not even > sure about the NetROM example). > > My web page at http://www.febo.com/linux-ax25 has a link to an explanation > of how to configure this that includes sample configuration files. It's > still based on the 2.0 kernel and associated tools, but the concept and > vast majority of the configuration info is still valid with 2.2 kernels; > it's mainly the syntax of a few of the tools that has changed. > > 73, > John N8UR > [EMAIL PROTECTED] > > In message <[EMAIL PROTECTED]>, "Charles E. Gelm" writes: > >Hi, Richard et allia: > > > > I probably didn't give enough information in my original post. > > > > I am assuming that everyone in 'linux-hams' is familiar with > >'NetRom', 'TheNet' and 'BPQ node' application. I use packet BBS > >software authored by AA4RE. A mention is made to the node function > >in the MSYS BBS program by WA8BXN. > > > > I run a three radio port packet node and mail switch. > >O/S is MS-DOS v6.22, applications are G8BPQ code v4.08a > >and AA4RE's BB v2.1t. > > > > With this combination I propagate the CALLSIGN-SSID that others > >can use to establish a 'node' circuit to my node switch and the > >CALLSIGN-SSID to use to establish a node circuit to my pBBS. > >These two NODE & BBS CALLSIGN-SSIDs are the same on all packet radio > >ports. > > > > Occasionally my neighbor node's routing is messed up and I need to > >establish AX.25 circuits for forwarding. With TheNet, NetRom, MSYS, > >and G8BPQ nodes it is intuitively obvious what ALIAS-SSID anyone can > >use to establish AX.25 circuits. > > > > What I am asking is; > > > >1. if I change my O/S to linux and my node application to linux-node, > >(and the pBBS application to linux-F6FBB. ) > >will my three radio ports each require a unique CALLSIGN-SSID > >for the node and each require a unique CALLSIGN-SSID for the pBBS? > > > >2. Can I make it intuitive what CALLSIGN-SSID or ALAIS-SSID is > >accepting AX.25 circuits to the NODE ? > > > >3. Can I make it intuitive what CALLSIGN-SSID or ALAIS-SSID is > >accepting AX.25 circuits to the pBBS ? > > > >4. Can these CALLSIGN-SSIDs or ALIAS-SSIDs be the same on all radio > >ports? > > > >Chuck nc8q > >a.k.a. Joe Packet
Re: Question, was; [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
Hi, Richard: Let me redefine my use of the word 'intuitive'; perhaps I could use 'overt', 'obvious', 'manifest', 'immediately evident', (one of my favorites) 'intuitively obvious to the casual observer'. I want the CALLSIGN-SSID that is accepting AX.25 circuits to the BBS to be 'made known' to those monitoring my AX.25 transmissions or viewing any 'node list'. You are saying that I can configure a port to accept an AX.25 connect request to a specific CALLSIGN-SSID. I am asking, can that specific CALLSIGN-SSID be 'made known' to others automatically, obviously, overtly? IOW, would I be the only one to know? Is the CALLSIGN-SSID that is accepting AX.25 connections to an application: overt, hidden, unknown to others? If the answer is not yes, could I substitute the word ALIAS for CALLSIGN and then could the answer be yes? OBTW, I don't know what 'ax25d' does or what a 'dummy interface via node' is. Is 'ax25d' a 'node' application for linux in the same manner that 'BPQ' is a 'node' application for DOS ? Regards, Chuck nc8q Richard Adams wrote: > > 2. Can I make it intuitive what CALLSIGN-SSID or ALAIS-SSID is > > accepting AX.25 circuits to the NODE ? > > Yes ax25d will listen for callsin-ssid combinations and start the defined > program. > > > > > 3. Can I make it intuitive what CALLSIGN-SSID or ALAIS-SSID is > > accepting AX.25 circuits to the pBBS ? > > Same as above. > > > > > 4. Can these CALLSIGN-SSIDs or ALIAS-SSIDs be the same on all radio > > ports? > > No each interface will need a seperate callsign-ssid combination, however > ax25d can be configured to listen for a seperate ssid on the same interface. > > A senario would be, > > port 1 n9zzz > port 2 n9zzz-1 > port 2 n9zzz-2 > > In the ax25d configuration file one could define; > > callssign-ssid VIA port 1 'open a certain program, node for example'. > > Or i belive i am correct in saying, > > n9zzz-2 VIA * which will take the asterisk as meaning accept n9zzz-2 > on all interfaces and open program X for the connectee. > > XFBB i belive needs a dummy interface via node, i dont run XFBB myself so i > cant realy comment, but i am sure there will be others willing to help. > > > > > Chuck nc8q > > a.k.a. Joe Packet > > I think we can forget the aka, ;-) > > -- > Regards Richard > [EMAIL PROTECTED] > http://people.zeelandnet.nl/pa3gcu/
Re: Question, was; [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
On Thu, 27 Apr 2000, Charles E. Gelm wrote about, Re: Question, was; [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5: > Hi, Richard et allia: > > I probably didn't give enough information in my original post. > > I am assuming that everyone in 'linux-hams' is familiar with > 'NetRom', 'TheNet' and 'BPQ node' application. I use packet BBS > software authored by AA4RE. A mention is made to the node function > in the MSYS BBS program by WA8BXN. > > I run a three radio port packet node and mail switch. > O/S is MS-DOS v6.22, applications are G8BPQ code v4.08a > and AA4RE's BB v2.1t. > > With this combination I propagate the CALLSIGN-SSID that others > can use to establish a 'node' circuit to my node switch and the > CALLSIGN-SSID to use to establish a node circuit to my pBBS. > These two NODE & BBS CALLSIGN-SSIDs are the same on all packet radio > ports. > > Occasionally my neighbor node's routing is messed up and I need to > establish AX.25 circuits for forwarding. With TheNet, NetRom, MSYS, > and G8BPQ nodes it is intuitively obvious what ALIAS-SSID anyone can > use to establish AX.25 circuits. > > What I am asking is; > > 1. if I change my O/S to linux and my node application to linux-node, > (and the pBBS application to linux-F6FBB. ) > will my three radio ports each require a unique CALLSIGN-SSID > for the node and each require a unique CALLSIGN-SSID for the pBBS? > > 2. Can I make it intuitive what CALLSIGN-SSID or ALAIS-SSID is > accepting AX.25 circuits to the NODE ? Yes ax25d will listen for callsin-ssid combinations and start the defined program. > > 3. Can I make it intuitive what CALLSIGN-SSID or ALAIS-SSID is > accepting AX.25 circuits to the pBBS ? Same as above. > > 4. Can these CALLSIGN-SSIDs or ALIAS-SSIDs be the same on all radio > ports? No each interface will need a seperate callsign-ssid combination, however ax25d can be configured to listen for a seperate ssid on the same interface. A senario would be, port 1 n9zzz port 2 n9zzz-1 port 2 n9zzz-2 In the ax25d configuration file one could define; callssign-ssid VIA port 1 'open a certain program, node for example'. Or i belive i am correct in saying, n9zzz-2 VIA * which will take the asterisk as meaning accept n9zzz-2 on all interfaces and open program X for the connectee. XFBB i belive needs a dummy interface via node, i dont run XFBB myself so i cant realy comment, but i am sure there will be others willing to help. > > Chuck nc8q > a.k.a. Joe Packet I think we can forget the aka, ;-) -- Regards Richard [EMAIL PROTECTED] http://people.zeelandnet.nl/pa3gcu/
Re: Question, was; [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
Hi Chuck -- I think that you can configure Linux AX.25 to do what you want. The secret is that although you do need to assign a unique call/SSID to each physical port, those calls do not have to be used by the application or its users. If I recall correctly, you can configure so that the only place the "hardware" callsign is used is on outbound TCP/IP packets. You can define the callsign that applications listen for within each application, or using the ax25d.conf configuration file for programs that are launched by the ax25d daemon program. For example, using the ax25d.conf configuration file, you can define by interface what callsign the node (BPQ-like front end) program will respond to. You can have multiple calls for one interface, or the same call for several interfaces. You can also select what happens based on the *source* callsign of a packet, which opens up some interesting possibilities. You can also define the NetROM callsign and alias for incoming connects separately from the NetROM "hardware" callsign. (By the way, FBB uses its own configuration file to set the callsign and interfaces it uses, but it can be made to coexist with the node front- end.) In short, the various configuration files allow you to use pretty much whatever callsigns you want for whatever services and ports you want, and the unique call/SSIDs that you assign to each port can be ignored in the real world. At worst, they will be seen on oubound UI frames containing TCP/IP data and NetROM layer 2 packets (and I'm not even sure about the NetROM example). My web page at http://www.febo.com/linux-ax25 has a link to an explanation of how to configure this that includes sample configuration files. It's still based on the 2.0 kernel and associated tools, but the concept and vast majority of the configuration info is still valid with 2.2 kernels; it's mainly the syntax of a few of the tools that has changed. 73, John N8UR [EMAIL PROTECTED] In message <[EMAIL PROTECTED]>, "Charles E. Gelm" writes: >Hi, Richard et allia: > > I probably didn't give enough information in my original post. > > I am assuming that everyone in 'linux-hams' is familiar with >'NetRom', 'TheNet' and 'BPQ node' application. I use packet BBS >software authored by AA4RE. A mention is made to the node function >in the MSYS BBS program by WA8BXN. > > I run a three radio port packet node and mail switch. >O/S is MS-DOS v6.22, applications are G8BPQ code v4.08a >and AA4RE's BB v2.1t. > > With this combination I propagate the CALLSIGN-SSID that others >can use to establish a 'node' circuit to my node switch and the >CALLSIGN-SSID to use to establish a node circuit to my pBBS. >These two NODE & BBS CALLSIGN-SSIDs are the same on all packet radio >ports. > > Occasionally my neighbor node's routing is messed up and I need to >establish AX.25 circuits for forwarding. With TheNet, NetRom, MSYS, >and G8BPQ nodes it is intuitively obvious what ALIAS-SSID anyone can >use to establish AX.25 circuits. > > What I am asking is; > >1. if I change my O/S to linux and my node application to linux-node, >(and the pBBS application to linux-F6FBB. ) >will my three radio ports each require a unique CALLSIGN-SSID >for the node and each require a unique CALLSIGN-SSID for the pBBS? > >2. Can I make it intuitive what CALLSIGN-SSID or ALAIS-SSID is >accepting AX.25 circuits to the NODE ? > >3. Can I make it intuitive what CALLSIGN-SSID or ALAIS-SSID is >accepting AX.25 circuits to the pBBS ? > >4. Can these CALLSIGN-SSIDs or ALIAS-SSIDs be the same on all radio >ports? > >Chuck nc8q >a.k.a. Joe Packet
Re: Question, was; [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
Hi, Richard et allia: I probably didn't give enough information in my original post. I am assuming that everyone in 'linux-hams' is familiar with 'NetRom', 'TheNet' and 'BPQ node' application. I use packet BBS software authored by AA4RE. A mention is made to the node function in the MSYS BBS program by WA8BXN. I run a three radio port packet node and mail switch. O/S is MS-DOS v6.22, applications are G8BPQ code v4.08a and AA4RE's BB v2.1t. With this combination I propagate the CALLSIGN-SSID that others can use to establish a 'node' circuit to my node switch and the CALLSIGN-SSID to use to establish a node circuit to my pBBS. These two NODE & BBS CALLSIGN-SSIDs are the same on all packet radio ports. Occasionally my neighbor node's routing is messed up and I need to establish AX.25 circuits for forwarding. With TheNet, NetRom, MSYS, and G8BPQ nodes it is intuitively obvious what ALIAS-SSID anyone can use to establish AX.25 circuits. What I am asking is; 1. if I change my O/S to linux and my node application to linux-node, (and the pBBS application to linux-F6FBB. ) will my three radio ports each require a unique CALLSIGN-SSID for the node and each require a unique CALLSIGN-SSID for the pBBS? 2. Can I make it intuitive what CALLSIGN-SSID or ALAIS-SSID is accepting AX.25 circuits to the NODE ? 3. Can I make it intuitive what CALLSIGN-SSID or ALAIS-SSID is accepting AX.25 circuits to the pBBS ? 4. Can these CALLSIGN-SSIDs or ALIAS-SSIDs be the same on all radio ports? Chuck nc8q a.k.a. Joe Packet
Re: [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
Craig Small wrote: > It sounds like you are re-writing an awful lot, that's fine too. If you > are removing ioctls, let's add the new ones in leave the old ones there > then remove the old ones. Look at what was done with ipchains/ipfwadm. Of cause. Here the same rules apply as with the socket API. > I think merging could be a good idea, let's see what others think. > I have strong objections to calling it ax25-utils; this would be a "new" > package and you have the choice of what to call it and you go for one of > the three words that can cause confusion when you could choose anything > except -utils -apps or -tools and there would be NO confusion at all. The problem is the good ones are all taken. Even "squid" is. :) -- Jens
Re: Question, was; [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
On Fri, 21 Apr 2000, Chuck Gelm wrote about, Re: [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5: > Howdy, Y'all: > > Does AX.25 for linux still require a unique CALLSIGN-SSID > for each packet radio port? Normally speaking here in EU land, its required that one uses a callsign to identify his/her stn, however one can call a radio port what one likes. /etc/ax25/axports 2m dick 9600256 4 test kissattach -l -m 512 /dev/ttyS1 2m 10.0.0.1 ax1 Link encap:AMPR AX.25 HWaddr DICK inet addr:10.0.0.1 Mask:255.0.0.0 UP RUNNING MTU:512 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:10 > Is there an AX25-HOWTO for a 2.2.x kernel ? I think someone mentioned one a while back, take a look at the archives at; http://hes.iki.fi/archive/linux-hams/ > Chuck nc8q > a.k.a. Joe Packet Huum. -- Regards Richard [EMAIL PROTECTED] http://people.zeelandnet.nl/pa3gcu/
Re: [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
Howdy, Y'all: Does AX.25 for linux still require a unique CALLSIGN-SSID for each packet radio port? Is there an AX25-HOWTO for a 2.2.x kernel ? Chuck nc8q a.k.a. Joe Packet Richard Adams wrote: > Gentelmen, we all know that everyone is free to change what he/she wants > to, but once again, please take into consideration Joe Packet, the one who > constanly keeps complaining that the AX25-HOWTO is out of date, the one who > keeps sending mails asking how do you do "Y" under linux, howto this howto > that, it seems to me that those sort of questions have somewhat dissapiered > from the Linux-Hams list (not altogether but traffic is quite latley). > That must say that folks are getting used to things, more and more hams > know how things fit together and tell and help others. > -- > Regards Richard > [EMAIL PROTECTED] > http://people.zeelandnet.nl/pa3gcu/
Re: [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
On Thu, 27 Apr 2000, Jens David wrote: > > The later will use the netlink interface, I don't know > > how to fix net2kiss for the new DDI, and listen can easily be tweaked > > to work with all kernels. > > As I said, listen is already done, but net2kiss really puzzles me. > Maybe AF_AX25, SOCK_DGRAM orientated? Umm.. What is it that is difficult with net2kiss? Taking a quick look it receives a packet from a network interface, KISS encapsulates it and writes to a pty. Definitely a PF_PACKET thing, (PF_AX25, SOCK_DGRAM) won't give you enough of the received packet. Am I missing something here? Oh, BTW, rxecho also needs to be fixed. > > Well, those are for "node" and similar programs to view the > > connection status of other processes. What's wrong with that? > > Even if they were always updated to match the current kernel > behaviour (i.e. formatting), or through libax25 I still think > this would be a performance issue. Doesn´t the kernel for example > disable all interrupts while a proc file is accessed (composed) or did > I get this wrong? I have understood so but at least node doesn't use them in a way that would cause any performance issues. > I do not yet understand why an application programmer (e.g. terminal program > writer) has to access the axports file at all. Why not use the socket interface > and ioctl()s as AF_INET applications do? They do not require a ipports file > either, don´t they? > As I understood it the axports file was created to give kernel-ax25 a little > bit the touch of a NOS-app? The original reason for axports was that interfaces could only be differentiated by the interface callsign. There was no way to tell the kernel to "open a connection through device ax0". It needed to be done by telling the kernel to "open a connection through the interface having hardware address N0CALL". And this still is the default method. This would obviously have been very cumbersome to the users without an abstraction layer of some sort and as long as that was needed, symbolic names were easy to add. Now we have bind-to-device and settable interface names so we can start thinking whether all this is needed. (This btw raises another question: with the current state of things do we still need unique interface HW-addresses? If we could get rid of that restriction, it would help a lot.) The question is how will the old functionality be phased out and whether the [ax|nr|rs]ports files still have a place for some other reason. That needs to be discussed. -- Tomi Manninen Internet: [EMAIL PROTECTED] OH2BNS AX.25: [EMAIL PROTECTED] KP20ME04Amprnet: [EMAIL PROTECTED]
Re: [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
On Wed, 26 Apr 2000, Jens David wrote: > please calm down and let us deal with this on the facts. It was definetely > not my intention to start another flamewar when I did that announcement. Neither did I. Sorry if I seemed a little too exited earlier. > Fact is, nobody else but Jan and Joerg came up with any concrete, factual > ideas/founded bug reports/patches. This is _very_ irritating, especially > if you spend most of your spare time on this stuff while the download > counter reaches the "100" mark. I really need more feedback. Exactly. Pardon me but the way you presented things in your previous posts on this subject didn't exactly prompt me to contribute. Again, I buy many of the arguments you give. That channel access stuff etc. is self-evident. I just feel that these things should be discussed before making hasty decisions. Especially as it seems you want to drop things that are concidered important by others. You are of course entitled to do as you please but if the real world isn't taken into account, I fear your valuable work ends up something only your "group of high standards" knows about... Anyway we now have discussion and that is good. > I my opinion only configuration should be in /proc. That´s settings, port > status, ax25 circuit list (for reading only of cause) etc. That´s mostly > what it consists of now, so it should stay there. What I have a bad feeling > about is that terminal programs begin scanning /proc/net/ax25 to find out > about L2 state of "their" sockets just to display them. They IMHO ought to > use the ioctl() interface. As I said, that /proc reading stuff was written for node. Jonathan then thought it should be moved to the lib so others could use it. In node it is only used to give the user information about what is happening in the system. I don't see what's wrong in that. Oh, and it's also used to get the NET/ROM routing info from kernel in order to do mnemonic->callsign translation. Currently there is no other way and I see little reason to change that. We have seen wrongful uses of the stuff but (now that the ioctl interface is powerful enough) they have been rectified. I'm not buying it should be removed just because someone could use it for wrong purposes. > Another thing is trying to find ax25-Interfaces. Some apps scan the proc > entries instead of using ioctl()s. They break when proc format changes. > In my opinion procfs should be reserved for user interaction with standard > tools such as "cat", "grep" etc, applications and tools should use the > ioctl() interfaces. What apps? That's seems just plain stupid. Anyway in my opinion "when proc format changes" is entirely analogous to "when the kernel api changes". If something changes in the API the apps break just as if they would when a proc file format changes. That should just be avoided! And if it cannot be avoided then it should be hidden behind a library anyway. -- Tomi Manninen Internet: [EMAIL PROTECTED] OH2BNS AX.25: [EMAIL PROTECTED] KP20ME04Amprnet: [EMAIL PROTECTED]
Re: [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
Who said it does'nt matter, but someone said in a reply mail to linux-hams. > > Some developers talk, some actually develop something .. :) > > (just my opinion about new-ax25 discussion .. > > don't take personaly (anyone)) Normally i dont get involved in discusiions about how development should or should not be done, i dont have the knowlage to write the stuff myself, however i do hack some programs to suit my needs but that is besides the point. I am speaking for the multitude, (i hope). However considering Tomi's humorous attitude i would like to make a few suggestions for the "users" of the wonderfull linux AX25 system. 1) Whatever is going to be altered, please take into consideration that your normal Joe Packet user is not a programmer and does not know the differance between a 'c' file or a 'h' file. 2) Please keep or try to keep the config files in the same directory's as they are now, i remember the chaos a few years ago when Jonathan Naylor changed from /usr/local/etc to /etc/ax25. ( or i should say i called it chaos ). 3) Whats wrong with having changeable param files in /proc ?, we all have gotten used to them now, once again there was a commotion when G4KLX changed that as well, it has been there now for a while and personally i find it a blessing. Why am i writing this anyway, well i brougt it upon myself once to say openly in Linux-Hams, if anyone wants advice on configuring an AX25 system send me a mail and i will try and help, well i got mails from just about every "corner" of our (round) World, of which i have answered, or tryed to answer everyone, most of them from folks who had no idea howto get AX25 going under Linux. So hence this mail to ask you developers "nicely" to, please try not to change to much in the way of, where everything belongs. There is nothing wrong with changing things internaly if cosmeticly things stay just about the same. ( Really my opinion ). I hepled in a small way when the origanal code was under development, i even sent 2 patches for the old netrom code one of which was accepted by G4KLX, or i should say he saw what i meant and improved my code, (if one could call it that), Joreg DK1BKE listened to me time and time again about problems i found in the scc driver, we exchanged many lengthy mails and he constanly sent me test code. That is what i call working toegther. HINT. Gentelmen, we all know that everyone is free to change what he/she wants to, but once again, please take into consideration Joe Packet, the one who constanly keeps complaining that the AX25-HOWTO is out of date, the one who keeps sending mails asking how do you do "Y" under linux, howto this howto that, it seems to me that those sort of questions have somewhat dissapiered from the Linux-Hams list (not altogether but traffic is quite latley). That must say that folks are getting used to things, more and more hams know how things fit together and tell and help others. Imagen changing everything around "again" need i say more. > > But let's drop this FlexNet issue here and now. It won't be > productive. Apologies for getting caught by that flame bait... O yes, Tomi, was the bate in that Flexynet with the hooks on it.? and how did it taste.? And of course my humble appols., for taking it upon myself to speak for the multitude. > > -- > Tomi Manninen Internet: [EMAIL PROTECTED] > OH2BNS AX.25: [EMAIL PROTECTED] > KP20ME04Amprnet: [EMAIL PROTECTED] -- Regards Richard [EMAIL PROTECTED] http://people.zeelandnet.nl/pa3gcu/
Re: [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
I thought I better first up say that I have not looked at the implementation, is it better or not (though I totally agree that the way things are done is suboptimal and would like to see sounthing like iproute if ifup/ifdown scheme). My only problem is a migration strategy. We are at X and we want to get to Y. It sounds like you are re-writing an awful lot, that's fine too. If you are removing ioctls, let's add the new ones in leave the old ones there then remove the old ones. Look at what was done with ipchains/ipfwadm. On Wed, Apr 26, 2000 at 11:17:52PM +0200, Jens David wrote: > Joerg conviced me that keeping the old socket API for applications is > mandatory. However, I do not see why new user space setup utilities > need to work with (mostly) 3 years old kernel code? Do other tools such > as the hdparms etc. work with old kernel drivers? I honestly don´t know, > but I would not expect it to do so. The point why I am asking this is > because it bloats tool source and IMO makes it unmaintainable, thus again > causing potention error sources. If you are radically changing a tool, then please change its name to something different. Look at iproute, they didn't suddently change ifconfig breaking pretty much everything, the made a new tool called /sbin/ip ip does pretty much what ifconfig does, but more. So if you want the new feature Z, then you must use ip. I actually like ip a lot, other than its name. And yes there are plenty of tools that have different ioctls or other functions depending on what kernel they are running on and *this is a run-time check*. The main idea is to stick all that sort of stuff into a library, then all tools just use that library. If you only change the back end, you bump the minor number, change the API you bumb up the major and have a binary->library dependency. > Remember we are talking about the future here, maybe one or 1.5 years. Plenty of time to do a nice slow migration across, don't you think? #ifdefs are a bad idea for reasons mentioned before. I mean if it comes to it take the libax25 make two directories, put the old stuff in old/ your stuff in new/ and in the top directory a big bunch of if (something to test) then new_func(); else old_func(); I believe any existing tools and apps would not need too much modification, if there is a need what needs to be changed. Perhaps anything dependent on the kernel should be shifted into the library, we can do that now. Let's get the library ready for the new kernel (and its API) now, so people will migrate over to the dual mode library so when the kernel changes the tools suddenly die. > What I really do not understand is why for example listen is part of > ax25-apps while other low-level stuff is part of ax25-tools. Where´s the > difference, why not one package for simplicity? > Why not call the resulting package "ax25-utils" again, any refs on the I think merging could be a good idea, let's see what others think. I have strong objections to calling it ax25-utils; this would be a "new" package and you have the choice of what to call it and you go for one of the three words that can cause confusion when you could choose anything except -utils -apps or -tools and there would be NO confusion at all. > original 2.1.43 (or whatever it was) stuff will surely be erased by then, > or at least nobody will have the bright idea to use 2.1.x-stuff with 2.5, > right? So this should be enough to distinguish both packages? Without causing offence to fellow hams, I think you have greatly overestimated some peoples, hmm..., computer savvy. If the decision is to merge the packages, I dont care about the name, but anything but not those three! -- Craig Small VK2XLZ GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 Eye-Net Consulting http://www.eye-net.com.au/<[EMAIL PROTECTED]> MIEEE <[EMAIL PROTECTED]> Debian developer <[EMAIL PROTECTED]>
Re: [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
Joerg Reuter wrote:
>
> Oh my, here we go again...
>
> > Of cause the new kernel needs new tools which will not work with
> > the old kernel.
>
> We need to differ between the tools, the applications and the library.
> My idea is to get rid of some programs altogether (axparms for example)
> and provide the functionality through procfs.
This is surely an interesting idea as long as things are concerned
which are not updated very frequently (i.e. not speed critical stuff).
But all routing stuff should be done via netlink interface, shouldn´t it?
Then we could do all routing stuff in user space with good performance.
If the kernel needs a route, it can ask the user space program. The user
space program can gather its information from all sorts of sources as
static (user) entry, listening to traffic (also via netlink interface,
not via AF_PACKET socket monitoring; however, we need to do some filtering
in kernel space to avoid performance problems with too many kernel/user space
transitions on high speed links, maybe some cache algorithm?), flexnet
internode protocol routing information.
> Some tools (those that
> use AF_PACKET to monitor traffic) need to get updated -- the DDI has
> changed, there is no prepending KISS command byte anymore. That's
> annoying, but only affects very few tools: AFAIK only listen, net2kiss
> and ax25rtd.
Because they are already fixed in my packages. But I think Mat´s decision
to do this was also right (note to avoid flamewar again: when I say "right"
I mean it complies with the rest of the linux kernel policies).
> The later will use the netlink interface, I don't know
> how to fix net2kiss for the new DDI, and listen can easily be tweaked
> to work with all kernels.
As I said, listen is already done, but net2kiss really puzzles me.
Maybe AF_AX25, SOCK_DGRAM orientated?
> > There is a lot of conceptionally
> > wrong stuff in there like dependencies on the stupid axports file and
> > /proc/*-Entries.
>
> That's not wrong stuff at all. /etc/ax25/{ax,nr,rs}ports isn't exactly
> the best solution (try adding new fields...)
You were the one to tell me that the unix way is to have little small
programs rather than big ones. One big central configuration file also differs
from most I have seen before on the network front. Does any other protocol
suite do something like this? I know of none. Take slattach for example,
it allows to specify all relevant pieces of information on the command line.
If I want to attach a simple KISS or 6pack port for test purposes I first
need to edit a configuration file? I do not know if this is right.
As I see it, it´s the task of the distros to centralize the configuration
information (compare IP interface setup on RedHat for example).
> But it has a purpose.
> Personally I'd like to substitute those with _one_ XML configuration
> file. Advantages:
>
> - easily expandable
> - a non-validating XML parser is small and fast
> - tools exist to manipulate it from within various programming
> languages and editors, even on different platforms
>
> And probably doing the same with /etc/ax25d.conf and /etc/node.conf
> (of course changing the name of the files to avoid confusion)
> The only disadvantage: XML can be hard to parse for the human
> reader, but that's the price of flexibility. The scheme bind8
> uses isn't better in this regard.
I really don´t know... In my opinion even the bind8 scheme is by
far too complex to be understood by the majority of people. I liked
more the /proc/sys-approach. This is more flexible. Then somebody
can implement a menu-based configuration program like HP did which
generates simple shell scripts for setup which are more transparent.
> > Also, I will remerge ax25-tools and -apps (I do not see the reason to have
> > two packages here)
>
> Makes life easier for the maintainers.
Why? Because the file size is smaller when a new release comes out? ;)
> > and call the resulting package ax25-utils again. The
> > library will have to be completely reworked, too.
>
> Why, for heaven's sake? You'll break _every_ application that uses
> the shared libraries -- that is a big no-no.
Because I do not have the time to maintain everything on my own. It
takes a lot of time to fit those functions to match the current kernels
capabilities. Do ifconfig or iproute2 use such a library that does ioctl()
calls or parses procfs entries?
> > I do not like those proc-scanning functions
>
> Well, those are for "node" and similar programs to view the
> connection status of other processes. What's wrong with that?
Even if they were always updated to match the current kernel
behaviour (i.e. formatting), or through libax25 I still think
this would be a performance issue. Doesn´t the kernel for example
disable all interrupts while a proc file is accessed (composed) or did
I get this wrong?
> > and axports stuff
>
> This _has_ to get discussed in detail with the application programmers and
> maintainers.
I do not yet understand why
Re: [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
Craig Small wrote: > > On Wed, Apr 26, 2000 at 11:57:00AM +0200, Jens David wrote: > > Of cause the new kernel needs new tools which will not work with > > the old kernel. That´s why I released seperate distributions. I > > orginally wanted to keep the new tools backward compatible. I modified > > the autoconf scripts so that they tried to find out at compile time whether > > they were being compiled for old or new AX.25 . I sent the patches to you, > > but did not get any response. I concluded that there was no interest. Thus > > I became quite sloppy about placing my #ifdefs during further changes. > I don't recall an email, which address did you send it to? I am pretty sure I sent it to <[EMAIL PROTECTED]>. As I got no response I asked on the list if somebody had seen you recently. No response. > I do remember some discussion about non-backwards compatible API and how > I and many others said it was a bad idea. Joerg conviced me that keeping the old socket API for applications is mandatory. However, I do not see why new user space setup utilities need to work with (mostly) 3 years old kernel code? Do other tools such as the hdparms etc. work with old kernel drivers? I honestly don´t know, but I would not expect it to do so. The point why I am asking this is because it bloats tool source and IMO makes it unmaintainable, thus again causing potention error sources. > OK, just so I know when to expect the torrent of emails saying their > setup doesn't work are you telling me that a standard 2.2.14 kernel > does not work with the plain vanilla ax25 tools or apps? Remember we are talking about the future here, maybe one or 1.5 years. > Checking at compile time for what sort of system you are running is just > a totally bad idea. You do understand that the various distributions > distribute binaries, ie they are compilied once? Of cause, but as time comes I assume we will have re-merged the code. > > I know that this will pose a lot of administrative problems. But I will > > not accept any performance-compatibility tradeoffs here, except perhaps > > the binary compatibility with the old socket interface. > If I have read and understood things correctly, I don't think you > realise what size of a disaster you are making for people, especially > the distributions. Not exactly, no. If you have a concrete idea which is better, then let´s discuss it. What I really do not understand is why for example listen is part of ax25-apps while other low-level stuff is part of ax25-tools. Where´s the difference, why not one package for simplicity? Why not call the resulting package "ax25-utils" again, any refs on the original 2.1.43 (or whatever it was) stuff will surely be erased by then, or at least nobody will have the bright idea to use 2.1.x-stuff with 2.5, right? So this should be enough to distinguish both packages? -- Jens
Re: [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
On Wed, Apr 26, 2000 at 07:32:06PM +0200, Joerg Reuter wrote: > We need to differ between the tools, the applications and the library. > My idea is to get rid of some programs altogether (axparms for example) > and provide the functionality through procfs. Some tools (those that > use AF_PACKET to monitor traffic) need to get updated -- the DDI has > changed, there is no prepending KISS command byte anymore. That's > annoying, but only affects very few tools: AFAIK only listen, net2kiss > and ax25rtd. The later will use the netlink interface, I don't know And some applications -- aprsdigi, aprsmon, aprsd at least. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
Gentlemen, please calm down and let us deal with this on the facts. It was definetely not my intention to start another flamewar when I did that announcement. Tomi Manninen wrote: > > On Wed, 26 Apr 2000, Jan Wasserbauer wrote: > > > I have to support Jens since I think nex-Ax25 support is much better (and > > what is done so far greatly proves that). > > > > Have in mind we're talking about Ax25 for 2.5/2.6 kernels .. (or patched > > 2.2/2.4 of course) so compatibility issues are not that important. > > I wasn't talking about compatibility issues (which are important also of > course) or which implementation is better. I was talking about attitudes. > [...] I´m sorry if my matter-of-fact-attitude has hurt somebody. I am currently in a local group which sets very high high standards. Matthias successfully tried to fullfill these standards and contributed a lot of interesting stuff, not only in the linux/ax25 area as long as his spare time permitted it. I took over, but people still tell me there´s a lot of work to do, and I know they are right. I am not going to point out again why KISS is suboptimal when CSMA is used or why the unix philosophy is to have many little tools rather than one large tool. I assume that people know, and that they know the neccessity to correct this. If that means rewriting some or most code, you have to eat that sour apple, that´s what I was told my whole life long. Note that I once did the same mistakes when coding AIRS (see http://www.afthd.tu-darmstadt.de/~dg1kjd/airs/). I realized that it was crap what I did and merily dropped it. Of cause I also spent a lot of time on it, but I know that this time is was not lost since I learned a lot. For example I accepted that this "channel-access thing" affects more than low-level driver interfaces. It affects the whole LAPB state machine structure. That´s why Mat´s (mostly) rewrite was the right thing (tm) to do. Finally, we are doing this for fun and education, aren´t we? > > Some developers talk, some actually develop something .. :) > > (just my opinion about new-ax25 discussion .. > > don't take personaly (anyone)) > > Yeah, right. And some people think they know all the answers and never > need any advice/comments/suggestions/input. I definetely do not think I know the answers to everything. In fact I love to say "I know that I know nothing". I´m studying ee, not cs, so there are surely a lot people who have more knowledge and better ideas than me. That´s why I did that posting revealing my intentions. If somebody has other ideas I´d like him to speak up now, or leave it completely. Fact is, nobody else but Jan and Joerg came up with any concrete, factual ideas/founded bug reports/patches. This is _very_ irritating, especially if you spend most of your spare time on this stuff while the download counter reaches the "100" mark. I really need more feedback. > > > The /proc reading stuff was somethign I hacked quickly together to support > > > node. I don't think anyone else uses it. Would you care to elaborate on > > > what exactly is so evil about that. > > > > Someone was asking here what is so conceptionally wrong about old-ax25 > > .. so just one example .. > > And I still don't see an explanation of exactly _what_ is conceptionally > wrong about that. Explain it and I'm happy. (If the explanation makes > sense that is.) I my opinion only configuration should be in /proc. That´s settings, port status, ax25 circuit list (for reading only of cause) etc. That´s mostly what it consists of now, so it should stay there. What I have a bad feeling about is that terminal programs begin scanning /proc/net/ax25 to find out about L2 state of "their" sockets just to display them. They IMHO ought to use the ioctl() interface. Another thing is trying to find ax25-Interfaces. Some apps scan the proc entries instead of using ioctl()s. They break when proc format changes. In my opinion procfs should be reserved for user interaction with standard tools such as "cat", "grep" etc, applications and tools should use the ioctl() interfaces. > > > > I know that this will pose a lot of administrative problems. But I will > > > > not accept any performance-compatibility tradeoffs here, except perhaps > > > > the binary compatibility with the old socket interface. > > > > > > > > Comments? > > > > > > Good luck getting other developers interested in your (apprently personal) > > > crusade to save us from the evil of the old implementation. I do not expect may people to come and contribute much these days. Whoever has a little bit of brain and some spare time will go to the commercial market and make his/her skills to money with industrial programming. This is pretty much an academic thing. However, I have no objections agains people contributing stuff or ideas. You got that completely wrong. In fact I will set up a public CVS repository on dl0td as soon as possible. >[...] -- Jens
Re: [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
On Wed, Apr 26, 2000 at 09:47:25PM +1000, Craig Small wrote: > On Wed, Apr 26, 2000 at 11:57:00AM +0200, Jens David wrote: > > Of cause the new kernel needs new tools which will not work with > > the old kernel. That´s why I released seperate distributions. I > > OK, just so I know when to expect the torrent of emails saying their > setup doesn't work are you telling me that a standard 2.2.14 kernel > does not work with the plain vanilla ax25 tools or apps? The latest Debian versions are working just fine for me, with exactly kernel 2.2.14. I really appreciate your efforts getting that in there, Craig. And I'd feel quite comfortable with those versions being in a stable Debian release. The new node features are especially nice - I don't have to feel quite so inferior to all the NOS stations anymore. Likewise it's perfectly fine that when using a 2.0 kernel, one has to use the older ax.25 stuff. I can understand that sometimes a break from the past must happen in order for progress to be made. The old stuff worked well enough that there wasn't much need to continue development on it just to fix bugs. It was time to add features instead. Now, what is going on with Jens' new code? I think that if you are going to follow the same version numbering convention, then you'd better keep it compatible with 2.2.14, because 2.4 is not out yet, let alone 2.5/2.6. The old scheme of numbering ax.25-stuff releases (tracking the kernel release numbers) made sense, even though it was a frequenty-asked newbie question...but if you're not going to do that, then for crying out loud, at least make a new major version number when you go off in a new and incompatible direction. Performance is important to me, but knowing which version to install to easily get it working with any given kernel is way more important. I'm speaking here as an old user, since 1994 or 1995; not a developer (yet). However I am interested in application development so having some API consistency would seem to be important too. Again, if you go off in an incompatible new direction you should start a new major version. And continue fixing bugs in the previous version too, just like what is done with the kernel (2.2 bugs have been fixed continuously while 2.3 was being developed). I'm a CVS admin where I work, and I would make a branch for this sort of thing. > Checking at compile time for what sort of system you are running is just > a totally bad idea. You do understand that the various distributions > distribute binaries, ie they are compilied once? I agree. > > Aiee, please call them (ax25-utils and libax25-2) something else. The > first is evil because people will get confused about which package you > are talking about, the second because there will be confusion again > but also it has a wierd name format that plays havoc with packagers. Changing the naming scheme too often is not a good idea. Seems like Debian usually splits things up as much as possible though, so that's consistent with having the libs separate from the applications. And Debian also handles upgrades much better when the number and names of the packages stay the same. So I think I'd vote for leaving it alone. But get it onto a 1.0 release track, and then start a 1.1 branch for experimental stuff. What I'd like to see next is a Debian package for FBB...if that's even possible with 2.2 kernels. :-) -- ___ Shawn T. Rutledge / KB7PWD [EMAIL PROTECTED] (_ | |_) http://www.bigfoot.com/~ecloud [EMAIL PROTECTED] __) | | \ Get money for spare CPU cycles at http://www.ProcessTree.com/?sponsor=5903
Re: [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
Oh my, here we go again...
> Of cause the new kernel needs new tools which will not work with
> the old kernel.
We need to differ between the tools, the applications and the library.
My idea is to get rid of some programs altogether (axparms for example)
and provide the functionality through procfs. Some tools (those that
use AF_PACKET to monitor traffic) need to get updated -- the DDI has
changed, there is no prepending KISS command byte anymore. That's
annoying, but only affects very few tools: AFAIK only listen, net2kiss
and ax25rtd. The later will use the netlink interface, I don't know
how to fix net2kiss for the new DDI, and listen can easily be tweaked
to work with all kernels.
> I sent the patches to you,
> but did not get any response. I concluded that there was no interest. Thus
> I became quite sloppy about placing my #ifdefs during further changes.
Jens, don't give up too easily. Those patches aren't needed for the
current kernel, there is no need to include them into the mainstream
distribution yet.
> There is a lot of conceptionally
> wrong stuff in there like dependencies on the stupid axports file and
> /proc/*-Entries.
That's not wrong stuff at all. /etc/ax25/{ax,nr,rs}ports isn't exactly
the best solution (try adding new fields...) But it has a purpose.
Personally I'd like to substitute those with _one_ XML configuration
file. Advantages:
- easily expandable
- a non-validating XML parser is small and fast
- tools exist to manipulate it from within various programming
languages and editors, even on different platforms
And probably doing the same with /etc/ax25d.conf and /etc/node.conf
(of course changing the name of the files to avoid confusion)
The only disadvantage: XML can be hard to parse for the human
reader, but that's the price of flexibility. The scheme bind8
uses isn't better in this regard.
BTW, it be done completely transparent for any application that
uses ax25-lib.
> Also, I will remerge ax25-tools and -apps (I do not see the reason to have
> two packages here)
Makes life easier for the maintainers.
> and call the resulting package ax25-utils again. The
> library will have to be completely reworked, too.
Why, for heaven's sake? You'll break _every_ application that uses
the shared libraries -- that is a big no-no.
> I do not like those proc-scanning functions
Well, those are for "node" and similar programs to view the
connection status of other processes. What's wrong with that?
> and axports stuff
This _has_ to get discussed in detail with the application programmers and
maintainers.
> Comments?
You are free to do that -- but don't expect it will get accepted
widely. BTW, in what regard does /etc/ax25/axports hurt performance?
> Remember the flexnet slogan?: "It´s like re-inventing the wheel, and doing
> it the right way this time."
So what _is_ the right way? Flexnet surely isn't, it's still doctoring
on a protocol rooted in a low-speed, low-noise cable-bound environment,
hacked to work over radio. Doing it the Right Way would be to develop
something like Bluetooth, but for WANs.
73,
Joerg Reuter http://poboxes.com/jreuter/
And I make my way to where the warm scent of soil fills the evening air.
Everything is waiting quietly out there (Anne Clark)
PGP signature
Re: [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
On Wed, 26 Apr 2000, Jan Wasserbauer wrote: > I have to support Jens since I think nex-Ax25 support is much better (and > what is done so far greatly proves that). > > Have in mind we're talking about Ax25 for 2.5/2.6 kernels .. (or patched > 2.2/2.4 of course) so compatibility issues are not that important. I wasn't talking about compatibility issues (which are important also of course) or which implementation is better. I was talking about attitudes. (Actually the new-ax25 stuff looks very nice, I do believe it's better in many ways and I'm sad that I haven't had time to test it.) > Some developers talk, some actually develop something .. :) > (just my opinion about new-ax25 discussion .. > don't take personaly (anyone)) Yeah, right. And some people think they know all the answers and never need any advice/comments/suggestions/input. What I would have liked to see is something like: "I think feature X in the current implementation is somewhat suboptimal. I was thinking of rewriting/reimplementing/modifying it by implementing feature Y. What do you folks think? I'm going to start writing it now but am open to suggestions." ...and then really be open to the suggestions. This was _exactly_ what we saw when Matthias first started to write new-ax25! Now all I see is: "the old stuff is crap, let's dump it." > > The /proc reading stuff was somethign I hacked quickly together to support > > node. I don't think anyone else uses it. Would you care to elaborate on > > what exactly is so evil about that. > > Someone was asking here what is so conceptionally wrong about old-ax25 > .. so just one example .. And I still don't see an explanation of exactly _what_ is conceptionally wrong about that. Explain it and I'm happy. (If the explanation makes sense that is.) > > > I know that this will pose a lot of administrative problems. But I will > > > not accept any performance-compatibility tradeoffs here, except perhaps > > > the binary compatibility with the old socket interface. > > > > > > Comments? > > > > Good luck getting other developers interested in your (apprently personal) > > crusade to save us from the evil of the old implementation. > > Oh .. should we do it like Win95 ? (DOS compatibility) > Old implementation is working but that's just about all to tell about it. > If new-implementation was only frame-collector and adaptive timers it > would be better .. and new implementation is much more than that .. BZZZT. Wrong answer! Again. My point is that Jens doesn't seem to give a damn about what other people think about this. Jens of course has the right to do what he want's but I wouldn't that suprised if with the current attitude the stuff wouldn't catch fire. And that would be a shame in my opinion. Nobody wants DOS-like backwards compatibility. But the current approach seems like sticking your head in a bush and hoping the real world goes away. It won't. If all else fails Linus and Alan make sure it won't. > And it does not allow users to set parametrs but after some years on PR I > exactly understand why .. there are just too much people who have special > ability to misconfigure anything .. And this, my friend, is exactly what is so repulsive about FlexNet thinking. If all Linux developers shared that notion, we would have a reimplementation of Windows with all the plug'n'pray stuff and people at Redmond knowing much better what we want. That kind of thinking just doesn't fit into Linux! But let's drop this FlexNet issue here and now. It won't be productive. Apologies for getting caught by that flame bait... -- Tomi Manninen Internet: [EMAIL PROTECTED] OH2BNS AX.25: [EMAIL PROTECTED] KP20ME04Amprnet: [EMAIL PROTECTED]
Re: [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
I have to support Jens since I think nex-Ax25 support is much better (and what is done so far greatly proves that). Have in mind we're talking about Ax25 for 2.5/2.6 kernels .. (or patched 2.2/2.4 of course) so compatibility issues are not that important. On Wed, 26 Apr 2000, Tomi Manninen OH2BNS wrote: > On Wed, 26 Apr 2000, Jens David wrote: > > > Also, I will remerge ax25-tools and -apps (I do not see the reason to have > > two packages here) and call the resulting package ax25-utils again. The > > library will have to be completely reworked, too. I do not like those > > proc-scanning functions and axports stuff at all. I think I am going to > > call this libax25-2, but I´m not yet completely sure about this. > > Oh, how nice of you to discuss all of this with the other developers and > giving constructive critisism/feedback to those of us who have written the > old code! Some developers talk, some actually develop something .. :) (just my opinion about new-ax25 discussion .. don't take personaly (anyone)) And well.. if you want to give feedback .. just do it now! This is why new versions are released, don't you think ? > The /proc reading stuff was somethign I hacked quickly together to support > node. I don't think anyone else uses it. Would you care to elaborate on > what exactly is so evil about that. Someone was asking here what is so conceptionally wrong about old-ax25 .. so just one example .. > > I know that this will pose a lot of administrative problems. But I will > > not accept any performance-compatibility tradeoffs here, except perhaps > > the binary compatibility with the old socket interface. > > > > Comments? > > Good luck getting other developers interested in your (apprently personal) > crusade to save us from the evil of the old implementation. Oh .. should we do it like Win95 ? (DOS compatibility) Old implementation is working but that's just about all to tell about it. If new-implementation was only frame-collector and adaptive timers it would be better .. and new implementation is much more than that .. > > Remember the flexnet slogan?: "It´s like re-inventing the wheel, and doing > > it the right way this time." > > Are you referring to "doing everything under secrecy and without > discussing with others" when you talk about the "right way" á la Flexnet? > Give us a break... "secrecy" .. oh .. Sources and docs are freely available .. so what is so "secret" for you ? What I see is just ranting about new-ax25 but I don't see (have overlooked ?) those people actually trying new-ax25. BTW: FlexNet just _IS_ the best concerning channel acces algorithms / adaptive timers / routing. It is NOT good its authors don't like opensource and it seems they don't like Linux too. And it does not allow users to set parametrs but after some years on PR I exactly understand why .. there are just too much people who have special ability to misconfigure anything .. I'm getting feeling that people ranting about FlexNet etc. have never seen something better than BPQ node .. Jan
Re: [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
On Wed, Apr 26, 2000 at 11:57:00AM +0200, Jens David wrote: > Of cause the new kernel needs new tools which will not work with > the old kernel. That´s why I released seperate distributions. I > orginally wanted to keep the new tools backward compatible. I modified > the autoconf scripts so that they tried to find out at compile time whether > they were being compiled for old or new AX.25 . I sent the patches to you, > but did not get any response. I concluded that there was no interest. Thus > I became quite sloppy about placing my #ifdefs during further changes. I don't recall an email, which address did you send it to? I do remember some discussion about non-backwards compatible API and how I and many others said it was a bad idea. OK, just so I know when to expect the torrent of emails saying their setup doesn't work are you telling me that a standard 2.2.14 kernel does not work with the plain vanilla ax25 tools or apps? This information is critical for me as Debian is going into deep freeze and I must tell the release manager if there is a problem immediately. Checking at compile time for what sort of system you are running is just a totally bad idea. You do understand that the various distributions distribute binaries, ie they are compilied once? > Also, I will remerge ax25-tools and -apps (I do not see the reason to have > two packages here) and call the resulting package ax25-utils again. The > library will have to be completely reworked, too. I do not like those > proc-scanning functions and axports stuff at all. I think I am going to > call this libax25-2, but I´m not yet completely sure about this. Aiee, please call them (ax25-utils and libax25-2) something else. The first is evil because people will get confused about which package you are talking about, the second because there will be confusion again but also it has a wierd name format that plays havoc with packagers. > I know that this will pose a lot of administrative problems. But I will > not accept any performance-compatibility tradeoffs here, except perhaps > the binary compatibility with the old socket interface. If I have read and understood things correctly, I don't think you realise what size of a disaster you are making for people, especially the distributions. - Craig -- Craig Small VK2XLZ GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 Eye-Net Consulting http://www.eye-net.com.au/<[EMAIL PROTECTED]> MIEEE <[EMAIL PROTECTED]> Debian developer <[EMAIL PROTECTED]>
Re: [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
On Wed, 26 Apr 2000, Jens David wrote: > My future plans are the following: > I will mostly rework the complete packages. There is a lot of conceptionally > wrong stuff in there like dependencies on the stupid axports file and > /proc/*-Entries. > > Also, I will remerge ax25-tools and -apps (I do not see the reason to have > two packages here) and call the resulting package ax25-utils again. The > library will have to be completely reworked, too. I do not like those > proc-scanning functions and axports stuff at all. I think I am going to > call this libax25-2, but I´m not yet completely sure about this. Oh, how nice of you to discuss all of this with the other developers and giving constructive critisism/feedback to those of us who have written the old code! The /proc reading stuff was somethign I hacked quickly together to support node. I don't think anyone else uses it. Would you care to elaborate on what exactly is so evil about that. > I know that this will pose a lot of administrative problems. But I will > not accept any performance-compatibility tradeoffs here, except perhaps > the binary compatibility with the old socket interface. > > Comments? Good luck getting other developers interested in your (apprently personal) crusade to save us from the evil of the old implementation. > Remember the flexnet slogan?: "It´s like re-inventing the wheel, and doing > it the right way this time." Are you referring to "doing everything under secrecy and without discussing with others" when you talk about the "right way" á la Flexnet? Give us a break... -- Tomi Manninen Internet: [EMAIL PROTECTED] OH2BNS AX.25: [EMAIL PROTECTED] KP20ME04Amprnet: [EMAIL PROTECTED]
RE: [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
Craig will there be RPM versions available, for us lazy people that use them ? And Jens, I disagree with flexnet wheel ! -Original Message- From: Jens David [mailto:[EMAIL PROTECTED]] Sent: 26 April 2000 10:57 To: [EMAIL PROTECTED] Subject: Re: [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5 Craig Small wrote: > > On Sun, Apr 23, 2000 at 01:16:23PM +0200, Jens David wrote: > > I´m happy to announce the 5th attempt of DG2FEF/DG1KJD AX.25 > > for Linux 2.2.14. I originally intended to wait until 2.2.15, > > but since it seems there are some delays on its release and > > there are some nasty bugs I nailed down I decided commit the > > release now. > > It consists of > > > > - the kernel patch > > - new libax25 (in fact this did not change but I renamed it > > for consistency issues) > > - new ax25-tools > > - new ax25-apps > Urgh, are they backwards compatible? In other words will these new > tools work with old kernels? Will old tools work with new kernels? > > I'm trying to avoid some giant administrative nightmare here. Of cause the new kernel needs new tools which will not work with the old kernel. That´s why I released seperate distributions. I orginally wanted to keep the new tools backward compatible. I modified the autoconf scripts so that they tried to find out at compile time whether they were being compiled for old or new AX.25 . I sent the patches to you, but did not get any response. I concluded that there was no interest. Thus I became quite sloppy about placing my #ifdefs during further changes. My future plans are the following: I will mostly rework the complete packages. There is a lot of conceptionally wrong stuff in there like dependencies on the stupid axports file and /proc/*-Entries. Also, I will remerge ax25-tools and -apps (I do not see the reason to have two packages here) and call the resulting package ax25-utils again. The library will have to be completely reworked, too. I do not like those proc-scanning functions and axports stuff at all. I think I am going to call this libax25-2, but I´m not yet completely sure about this. I know that this will pose a lot of administrative problems. But I will not accept any performance-compatibility tradeoffs here, except perhaps the binary compatibility with the old socket interface. Comments? Remember the flexnet slogan?: "It´s like re-inventing the wheel, and doing it the right way this time." -- Jens
Re: [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
Craig Small wrote: > > On Sun, Apr 23, 2000 at 01:16:23PM +0200, Jens David wrote: > > I´m happy to announce the 5th attempt of DG2FEF/DG1KJD AX.25 > > for Linux 2.2.14. I originally intended to wait until 2.2.15, > > but since it seems there are some delays on its release and > > there are some nasty bugs I nailed down I decided commit the > > release now. > > It consists of > > > > - the kernel patch > > - new libax25 (in fact this did not change but I renamed it > > for consistency issues) > > - new ax25-tools > > - new ax25-apps > Urgh, are they backwards compatible? In other words will these new > tools work with old kernels? Will old tools work with new kernels? > > I'm trying to avoid some giant administrative nightmare here. Of cause the new kernel needs new tools which will not work with the old kernel. That´s why I released seperate distributions. I orginally wanted to keep the new tools backward compatible. I modified the autoconf scripts so that they tried to find out at compile time whether they were being compiled for old or new AX.25 . I sent the patches to you, but did not get any response. I concluded that there was no interest. Thus I became quite sloppy about placing my #ifdefs during further changes. My future plans are the following: I will mostly rework the complete packages. There is a lot of conceptionally wrong stuff in there like dependencies on the stupid axports file and /proc/*-Entries. Also, I will remerge ax25-tools and -apps (I do not see the reason to have two packages here) and call the resulting package ax25-utils again. The library will have to be completely reworked, too. I do not like those proc-scanning functions and axports stuff at all. I think I am going to call this libax25-2, but I´m not yet completely sure about this. I know that this will pose a lot of administrative problems. But I will not accept any performance-compatibility tradeoffs here, except perhaps the binary compatibility with the old socket interface. Comments? Remember the flexnet slogan?: "It´s like re-inventing the wheel, and doing it the right way this time." -- Jens
Re: [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
On Sun, Apr 23, 2000 at 01:16:23PM +0200, Jens David wrote: > I´m happy to announce the 5th attempt of DG2FEF/DG1KJD AX.25 > for Linux 2.2.14. I originally intended to wait until 2.2.15, > but since it seems there are some delays on its release and > there are some nasty bugs I nailed down I decided commit the > release now. > It consists of > > - the kernel patch > - new libax25 (in fact this did not change but I renamed it > for consistency issues) > - new ax25-tools > - new ax25-apps Urgh, are they backwards compatible? In other words will these new tools work with old kernels? Will old tools work with new kernels? I'm trying to avoid some giant administrative nightmare here. - Craig -- Craig Small VK2XLZ GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 Eye-Net Consulting http://www.eye-net.com.au/<[EMAIL PROTECTED]> MIEEE <[EMAIL PROTECTED]> Debian developer <[EMAIL PROTECTED]>
Re: [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
Dear Hams, Reading this memo, i see a driver for PCISCC-4 card. Is this card in production (yet?) , or is this beta ? Anyone working with this card .?. Regards, PD1ACF Ron Jochems -Original Message- From: Jens David <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: Sunday, April 23, 2000 1:28 PM Subject: [ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5 >Hi all, > >I´m happy to announce the 5th attempt of DG2FEF/DG1KJD AX.25 >for Linux 2.2.14. I originally intended to wait until 2.2.15, >but since it seems there are some delays on its release and >there are some nasty bugs I nailed down I decided commit the >release now. >It consists of > >- the kernel patch >- new libax25 (in fact this did not change but I renamed it > for consistency issues) >- new ax25-tools >- new ax25-apps > >Get the packages from > >http://dl0td.afthd.tu-darmstadt.de/~dg1kjd/linux-ax25/index.html >http://dl0td.rmn.de.ampr.org/~dg1kjd/linux-ax25/index.html > >Changes: >- Fixed LAPB state machine problem with retransmits >- Fixed a race condition in protocol/driver interface which caused > endless OOPS loop with IP-over-AX25 under certain conditions. >- Fixed a nasty DAMA bug that prevented anything to be sent after > a station was once connected and than closed all circuits. >- Optimized scheduler >- Optimized T2-handling >- Optimized high-speed behaviour to fit megabit requirements >- The old ax25rtd is back to work again. Note that this is still a > temporary hack >- ax25mond in ax25-tools package >- soundmodem diagnostic utilities re-included in ax25-tools and cross- > update with old ax25-tools-0.0.6 >- PCISCC-4 driver update >- EPPFLEX driver update >- a little fix in 6pack driver >- fixed ax25d-"cat /usr/bin/gdb-only-shows-32KB"-bug >- ... > > -- Jens
[ANNOUNCE] new-AX.25 for 2.2.14 Rel. 5
Hi all, I´m happy to announce the 5th attempt of DG2FEF/DG1KJD AX.25 for Linux 2.2.14. I originally intended to wait until 2.2.15, but since it seems there are some delays on its release and there are some nasty bugs I nailed down I decided commit the release now. It consists of - the kernel patch - new libax25 (in fact this did not change but I renamed it for consistency issues) - new ax25-tools - new ax25-apps Get the packages from http://dl0td.afthd.tu-darmstadt.de/~dg1kjd/linux-ax25/index.html http://dl0td.rmn.de.ampr.org/~dg1kjd/linux-ax25/index.html Changes: - Fixed LAPB state machine problem with retransmits - Fixed a race condition in protocol/driver interface which caused endless OOPS loop with IP-over-AX25 under certain conditions. - Fixed a nasty DAMA bug that prevented anything to be sent after a station was once connected and than closed all circuits. - Optimized scheduler - Optimized T2-handling - Optimized high-speed behaviour to fit megabit requirements - The old ax25rtd is back to work again. Note that this is still a temporary hack - ax25mond in ax25-tools package - soundmodem diagnostic utilities re-included in ax25-tools and cross- update with old ax25-tools-0.0.6 - PCISCC-4 driver update - EPPFLEX driver update - a little fix in 6pack driver - fixed ax25d-"cat /usr/bin/gdb-only-shows-32KB"-bug - ... -- Jens
