dhcpd + sv2agw
Cathryn Mataga
is to put the 9600 baud port on a C-net and 192.168.1.0, and use
ip masquerade to convert ip adresses to my amprnet adress. When
I use static ip adresses on the Windows machines, it works great,
and I have no trouble with that. But Linux dhcpd doesn't seem to respond
to dhcpd requests from Win98 and SV2AGW.
Here's how I bring up the device.
/usr/sbin/kissattach -l /dev/ttyq2 km2 192.168.1.1
/usr/sbin/kissparms -p km2 -t 90 -s 100 -r 128 -f n
/sbin/ifconfig ax2 netmask 255.255.255.0
/sbin/ifconfig ax2 broadcast 192.168.1.255 mtu 1500
/sbin/route add -net 192.168.1.0 netmask 255.255.255.0 ax2
Here's the output of ifconfig. Strange -- why doesn't it list
the broadcast ip, and show the BROADCAST flag? I
tried doing ifconfig ax2 broadcast in various combinations
and could never get it to show BROADCAST here. I suspect
this is the reason it doesn't work, but I don't know what to do
to fix it. To me, it the manpage reads like doing
ifconfig broadcast should do it -- right?
[root@hamradio /root]# /sbin/ifconfig ax2
ax2 Link encap:AMPR AX.25 HWaddr KE6I-5
inet addr:192.168.1.1 Mask:255.255.255.0
UP RUNNING MTU:1500 Metric:1
RX packets:188 errors:0 dropped:0 overruns:0 frame:0
TX packets:322 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10
Here's what my dhcpd.conf looks like...
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.10 192.168.1.100;
range 192.168.1.150 192.168.1.200;
default-lease-time 600;
max-lease-time 7200;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.1.255;
option routers 192.168.1.1;
option domain-name-servers 207.21.11.9, 207.21.11.2;
option domain-name "ampr.org";
}
subnet 207.21.11.0 netmask 255.255.255.0 {
}
subnet 44.4.0.0 netmask 255.255.192.0 {
}
subnet 44.4.64.0 netmask 255.255.192.0 {
}
subnet 192.168.0.1 netmask 255.255.255.255 {
}
subnet 192.168.0.2 netmask 255.255.255.255 {
}
subnet 192.168.0.3 netmask 255.255.255.255 {
}
subnet 192.168.0.4 netmask 255.255.255.255 {
}
subnet 192.168.0.10 netmask 255.255.255.255 {
}
Here's the output of Listen. -- This is right after
the SV2agw Win98 machine boots up.
km2: fm [invalid] to QST ctl UI pid=CC(IP) len 328
IP: len 328 0.0.0.0->255.255.255.255 ihl 20 ttl 128 prot UDP
UDP: len 308 bootpc->bootps Data 300
0000 ......ÝS........................................................
0040 ................................................................
0080 ................................................................
00C0 ............................................c.Sc5..=..........CA
0100 THRYN.7.....,./9ÿ...........................
km2: fm [invalid] to QST ctl UI pid=CC(IP) len 328
IP: len 328 0.0.0.0->255.255.255.255 ihl 20 ttl 128 prot UDP
UDP: len 308 bootpc->bootps Data 300
0000 ......ÝS........................................................
0040 ................................................................
0080 ................................................................
00C0 ............................................c.Sc5..=..........CA
0100 THRYN.7.....,./9ÿ...........................
km2: fm [invalid] to QST ctl UI pid=CD(ARP) len 30
ARP: len 30 hwtype AX25 prot IP op REQUEST
sender IPaddr 169.254.253.109 hwaddr [invalid]
target IPaddr 169.254.253.109
km2: fm [invalid] to QST ctl UI pid=CC(IP) len 28
IP: len 28 169.254.253.109->224.0.0.2 ihl 20 ttl 128 prot ICMP
ICMP: type 10
km2: fm [invalid] to QST ctl UI pid=CC(IP) len 96
IP: len 96 169.254.253.109->169.254.255.255 ihl 20 ttl 128 prot UDP
UDP: len 76 netbios-ns->netbios-ns Data 68
0000 ..)......... EDEBFEEIFCFJEOCACACACACACACACAAA.. ..À.. .....à....
0040 ©þým
km2: fm [invalid] to QST ctl UI pid=CC(IP) len 96
IP: len 96 169.254.253.109->169.254.255.255 ihl 20 ttl 128 prot UDP
UDP: len 76 netbios-ns->netbios-ns Data 68
0000 ..)......... EKFFEOEHEMEFFGEJFDEJEPEOCACACAAA.. ..À.. .....à....
Here's the log from dhcpd. Nothing much here.
Oct 21 16:31:09 hamradio dhcpd: Internet Software Consortium DHCP Server 2.0
Oct 21 16:31:09 hamradio dhcpd: Copyright 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium.
Oct 21 16:31:09 hamradio dhcpd: All rights reserved.
Oct 21 16:31:09 hamradio dhcpd:
Oct 21 16:31:09 hamradio dhcpd: Please contribute if you find this software useful.
Oct 21 16:31:09 hamradio dhcpd: For info, please visit http://www.isc.org/dhcp-contrib.html
Oct 21 16:31:09 hamradio dhcpd:
Oct 21 16:31:09 hamradio dhcpd: Listening on LPF/ax4/96:8a:6c:92:40:40/192.168.0.2
Oct 21 16:31:09 hamradio dhcpd: Sending on LPF/ax4/96:8a:6c:92:40:40/192.168.0.2
Oct 21 16:31:09 hamradio dhcpd: Listening on LPF/ax3/96:8a:6c:92:40:40/192.168.0.3
Oct 21 16:31:09 hamradio dhcpd: Sending on LPF/ax3/96:8a:6c:92:40:40/192.168.0.3
Oct 21 16:31:09 hamradio dhcpd: Listening on LPF/ax2/96:8a:6c:92:40:40/192.168.1.0
Oct 21 16:31:09 hamradio dhcpd: Sending on LPF/ax2/96:8a:6c:92:40:40/192.168.1.0
Oct 21 16:31:09 hamradio dhcpd: Listening on LPF/ax1/96:8a:6c:92:40:40/44.4.64.0
Oct 21 16:31:09 hamradio dhcpd: Sending on LPF/ax1/96:8a:6c:92:40:40/44.4.64.0
Oct 21 16:31:09 hamradio dhcpd: Listening on LPF/ax0/96:8a:6c:92:40:40/192.168.0.1
Oct 21 16:31:09 hamradio dhcpd: Sending on LPF/ax0/96:8a:6c:92:40:40/192.168.0.1
Oct 21 16:31:09 hamradio dhcpd: Listening on LPF/sm0/96:8a:6c:92:40:40/44.4.0.0
Oct 21 16:31:09 hamradio dhcpd: Sending on LPF/sm0/96:8a:6c:92:40:40/44.4.0.0
Oct 21 16:31:09 hamradio dhcpd: Listening on LPF/nr1/<null>/192.168.0.10
Oct 21 16:31:09 hamradio dhcpd: Sending on LPF/nr1/<null>/192.168.0.10
Oct 21 16:31:09 hamradio dhcpd: Listening on LPF/nr0/<null>/192.168.0.9
Oct 21 16:31:09 hamradio dhcpd: Sending on LPF/nr0/<null>/192.168.0.9
Oct 21 16:31:09 hamradio dhcpd: Listening on LPF/eth0/00:40:c7:21:10:72/207.21.11.0
Oct 21 16:31:09 hamradio dhcpd: Sending on LPF/eth0/00:40:c7:21:10:72/207.21.11.0
Oct 21 16:31:09 hamradio dhcpd: Sending on Socket/fallback/fallback-net
Bob Meyer
> I'm trying to get dhcpd on Linux talking to SV2agw on Win98. The idea here
> is to put the 9600 baud port on a C-net and 192.168.1.0, and use
> ip masquerade to convert ip adresses to my amprnet adress. When
> I use static ip adresses on the Windows machines, it works great,
> and I have no trouble with that. But Linux dhcpd doesn't seem to respond
> to dhcpd requests from Win98 and SV2AGW.
>
Did ya route 255.255.255.255 to ax2?
Bob
Cathryn Mataga
Hmm, no I didn't, as a matter of fact. Though I put in a
route for this, and restarted dhcpd, and it didn't seem to
change anything.
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
255.255.255.255 * 255.255.255.255 UH 0 0 0 ax2
255.255.255.255 * 255.255.255.255 UH 0 0 0 eth0
207.21.11.43 * 255.255.255.255 UH 0 0 0 eth0
207.21.11.0 * 255.255.255.0 U 0 0 0 eth0
192.168.1.0 * 255.255.255.0 U 0 0 0 ax2
192.168.1.0 * 255.255.255.0 U 0 0 0 ax2
192.168.0.0 * 255.255.255.0 U 0 0 0 ax0
192.168.0.0 * 255.255.255.0 U 0 0 0 ax3
192.168.0.0 * 255.255.255.0 U 0 0 0 ax4
192.168.0.0 * 255.255.255.0 U 0 0 0 nr0
192.168.0.0 * 255.255.255.0 U 0 0 0 nr1
44.4.64.0 * 255.255.192.0 U 0 0 0 ax1
44.4.0.0 * 255.255.192.0 U 0 0 0 sm0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
44.0.0.0 uhf.w6yx.ampr.o 255.0.0.0 UG 0 0 0 ax1
default 207.21.11.1 0.0.0.0 UG 0 0 0 eth0
>
I'm also still trying to figure out the BROADCAST flag, and whether
this is necessary. My ethernet card shows a Bcast:XX.XX.XX.XX
address and the BROADCAST flag in ifconfig, but none of my ax25
ports do. Why doesn't /sbin/ifconfig ax2 broadcast turn this on?
Oh, and I just figured out to turn off Microsoft networking over sv2agw,
-- and that clears some of the junk out of the log. (Gawd, smbd
over ham radio -- shudder.) Still, it doesn't look
like my system is answering the first broadcast
IP: len 328 0.0.0.0->255.255.255.255 ihl 20 ttl 128 prot UDP
UDP: len 308 bootpc->bootps Data 300
0000 ......İS......................0(TT..............................
0040 ................................................................
0080 ................................................................
00C0 ............................................c.Sc5..=....0(TT..CA
0100 THRYN.7.....,./9ÿ...........................
km2: fm NOB9KK to QST ctl UI pid=CD(ARP) len 30
ARP: len 30 hwtype AX25 prot IP op REQUEST
sender IPaddr 169.254.111.221 hwaddr NOB9KK
target IPaddr 169.254.111.221
km2: fm NOB9KK to QST ctl UI pid=CC(IP) len 28
IP: len 28 169.254.111.221->224.0.0.2 ihl 20 ttl 128 prot ICMP
ICMP: type 10
km2: fm NOB9KK to QST ctl UI pid=CC(IP) len 28
IP: len 28 169.254.111.221->224.0.0.2 ihl 20 ttl 128 prot ICMP
ICMP: type 10
km2: fm NOB9KK to QST ctl UI pid=CC(IP) len 28
IP: len 28 169.254.111.221->224.0.0.2 ihl 20 ttl 128 prot ICMP
ICMP: type 10
What's at 224.0.0.2, anyway? Who is Microsoft trying to talk
to?
Chris Hewitt
>
> What's at 224.0.0.2, anyway? Who is Microsoft trying to talk
> to?
nslookup reveals the hostname ALL-ROUTERS.MCAST.NET whatever that is.
Regards
Chris
g0pae
Jerry Chamberlin
Oh S......t Guess MS is multicasting code 'non-functional fixes' to all
machines.
The Net Lab year 2000 and beyond Internet Education is Science
http://www.netlab.org
WA0JRJ - Jerry
ICQ 6408731
AIM PappyJerry
Ken Koster
> -----Original Message-----
> From: Bob Meyer <ko...@gw.ko6ri.ampr.org>
...
> >Cathryn Mataga wrote:
> >
> >> I'm trying to get dhcpd on Linux talking to SV2agw on Win98. The idea here
...
>
> I'm also still trying to figure out the BROADCAST flag, and whether
> this is necessary. My ethernet card shows a Bcast:XX.XX.XX.XX
> address and the BROADCAST flag in ifconfig, but none of my ax25
> ports do. Why doesn't /sbin/ifconfig ax2 broadcast turn this on?
Broadcast operation seems to be broken, at least on those ax25 ports
supported via KISS. I ran into this problem some time back when trying
to get gated to work over the air. It is likely that the same problem is
keeping dhcp from working.
Part of the problem is that the mkiss code is not setting the flag that tells
the rest of the system that it is capable of doing broadcasts. This all used
to work, but seems to have been broken sometime around the 2.2 kernel
release. From what I can tell, the networking code used to assume that
broadcast was supported, despite the flag not being set.
The following code change will set the broadcast flag and allow ifconfig
to set the broadcast address.
WARNING, while this won't break anything, I can't be sure it will fix the
dhcp problem either. It partially fixed my problems with gated, but I still
have problems receiving broadcasts, thus it's probably only part of the
problem. Offered in the hope it will fix your problem or at least point you
in the direction of a fix. My time has been limited lately and I haven't been
able to take this any farther.
--
Make the following mod to the file /usr/src/linux/drivers/net/hamradio/mkiss.c
and recompile the kernal and modules.
At line 1031 change the entry for
dev->flags = 0;
to
dev->flags = 0x2;
ifconfig will now show the BROADCAST field and allow you to modify it.
Programs that check for broadcast capability (like gated and dhcpd) should
now attempt to use ax25 ports as well.
--
Let me know if this helps.
Ken, N7IPB
n7...@wetnet-mafia.org - TCP/IP packet radio in the Pacific Northwest
te...@animats.net
> Broadcast operation seems to be broken, at least on those ax25 ports
> supported via KISS. I ran into this problem some time back when trying
> to get gated to work over the air. It is likely that the same problem is
> keeping dhcp from working.
Actually Ken, I'd think part of the problem is that the AX.25 protocol
doesn't define a broadcast address. Irrespective of what changes have
been made in the kernel source.
There are a couple of de-facto standards around: QST-0 for example, but
I've seen nothing that actually defines a standard AX.25 broadcast
address. Until that happens it's kinda difficult to know what to do
with datagrams sent to the IP broadcast address. Reasonable behaviour
would probably be to make the AX.25 broadcast address configurable and
then support IP broadcast over it in UI mode.
Terry
--
te...@animats.net, te...@linux.org.au, te...@albert.vk2ktj.ampr.org
Cathryn Mataga
BROADCAST flag and address set. Except this still doesn't allow
me to receive the broadcasts -- like you said. Or, at least I dhcpd
doesn't work. I probably need to cook up a simpler test program
than dhcpd.
Btw, in mkiss.c, I think these two constants are wrong.
static char ax25_bcast[AX25_ADDR_LEN] =
{'Q'<<1,'S'<<1,'T'<<1,' '<<1,' '<<1,' '<<1,'0'<<1};
static char ax25_test[AX25_ADDR_LEN] =
{'L'<<1,'I'<<1,'N'<<1,'U'<<1,'X'<<1,' '<<1,'1'<<1};
I think they should be 0 instead of '0', if ax25_addr is the
final source on what is the correct format -- right? But, then
how did Arp ever work? This is right, I think...
static char ax25_bcast[AX25_ADDR_LEN] =
{'Q'<<1,'S'<<1,'T'<<1,' '<<1,' '<<1,' '<<1,0<<1};
static char ax25_test[AX25_ADDR_LEN] =
{'L'<<1,'I'<<1,'N'<<1,'U'<<1,'X'<<1,' '<<1,1<<1};
I was all fired up, about maybe this being the problem, but
then still dhcpd doesn't work. Though I now have some other
things to try again.
Maybe it would be better to call asc2ax here -- hmm?
>>
>> I'm also still trying to figure out the BROADCAST flag, and whether
>> this is necessary. My ethernet card shows a Bcast:XX.XX.XX.XX
>> address and the BROADCAST flag in ifconfig, but none of my ax25
>> ports do. Why doesn't /sbin/ifconfig ax2 broadcast turn this on?
>
>Broadcast operation seems to be broken, at least on those ax25 ports
>supported via KISS. I ran into this problem some time back when trying
>to get gated to work over the air. It is likely that the same problem is
>keeping dhcp from working.
>
Jens David
> There are a couple of de-facto standards around: QST-0 for example, but
> I've seen nothing that actually defines a standard AX.25 broadcast
> address. Until that happens it's kinda difficult to know what to do
> with datagrams sent to the IP broadcast address. Reasonable behaviour
> would probably be to make the AX.25 broadcast address configurable and
> then support IP broadcast over it in UI mode.
In fact everything I扉e seen so far (and that was a lot, starting
with xNOS DOS applications, FlexNet, AIRS (OS/2, Linux), the original
WAMPES etc.) did it that way. I think we can safely call this a
standard.
By the way, (try to) use Mat愀 reworked AX25-Stuff from
http://www.afthd.tu-darmstadt.de/~dg2fef .
-- Jens
Cathryn Mataga
these packets in the agw, and they look right. But, those packets
sent on Windows 0.0.0.0 to 255.255.255.255 end up in a black hole
somewhere when they come over ax25. Becuase my test
code will see packets from the local machine going to 255.255.255.255
but the ones that the Win dhcp client sends just don't show up in
the same code.
Unfortunately, to test 'normal broadcast' packets, I need to dig up my
Visual C++ CD, and make some test code there. Unless someone
has a simple win32 based utility for sending out udp test packets?
Hmm?
-----Original Message-----
From: Cathryn Mataga <cat...@junglevision.com>
To: linux...@vger.rutgers.edu <linux...@vger.rutgers.edu>
Date: Saturday, October 23, 1999 12:08 AM
Subject: Re: dhcpd + sv2agw
Cathryn Mataga
line twice in /usr/src/linux/net/ax25/ax25_in.c right before each call to ip_rcv. This
occurs once in ax25_rcv, and ax25_rx_iframe The code is identical in both routines.
With this change, and the flag change as suggested earlier, now my broadcast
tests work over ax25. .
skb->pkt_type = PACKET_HOST;
skb->protocol = __constant_htons(ETH_P_IP); /* Added by Cathryn to prevent loss of Bcast */
ip_rcv(skb, skb->dev, NULL); /* Wrong ptype */
ip broadcasts on ax25 are getting eaten in /usr/src/linux/net/ipv4/route.c. Near line 1275
I checked the value of skb->protocol, and it's htons(ETH_P_AX25) -- so it bugs out right
there with EINVAL. The fix I suggest above, just forces the protocal to ETH_P_IP, which
I believe is right, since once the packet is passed to the IP code, it should be an IP
packet and no longer ax25 -- right?
brd_input:
if (skb->protocol != __constant_htons(ETH_P_IP))
return -EINVAL;
if (ZERONET(saddr)) {
spec_dst = inet_select_addr(dev, 0, RT_SCOPE_LINK);
} else {
err = fib_validate_source(saddr, 0, tos, 0, dev, &spec_dst, &itag)
I believe that these changes are right, the second as suggested by the friendly
advice of the guy who's been playing with this before me. I believe the
bcast being 0 and not '0' doesn't actually cause a problem, because
of '0' happens to be 48. And 48*2=96=0x60, so when the value gets
anded with 0x1e later on, it compares okay. Still, it's kind of hacky the
way it is right now.
static char ax25_bcast[AX25_ADDR_LEN] =
{'Q'<<1,'S'<<1,'T'<<1,' '<<1,' '<<1,' '<<1,0<<1}; /* cathryn chang
e to 0 from '0' */
static char ax25_test[AX25_ADDR_LEN] =
{'L'<<1,'I'<<1,'N'<<1,'U'<<1,'X'<<1,' '<<1,1<<1}; /* changed to 1
from '1' */
...
dev_init_buffers(dev);
/* New-style flags. */
dev->flags = IFF_BROADCAST; /* Cathryn was 0 */
These flags would be changed in all the hamradio drivers.
I just make this change, and the kernel seems to work. Though I need to pull
my teltales, and run it a bit more to make sure it's okay. And, I still need
to try getting dhcpd running, though I'll mess with that later.
Cathryn Mataga
of the programmer of dhcpd, I set the USE_SOCKETS flag. After I did
that, my DHCP requests were answered.
He said it's something to do with LPF. Though come to think of it,
doesn't listen use that? Hmm, anyway, this might be more operator
confusion or something. In any case, I got it working.
te...@animats.net
> te...@animats.net wrote:
>> There are a couple of de-facto standards around: QST-0 for example, but
>> I've seen nothing that actually defines a standard AX.25 broadcast
>> address. Until that happens it's kinda difficult to know what to do
>> with datagrams sent to the IP broadcast address. Reasonable behaviour
>> would probably be to make the AX.25 broadcast address configurable and
>> then support IP broadcast over it in UI mode.
>
> In fact everything I扉e seen so far (and that was a lot, starting
> with xNOS DOS applications, FlexNet, AIRS (OS/2, Linux), the original
> WAMPES etc.) did it that way. I think we can safely call this a
> standard.
Sorry, it's unclear to me what you're suggesting is the standard here.
> The ability to configure the broadcast address.
or
> Using QST-0 as the broadcast address.
I personally would prefer a configurable broadcast address with QST-0
used as the default if unspecified.
Cathryn Mataga
so each broadcast socket would have a different callsign? What's the application or
bug fix you have in mind for this? (That is configurable callsigns for ip broadcast packets.)
More interesting to me, is what happens if we turn on the MULTICAST flag with the
ax25 driver. Me, I'm not even sure exactly how to test MULTICAST, but I was thinking
that maybe, it might be fun to have some kind of HAMBONE (like M-bone) with news messages
or maybe audio or something.
-----Original Message-----
From: te...@animats.net <te...@animats.net>
To: linux...@vger.rutgers.edu <linux...@vger.rutgers.edu>
Date: Saturday, October 23, 1999 6:18 PM
Subject: Re: dhcpd + sv2agw
te...@animats.net
> Would it be like a kernel compile time thing? Or like a setsockopt type of mechanism
> so each broadcast socket would have a different callsign? What's the application or
> bug fix you have in mind for this? (That is configurable callsigns for ip broadcast packets.)
For consistency you'd want it configurable with a tool like ifconfig or
axparms maybe.
> More interesting to me, is what happens if we turn on the MULTICAST flag with the
> ax25 driver. Me, I'm not even sure exactly how to test MULTICAST, but I was thinking
> that maybe, it might be fun to have some kind of HAMBONE (like M-bone) with news messages
> or maybe audio or something.
Same deal. Configurable multicast address would be nice. I think many
ethernet drivers already support configurable multicast addresses, so
we probably wouldn't have to break anything too much to implement it.
regards
Cathryn Mataga
From: te...@animats.net <te...@animats.net>
To: linux...@vger.rutgers.edu <linux...@vger.rutgers.edu>
Date: Sunday, October 24, 1999 3:46 PM
Subject: Re: dhcpd + sv2agw
>On 24 Oct, Cathryn Mataga wrote:
>> Would it be like a kernel compile time thing? Or like a setsockopt type of mechanism
>> so each broadcast socket would have a different callsign? What's the application or
>> bug fix you have in mind for this? (That is configurable callsigns for ip broadcast packets.)
>
>For consistency you'd want it configurable with a tool like ifconfig or
>axparms maybe.
>
Interestingly, there is a SIOCSIFHWBROADCAST 0x8937 /* set hardware broadcast addr */
in /usr/src/linux/include/linux. From the source, I suspect this might just work already, if you just
pass ioctl the callsign. Is there a shell command to do ioctls? If so, maybe we have this
already, and just don't know it. If not, it's like two lines of C code.
I do know, having just looked at this, that the dev->broadcast varialbe is setting is what
the kernel uses to match the callsign for received broadcasts, at least. Not sure about
sending broadcasts, but in a sane world, that would be changed alsoo. :)
(Note, you need to weirdly mung the callsign by shifting the letters left by 1 bit. -- 6 bytes
for the call padded with spaces and one byte for the number)
>> More interesting to me, is what happens if we turn on the MULTICAST flag with the
>> ax25 driver. Me, I'm not even sure exactly how to test MULTICAST, but I was thinking
>> that maybe, it might be fun to have some kind of HAMBONE (like M-bone) with news messages
>> or maybe audio or something.
>
>Same deal. Configurable multicast address would be nice. I think many
>ethernet drivers already support configurable multicast addresses, so
>we probably wouldn't have to break anything too much to implement it.
>
Yeah, having just thought about it, I thought I'd try setting up multicast on
my network here, but even just on ethernet, uh, this is a little bit tricky. Or
at least, I think I'm supposed to build mrouted and I find this requires fussing
with bad .h files to get it to compile in Linux on Redhat -- sigh. I see mrouted
is doing SOCK_RAW stuff, which I assume will work over ax25 -- right? It's
just AF_PACKET that's different between ethernet and ax25, isn't it, and
SOCK_RAW is the same for both?
Just for fun, I or-ed the flag in mkiss.c with ISS_MULTICAST, and yes, then
I could turn on multicast for ax25. But it'll take a lot of fuss to figure out if
it really works or not -- that is not knowing how the multicast stuff is supposed
to work in the first place very well. (I did a quick browse of some websites
on this.) There is a lot too this, it seems.
I suspect, that if MULTICAST does what I think it is supposed to do, that it might
be uniquely suited for ham radio links with low bandwidth. That is, say,
for doing something like a convers or irc type chat system, where the chat messages
were smart enough only to go down the routes where someone was listening,
and also only go down the route once, you know. That is maybe all those hard problems
are solved down in this code by clever PHd type people. Still, me I haven't
gotten it working yet with ethernet -- though I haven't put a lot of time into it, and it's
not a high priority for me.
I did see an IOCTL for multicast address, though at this point, I can't say that I know
what that is.
>--
>te...@animats.net, te...@linux.org.au, te...@albert.vk2ktj.ampr.org
>
te...@animats.net
> I suspect, that if MULTICAST does what I think it is supposed to do, that it might
> be uniquely suited for ham radio links with low bandwidth. That is, say,
> for doing something like a convers or irc type chat system, where the chat messages
> were smart enough only to go down the routes where someone was listening,
> and also only go down the route once, you know. That is maybe all those hard problems
> are solved down in this code by clever PHd type people. Still, me I haven't
> gotten it working yet with ethernet -- though I haven't put a lot of time into it, and it's
> not a high priority for me.
I've been thinking about precisely the same thing. I was originally
thinking of modelling it on a hole-fill protocol like the pacsat
broadcast protocol. I think that is still a good idea, but carried over
a multicast medium.
BBS forwarding (lots of BBS on one frequency), convers, irc, DX
cluster, weather information sharing, all sorts of things. Anywhere
where you need to flood information out to multiple users on one
frequency.
Cathryn Mataga
From: te...@animats.net <te...@animats.net>
To: linux...@vger.rutgers.edu <linux...@vger.rutgers.edu>
Date: Sunday, October 24, 1999 4:46 PM
Subject: Re: dhcpd + sv2agw
Yeah, for people on the same frequency, doing BROADCAST, with the kernel changes
I showed earlier should work. Then you can just 'sbin/ifconfig broadcast 44.4.28.255'
for example, and send to that address (And you need to setsockopt also.).
Other programs just read from the broadcast
address. I've been doing exactly these tests just yesterday.
MULTICAST, that is "/sbin/ifconfig device multicast",
should, as I understand it, with a network of worldwide servers, be smart enough
only to forward to servers who have users who need the packets. It's like I open
one socket, write a packet, and either one computer or every computer on the
whole net could see that data.
I assume, how it might happen for hams, then is that people running Internet gateways would
run mrouted on their systems. And then users on those lans could run existing
MULTICAST applications either from native Windows or on Linux. And, by my
understanding, say, if someone wanted to broadcast a radio show or something,
they'd open a single socket on the host machine, and write that voice data. And,
then the network would be responsible for distributing the information to everyone
who was listening. Maybe with slow ham networks, voice would be overkill, but
it should also work with text based stuff too. Like maybe chat rooms and things.
Try...
http://www.linuxdoc.org/HOWTO/Multicast-HOWTO.html
I think everything is in the Linux KERNEL to do multicast over RF, theoretically,
though I don't know how close it is to working. I do know the packets do go
through a bunch of code that looks like it's supposed to be for multicast
packets when they come in over ax25, so it looks like it should work. That
weird packet that comes out of Windows, to 224.0.0.2 is some kind of
multicast thing also.
It seems most of the multicast activity is on BSD, and
not linux -- but then the ax25 is all Linux and not BSD, so there you go.
If multicast isn't catastrophically dead for ax25, it'd be nice to find out,
so that we could have it turned on for 2.14 or something and try some
applications.
te...@animats.net
> MULTICAST, that is "/sbin/ifconfig device multicast",
> should, as I understand it, with a network of worldwide servers, be smart enough
> only to forward to servers who have users who need the packets. It's like I open
> one socket, write a packet, and either one computer or every computer on the
> whole net could see that data.
You're thinking "IP Multicast", I was talking about AX.25 Multicast.
You can do IP multicast now without modification.