Okay, I think I know why broadcasts aren't working on ax25. I added the ETH_P_IP
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.
-----Original Message-----
From: Cathryn Mataga <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Saturday, October 23, 1999 1:38 PM
Subject: Re: dhcpd + sv2agw
>The broadcast going out on ax25 looks good, at least. I can trace
>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 <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
>Date: Saturday, October 23, 1999 12:08 AM
>Subject: Re: dhcpd + sv2agw
>
>
>>Thanks for the pointer. Well, this patch does allow me to get the
>>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.
>>>
>>>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
>>>[EMAIL PROTECTED] - TCP/IP packet radio in the Pacific Northwest
