Date: Mon, 15 Nov 2004 15:05:19 -0800 From: Julian Elischer <julian@elischer.org> To: Gleb Smirnoff <glebius@freebsd.org> Cc: net@freebsd.org Subject: Re: divert(4) socket isn't connection oriented Message-ID: <4199362F.2070401@elischer.org> In-Reply-To: <20041115200936.GB96804@cell.sick.ru> References: <20041115104331.GA93477@cell.sick.ru> <200411151417.iAFEHfhN015171@arch20m.dellroad.org> <20041115200936.GB96804@cell.sick.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Gleb Smirnoff wrote: >On Mon, Nov 15, 2004 at 08:17:41AM -0600, Archie Cobbs wrote: >A> > Since it is working, it was not noticed quickly. Real problems occur when >A> > a multicast packet comes on interface: it is diverted to ng_ksocket, returned >A> > and div_output() sends it to ip_output(). In ip_output() it is ip_mloopback()ed >A> > and if_simloop()ed. A copy of packet enters divert socket, duplicated... a >A> > forever loop and total freeze. >A> >A> Your fix makes sense, but is it more of a workaround than a proper fix? > >I don't think so. > >Is divert(4) connection oriented? No, therefore so->so_state & SS_ISCONNECTED >must be zero; therefore it shouldn't have pru_disconnect method. >Does divert(4) has listen queue? No, therefore it shouldn't have pru_abort >method. > >A> It seems like the real bug is that divert is promising to write the packet >A> as "outgoing" yet the packet loops back as "incoming". Maybe it would make >A> more sense to attach a tag to the packet that divert would recognize and >A> know to ignore the extra incoming packet. > >This would be a workaround. divert(4) protocol uses sockaddr for this purpose, >because m_tags do not pass thru userland. And ng_ksocket should emulate >userland socket perfectly, otherwise it has no sense. It must understand >sockaddr. > >A> Also, does the same thing happen with broadcast packets? > >No. > >So, the real change suggested is to remove SS_ISCONNECTED from so->so_state. All >other changes are its logical consequences. >What was idea of that SS_ISCONNECTED flag always set? I can't find any problems we >can get by removing this code. > I think that if there were any reasons they have probably been removed over the years.. I cannot remember why we did this.. maybe if we could look at the old Whistle CVS tree, we might remember but it may even have been a cut-n-paste thing with no "reason" other than teh feeling that the destination of teh packets (the IPFW module) was fixed. also there may have been code that refused to send packets using sendto() if there was a NULL address. I think we wanted a plain "write" to teh socket to do smething so that you could pipe to it.. > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4199362F.2070401>