Ahhhh -- I finally got dhcpd working.  One last thing.  By the suggestion
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.  

-----Original Message-----
From: Cathryn Mataga <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Saturday, October 23, 1999 5:23 PM
Subject: Re: dhcpd + sv2agw


>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

Reply via email to