headers
Cathryn Mataga | 1 Dec 2009 07:05
Favicon

Re: nr0 doesn't show up (netrom)

For the record, I actually managed to connect to another NETROM
site over actual RF after fixing nrattach.c and recompiling.  It's acting
kind of slow but I need to do some conventional AX25 tweaking
first before I can claim anything is actually broken here. This is
a new install, using the rc2 files on the site.

I'm still dependent on the BSD style pty's, and it looks like
the utilities have been updated to get around this, so I have to
put in some time to see if I can run a completely stock
kernel from Fedora, which would be nice.

Generally, it's looking good so far though.
--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 5 comments |
headers
Geoff Bagley | 1 Dec 2009 14:33

Gyrators.

I would like to hear from any other amateur who has experience with 
simulation of
hi-Q inductors for use in VLF receivers by means of gyrator circuits.

There seem to be two sorts. 

There is a simpler one which you can find in Wikipedia,
and there is a rather more complicated one by WB9ATW  (taken from Ham 
Radio  June 1979 )
which is to be found in  the RSGB  "LF Experimenter's Source Book  2nd 
Ed. Ed G3LDO.

This second circuit uses two op-amps rather than one (for the gyrator) 
and was used by N8BN
in a receiver design published in the same publication.

I am interested in what Q-factor values are feasible,  and the relative 
merits of the two circuit
configurations.

It sounds nice to be able to vary the tuning of the circuit by means of 
a single potentiometer !

I imagine that if a very Hi-Q tuned circuit were to be made in this 
manner, you would have to drive it
in such a manner as not to cause any appreciable damping, and consequent 
lower Q.

Any hints or experiences welcome.  TIA.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Cathryn Mataga | 7 Dec 2009 11:30
Favicon

ax25ipd.c routing

How does this work with multiple connections?

Suppose I have two incoming connections
My call is K1BBS.

route K1PAR 1.0.0.0
route K2PAR 2.0.0.0 d

Then suppose K1USR at K1PAR does a connect to K1BBS.

What seems to happen is I see packets come in from K1USR  to K1BBS.
But then when packets go back out, they go back to K2PAR, even though
he's at K1PAR.   At least that's what I think is happening.

Shouldn't ax25d.c keep a record of which IP callsigns came from, so that
way when it needs to send a packet back they go to the right place?
I'm not 100% sure of this, but it seems like the lookup only checks
the route commands.   I only see one call to route_add in config.c.

Shouldn't it 'route_add' every time a callsign comes in axip?
Or the only way to make this work is to run a separate
ax25ipd for every connection.
--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 4 comments |
headers
Thomas Osterried | 7 Dec 2009 17:25
Picon

Re: ax25ipd.c routing

On 2009-12-07 02:30:27 -0800, Cathryn Mataga <cathryn <at> junglevision.com>
wrote in <4B1CD943.6030808 <at> junglevision.com>:
> How does this work with multiple connections?
>
> Suppose I have two incoming connections
> My call is K1BBS.
>
> route K1PAR 1.0.0.0
> route K2PAR 2.0.0.0 d
>
> Then suppose K1USR at K1PAR does a connect to K1BBS.
>
> What seems to happen is I see packets come in from K1USR  to K1BBS.
> But then when packets go back out, they go back to K2PAR, even though
> he's at K1PAR.   At least that's what I think is happening.
>
> Shouldn't ax25d.c keep a record of which IP callsigns came from, so that
> way when it needs to send a packet back they go to the right place?
> I'm not 100% sure of this, but it seems like the lookup only checks
> the route commands.   I only see one call to route_add in config.c.

ax25ipd in it's current version does not learn routes.
In fact, route_add() is only being called from the config file.
.../ax25-apps/ax25ipd$ grep route_add *.c
config.c:               route_add(tip, tcall, uport, flags);
routing.c:void route_add(unsigned char *ip, unsigned char *call, int udpport,
.../ax25-apps/ax25ipd$ 

That's why your packet goes out via the default connection (route K2PAR
2.0.0.0 d).
(Continue reading)

Permalink | Reply | 3 comments |
headers
Cathryn Mataga | 7 Dec 2009 21:02
Favicon

Re: ax25ipd.c routing


> ax25ipd in it's current version does not learn routes.
> In fact, route_add() is only being called from the config file.
> .../ax25-apps/ax25ipd$ grep route_add *.c
> config.c:               route_add(tip, tcall, uport, flags);
> routing.c:void route_add(unsigned char *ip, unsigned char *call, int udpport,
> .../ax25-apps/ax25ipd$ 
> 
> That's why your packet goes out via the default connection (route K2PAR
> 2.0.0.0 d).
> 

Thank you.  This confirms my understanding of the current issue.

