On Thu, Apr 20, 2000 at 11:21:40AM +0200, Niccolo Rigacci wrote: > I fund an annoyng bug in diald when the following conditions are met: > > - Diald start a connection because a packet is accepted by the filter. > - The first packet went through the interface is a packet which > is to be ignored because it has no matching rule (or because > it is discarded by strict-forwarding option). > > In this case diald stops the connection logging "Closing down idle > link". This was my case, because my ISP floods multicast packets (IP > dest 224.0.0.x) on the line. > > You can reproduce the bug in this way: > > - Put as standard.filter the single line > "accept icmp 180 ip.daddr 195.110.109.2" > > - Bring the line up with a single "ping -c 1 195.110.109.2" > > - Just after the line went up, send another ping: > "ping -c 1 195.1.1.1" > The line goes down. This one was difficult to duplicate, but it was possible. I had to disable anything in /etc/ppp/ip-up.d, bring up the line with a FIFO command, and do a continuous ping on the ignored IP. > The bug is in firewall.c, function check_firewall(). The function should > return 1 if found an accepting rule with non zero timeout, but it > returns 1 also if no matching rule is found: > > /* Failed to match any rule. This means we ignore the packet */ > if (debug&DEBUG_FILTER_MATCH) > log_packet(0,ip_pkt,len,0); > return 1; Hmm... no, that doesn't look right. It should return 0, as you say. > A few line before there is also a mispelled condition: > > return ((fw->filt.type != FW_TYPE_IGNORE || > fw->filt.type != FW_TYPE_WAIT) && fw->filt.timeout > 0); > > But (A != B || A != C) is always true! May be it should be && instead of > ||. Beside that the code here refers to a rule of type FW_TYPE_WAIT: as > far I can see in the code there are not rule of this type. I think this > is a stale constant and should be removed. Perhaps, but I don't know what's going on in Mike's mind (or what went on in Eric's). This may be a planned feature for some future version. I'll let Mike make that call. The comparison is definitely bogus, though. Perhaps an && would suffice; it is the equivalent to your patch for now, and won't break should someone decide to implement that feature. > There are other problems too. I think the upstream mantainer should be > contacted to revise the fix. Till now I discussed the matter on > [EMAIL PROTECTED], without much feedback. So I've noticed. I'll CC the list. I suppose I should take this time to introduce myself to the list. I'm the new maintainer of diald for Debian. I'll be uploading a fix to these bugs to the unstable "woody" distribution; additionally, this version will integrate into Debian's "pppconfig" system for configuring dialup addresses, and will support ethertap on Debian "out of the box". I'll let the list know when this is available. - To unsubscribe from this list: send the line "unsubscribe linux-diald" in the body of a message to [EMAIL PROTECTED]
