Okay, I figured it out. It was a firewall issue. That I had copied
/sbin/ipchains -P forward DENY according to the ipchains instructions
without really thinking about it too much.
/sbin/ipchains -M -S 7200 10 160
/sbin/ipchains -P forward DENY
/sbin/ipchains -A forward -s 192.168.1.0/24 -j MASQ
I just changed it to
/sbin/ipchains -P forward ACCEPT, and it now works fine. Duh. I think this
is a security issue -- or that's what it said in the ipchains manual, so I have
to study that a little more to only allow 224.0.0.0/4 -- no big. Heh..
Anyway, doing this, basically, multicast, that is into and out of ax25 seems
to work. Cool. Kernel/libax25 are all okay. Now, all I need to do is
pull out a few telltales, cook up a klugely little chat application, and
find some people to tunnel with. (I believe you need static ip's for this. Though
I'm hoping to get this working on low bandwidth connections. I guess I'll only
find out how low it can go bandwidth-wise, by testing it out.) I'll keep a
precompiled mrouted on http://ke6i.com .
-----Original Message-----
From: Cathryn Mataga <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Tuesday, October 26, 1999 1:18 PM
Subject: Re: mrouted (Multicast) + libax25
>Btw, does anyone know the story behind this interesting, but
>slightly distressing comment in /usr/src/linux/net/ipv4/arp.c
>Like, does anyone know what is this business about
>hard_start_xmit and rebuild_header?
>
>
>#if 1
> /* So... these "amateur" devices are hopeless.
> The only thing, that I can say now:
> It is very sad that we need to keep ugly obsolete
> code to make them happy.
>
> They should be moved to more reasonable state, now
> they use rebuild_header INSTEAD OF hard_start_xmit!!!
> Besides that, they are sort of out of date
> (a lot of redundant clones/copies, useless in 2.1),
> I wonder why people believe that they work.
> */
> switch (dev->type) {
> default:
> break;
> case ARPHRD_ROSE:
>#if defined(CONFIG_AX25) || defined(CONFIG_AX25_MODULE)
> case ARPHRD_AX25:
>#if defined(CONFIG_NETROM) || defined(CONFIG_NETROM_MODULE)
> case ARPHRD_NETROM:
>#endif
> neigh->ops = &arp_broken_ops;
> neigh->output = neigh->ops->output;
> return 0;
>#endif
> }
>#endif
> if (neigh->type == RTN_MULTICAST) {
> neigh->nud_state = NUD_NOARP;
> arp_mc_map(addr, neigh->ha, dev, 1);
> } else if (dev->flags&(IFF_NOARP|IFF_LOOPBACK)) {
> neigh->nud_state = NUD_NOARP;
>
>I'm sort of meditating now, on exactly how this works.
>I'm trying to figure out whether in order
>to get this to work, I need to come up with some kind of mapping
>from multicast addresses to AX25 destination callsigns. Or whether
>the rest of the code can live without this. I think, this is just a filter
>mechanism -- so it shouldn't matter.
>
>int arp_mc_map(u32 addr, u8 *haddr, struct device *dev, int dir)
>{
> switch (dev->type) {
> case ARPHRD_ETHER:
> case ARPHRD_IEEE802:
> case ARPHRD_FDDI:
> ip_eth_mc_map(addr, haddr);
> return 0;
> default:
> if (dir) {
> memcpy(haddr, dev->broadcast, dev->addr_len);
> return 0;
> }
> }
> return -EINVAL;
>}
>
>
>The igmp packets do make it to mrouted, I've figured out. Or mrouted's logs
>look the same whether I'm listening on ethernet or on ax25.
>