> 
> Btw, the dyndns feature which Bernard Pidoux f6bvp reminded to a few weeks ago
> is still the my queue.
> I've -mostly theoretical- problems with it because it resolves on a
> periodical basis, which means that if the dns currently is broken,
> it even affects LAN connections served by ax25ipd by introducing periodical
> delays.
> Bernard changed route_add(), as also my test-version does, but in a slightly
> different way.
> The test-code also implements periodical dyndns resolving, but iirc, it does
> not work correctly (can't remember).

Hmm.

What about this for both my and Bernard's issue.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Thomas Osterried | 7 Dec 2009 21:26
Picon

Re: ax25ipd.c routing

Hello,

> What about this for both my and Bernard's issue.
>
> 1.  If a callsign is received from the ip of a known route
> but is not the callsign of a known route, or the callsign
> of the local station, then add this callsign
> and the route pointer to a binary tree.  If the callsign
> was previously in the tree, then the new route replaces
> the old one, if different.

yes. And if not set to "permanent" (p).

> 2.  in call_to_ip, before it checks the default route,
> it checks this binary tree for this callsign, and returns the
> route it came from.  If the callsign is not found, the default
> route is used.

yes.

> 3.  Callsigns never expire.  The tree just grows.

yes.

> 4.  SSID's are matched as unique callsigns.

call + same-ssid unique.
If you like to route i.E. ssid 0 to 15 permanently to a specific host,
it's only 16 lines. That's ok.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ray Wells | 8 Dec 2009 00:30
Picon

Re: ax25ipd.c routing

Hi,

Excuse me if I'm barking up the wrong tree.

I've been using ax25ipd for many years and haven't observed any routing 
problems.  For many years the system ran fbb (40 ports - ax25, rose and 
telnet) and fpacnode, as well as xastir (aprs).

I was a beta tester for some modifications implemented by vk5asf back in 
2005 and haven't used the stock sources since then. I know that f6bvp 
has also introduced some fixes. I always get my sources from the f6bvp 
web site.

Also, I don't remember how far back it was introduced, or by whom, but 
specifying an ssid of zero causes that route to respond to any ssid from 
that callsign. I used a mixture of generic (-0) and directed ssid's.

 >From my ax25ipd.conf.

route vk2tv-3 gizmo udp 10093 d
route vk2tv-8 gizmo udp 10093 b
route kp4djt-0 w4bgh.no-ip.org udp 10095 b
route k4gbb-9 k4gbb.serveftp.com udp 10093
route k4gbb-12 k4gbb.serveftp.com udp 10094
route k4gbb-14 k4gbb.serveftp.com udp 10093 b
route f6bvp-0 82.66.61.83 udp 10093 b
route gb7yb-0 62.49.59.169 udp 10093 b
route gb7ydx-1 gb7ydx.ath.cx udp 10093 b
#route kd4yal-0 kd4yal.servebbs.org udp 10093 b
route kd4yal-0 97.97.181.223 udp 10093 b
(Continue reading)

Permalink | Reply | 0 comments |
headers
Cathryn Mataga | 8 Dec 2009 02:45
Favicon

Re: ax25ipd.c routing


> Cathryn, do you have the possibility to do a packet-trace?
> 

Alright, here's a case where it doesn't work.  I connect to
my partner's system at gvcity.ampr.org. His callsign is KG6BAJ.
I log into his system via telnet with my call KE6I.  He's running
"Xrouter v186b".  I'm connected to 'port 6' on his system, so
I do the command.

C 6 KE6I-9

This is a trace from my side with stock ax25ipd.  His site
connects to mine using my call KE6I-15.  My side is trying
to send the packet back, but they're all going to the default
route, so it keeps trying and never gets a response.  On the
connecting side, I just see a timeout.  From gvcity.ampr.org
I never see the 'uronode' message.

axip: fm KE6I-15 to KE6I-9 ctl SABM+
axip: fm KE6I-9 to KE6I-15 ctl UA-
axip: fm KE6I-9 to KE6I-15 ctl I00^ pid=F0(Text) len 102
0000  URONode v1.0.7 - Welcome to XX#XX-#.Welcome KE6I in Berkeley Cal
0040  ifornia.  Type 'CONV' for live chat...
axip: fm KE6I-9 to KE6I-15 ctl I01+ pid=F0(Text) len 4
0000  .=>
axip: fm KE6I-15 to KE6I-9 ctl SABM+
axip: fm KE6I-9 to KE6I-15 ctl UA-
axip: fm KE6I-9 to KE6I-15 ctl I00^ pid=F0(Text) len 102
0000  URONode v1.0.7 - Welcome to XX#XX-#.Welcome KE6I in Berkeley Cal
(Continue reading)

Permalink | Reply | 0 comments |
headers
Terry Dawson | 8 Dec 2009 05:32

Re: [PATCH] net-tools-1.60-23 netstat ampr ROSE

Bernard Pidoux wrote:

> It already includes AX.25 and Netrom sockets contents
> and NetRom route table.
> 
> Terry Dawson VK2KTJ, implemented (although partially ?) ROSE
> in netstat, some time ago (date ?).
> 
> I completed the work with a patch against the last net-tools
> source I found at http://packages.debian.org/sid/net-tools

Hi Bernard,
Thanks for the cc: I'd lost this list and am pleased to have a pointer 
to where it again.

regards
Terry

--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Cathryn Mataga | 8 Dec 2009 06:11
Favicon

Re: ax25ipd.c routing

http://www.mataga.net/mataga/ax25ipdke6i.diff

Here's a link to the change I made to ax25ipd.  This is a diff
versus the rc2 version.   It hasn't been tested that much,
but it does work for me.

It's pretty basic.  It reads ip addresses and callsigns
using code taken from the test version.  But then it stores the
matching route/Callsign in a btree, and uses this btree to
retrieve the correct ip during sending.  It does fix the issue
shown in the logs I created earlier.

It doesn't deal with the route IP's changing.  Currently, I just
print a message when this happens.  It only addresses the issue
of user callsigns.
--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |

Gmane