Re: RF transmission problem
On Thu, 10 Aug 2000, Steve Stuart wrote: Yes, I did edit ax25d.conf (smile). You can be confident that I'm not bootlegging your callsign. ;-) The radio baud rate is 9600, and I'm pretty sure the serial baudrate is as well. This is easy to check via minicom. How do I reset kiss mode without rebooting my pc? Entered "kissparms -x -p ax0", but minicom says /dev/ttyS0 is locked? Kissparms -x takes the TNC out of KISS mode but it's kissattach that locks the tty. You need to kill it. Probably easiest with "killall kissattach". -- Tomi Manninen Internet: [EMAIL PROTECTED] OH2BNS AX.25: [EMAIL PROTECTED] KP20ME04Amprnet: [EMAIL PROTECTED]
Re: RF transmission problem
On Thu, 10 Aug 2000, Steve Stuart wrote: I've just installed the ax-25 stuff, node-0.3.0-1.i386.rpm, libax25-0.0.7-1.i386.rpm ax25-tools-0.0.5-1.i386.rpm ax25-apps-0.0.4-1.i386.rpm on RedHat 6.2 system (2.2.14-5.0) with a pentium 133 and 80M ram. Recompiled/installed the kernal (and modules) with ham radio stuff enabled. Then set up /etc/ax25/axports with the line: "ax0 W8AN-4 9600 255 2 144.050 MHz (9600 baud)". Modprobe Wild guess: your TNC serial line bit rate is not 9600 but something else? That 9600 at the speed field of axports is used for the serial bit rate, not the radio bit rate. mkiss successful. Next "kissattach /dev/ttyS0 ax0 44.70.161.132" followed by "/etc/rc.d/init.d/ax25d start". Even setup a couple routes to Just to be on the safe side: Ax25d is not needed for outgoing connections or tcp/ip over ax25. And if you do want incoming connections, you did edit /etc/ax25/ax25d.conf right? Otherwise you'll be using my callsign... :) -- Tomi Manninen Internet: [EMAIL PROTECTED] OH2BNS AX.25: [EMAIL PROTECTED] KP20ME04Amprnet: [EMAIL PROTECTED]
Re: GW-List - Mkiss and Polled BPQ
On Tue, 8 Aug 2000, Albert D. Lawson wrote: The mkiss docs say that to use it with TNC's that have the polled kiss proms by G8BPQ that you use the -c and -p arguements. I have three TNC's on one serial port with BPQ polled kiss proms, the addresses are C, D, and E. So far, only one TNC is being polled, and it's not on the "port" it was assigned to be on. Are there any additonal arguements to pass the addresses of each prom onto mkiss so it knows what TNC's are there...??? No. Mkiss starts the addressing from TNC 0 and goes up from there depending on how many pty interfaces you define on the command line. I don't remember how the BPQKISS addressing goes but if it starts from A then you could try and define two dummy ports and then the three "real" ones. If the address is a hexadecimal number then I'd try to find an EPROM programmer... Has any one made this work before... Run mkiss and BPQKISS with polling and checksum enabled? Yes, that is what I wrote the support for. -- Tomi Manninen Internet: [EMAIL PROTECTED] OH2BNS AX.25: [EMAIL PROTECTED] KP20ME04Amprnet: [EMAIL PROTECTED]
Re: EPP adapter woes
On Wed, 2 Aug 2000, Jens David wrote: Once the interface is up, packets never come out the h/w even though listen -a shows them going. This is not so good. Check that in BIOS setup EPP version 1.9 is selected and/or check for a BIOS upgrade. In addition to that (this might sound a little but funny) change the cabling. The drivers have different timings (this is quiet critical). I have no experience with DOS but under Linux I too have noticed that the cabling is really critical. For example even a rather short length of flat cable can totally ruin the communication. This seems to make it a bit difficult with the older AT motherboards where the D-connector is not directly on the board... BTW I'm talking about the EPPFLEX hardware. Don't know if this is applicable to the older EPP adapter. -- Tomi Manninen Internet: [EMAIL PROTECTED] OH2BNS AX.25: [EMAIL PROTECTED] KP20ME04Amprnet: [EMAIL PROTECTED]
Re: KPPP problems
On Fri, 28 Jul 2000 [EMAIL PROTECTED] wrote: And once upon a time ham operators were helpful people Could I refer you some of the Linux Hams to the Amateur Code as published in the ARRL handbook for many years. The Radio Amateur is CONSIDERATE LOYAL PROGRESSIVE FRIENDLY BALANCED PARRIOTIC. A couple of replies to Marks VK3JMA plea for help certainly did not meet the critera needed to be an Amateur. Ok. Maybe the correct answer to the original plea would then be: "Mark, this list is not meant for such questions. Please consider subscribing to linux-newbies and asking there. Or perhaps Red Hat might be able to answer your question; there should be pointers to the correct place to ask somewhere in your distributions documentation." How does that sound? I am like Mark becoming involved with Linux simply to apply the new skill to my entertainment in amateur radio. This is the only group to which I subscribe and had assumed if I had a Linux question my fellow amateurs may be able to assist. Obviously you assumed wrong. Perhaps you are also a newbie in Internet? The purpose of this mailing list was sent to you when you subscribed. After a few years of Internet experience you will understand why it is rather important to stick to the meant purpose of a mailing list. Another point I get the feeling you guru's just what your private little club, well consider the demise of the RF side of the hobby primarily because of such attitudes. How many amateur controlling bodies are in a growth mode.?? No clubs here. It's a question of simple practicalities. I receive ~100 emails a day from several mailing lists. Some get more. If the signal to noise ratio drops too low on a list, I simply have to unsubscribe. Maybe I wouldn't be such a loss to this list but it would be yet another one, possibly having answers to relevant questions, off the list. A few off-topic posting every now and then doesn't really hurt, but they should be firmly discouraged. Believe me, a lot of the real guru's have already unsubscribed. And not because they feel they're somehow superior to you. It's because of practicalities. Let remember the Amateur code maybe even dust of the old handbook and reread it might make you all think to engage brain before tapping the fingers. I remember the time when the Internet used to be a place for educated and conciderate people. The code used to be "listen before transmitting". The so called netiquette (which almost was required reading before getting access to the Net) was truly understood and obeyed. Everybody would carefully observe if a given mailing list or news group was really the one to ask his or her question. Oh, those were the days. Sounds familiar? It should. The only difference is that here you can not transmit over someone else. But you can transmit in a completely wrong place. The consequences are just as "bad". -- Tomi Manninen Internet: [EMAIL PROTECTED] OH2BNS AX.25: [EMAIL PROTECTED] KP20ME04Amprnet: [EMAIL PROTECTED]
Re: NEWQPSK tests
On Sun, 23 Jul 2000, Hamish Moffatt wrote: Well, I was going to arrange a time and frequency where we could try to make contact. If nothing else I might leave a beacon running one day this week, if there's anyone hear who would try to copy it. I would be running Tomi's NEWQPSK modem for Linux, transmitting AX.25 packets using the 'beacon' program. Would anyone try to decode this if I set it up? Unfortunately I'm now back from my vacation and HF antennas are a problem but I might try to set up something. By the way if anyone here in EU is trying to connect to Joni's NEWQPSK station at 3590.0kHz LSB, it's now running 2500bps (8000sps), interleave=8 and fec=3. After some tests we decided that the 3000bps (9600sps) mode is too wide for most ham rigs and the high and low carriers are unnecessarily attenuated and performance thus degraded. 2500bps is much better at least in that sense. -- Tomi Manninen Internet: [EMAIL PROTECTED] OH2BNS AX.25: [EMAIL PROTECTED] KP20ME04Amprnet: [EMAIL PROTECTED]
Re: KISS over psuedo TTY
On Sun, 23 Jul 2000, Charles Brain wrote: What I am getting in my own task at the slave tty is sort of KISS data in that What I am actually receiving is 0x00 0xCC 0x07 everytime I ping. Strange. And somewhat hard to figure out without more info about what you are doing. If you want you can send me (off list) your config scripts and maybe a code fragment of your modem so I can see if I can find the problem. Is it me or is this listserver taking a couple of hours to reflect each message? The listserver. Vger is under a rather heavy load I'd think. -- Tomi Manninen Internet: [EMAIL PROTECTED] OH2BNS AX.25: [EMAIL PROTECTED] KP20ME04Amprnet: [EMAIL PROTECTED]
Re: KISS over psuedo TTY
On Sat, 22 Jul 2000, Charles Brain wrote: I am trying to set up a kiss link over a psuedo TTY without much luck. I can do it with slip not not it seems with KISS. I am trying to set up a link to my own application. the Kernel is 2.2.12-20 and I am using apps-0.0.4 and tools 0.0.5 Anyone have any ideas? How exactly does it fail? It should work just fine with the versions you mention (though upgrading to the latest wouldn't probably hurt). -- Tomi Manninen Internet: [EMAIL PROTECTED] OH2BNS AX.25: [EMAIL PROTECTED] KP20ME04Amprnet: [EMAIL PROTECTED]
Re: soundmodem
On Fri, 14 Jul 2000 [EMAIL PROTECTED] wrote: Before I go into a longish talk about transforms, I's, and Q's, is there anyone out there that regularly runs newqpsk? I'm loopback testing the modem on vhf fm and I get a 50% error rate. I run it somewhat regularly... :) Sorry that I didn't answer to your direct email, but I'm currently on a summer cottage 200km away from home and using GSM dada is a bit expensive. I'll reply later. That error rate is probably due to a somewhat ugly feature of the original modem desing. You see, after the symbol sync is acquired and the modem switches to data mode it just starts to feed the symbols through the (self synchronising) de-interleaver. However there is no way of knowing when avctually the sync sequence is over and valid data starts so there is bound to be several symbols worth of garbage at the beginning of every transmission. There is no way of counting the _real_ FEC errors... I've been thinking about reimplementing part of that but it'll mean that compatibility with the original modem is broken. I've used the afsk1200 baud modem in the linux kernel, I've also written a packet modem that works with the 'newqpsk' userspace soundmodem code. Both the modulator and the demodulator work on the air, but they're mainly a learning tool. Tom has already written modems for all the modes that the kernel driver handles. But as you said, writing them is good way of learning. -- Tomi Manninen Internet: [EMAIL PROTECTED] OH2BNS AX.25: [EMAIL PROTECTED] KP20ME04Amprnet: [EMAIL PROTECTED]
Re: Kernel IP routing bug
On Tue, 20 Jun 2000, Arno Verhoeven wrote: Robin Gilks wrote: Has anyone found a fix yet for the routing bug in 2.2 kernels that I highlighted about 5 months ago? Funny... Last weekend I saw the very same thing on our packet radio node. I was just about to send a question about this to the mailing list. I don't have a sollution for it, but I'm very interested in any ideas for a sollution. The solution is for someone to dig in the kernel networking code and find out what is going on. I once did that but as the networking code is rather confusing and the bug doesn't currently affect me, I soon lost interest. The other solution is to wait for SomeOne Else (tm) to do that Use the source Luke, that's why you have it. -- Tomi Manninen Internet: [EMAIL PROTECTED] OH2BNS AX.25: [EMAIL PROTECTED] KP20ME04Amprnet: [EMAIL PROTECTED]
Re: kissparams mkiss
On Thu, 8 Jun 2000, Richard Adams wrote: I belive Tomi has said before, you can ignore them, but for the record my comments. BTW; just about all of my ax25 stuff is modules. Jun 8 19:00:25 gb7cip kernel: kissparms uses obsolete (PF_INET,SOCK_PACKET) I have serveral machines all running kernel ax25 netrom, drivers include mkiss scc dxlmodem, i also get the obsolite message for; netromd and mheardd, but not from kissparms, further more i cant say i have seen your problem. The message can come from any program that uses the packet capturing interface the old way. These include kissparms, listen, netromd, mheardd, xfbbd... However the kernel only prints the warning once after a boot so what you see in your system logs depends on how you set up your AX.25. Anyway, once again, the message is completely harmless. It just warns us that sometime in the future this backwards compatibility feature will be removed and the program will stop working. All this has already been taken into accound in recent versions of ax25-tools/apps (if someone sees this message when using the very latest tools/apps please let us know). -- Tomi Manninen Internet: [EMAIL PROTECTED] OH2BNS AX.25: [EMAIL PROTECTED] KP20ME04Amprnet: [EMAIL PROTECTED]
Re: SCC causes kernel crash
On Wed, 7 Jun 2000, Paul Lewis wrote: Like others, I have been suffering with a problem since December 1999 when I switched from 2.0.35 kernel +ax25 to the new 2.2.13, 2.2.14 to the current 2.2.15. The problem I have is with the Ax25 code. (maybe nothing wrong with the code - I still have a problem to solve) The AX25 interface(s) normally one of the very busy ax25 interfaces. (they all run TCP/IP,AX25,NetROm over them) stop working decoding for AX25 data, yet the TCP/IP stack continues to work over the interface. Next time this happens, could you try "cat /proc/net/ax25" and if it succeeds send the output here. Also do you see anything strange in the system logs? -- Tomi Manninen Internet: [EMAIL PROTECTED] OH2BNS AX.25: [EMAIL PROTECTED] KP20ME04Amprnet: [EMAIL PROTECTED]
Re: SCC causes kernel crash
On Wed, 7 Jun 2000, Paul Lewis wrote: gb7cip:root /var/log # cat /proc/net/ax25 Segmentation fault gb7cip:root /var/log # tail syslog Jun 7 12:48:28 gb7cip kernel: Unable to handle kernel NULL pointer dereference Jun 7 12:48:28 gb7cip kernel: current-tss.cr3 = 00a06000, %cr3 = 00a06000 Jun 7 12:48:28 gb7cip kernel: *pde = On the console screen I get the memory dump related to the segmention. Can not seem to save that to a file. Other than write out the screen to paper for input on my internet connect PC. You seem to have somethign odd in /etc/syslog.conf or the kernel default message level. Try to fix that so you get the full register dump to your log file (hopefully with symbols resolved). Otherwise writing it to paper and running through ksymoops is the only way... The register dump with symbols resolved is the information were interested in. -- Tomi Manninen Internet: [EMAIL PROTECTED] OH2BNS AX.25: [EMAIL PROTECTED] KP20ME04Amprnet: [EMAIL PROTECTED]
Re: New install of linux
On Fri, 2 Jun 2000, Shane Deering wrote: I might leave RH 6.2 for a while or make an extra partition for it and have it as a boot option while working with 6.1. I wouldn't do that. I'd just go with RH6.2 and apply all the updates (that is what you should do anyway with any distribution). Applying the updates is very easy. -- Tomi Manninen Internet: [EMAIL PROTECTED] OH2BNS AX.25: [EMAIL PROTECTED] KP20ME04Amprnet: [EMAIL PROTECTED]
Re: About SQUID (dnsserver) ...
On Thu, 18 May 2000, r00t the LiNuXeRRR wrote: We resolve our problem with the cache dir. Now we have another problem ... Please solve that on some other list than linux-hams and stop crossposting to several mailing lists... -- 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, 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
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: [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
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: 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: sendmail problem
On Mon, 17 Apr 2000, Aaron Sethman wrote: What I do is on my systems is allow mail to be relayed from any 44.0.0.0/8 address. I don't know if sendmail supports this, but I do know that postfix does. Now all I need to do is hack LZW support into postfix, and I'll be happy :). Long time ago I did that to ZMailer but only on smtp server (incoming). If you want I could try to find the code. -- Tomi Manninen Internet: [EMAIL PROTECTED] OH2BNS AX.25: [EMAIL PROTECTED] KP20ME04Amprnet: [EMAIL PROTECTED]
Re: Attention UK netrom users
On Mon, 10 Apr 2000, Robin Gilks wrote: The other problem is, using 2.0.36 kernel, how do I get the netrom broadcast to send the alias as well as the netrom call. I've set nrports the same as a 2.2 kernel box which works OK. An adjacent node adds the call to its node list but no alias :-(( The sending node alias is part of every NODES broadcast sent by the node. It should work the same with regardless of the kernel version. Have you watched the 2.0.36 box sending the broadcasts? With listen -a on that box? From another box over the radio? Is there perhaps something strange in the nrports file on that box? -- Tomi Manninen Internet: [EMAIL PROTECTED] OH2BNS AX.25: [EMAIL PROTECTED] KP20ME04Amprnet: [EMAIL PROTECTED]
Re: Node query
On Mon, 10 Apr 2000, Robin Gilks wrote:
The line in my node.conf that is affected is:
Alias CONVers "telnet %{2:gb7ipd.ampr.org} 3600 \"/n %u %{1:160}\""
and its the bit in the quotes at the end that don't work no more...
Actually you'll probably find that the first part won't work either. You
won't be able to specify another convers server at runtime...
What does work is;
'telnet %{2:gb7ipd.ampr.org} 3600 "/n %u %{1:160}\n/w *"'
Changing the double quotes to single quotes and removing the escape character
from the double quotes fixed it!!
Not an obvious problem!!
The reason is that those %-escapes get processed twice: first when the
configuration file is read and later when the alias is actually executed.
The problem is that positional parameters (%1 and %2 in this case) don't
really have a meaning when the configuration file is read. They only have
a meaning when the alias is executed. So you need to be able to enter the
alias definition so that the %-escapes are not processed while reading the
config but only at alias execution time. That required a slight change in
the config syntax. The change is documented (see the HISTORY file,
node.conf(5) manual page and the sample files) but probably very easy to
miss...
The way it works is probably easiest explained with the example included
in the sample file:
ExtCmd TIme 1 nobody /bin/echo echo %N Node session started at %I, current time is \%I.
The %N will be expanded to the NodeId (at startup so NodeId needs to be
specified above this). %I will be the current time again at the time the
config file is read. The second %I has the percent sign escaped so it will
be expanded only when the extcmd is executed. (The same effect would have
resulted from enclosing it in single quotes: '%I')
I know this may sound confusing (I certainly was first confused when
trying to code it) but IMHO when you understand it, you'll see that it is
the only clean way of implementing it.
--
Tomi Manninen Internet: [EMAIL PROTECTED]
OH2BNS AX.25: [EMAIL PROTECTED]
KP20ME04Amprnet: [EMAIL PROTECTED]
Re: Unproto Path in AX25
On Mon, 10 Apr 2000, John Gorkos wrote: Background: I am running APRSdigi on my RedHat 6.1 box, with a MFJ-1278 hanging on ttyS0. I am using the modified AXtools from Alan Crosswell, N2YGK. Everything is working well (aprsmon allows TCP/IP connections, beacons are sent, etc.). What is "modified AXtools from Alan Crosswell" ? Problem 2: The beacon command I use looks like this: beacon -d APRS -t 15 ax0 'my beacon string' Unfortunately, with APRS being a UI-only protocol, my beacons don't get propagated through the APRS system. I need to be able to do something like this: beacon -d "APRS via WIDE,WIDE,WIDE" ... Is there an axparm that I'm missing in the documentation that will allow me to do this? Thanks. Have you tried beacon -d "APRS v WIDE WIDE WIDE" ... That should work. -- Tomi Manninen Internet: [EMAIL PROTECTED] OH2BNS AX.25: [EMAIL PROTECTED] KP20ME04Amprnet: [EMAIL PROTECTED]
Re: Unproto Path in AX25
On Mon, 10 Apr 2000, jerome schatten wrote: John... I went through this years ago running a 1278 in kiss mode on an fbb bbs. As soon as it receives a string which is the same as the KISSOFF command, it drops out of kiss mode. I can't remember what the hex sequence was, but it was reproducible. No-one was able to fix it, and it seemed true across all 1278's in this area. The "kiss off" sequence in hex is 0xC0 0xFF 0xC0 and it can never appear in a valid kiss data flow. So there must be more than that to it if it really was happening in response to serial data to the TNC. Long ago I had a problem with a Symek TNC2S with the TAPR firmware that came with it. It would just reset itself after a while. But IIRC it stayed in KISS mode, it flashed the LEDs three times and forgot the channel access parameters... Anyway it was a bug in the firmware. -- Tomi Manninen Internet: [EMAIL PROTECTED] OH2BNS AX.25: [EMAIL PROTECTED] KP20ME04Amprnet: [EMAIL PROTECTED]
Re: OT: T4 terminal program?
On Sun, 26 Mar 2000, Gerd wrote: sorry for being offtopic, but here at the list for me there was the only place the T4 packet radio terminal program was mentioned. I could not find it in the Internet, however. Does anyone know where to get it from? ftp://ftp.funet.fi/pub/ham/Finnish/oh2mkp/ I'm not sure if newer versions can be found anywhere on the net. The latest is something like 1.5a24. After that Mikko lost interest in it... -- Tomi Manninen Internet: [EMAIL PROTECTED] OH2BNS AX.25: [EMAIL PROTECTED] KP20ME04Amprnet: [EMAIL PROTECTED]
Re: Kernel based AX25 on Sparc?
On Fri, 24 Mar 2000, Geoff Blake wrote: I may be going off at "half cock" but during a spare moment at work today I was looking at compiling an "AX25 aware" kernel on a Sparc 10. I was doing about a dozen other things at the time, but it appeared that Menuconfig did not offer the same options as the usual i386 config. Should the Sparc Linux kerne source tree include the same AX25 utilities or is the RedHat 6.1 (2.2.12) distribution a stripped down version? (I did not have a recent kernel tree to hand nor did I want to d/load one over a 28K link!) An excerpt from the announcement of Alan's 2.2.15pre1 kernel: ... o Use amateur radio drivers on Sparc (Tom Sailer) ... Seems they were accidentally left off at some point. -- Tomi Manninen Internet: [EMAIL PROTECTED] OH2BNS AX.25: [EMAIL PROTECTED] KP20ME04Amprnet: [EMAIL PROTECTED]
Re: VC and datagram mode?
On Fri, 24 Mar 2000, Thomas Sailer wrote: "Wilson G. Hein" wrote: Is this a part of the current implementation of linux ax25 and x1j nodes? It's not in the stock kernel, however part of the DG2FEF/DG1KJD patch. No idea about x1j. It works in Flexnet and Xnet. Wampes also has some h2h ack code. In theory, you could also use net/rom to achieve this, but this adds overhead (net/rom header), a window size problem (if you don't use mod128 sequence numbers), and the original net/rom routing protocol is quite broken (INP is said to solve this though). On the other hand both Linux (current implementation) and X1J are capable of IP routing and support Virtual Circuit mode so if configured to do that the whole problem disappears. -- Tomi Manninen Internet: [EMAIL PROTECTED] OH2BNS AX.25: [EMAIL PROTECTED] KP20ME04Amprnet: [EMAIL PROTECTED]
Re: Syslog message: pg uses obsolete (PF_INET,SOCK_PACKET)
On Mon, 20 Mar 2000, Bent Bagger wrote: I am hunting an error in PG (the program for upload of files to the Microsats) and I have turned socket debug information on by doing a 'setsockopt(s, SOL_SOCKET, SO_DEBUG, opt, sizeof(opt)' call. When I inspect the system log, I now find this message: pg uses obsolete (PF_INET,SOCK_PACKET) This shouldn't depend on having SO_DEBUG on. You probably just haven't noticed it before. Also you only get it once after a reboot and it may be that you didn't see it because some other program has already got the complaint. So it depends on the order in which you run programs after a reboot. Could somebody please shed some light on the significance of this message, more specifically: what has been changed in the ax25utilities since the days of kernel 2.0.35 (I'm now on kernel 2.2.13 with glibc 2.1 and libax25 0.0 (?)) and what changes should I do in PG to make this message go away? Nothing changed in the utils, it's the kernels generic packet capture interface that was changed. The message is completely harmless (other than a program causing it may stop working sometime in the future if not fixed). You can get rid of the message just by changing PF_INET - PF_PACKET in the source. While that is actually also obsolete (see "man packet") I believe it will continue to work for some time still. I have not checked what it would take to properly use (PF_PACKET, SOCK_RAW) like suggested in the packet(4) manual page. -- Tomi Manninen Internet: [EMAIL PROTECTED] OH2BNS AX.25: [EMAIL PROTECTED] KP20ME04Amprnet: [EMAIL PROTECTED]
Re: DSP boards.
On Sun, 19 Mar 2000, Geoff Bagley wrote: I had not realised that stand-alone DSP boards were getting scarce. The Motorola DSP56002EVM was discontinued some time ago. Newer models are of course available but there is no direct replacement. There was a discussion on this topic on the TAPR DSPSIG (or was it HFSIG?) so if anyone is interested you can check the archives on TAPR home page. -- Tomi Manninen Internet: [EMAIL PROTECTED] OH2BNS AX.25: [EMAIL PROTECTED] KP20ME04Amprnet: [EMAIL PROTECTED]
Re: ARP Timeout problem
On Sat, 18 Mar 2000, F. D. Johnson wrote: Hi Folks, can anyone point me in tthe right direction ? My system (Suse6.3), when initiating any tcpip/radio session sends out 3 very rapid ARP requests then, more often than not, times out before the remote end has had chance to reply. Can I lengthen the ARP timeout ? Yes, through the proc interface. See /usr/src/linux/Documentation/proc.txt section Network Neighbor handling. The parameter you want to adjust is retrans_time. -- Tomi Manninen Internet: [EMAIL PROTECTED] OH2BNS AX.25: [EMAIL PROTECTED] KP20ME04Amprnet: [EMAIL PROTECTED]
Re: Q15X25 - newpsk.0.0.1
On Mon, 6 Mar 2000, Jörgen Overgaard wrote: Is there any one who has successfully compiled and run the Q15X25 (newpsk-0.0.1) package on RedHat 6.1?? Well, I still run RH6.0 but I really don't think there are any 6.1 spesific problems... For me it all compiles well,but when i try to start it with ./soundmodem it stops and shouts angry at me that threre is a problem with TIOCSETD. Do you have MKISS support compiled in the kernel or if it is compiled as a module, is the module loaded? After some VERY rude hacking in the code it runs a bit longer,but not much. Now it says it cannot open PTY "". (I understand that you cannot open "" nothing,but why is it trying) Better undo those hacks... :) Anyway there is a newqpsk-0.0.2 available in the same place you downloaded 0.0.1. There is nothing really new but the nasty tx-lockup bug mentioned in BUGS is fixed. Oh, and I should probably soon upload 0.0.3 as there is also a problem when running newqpsk with the standard sound drivers (I use ALSA drivers to develop). -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: pa4ab
On Mon, 7 Feb 2000, Gregory Maxwell wrote: On Mon, 7 Feb 2000, Ing. Jose A. Amador wrote: On Mon, 7 Feb 2000, Tomi Manninen wrote: Why not try Q15X25 (aka NEWQPSK). Download the package from http://www.hes.iki.fi/pub/ham/unix/linux/ax25/ and give it a try! I already got it, precisely from THAT URL, but have not compiled it yetIs anyone using it on HF ? Have I been out of the soundmodem loop too long or are all soundmodems now implimented as very nice userspace daemons like this one? As explained in the README file, I used an early beta version of a userspace implementation from Thomas HB9JNX as the core of my Q15 code. I stripped all the other modulator/demodulator libraries from my package in order to avoid confusion. Unfortunately it seems Thomas is so busy with more important projects (read work) so he hasn't been able to finish the soundmodem code. The beta I have used works, but still has issues to be solved and probably wouldn't work too well on a busy VHF channel. So were stuck with the kernel soundmodem implementation at least for a while. -- Tomi Manninen Internet: [EMAIL PROTECTED] OH2BNS AX.25: [EMAIL PROTECTED] KP20ME04Amprnet: [EMAIL PROTECTED]
Re: Routing problem
On Sat, 5 Feb 2000, Hamish Moffatt wrote: On Thu, Feb 03, 2000 at 07:36:57PM -, Robert A Jenkins wrote: For machines within the same subnet to work via an intermediate system, you must add specific routes to the target machines with the intermediate as a gateway. I set mine up in rc.local. Well, they are not really on the same subnet then if an active intermediate is required. Can you change the subnet mask to the correct value, which may even be 255.255.255.254? (I don't know that such a mask is actually supported to be honest..) I'm not sure but I don't think the subnet / netmask issue is of relevance here. The main point of the problem is that Linux 2.2 seems to refuse to send out an IP datagram on the same interface it came in. At least with AX.25 interfaces. I tested this at home by setting up a route to certain host through my only radio port. I tested that the route works from my machine and from another machine on my home ethernet. I then went to another site that is on the same frequency as mine (actually I dialed it up but anyway) and set up the route there to point _through_my_box_. With older kernels, this would have worked. With kernel 2.2 my box just throws the datagram away. -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
RE: Routing problem
On Fri, 4 Feb 2000, Robin Gilks wrote: Does anyone have a 2.0 system they can check to see if it behaves the same as 2.2 - be nice to know if this is a 2.2 problem only. If it is its move back time 2.0 lets you route back to the interface the datagram came in. I can verify that anytime on my home system. (despite other threads urging us to move on the bleeding edge). 2.2 is not bleeding edge... -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: Error opening terminal
On Mon, 3 Jan 2000 [EMAIL PROTECTED] wrote: I have two TNOS executables, the second just compiled for the y2k bug. When I try to run the new exe I get the following message: Error opening terminal: linux Probably it doesn't find the terminfo database. I guess the executable was compiled on another machine? Running tnos with strace might reveal where it expects to find the database and then you can add a symbolic link there. For example on one box I had to do ln -s /usr/share/terminfo /usr/local/lib/terminfo to get some old stuff running after upgrading the system. Possible places for where the database is and/or where tnos searches for it are /usr/lib, /usr/share, /usr/local/lib and /usr/local/share at least. -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: Linux FBB and Unproto list.
On Wed, 29 Dec 1999, Dirk Koopman wrote: Because I wish to receive packets addressed to generalised, as it were, "broadcast" addresses eg "DX", "ANN", "LINK" (these are examples, not necessarily real) as well as to my callsign. I also may want to gateway UI frames to callsigns that I know (by various higher level means) to be part of "my" network (i.e to "digi" UI frames selectively across ports according to heuristics under my control). The point of this that a reliable multicast protocol requires there to be some group addresses, for DX cluster work there are several logical groups that one could envisage including, but not limited to, "node-to-user" things, "network" things, "inter-user" things and so on. As well as multicast, there is a point to point message requirement that could be done by "normal" connected mode but I would prefer, for orthogonality, to also be done by a simple UI based, window=1, protocol. Some kind of braodcast/multicast method should probably be added to the AX.25 stack. But if you want that much flexibility it might be easiest to really use PF_PACKET. Sure you need root for that but only when calling socket(). I was not envisaging a PF_PACKET based thing - I understand why this is a problem. I was under the impression that we were talking about SOCK_RAW here and that that required root as well. Calling socket(PF_AX25, SOCK_RAW, ...) doesn't require root but then binding the socket to any local address other than your own does require it. Have you any sample code that does things with SOCK_RAW? I am perfectly happy to generate raw AX25 packets (I can do that bit), it is the ioctl and socket magic that I am confused (and cannot find any documentation for SOCK_RAW) about. SOCK_RAW with AX25 seems to be just about the same as SOCK_DGRAM except that when you receive you get the PID byte as well. Thus I'm not sure if it's really very usefull. -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: no more ipc channels
On Mon, 3 Jan 2000, Kjell Jarl wrote: Thanks Tomi, yes kill -9 my.script has been performed regularly. Seems to be a bad habit of mine, have to change it. Also, I may be doing wrong in the expect script, node simply is left in the dark? Well sending SIGKILL to terminate node certainly doesn't give it any chance to free the IPC message channel. Besides using SIGKILL should always be the absolute last resort when trying to make a process terminate. If you can't get node to exit cleanly you can send a SIGTERM or a SIGQUIT to it. -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: Linux FBB and Unproto list.
On Wed, 29 Dec 1999, Hamish Moffatt wrote: On Tue, Dec 28, 1999 at 04:39:06PM -, Dirk Koopman wrote: Please would you answer the question? Why does it _actually_ need root privileges for ax25 protocol traffic? We are talking here about something which, whatever you do, is insecure. Anybody can program a TNC to be any callsign. Anybody can monitor anything using a TNC. Why does linux have to be different? Because Linux tries to integrate AX.25 with Unix, rather than Unix with AX.25. It treats AX.25 like just another protocol; it should be as secure as IP. Obviously it is trivially easy to imitate someone else's callsign if you really want to, even with linux. But not without having root and/or hardware access to the system. Or that's how it is supposed to be. IMHO in this case root access doesn't have to mean a process running as root however. -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: Linux FBB and Unproto list.
On Tue, 28 Dec 1999, Dirk Koopman wrote: On 23-Dec-1999 Tomi Manninen wrote: On Thu, 23 Dec 1999, Leszek A. Szczepanowski wrote: Is ANY posibility to use unproto list (raw socket), running FBB as ordinal user, not root? I was looking in kernel sources, and found in AF_AX25 there is one 'suser' function checking if user has priviledges to open such a socket. I think it is uneseseary there, security solutions in this case aren't needed! What a stupid reason. If I'll make patch, to open raw socket for AX25 by any user, it will be placed on this list. Please don't distribute such bugs on this list. There are good reasons for why the unix security model is as it is. Besides, doing what you want (running FBB as non-root) would be fairly simple to do the right way. If you want to be usefull, just help Jean-Paul in doing that. Erm.. a "bug"? I am not at all sure that this is a "bug". I also cannot, for the life of me, see why a "feature" of this sort cannot be discussed here. Well, of course it can be discussed. Maybe my reaction was too strong. I would like to hear the reasons why this feature is "root only", especially bearing in mind that computers running ax25 should be amateur use only. Amateur use only? Why? Running ax25 stacks on "commercially sensitive" machines especially with ax25 programs running as root (UI generating or not) strikes me a security exploit waiting to happen! There is _NO_ need to have root privileges after opening the socket! Just drop them and suddenly you have 100% secure application. The stack it self should be secure. Unless some bright one decides to distribute a patch removing super user checks... For the record, I too would like to be able to both receive and generate UI frames from programs that are non-root. This is going to become an issue during the course of the year with my DXSpider cluster program. Generating UI frames as non-root is easy, just use a datagram socket. Receiving should be just as easy but I haven't tested. Of course you are then restricted to your own source call. -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: Error compiling libax25
On Fri, 17 Dec 1999, Hamish Moffatt wrote: On Wed, Dec 15, 1999 at 10:25:03PM +0200, Tomi Manninen OH2BNS wrote: On Wed, 15 Dec 1999, Hamish Moffatt wrote: On Wed, Dec 15, 1999 at 02:24:43AM +, Jorge Matias wrote: Probably you don't have symbolic links: /usr/include/asm to /usr/src/linux/include/asm-i386 /usr/include/linux to /usr/src/linux/include/linux And be glad that you don't, because you shouldn't. Oh? Really? Then how come a _LOT_ of my glibc headers include linux/*.h and/or asm/*.h ? Is glibc supposed to replace all those some day (good luck!) ? Anyway a small correction: /usr/include/asm should point to /usr/src/linux/include/asm not asm-i386. Including linux/*.h and asm/*.h is fine. The glibc kernel headers include the files in /usr/include/linux and /usr/include/asm directly; they are not links into /usr/src/linux (there is no need). Well, this simply is not true with Red Hat, at least not on 6.0 that the original question was about. If you need the exact .h files for the current kernel, you should get them out of /usr/src/linux/include directly using -I. On Debian at least, /usr/include contains the header files provided by glibc, and not the current kernel versions. Craig's ax25-tools sources cope just fine with this. Yes, you told us that could compile the tools with 2.0.35 kernel in your /usr/src/linux. Well, do those tools work if you really run that kernel? ... I didn't think so. I rest my case. -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: Error compiling libax25
On Fri, 17 Dec 1999, Craig Small wrote: Tomi Manninen OH2BNS said: On Wed, 15 Dec 1999, Hamish Moffatt wrote: On Wed, Dec 15, 1999 at 02:24:43AM +, Jorge Matias wrote: Probably you don't have symbolic links: /usr/include/asm to /usr/src/linux/include/asm-i386 /usr/include/linux to /usr/src/linux/include/linux And be glad that you don't, because you shouldn't. Oh? Really? Then how come a _LOT_ of my glibc headers include linux/*.h and/or asm/*.h ? Is glibc supposed to replace all those some day (good luck!) ? A lot? Hmm, I have approximately 20 headers including linux/*, mostly in the net,netinet and sys areas and they're probably grabbing magic numbers and about 10 headers including asm/* also mostly in netinet and sys. Ok, maybe the "a lot" part was a bit exaggerated. I have resisted the temptation to launch into yet another tirade at the totally brokeness of some distro's headers. Most people know my opinions already about that. I hope you don't mean Red Hat and the netax25/*.h fiasco. Because that wasn't at all Red Hats fault. We could try to blame the glibc folks but that too were unfair. No, it's us, the ax.25 developers who are to blame. Yes, the general idea is to remove or reduce the number of linux/*.h and asm/*.h headers and other headers that include them. There are very good reasons for doing so. Out of curiosity: How do they intend to cope with kernel api changes? Like the one we had in 2.0.35 - 36 and again 2.0.x - 2.2.x (and probably 2.2.x - 2.4.x). I hope they have a plan. -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: Error compiling libax25
On Wed, 15 Dec 1999, Hamish Moffatt wrote: On Wed, Dec 15, 1999 at 02:24:43AM +, Jorge Matias wrote: Probably you don't have symbolic links: /usr/include/asm to /usr/src/linux/include/asm-i386 /usr/include/linux to /usr/src/linux/include/linux And be glad that you don't, because you shouldn't. Oh? Really? Then how come a _LOT_ of my glibc headers include linux/*.h and/or asm/*.h ? Is glibc supposed to replace all those some day (good luck!) ? Anyway a small correction: /usr/include/asm should point to /usr/src/linux/include/asm not asm-i386. -- Tomi Manninen Internet: [EMAIL PROTECTED] OH2BNS AX.25: [EMAIL PROTECTED] KP20ME04Amprnet: [EMAIL PROTECTED]
Re: Config help required..
On Fri, 10 Dec 1999, Rob Compton wrote: Hamish, after loading soundmodem.o/baycom.o/yam.o module and correctly configure this driver we got network device, such as sm0, bc0 etc. This device can be used for IP over AX25, but, we can't make simple 'call' for connecting to other station and use this device in LinuxNode/xfbbd etc ... For this utils we need to make KISS stream w/net2kiss (man net2kiss), and w/kissattach create standart AX.25 port. Now I'm confused more. In my YAM docs, it says nothing about kissattach to use the port for xfbb. Don't you just love incomplete documentation. Looks like I'll have to go all the way through my config and do some more work! No, no! Don't panic. What Yuri says above isn't true. -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: Route
On Mon, 29 Nov 1999 [EMAIL PROTECTED] wrote: I need help to lock a route in net/rom. Sk7hw is heard on my port1 but i cant connect this way. My connectway is on port2 via sk7bk-5. How can i lock the port so that the connection goes the right way? I have tryed nrparms -nodes sk7hw-5 - vxo 50 5 port1 to remove it from the list. When sk7hw sends out nodeinfo it comes back. How? You can not lock a node in Linux. What you can do is lock a route (a neighbour). If you lock the quality of that particular neighbour (sk7hw on port1) to a low value, the node routes it advertises won't be used except as a last resort. Locking a route is of course done with "nrparms -route". However if there are also no other "good" neighbours on your port1 frequency it might be a better idea to lower the default quality for that port in /etc/ax25/nrbroadcast. The effect will be the same but it will by default affect all neighbours on that port. -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: Interesting High Speed Engineering Project from WSU
On Sun, 7 Nov 1999, Cathryn Mataga wrote: Yeah, I wonder if it would work just sending raw TCP/IP without any ax25 headers at all. Aren't the crc's and packet lengths and all that stuff just transmitted twice? I'm not sure. Need to include amateur callsigns in there somewhere, though, since IP addresses aren't official identification. Or do we need the callsigns in every single packet? US-wise, I thought we only needed to ID every 10 minuts. I guess we still need some sort of MAC level addresses anyway. Ethernet has them too. IP over AX.25 in datagram mode actually isn't much more than AX.25 addresses in front of an IP frame. Is Van Jacobsen compression used? I haven't used TCP/IP over AX.25 yet, still waiting on an IP allocation. VJ header compression is routinely used on dialup PPP links, and if a link that fast (comparatively) can benefit from it, I suspect our links could too. My understanding is that tcp/ip headers are not compressed. I believe every packet goes out with an ax25 header and a TCP/ip header. Isn't some kind of header compression going to be part of the 2.3/2.4 kernels? Does *NOS understand any kind of header compression? Matthias' new AX.25 stuff supports VJ compression over connected mode AX.25. VJ won't work with datagram mode as it depends on the incoming frames being ordered. -- Tomi Manninen Internet: [EMAIL PROTECTED] OH2BNS AX.25: [EMAIL PROTECTED] KP20ME04Amprnet: [EMAIL PROTECTED]
Re: Virtual console corrupted with xfbbC
On Tue, 2 Nov 1999, Alexandre Fornieles wrote: When i start a chat with a user connected to FBB, with '=F1CAY', the concole gets completely corrupted. Characters become unreadable and it remains in this state even when leaving xfbbC and logging out from that console. I mean, there are characters, but they're not displayed as normal letters but as strange symbols that are mixed with a few readable normal letters. It just remains unusable and haven't found yet how to restore it until i reboot the machine which does not happen so often. Try typing "reset" when you get back to the shell prompt and see if that helps. The problem is possibly that you receive the "switch to alternate character set" -character. That happens often here when one reads a packet bbs message written with the DOS character set (IBM codepage 437) and someone or something has stripped the 8th bit. The "ö" (o-diaresis) character then becomes the switch character... I wish people would start to use ISO character sets on packet too. -- Tomi Manninen Internet: [EMAIL PROTECTED] OH2BNS AX.25: [EMAIL PROTECTED] KP20ME04Amprnet: [EMAIL PROTECTED]
Re: QRZ! + node
On Thu, 28 Oct 1999, James S. Kaplan KG7FU wrote: Actually, I was looking to usse the cdrom and perhaps the unix/linux files supplied on it. If there is a command line tool to query a callsign then interfacing that to LinuxNode should be simple. Just use the extcmd facility, probably you want to use the "pipe" flag there. See the node.conf manual page. -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: mkiss.c: uninitialized function (kernel)
On Wed, 27 Oct 1999, Jorge Matias wrote: gcc -D__KERNEL__ -I/usr/src/linux-2.2.13/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=586 -DMODULE -c -o mkiss.o mkiss.c mkiss.c: In function `kiss_esc_crc': mkiss.c:805: warning: `c' might be used uninitialized in this function Anyone knows if this is a possible problem? http://www.hes.iki.fi/archive/linux-hams/199910/0139.html -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: TCP/IP config/connect problem
On Tue, 26 Oct 1999, Ron Jochems wrote: Can you help me find the archive .?. Is it online, or also downloadable.?.. http://www.hes.iki.fi/archive/linux-hams/ -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
/proc/.../neigh interface (Was: Re: TCP/IP config/connect problem)
I wrote: PS. Does anyone have a pointer to a document describing the /proc/sys/net/ipv4/neigh/ interface? /usr/src/linux/Documentation/proc.txt (searching for a brown paper bag...) -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: Killing KIssattach Kills Linux!
On Mon, 25 Oct 1999, Joachim Holst wrote: What makes you (two) think the crashing is caused by anything AX.25 related? Do you see something AX.25 related in the Oops dump when it happens? If so, what? Please give us something usable to work with. Find the Oops in your system log and send it here for us to see or if your machine freezes before anything gets written in the log then write the Oops down and run it through ksymoops. From my side, it's a very loose guess. Since I didn't have this problem with older kernels 2.0.x and the old AX25 utils but I do now with new kernel and old AX25 utils, I found it quite natural to assume that it was related with incompatible AX25 utils. Well, I don't find that very natural at all. There are million other things that changed in the kernel between 2.0.x and 2.2.x. It's actually much more probable that the problem is elsewhere. BUT, if you can show us an Oops trace (symbols resolved) with something AX.25 related then we can start debugging... The old ones don't compile on a 2.2.x kernel (at least not the last time I tried) and neither did the new AX25 libs. I know that newer versions have been released that do compile on a RedHat system (the reason why they didn't compile earlier, weas RedHat related). Installing the new lib/tools/apps is very simple and there are now even RPMs available. Anyway if the problem turns out to be this (old utils) then it still is a kernel bug. No usermode application should be able to crash the kernel, even a faulty one! -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: nrparms command error with new ax25 tools
On Thu, 21 Oct 1999, Arno Verhoeven wrote: Everything is looking pretty good except the nrparms portion of my startup script. When it executes an nrparms command directly in the script ... and when it runs the embedded nrparms command in the nodes.save file saved by the nodesave command, it reports the following error: nrparms: SIOCADDRT - invalid operation A bug in nrparms. I'd recommend you get the RPMs from the Red Hat Powertools 6.1 collection and try those. That particular bug is fixed there. Is there a diff available that fixes his problem? It's now available at ftp.hes.iki.fi aka ftp.oh7lzb.ampr.org: ftp://ftp.hes.iki.fi/pub/ham/linux/ax25/ax25-tools-0.0.5-oh2bns.patch.gz -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: Baycom installation fails
On Fri, 22 Oct 1999 [EMAIL PROTECTED] wrote: No error messages whatsoever. Still the device /dev/bc0 (51,0) remains dead. I also read about the new devices bcsf0 etc., but those do not exist on my system. I'd like to create them using mknod, however I do not know which major number to use. The new baycom devices are _network_ devices and they don't have an entry in /dev/. Try "ifconfig bcsf0" to see if the network device is there. -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: nrparms command error with new ax25 tools
On Fri, 22 Oct 1999, Kai Altenfelder wrote: It's now available at ftp.hes.iki.fi aka ftp.oh7lzb.ampr.org: ftp://ftp.hes.iki.fi/pub/ham/linux/ax25/ax25-tools-0.0.5-oh2bns.patch.gz Is this patch needed for every distribution or for RH only? The patch fixes a bug in nrparms and in the user_call set of utils. It's not Red Hat specific. -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: Notebook and Linux/AX25.....
On Mon, 11 Oct 1999 [EMAIL PROTECTED] wrote: On 10 Oct, richadr wrote: I want to buy a notebook, but it must be able to run Linux (preferably SuSE 6.2). Anyone out there that can tell me something about the possibillities and impossibillities or perhaps redirect me to the right news-group? Richard, Just about any notebook should work fine. There is a Linux LapTop-HOWTO (http://www.linuxdoc.org/) that should provide hints and pointers to what to buy and what to watch out for. The usual precautions apply: treat it as a PC with hardware that you can't easily change, make sure the hardware is supported. And since we are talking about possible ham use, you might want to make sure the soundcard is well supported in general and preferably by the soundmodem too. I believe quite a few laptops have cs423x based soundcards so one of them might be a good choise. -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: TCP/IP config/connect problem
On Sun, 3 Oct 1999, Elan Portnoy wrote: I have kernel based ax25 connects working ok. The trouble I am experiencing is with my TCP/IP connections. My IP is 44.68.48.216, the IP of the nearest node is 44.68.48.1. I used ifconfig to set ax0 with my IP and added the route to the 44.68.48.0 network. When I try a telnet, the transmitter quickly kicks on and off several times and I get "No route to host" error message. Most probably your ARP query times out. For some reason the new kernels have very short timeouts. One solution is to enter a manual ARP entry for the gw and then route everything through it. Another solution (in some cases a better one) would be to fix the timeouts. Someone posted howto do that on this list a few weeks ago. Maybe you can find it in the archive. PS. Does anyone have a pointer to a document describing the /proc/sys/net/ipv4/neigh/ interface? -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: Problems compiling ax25-utils-2.1.42a
On Tue, 28 Sep 1999, Jaime Robles wrote: Hello all! I am having BIG problems with the last ax25-utils... Since i update to linux 2.2.12 (from 2.0.36) my ax25 connection stopt working... I only used "call" to connect the DX-cluster, but for a week or less i have been "fighting" the PC and i have been unable to make the call work! The problem i got when i try "make" in the ax-util directory is: gcc -Wall -Wstrict-prototypes -O2 -c -o procutils.o procutils.c procutils.c: In function `read_proc_ax25': procutils.c:36: `errno' undeclared (first use this function) procutils.c:36: (Each undeclared identifier is reported only once procutils.c:36: for each function it appears in.) Umm... Are you trying to compile ax25-utils-2.1.42a? Forget that. Remove everything that was installed by that in the past. Then get the latest ax25-lib/tools/apps from ftp.hes.iki.fi, configure and install them as described in the INSTALL file that comes with each package. (I recommend using the "--prefix=/usr ..." stuff when configuring.) I start the ax25 with: kissattach -m 512 -v /dev/tnc radio 44.133.228.22 ^^^ Then i get: ea4abw:~/.pgp# tnc.bat kissattach: 0.0.5 That's the problem. The "-v" option causes kissattach to display the version number and _exit_immediately_. So your kissattach line doesn't do anything. Remove the "-v" and try again. BTW. Judging from the kissattach version number you obviously have already installed ax25-lib/tools/apps. Why are you trying to compile ax25-utils? -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: AX.25 Layer 1
On Tue, 28 Sep 1999, Dirk Koopman wrote: On 28-Sep-99 Samuel A. Falvo II wrote: I'm looking for the physical characteristics for AX.25, as used on the VHF bands. Any ideas? Would they be on tapr.org? (Of course, I'll look there anyway, but it doesn't hurt to ask.) layer 1 = bell 202 tones. Just to be sure we don't confuse anyone here: The AX.25 specification makes no attempt at defining layer 1 issues. It is however true that on VHF the most popular signaling method is AFSK with bell 202 tones (1200Hz and 2200Hz) with signalling rate of 1200 bps. Also HDLC bit stuffing and NRZI is used. -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: Problems compiling ax25-utils-2.1.42a
On Wed, 29 Sep 1999, Dirk Koopman wrote: I am confused. Are the new ax25 tools a complete replacement for 2.1.42a on all kernels (ie 2.0.35 upwards) or just 2.2.x kernels or 2.3.x kernels? The lib/tools/apps are an almost complete replacement for the utils for 2.2.x kernels. Almost complete means that some packages that previously were in utils are now distributed separately. Like node for instance. Anyway mixing ax25-utils and libax25/ax25-tools/ax25-apps is asking for trouble. -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: Antwort: Re: new kernels
On Wed, 22 Sep 1999 [EMAIL PROTECTED] wrote: Hi Tom , tnx for the reply, now I'm getting really confused, as I have already set the retry timers to linear, but they still behave as exponential timers. I was told that the kernel timers in 2.0.36 are exponential, Can this be clarrified ? The AX.25 T1 (retry) timer has three modes in the linux implementation. First is no backoff, second is linear backoff and third exponential. (The numbers for the sysctl interface are 0, 1 and 2 respectively.) AFAIK the timers work just fine both in 2.0.x and 2.2.x. But if you either telnet or ftp kernel to kernel over a not to good path, once a couple of packets have been missed the backoff time just get worse. I cant do much about the path , it got a big lump of iron ore in the way, it a great microwave reflector !!! but if I can improve the rate of retry attemps it would help.. You are talking about the TCP timers here. Nothing to do with the kernel AX.25 implementation. That code is done by completely different people and I doubt we have much chances of getting that changed. Everything except exponential TCP timers is simply concidered evil in the real world. (However Jonathan did a patch long time ago that set the TCP timers to be linear. Jonathan called the patch something like "the evil sick TCP timer patch...") the retry timers in tnos can be set to linear and when set are linear, the Tampa convers server, and the modified and cleaned up variant HTPP also behave linearly. This however confuses me. Are you saying that you are using HTPP, a normal Linux application, and TNOS timers have an effect on convers connections? -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Patch for kernel 2.2.12
Hello all! I meant to send this last weekend but... Anyway according to Alan kernel version 2.2.13 is still at least a couple of weeks away, so I uploaded my patch to hes.iki.fi for people to test. The patch can be downloaded at: ftp://ftp.hes.iki.fi/pub/ham/linux/ax25/linux-2.2.12-bns.diff.gz or ftp://ftp.oh7lzb.ampr.org/pub/ham/linux/ax25/linux-2.2.12-bns.diff.gz The patch is also already included in Alans linux-2.2.13preXX kernels (at least it is in pre10). This patch fixes the "unknown address family" bug that people have seen with node and possibly other programs using the getpeername() and getsockname() system calls. The patch should also finally once and for all fix the "crash on ifconfig ax0 down" bug. If and when people are testing this, please make sure you don't have any of the other "fixes" that have been proposed to fix this one. I'd like people to verify that this really is The Correct Fix (tm). Finally there is a small change to the netrom loopback mechanism. If you have ever experianced an oops or crash relating to this (if you've seen an oops dump in your system log with nr_loopback_timer() mentioned) I'd like to know about it. PS. Note that much of the credit for finding the getpeername bug goes to Cathryn Mataga. Thanks Cathryn! -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: Antwort: Re: new kernels
On Wed, 22 Sep 1999, Richard Adams wrote: Well the way in which i would do it, a way which has been flamed many times is the same way G4KLX once sent out a patch for, i have los the patch, but the idea is just change the default max backoff time from 120 seconds to what ever you want, i still use 60 for a link which plays up every now and again. I use 2.0.36, but looking at 2.2.x code its the same so i see no reason why it should nopt work. I seem to remember Jonathan had a patch that really made the timers linear (as I said in the other email). Anyway I have also used the method you describe above a few times. -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: Kernel 2.2.12 select()/accept() broken ?
On Tue, 14 Sep 1999, Cathryn Mataga wrote: I had that problem on my system (RedHat 5.1, kernel 2.2.9). Because I couldn't solve the problem, I decided to reinstall on a new harddisk the latest RedHat with the 3 ax25 packages. Guess what? LinuxNode started to work again perfectly fine. Yup, the nature of this thing is that it's likely completely random in how or when the bug strikes. I think 'node' was unusually succeptible, for reasons which are no fault of node at all. Is someone going to upload a kernel patch on ftp.hes.iki.fi or radio.linux.org.au? Err how is this kind of bug normally handled. I have prepared a patch that fixes this (also for ROSE, NET/ROM was ok all along) and some other stuff. I'll submit it to Alan today and ask him about the release schedule for 2.2.13. If it takes very long I'll put the patch available somewhere. -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: Kernel 2.2.12 select()/accept() broken ?
On Mon, 6 Sep 1999, Jan Wasserbauer wrote:
Hi everyone on the list ..
Part of checklogin() function:
...
tv.tv_sec = 0;
tv.tv_usec = 0;
if (select (maxsock + 1, rfds, NULL, NULL, tv) = 0)
return;
for (i = 0; i listen_sock_num; i++)
{
if (!FD_ISSET (listen_sock[i], rfds))
continue;
addrlen = sizeof (struct full_sockaddr_ax25);
ret = accept (listen_sock[i], (struct sockaddr *) newconn, addrlen);
...
This does work OK with any kernel below 2.2.12.
With 2.2.12 accept() does not correctly fill sockaddr struct
when tv.tv_sec=tv.tv_usec=0 (some binary mess instead of callsigns)
It works when tv is nonzero.
Reffering to select() man page tv=0 should cause select
to check descriptors and exit immediately (and not just
break accept() :) )
To me it seems like kernel bug ..
This sounds very similar to the problem _some_ people have had with
LinuxNode on 2.2.x kernels. The most visible symptom of the bug is that an
incoming AX.25 connection to the node fails immediately and a message
about unsupported address family is logged in the syslogs.
Also seems that in these cases ax25d logs the connection as coming from
port (null).
At least in node the problem seems to be that a
getpeername(s, addr, len) system call returns with len==0 and bogus data
in the addr struct. The ax25d problem could be similarly failing
getsockname() but I haven't been able to verify that (see below).
It's noteworthy that this has happened to different people with different
2.2.x kernels, with different ax25d and node versions, different
distributions with different libc... For one guy this all suddenly went
away as he upgraded to RH6 but I've had reports on that platform too...
It's also noteworthy that I haven't been able to duplicate this error EVER
on ANY kernel version, including 2.2.12. This makes debugging very
difficult... :(
My system - Slackware 4.0 (gcc2.7.2.3, libc5.4.46)
If this is known bug I hope this at least saves some time
to people wondering why their software doesn't work with 2.2.12.
--
--- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: ax25_get_info() - TNTBayCom modem
On Mon, 6 Sep 1999, Jan Wasserbauer wrote: Is there any reason why linux/net/ax25/af_ax25.c - ax25_get_info() disables interrupts ? Probably because ax25_get_info reads kernel internal tables that could be changed from an interrupt. You would crash the kernel nicely if you happened to be just reading an ax25 control block that is suddenly removed from an interrupt... This causes problems with BayCom modem (and possibly others) since its driver cannot receive interrupts from serial port while something is reading /proc/net/ax25. TNT reads it every 300ms which makes it unusable with BayCom modem (255B packets just can't get into 300ms on 1200bd) IMHO TNT is broken in this case. Why does it need to read it so often? Ah, don't tell me, the DOS version shows that info too...? ;) PS: strerror() returns inet-style link state messages which are sometimes quite confusing to PR users (like "Connection timed out"). Why is that confusing? Timed out _is_ timed out. What about some ax25_strerror() (in libax25 probably) which would return PR-style warnings (like "Link failure") ? This on the other hand is under concideration already. It is possible Craig has already written some code, I don't know. Anyway it will be only error messages that are specific to libax25, eg. "Invalid callsign", "Port xxx not active" etc. -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: ax25ipd errors out
On Thu, 2 Sep 1999, Peter Grace wrote: device /dev/ttyS0 (error was 'fetching tty device parameters: Invalid argument') Don't know whats wrong here. Oh, except in the script below you have already used ttyS0 for kissattach. You can't of course have two processes use the same serial port at once. device /dev/ttyp0 (I/o error) and also /dev/ttyq0 (i/o error) These are both slave ends of a pty/tty pair. I guess you don't have anything in the master end (I don't see anything in the script below). That would cause exactly the error message you get. In case you didn't know the pty/tty pair (or pipe) has two ends that are not quite equal. The pty one (eg. /dev/ptyp0) is the master and it needs to always be opened first. Also if the process that opened the master end dies or otherwise closes the master end, the slave end will instantly get an I/O error. So what you seem to miss is a kissattach process opening and doing the kiss stuff at the master end. After that you can start ax25ipd. /usr/sbin/kissattach -i 44.56.20.25 -m 512 /dev/ttyS0 radio /usr/sbin/axparms -assoc kb1cvh pgrace /sbin/route add -host 44.56.20.0 ax0 /sbin/route add ax0 /usr/sbin/kissparms -p radio -t 300 -s 300 -r 25 /usr/sbin/nrattach -i 44.56.20.25 -m 512 netrom route add 44.56.20.25 nr0 /usr/sbin/ax25ipd /usr/sbin/ax25d /usr/sbin/netromd -i -t 120 /usr/sbin/mheardd /usr/sbin/nrparms -routes radio K1CF-1 + 120 /sbin/route add 44.56.14.11 nr0 /sbin/arp -t netrom -s 44.56.14.11 K1CF-1 /usr/sbin/nrparms -nodes KA1TUZ + BBSTUZ 120 5 radio K1CF-1 /usr/sbin/nrparms -nodes KA1TUZ-11 + "*" 120 5 radio K1CF-1 /usr/sbin/nrparms -nodes WZ1L + BBSWZL 120 5 radio K1CF-1 /usr/sbin/nrparms -nodes WB1DSW-2 + EKINGS 120 5 radio K1CF-1 /usr/sbin/nrparms -nodes W1UU + MASS 120 5 radio K1CF-1 /usr/sbin/nrparms -nodes WZ1L-5 + POWOW 120 5 radio K1CF-1 /usr/sbin/nrparms -nodes K1TR-10 + WHDHM 120 5 radio K1CF-1 /usr/sbin/nrparms -nodes K1UGM + BBSUGM 120 5 radio K1CF-1 -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: New lib,tools and apps
On Thu, 26 Aug 1999, Craig Small wrote: Bob Meyer said: Craig Small wrote: The latest lib, tools and apps for ax25 are out. The main difference between this version and the last is I finally got my act together and put Tomi's patches in. Call is broken here, on Redhat6. Executing any of the menu commands causes a "Segmentation fault". This is very strange because the patch changes one value to be static and the rest is just cleaning up of the configure script so it detects broken redhat includes properly. Don't tell me those library/includes are broken in yet another way. Actually not even that. The patch removes a compiler warning by explicitly declaring the variable "int". Before it was implicitly declared "int" by the compiler. So that can not be the problem. My guess is there might a problem with ncurses. Red Hat 6 might have a version on ncurses that call isn't quite compatible with. If I understood Richard correctly this segfault has been there in previous versions too? -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: Is Netrom/node ok in 2.2.5 ?
On Tue, 24 Aug 1999, pa3gcu wrote: I have Redht 6.0 libax25-0.0.5 ax25-apps-0.0.3 ax25-tools-0.0.4 installed following the INSTALL and README, however NETROMD gives; Aug 19 20:16:55 pa3gcu netromd[]: netromr: SIOCADDRT: Invalid argument I have a bpq interface between two computers. Installing the netromd from ax25-utils-2.1.42a solves this problem. Try installing the new libax25, ax25-tools and ax25-apps that Craig announced just today and tell us if that fixed the problem. It should. -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: listen utility and permissions
On Fri, 20 Aug 1999, Gerd wrote: Hmm *thinking*... I thought you need root permissions in order to open the socket? Did you have a version of listen that used to have only that part for opening the socket set to UID root? How about two different versions of a listen utility? So it would depend on the remote server's admin whether stupid users are able to trash the links or not :) I think you are missing the point. In the new ax25-tools nothing has been changed in listen (well some formatting changes have been done but anyway). It's just that "make install" doesn't set the setuid bit anymore. Craig gave the explanation why and I think it makes perfect sense. BUT. You have the root password so you can do whatever you want. If you want everyone to be able to "listen" then just set the setuid bit. By playing with the file ownerships and permissions you can even make it so that only certain regular users can "listen". This is Linux, all that is possible. -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: listen utility and permissions
On Thu, 19 Aug 1999, Ronnie Hale wrote: I'm with you on this too, Gerd. Fortunately, there exists such a program, TNT. TNT is similar to SP (Eskay Packet), and while it works as a front-end to DPBOX, it is also an excellent stand-alone packet terminal program. It doesn't have the million or so remote features as SP, but it isn't as complicated to set up. It will work with Linux kernel/ax25 ports, hostmode tnc, kiss tnc (via tfkiss driver). It has //mheard (selectable) for remote users, real-time monitor window in terminal (like SP 3-way split screen), F11 monitor channel, huffman encode/decode in terminal qso and monitor, Extended monitor (to monitor a specific callsign qso). Lots of goodies us old-timer packet operators enjoyed when using Stupid programs like SP, GP, etc. Did I say these programs are stupid? No, I didn't. I said the platform they run on sucks and thus required them to be designed as they are. That doesn't automatically make the desing good or bad. I'm just slightly annoyed everytime someone goes "it works this way on DOS, why the heck does it work differently on Linux." -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: listen utility and permissions
On Wed, 18 Aug 1999, Gerd wrote: Hello Tomi, hello all, I don't see the need for such an elaborate arrangement, at least if the only reason was to replace the current "listen". Listen has no user interaction and it should be pretty easy to make sure it has no buffer overflows or other security risks. So there really isn't any reason a sysop couldn't make it setuid root if he/she wants to. It's just that now it isn't setuid root by default. A thing that should be mentioned in the HOWTO, though. Of course. But I was thinking a little bit further. Packet Radio terminal programs that want to be able to monitor and show the traffic on the QRG (similar to let's say Eskay Packet under DOS) have to open and establish interaction with the same socket as the listen program. Ahem, well, the reason Eskay Packet under DOS or similar systems under DOS/Windows have a band monitoring tool built in is that on those (stupid) platforms something as simple as "listen" is not possible. IMNSHO there is _no_ reason to duplicate that kind of design in Linux. Linux is a good multitasking operating system and the networking model nicely permits running these things in separate programs that are well designed for their purpose. You won't run out of virtual consoles on Linux unless you are doing something really weird to occupy all of them. With X there is of course no limit in that sense. In another mail Heikki Hannikainen [EMAIL PROTECTED] mentioned setting only certain program parts UID root since this is only required to _open_ the socket. Is this at all possible? Until now, I thought that only whole programs could be set to run under UID root. Yes, it is possible. I recommend reading the man pages Hessu mentioned and the books too. -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: listen utility and permissions
On Wed, 18 Aug 1999, Gerd wrote: So it seems there must be a solution like the following available to avoid setting the whole terminal program UID root: On the socket listens a daemon with UID root that could be started upon system boot or with sudo or something else to assure its root permissions. The terminal then must be able to talk to this daemon to get information about the actual traffic on the QRG. Is this a suitable approach or do I miss something here? I don't see the need for such an elaborate arrangement, at least if the only reason was to replace the current "listen". Listen has no user interaction and it should be pretty easy to make sure it has no buffer overflows or other security risks. So there really isn't any reason a sysop couldn't make it setuid root if he/she wants to. It's just that now it isn't setuid root by default. -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: Problems with ax25-tools-0.0.4 and Kernel 2.2.11
On Wed, 18 Aug 1999, Robert Schelander wrote: I've tried to compile ax25-tools-0.0.4 './configure' worked without any problems, but when I try to 'make install' I get the following message: axctl.c:93: structure has no member named 'digi_count' what could be the reason? This has been answered quite a few times here already... You probably use Red Hat 6.0. Currently the tools don't compile on that platform. A new version of the libs/tools/apps is on it's way. -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: sucess story! upgrade from RH4.2 - RH6.0
On Mon, 16 Aug 1999, Thomas M. wrote: To get this far, I've had to patch a couple of files : in libax25 kernel_netrom.h is missing the definition of SOL_NETROM, after browsing some sources i found out that this should be 259, so I added a #define SOL_NETROM 259 to the file... This one is ok. Though there are other errors in that file so you will find that many netrom tools won't work. in ax25_tools, the axctl program has an error, i removed the line near the bottom of the file, saying ax25_ctl.digi_count, as digi_count doesn't appear in the ax25_ctl struct... There is no error in axctl. Zeroing ax25_ctl.digi_count is crucial to axctl's function, in fact with kernels older than 2.2.11 you can crash the kernel big time if it's not properly initialized... The problem is that the kernel_*.h "compatibility headers" are broken. Patch sent. Waiting for something to happen. -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: Compiling new AX25 stuff on Slackware 3.6
On Thu, 12 Aug 1999, Craig Small wrote:
Kai Altenfelder said:
open("/usr/etc/ax25/axports", O_RDONLY) = -1 ENOENT (No such file or
^
[...]
Where the hell does this prefix "/usr/etc" come from? An error of the
libax25 function "ax25_config_load_ports()"?
Yep, so you can put whatever you like for the ax25-tools compile and it is
not going to make one bit of difference.
Recompile libax25.
Kissattach is different in that it doesn't use libax25 to read the config
but has its own readconfig() routine. I really don't know why but it does.
Kissattach tries to fopen(CONF_AXPORTS_FILE, "r")) and CONF_AXPORTS_FILE
is defined in "../pathnames.h":
#define CONF_AXPORTS_FILE AX25_SYSCONFDIR"axports"
AX25_SYSCONFDIR on the other hand is defined from gcc command line so you
should see what it is when you compile the stuff.
My guess is something went wrong when you ran ./configure. Have you tried
starting over with freshly unpacked source code? Autoconf can be confusing
sometimes as it caches all sorts of information.
Just for reference, kissattach works for me and reads the correct config
file. I just checked yesterday evening.
--
--- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: Compiling new AX25 stuff on Slackware 3.6
On Tue, 10 Aug 1999, Gareth Rowlands wrote: The slackware 3.6 has been augmented with Kernel 2.2.10 and net-tools 1.52 The glibc already supplied with the distribution is 2.0.7 ax25-tools-0.0.4 Stops compiling with an error relating to a structure member in axctl.c line 93 ax25_ctl.digi_count = 0; Within the file ax25-tools-0.0.4/ax25/axctl.c I just commented out this particular line for now, as I couldn't work out the specifics of the problem (digi_count belongs to the structure ax25_routes ?) /* ax25_ctl.digi_count = 0; */ Time will tell as to whether I've made a duff move. Unfortunately with that "fix" axctl won't work and with kernels earlier than 2.2.11 one can produce a major kernel screw-up with it... :( (The AX.25 related security update mentioned at http://www.uk.linux.org/VERSION/relnotes.2211.html fixes the latter.) The problem is a little more complicated and the real fix needs to be done in the "compatibility headers" that libax25 installs. I have sent patches for libax25 to Craig so we'll just have to wait... ax25-apps-0.0.3 Compiles and installs OK. If you have a 'heritage' installation like mine, you may find that 'call' and 'listen' etc. complain of being unable to open the axports file Within the directory /usr/local/etc set a link to /etc/ax25 ln -s /etc/ax25 ax25 I'd suggest you instead do the following: 1. Run "make uninstall" 2. Run "./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var" 3. Run "make" and "make install". You do this to all the three packages starting with libax25 and suddenly you have all the stuff in the "right" places... The "make uninstall" is of course needed only if you have already installed the packages to /usr/local. Hope this helps. -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: Virtual Netrom circiut/Ip over Netrom
On Sun, 8 Aug 1999, Glasscock Family wrote: I haven't seen anything on this so here is my question: I have the standard ax25 tools, version 2.1.42 or whatever that is, and I am trying to set up a link to someone using TCP/IP carried over netrom, for the netrom man page: IP traffic may be stacked on top of NET/ROM frames using a non-standard extension to the NET/ROM protocol. I am wondering how do I set it up. Ok. This is from memory so some details might be wrong. But I think it should get you going. After this script your end should be ok. Then you have to get the #ALW router to do the same so it can route any reply IP datagrams to you. A route and arp needs to be set up there. # Set up the netrom interface. (Assuming you haven't already done that) # nrattach -i 44.12.0.144 -m 236 netrom_port_name_as_in_nrports # # Route the gw through the nr0 interface. # route add -host 44.12.3.131 window 392 dev nr0 # # NET/ROM doesn't support automatic ARP so this has to be done manually. # You will have to replace "#ALW" with the real callsign, alias won't work. # arp -H netrom -s 44.12.3.131 #ALW # # The rest of the world is behind the router. # route add -net 44.0.0.0 netmask 255.0.0.0 gw 44.12.3.131 # # All done! -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: 6pack: spattach won't die !
On Mon, 9 Aug 1999, Andreas Koensgen wrote: I've tested the problem on the weekend and could reconstruct it. I've discovered even another error -- when killing spattach after a TCP connection has been opened the kernel panics with the messages "killing interrupt handler" and "unable to kill the idle task". I think the problem is that the driver code which interfaces the kernel is very old -- it has been taken from the SLIP driver for 2.0.x kernels, later minor changes were done to get it compiled on 2.1.x kernels. But meanwhile so many things in the networking code have been changed that it is probably easier if I take the kernel interface code from the latest 2.2.x mkiss driver and replace/add the 6pack-specific routines. This will also be a good opportunity to fix the old documentation attached with the driver ... I think the mkiss driver may suffer from the same problem. I once had similar behaviour with kissattach but didn't investigate it further... -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
radio.linux.org.au
Hi! Am I the only one that gets an error message when trying to look at the package description: 1064: You have an error in your SQL syntax near '§pat=packet' at line 1 Warning: 0 is not a MySQL result index in /home/pa4tu/radio/pkgdetail.phtml on line 22 Manually changing the '§' in the URL to a '' fixes th problem. A typo somewhere? -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: netromd not saving routes it hears
Your problem seems very strange indeed. Off-hand I can't think of a reason for the /proc/sys entries disappearing. But: /usr/sbin/kissattach -i 44.124.6.16 -m 512 /dev/ttyS1 ax0 ifconfig ax0 netmask 255.0.0.0 broadcast 44.255.255.255 mtu 256 Why do you first set the MTU to 512 with kissattach and then to 256 with ifconfig? However I don't think that should really matter. WHy in the world would netromd not be able to create the proper /proc/sys entries when ax25d (which is very similar in src code) can? Just a comment: ax25d and netromd are very different both in src code and in what they do. -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: soundmodem on SBPro
On Wed, 4 Aug 1999, Thomas Sailer wrote: Tomi Manninen OH2BNS wrote: On Wed, 4 Aug 1999, Hamish Moffatt wrote: Do you think it is a problem to operate with the squelch open always? The soundmodem seems to do a pretty good carrier detect anyway. As far as I can see, using squelch with soundmodem can only make things worse. It _will_ make carrier detection slower and possibly also receiver recovery (from tx). Both are very important factors for efficient channel usage. False carrier detection is much less dangerous. CPU usage might be slightly lower with squelch but I doubt you can even notice that. On the other hand, if a hardware squelch decides wrongly, the packet is trashed. If the software squelch (or rather carrier detect) errs, the packet reception is not affected. Umm... Isn't that just another reason not to use squelch (or rather run squelch open). Did I miss something? So it depends. If you have a very fast hardware squelch (preferably that operates on the RF power level), then use it, but I doubt that most FM rigs have anything but an extremely slow squelch. But in the case of soundmodem, the carrier detection is done in software anyway and any kind of squelch, no matter how fast, can only make the DCD slower. Right? -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: CEPT callsigns
I tried to keep my hands out of this but... :-) Just put GB50BO in the callsign field... Thereby contravening the regulations in just about EVERY country I've ever operated in! Certainly, doing that is against the British regulations, the US regulations, the Canadian regulations, the French regulations...should I keep going? If my interpretation of the Finnish regulations is correct, there really isn't anything that says that the AX.25 source and destination addresses need to be valid callsigns. As long as you make clear what your real callsign is at least every 15 minutes. Just like on phone, you don't need to say the callsigns on every over, it's quite ok to go "ok Riley, perfect copy here in Helsinki, thanks for the report, yours is..." Anyway I do agree that valid callsigns should be used as AX.25 addresses, and here it _is_ considered very bad practise to use anything else... But those celebration-callsigns are IMHO rare and therefore a minor "problem" :-) You obviously make little use of amateur radio then. My question is: Is it _really_ necessary for a special event station to be able to use the special callsign on packet radio? Do people want to send for example QSL cards for packet radio QSOs? Isn't that sort of stupid? Here in Finland we don't have the problem though as our TAC refuses to give callsigns that don't comply with the IARU/ITU/whatever recemmendations. Special event stations get either a single letter suffix or occasinally a special prefix (we have OF-OJ). And this only for GB50BOB? Since you clearly don't use the amateur radio bands, you equally clearly won't be aware of just how many callsigns are in regular use that can not be used in the AX.25 protocol due to this stupid flaw in the protocol. IMNSHO that callsign and other similar are as much illegal or at least against established practises as Walters proposal so those special event stations get what they have coming... In some future link layer protocol that fixes many other things as well this issue should be taken into account. For now I don't see the big problem. And whatever people do, don't create a quick and dirty, almost-but-not-quite backwards compatible hack to AX.25 to get around this "problem"... Add to that the fact that several countries have already proposed allocating ham callsigns with a four letter suffix since they are fast running out of callsigns to allocate, and you soon see just how daft your comments are... Really? What countries? -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: A problem
On Sun, 1 Aug 1999, Brad Fisher wrote: I'm a bit new at this, but I don't quite understand why assigning an IP address would have anything to do with his layer 1 device problem. Please explain the relationship. The axconfig library routines get the information about available interfaces using a ioctl(SIOCGIFCONF) system call (SIOCGIFCONF = Socket I/O Control Get InterFace CONFig). An interface can only appear on that list if it has an IP address. Thus an interface without an IP address appears un-available to the ax25 utilities. That is the immediate reason for the error message one gets. There may be deeper reasons in the kernel networking that would prevent things from working even if SIOCGIFCONF did give information about interfaces without IP address. I don't know. And frankly, given that the workaround is so easy (just give the damn IP address, use a private network address if you don't have your own), it won't be very high at least on my priority list of things to be fixed... -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: Getting confused!
On Wed, 21 Jul 1999, Rob Compton wrote: I now see that, from reading the messages on this list, I have the wrong ax25-utils for the 2.0.36 kernel that I have - the one I've got is ax25_utils-2.1.42a-3.i386.rpm, and I see that I should have an earlier version. Why? Ax.25-utils 2.1.42a _is_ the correct one to use with 2.0.3[67] kernel. -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: AX25 update ?.
On Sun, 18 Jul 1999, Riley Williams wrote: I have had an accident with my linuxdirectory where I save LINHAM mails in. Could anybody help me with the websites where it's possible to get the new updates and what are they called ?? If it helps, the last 1,000-odd mails in Linux-Hams are archived (in pine folder format) at the following URL: ftp://ftp.memalpha.cx/pub/rhw/linux-hams.gz Of course one can also check the official searchable archive at www.hes.iki.fi. -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: node-0.3.0 broken??
On Thu, 15 Jul 1999, Byron Hicks wrote: I managed to get node-0.3.0 compiled and working, but when I use and extcmd, it doesn't pass the callsign to a program when I use %u or %s. The node that comes with the older ax25utils does pass the callsign to the program. I'm pretty sure it does for me (can't test right now). Could you send me the extcmd line in your node.conf so I can test if I can reproduce the error. -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: node and dxnet
On Fri, 16 Jul 1999, Kjell Jarl wrote: The reason I need to use netrom, is I am using dxnet, which I have failed connect on any other interface (scc0 (plain ax.25) does not work properly - it wouldn't have helped?) I need to connect the node and telnet from there. Any other suggestion with dxnet? Again, it would be possible to connect from the dxnet process to the node (or anything else for that matter) using netrom if only dxnet would allow it. -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: New netromd and listen
On Wed, 30 Jun 1999, Karl F. Larsen wrote: Got the Red Hat 6 system using kissattach well now and nrattach is also working well, but listen and netromd both produce the same error message and drop out. The error message is: netromd :Socket : Socket type not supported The kernel is 2.2.9 with most of the ax25-utils turned on. I am wondering if we need something obscure turned on again like loopback...:-) I will re-look at the /usr/src/linux/.config and see if I spot an error. Turn on the support for AF_PACKET. It's called "Packet socket" in the kernel configuration. Also "alias net-pf-17 af_packet" might be needed in /etc/conf.modules. PS. No, it doesn't have anything to do with packet radio per se, it's just something that is needed to be able to monitor any network traffic. -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: Is netromd broke in ax25-tools-0.0.2?
On Wed, 30 Jun 1999, Byron Hicks wrote: I installed the new ax25-tools, ax25-apps, and ax25-lib and everything works great with the exception of netromd. Netromd loads ok, but when I receive routing updates from netrom neighbors, I get the following error: Jun 30 13:24:20 w5gb netromd[10867]: netromr: SIOCADDRT: Invalid argument You are running a 2.2.x kernel, right? -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: Red Hat 6 and AX25
On Wed, 30 Jun 1999, Karl F. Larsen wrote: I loaded Red Hat 6 and as root compiled the three directories of data and other than a few warnings they all three compiled and I used the make install that put the files into the proper directories. When I tried to use them I got this error from kissattach when I used it like this: kissattach -i 44.30.2.5 -m512 /dev/ttyS2 ax0 and got this error message: kissattach: TIOCSETD: Invalid argument Does anyone know what this error message means? This has been discussed a million times on this list. There is nothing new about it in RH6.0 or the new utis. Look in the mailing list archives: http://www.hes.iki.fi/archive/linux-hams/ -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: Probs in the new ax.25 archives!
On Tue, 29 Jun 1999, Jorge Matias wrote: 1. This is change I had to make. The program "configure" wasn't detecting libax25io because this needs libz to compile and program has a mistake. --- configure Fri Jun 4 03:20:16 1999 +++ ../../ax25-tools-0.0.2/configureSat Jun 26 12:26:04 1999 @@ -1202,7 +1202,7 @@ echo $ac_n "(cached) $ac_c" 16 else ac_save_LIBS="$LIBS" -LIBS="-lax25io lz $LIBS" +LIBS="-lz -lax25io $LIBS" cat conftest.$ac_ext EOF #line 1208 "configure" #include "confdefs.h" Hmm... Haven't noticed this but you are probably right. Anyway as none of the current tools and apps use libax25io this isn't fatal. 2. Others changes: cd /usr/local/include mkdir netrose cd netrose ln -s /usr/include/linux/rose.h rose.h cd ../netax25 ln -s /usr/include/linux/netrom.h kernel_netrom.h These were the necessary changes to compile ax25-tools package. Anyone else had to do this? It's technically incorrect to use the kernel headers but if it works for you then fine. I would guess that it won't for most of people (are you perhaps running a libc5 based system?). Anyway only the most recent glibc 2.1 versions are truely trouble free when it comes to the ax25 stuff and headers. For example RH 6.0 does not have a recent enough glibc (even though it _is_ 2.1). So people will need to be prepared to fiddle with the headers... BTW, what about the node? I was waiting for this package to be released to install the "node", because "node" from ax25utils-2.1.42 doesn't work with my kernels from 2.2.6 to 2.2.10! I found that this new packages don't have the "node" program. Node (and some other bigger apps like pms, rspfd etc.) will be released as their own packages by their espective authors from now on. I'm in the process of making some final adjustments to node and then I'll release it. A couple of days... -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: Probs in the new ax.25 archives!
On Wed, 30 Jun 1999, Leszek A. Szczepanowski wrote: On Wed, 30 Jun 1999, Tomi Manninen OH2BNS wrote: Node (and some other bigger apps like pms, rspfd etc.) will be released as their own packages by their espective authors from now on. I'm in the process of making some final adjustments to node and then I'll release it. A couple of days... Will it know about flexnet nodes and have possible to connect to them using flexnet protocol? Maybe part of node should be as daemon running in background for flexnet purposes? No it won't. There is no real flexnet protocol support in Linux. I could add a "sort of" support (like in awznode) but the trouble is there are no flexnet nodes here so _I_ can not implement it. Feel free to do the coding and send a patch to me. -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
Re: Linux AX.25 programing help
On Wed, 30 Jun 1999, Rob Compton wrote: I have the HOWTO, I have read it, I understand what it's saying, BUT! For some reason I can't 'make' the new kernel. When I enter "make menuconfig", as per the instructions, it comes back with "*** No rule to make target 'menuconfig'. Stop." Are you in the directory where you have the full linux kernel source when you do that (usually /usr/src/linux) ? Do you _have_ the full kernel source on your machine? I have read, and re-read the RedHat 5.2 book, I have racked up loads of time on the 'net looking at FAQ's, and more, but I can't find "config", "menuconfig" or even "Xconfig" on my machine. Menuconfig etc. are not programs or even files. They are make _targets_. Try typing "man make" and read the DESCRIPTION chapter, it isn't long. That should give you an overview of what make does. Now, by running "make menuconfig" you select the "menuconfig" target in the kernel main Makefile that is supposed to first compile the menu dialog program and then run it. If make fails with "no rule to make target" you have done some fundamental mistake in getting and unpacking the kernel source code; you are in the wrong directory or the Makefile is somehow corrupted. -- --- Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ---
