locking in network if attach again
Hi all, the following problem occured just to me. Suppose the last lines in my attach() function look something like: if_attach(...) bus_setup_intr(...) Last time we had the locking discussion it was more or less the concensus, that no locking is needed in attach() and that the last thing I do is setting up the interrupt. It seems to me, however, that the following may happen here: 1. After if_attach but before setup_intr() a process on another processor calls if_ioctl to make the interface UP and if_start() to start output. 2. while the attach routine is blocked (perhaps while an interrupt is serverd) if_start initiates output. 3. The device tries to interrupt but cannot do that (setup_intr() has not been called yet). 4. The device gets stuck, because the interrupt is lost. 5. setup_intr() is called but that does not help. Is this a possible scenario? I must admit, that such a scenarion has a rather low probability, but according to Murphy's Law, it will happen. Maybe if_attach and bus_setup_intr can be reversed. In this case the interrupt routine must be careful to not call into the network system, because the network system doesn't know anything about the interface until if_attach(). Another solution would be to lock softc before if_attach, but this would probably provoke an LOR (as I remember). Regards, harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: route pointing to a gateway that's not on net
On Thu, Mar 13, 2003 at 03:34:18PM -0500, J. W. Ballantine wrote: >round-trip min/avg/max/stddev = 3.022/3.428/5.029/0.801 ms ># ping 207.172.3.8<<< one of isp's name server >PING 207.172.3.8 (207.172.3.8): 56 data bytes >ping: sendto: Host is down >ping: sendto: Host is down >ping: sendto: Host is down >ping: sendto: Host is down > > So this method allows my system to get to the > modem/dhcp server/gateway, but no further. (when I ping > from windows I get a response, so the system isn't down.) That is because 207.172.3.8 is not directly connected. By speficying a route entry with -iface you specify it is directly connected. That is the reason you can now reach the 10.*hosts. The problem with the 207.172.3.* hosts exists because your routing table expects the 207.172.3.* range to be directly connected. So either you have to make them apear directly connected, or you must say that they are not directly connected. The first can be doe by having your gateway do proxy arp, or by manually setting arp entries on your host (for all 207.172.3.* hosts, do arp -s host MAC, where MAC is the mac address of your gateway). I don't know how to do the second one, except for adding single host routes for each host, i.e.: route add host-ip-address gateway-ip-address. -Guido To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: route pointing to a gateway that's not on net
So what you are saying is that with the: route add -net default -iface -interface xl0 command the system thinks there is a direct connect. Doesn't this then send all packets out, since there is no address supplied with the route command, or is this a function the the 10.*.*.* addresses are private network addresses. If it sends all packets out, I would expect the 10.17.47.37 to receive it and forward it, since it is the gateway/modem. Having taken a quick look at the arp man page, it seems that one needs to arp each address/host rather than globally. Again, what I'm trying to do is get the system to pass all packets to the gateway/modem for forwarding over the net. Thanks Jim -- In Response to your message - > Date: Fri, 14 Mar 2003 11:24:31 +0100 > To: "J. W. Ballantine" <[EMAIL PROTECTED]> > From: Guido van Rooij <[EMAIL PROTECTED]> > Subject: Re: route pointing to a gateway that's not on net > Sender: [EMAIL PROTECTED] > > On Thu, Mar 13, 2003 at 03:34:18PM -0500, J. W. Ballantine wrote: > >round-trip min/avg/max/stddev = 3.022/3.428/5.029/0.801 ms > ># ping 207.172.3.8<<< one of isp's name ser ver > >PING 207.172.3.8 (207.172.3.8): 56 data bytes > >ping: sendto: Host is down > >ping: sendto: Host is down > >ping: sendto: Host is down > >ping: sendto: Host is down > > > > So this method allows my system to get to the > > modem/dhcp server/gateway, but no further. (when I ping > > from windows I get a response, so the system isn't down.) > > That is because 207.172.3.8 is not directly connected. By speficying a > route entry with -iface you specify it is directly connected. That > is the reason you can now reach the 10.*hosts. > > The problem with the 207.172.3.* hosts exists because your routing > table expects the 207.172.3.* range to be directly connected. > > So either you have to make them apear directly connected, or you must say th at > they are not directly connected. The first can be doe by having your gateway > do proxy arp, or by manually setting arp entries on your host > (for all 207.172.3.* hosts, do arp -s host MAC, where MAC is the mac address > of your gateway). > I don't know how to do the second one, except for adding single host routes > for each host, i.e.: route add host-ip-address gateway-ip-address. > > -Guido > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: route pointing to a gateway that's not on net
On Fri, Mar 14, 2003 at 09:51:46AM -0500, J. W. Ballantine wrote: > So what you are saying is that with the: >route add -net default -iface -interface xl0 > command the system thinks there is a direct connect. Doesn't this > then send all packets out, since there is no address supplied with > the route command, or is this a function the the 10.*.*.* addresses > are private network addresses. In order to send packets out directly they need to be directly connected, i.e. respond to arp requests whihc is only done on the same LAN. I hope you understand that this will not work with a default route. > > If it sends all packets out, I would expect the 10.17.47.37 to receive it > and forward it, since it is the gateway/modem. And how do you think the packets arive at 10.17.47.37? Suppose you want to send a packet to 1.2.3.4 with the above mentioned route. Then the system will arp for 1.2.3.4. Clearly noone will answer so this will fail. > > Having taken a quick look at the arp man page, it seems that one needs to > arp each address/host rather than globally. > > Again, what I'm trying to do is get the system to pass all packets to > the gateway/modem for forwarding over the net. Why dont you actually try what I advised you to do? Sorry to be blunt, but with the comments you make it is very clear that you have no clue on how IP traffic interacts with link level traffic. So either read a book or just try what people tell you. -Guido To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: route pointing to a gateway that's not on net
-- In Response to your message - > Date: Fri, 14 Mar 2003 19:11:40 +0100 > To: "J. W. Ballantine" <[EMAIL PROTECTED]> > From: Guido van Rooij <[EMAIL PROTECTED]> > Subject: Re: route pointing to a gateway that's not on net > Sender: [EMAIL PROTECTED] > > On Fri, Mar 14, 2003 at 09:51:46AM -0500, J. W. Ballantine wrote: > > So what you are saying is that with the: > >route add -net default -iface -interface xl0 > > command the system thinks there is a direct connect. Doesn't this > > then send all packets out, since there is no address supplied with > > the route command, or is this a function the the 10.*.*.* addresses > > are private network addresses. > > In order to send packets out directly they need to be directly connected, > i.e. respond to arp requests which is only done on the same LAN. > I hope you understand that this will not work with a default route. > > > > > If it sends all packets out, I would expect the 10.17.47.37 to receive it > > and forward it, since it is the gateway/modem. > > And how do you think the packets arive at 10.17.47.37? > Suppose you want to send a packet to 1.2.3.4 with the above mentioned route. > Then the system will arp for 1.2.3.4. Clearly noone will answer so this > will fail. > > > > > Having taken a quick look at the arp man page, it seems that one needs to > > arp each address/host rather than globally. > > > > Again, what I'm trying to do is get the system to pass all packets to > > the gateway/modem for forwarding over the net. > > Why dont you actually try what I advised you to do? > Sorry to be blunt, but with the comments you make it is very clear that > you have no clue on how IP traffic interacts with link level traffic. > So either read a book or just try what people tell you. Quite frankly, blunt is not a problem, one needs to call them as one sees them. However, responding to a question with a condesending, superior attitude(IMHO), while ignoring the question is. As for "just try what people tell you", if it doesn't appear resolve the larger problem, but just the example, than it isn't the correct resolution to the issue and trying to get clarification shouldn't be scorned, after all there is always someone out there who knows more. > > -Guido > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: route pointing to a gateway that's not on net
On Fri, Mar 14, 2003 at 03:07:26PM -0500, J. W. Ballantine wrote: > Quite frankly, blunt is not a problem, one needs to call them as one sees > them. However, responding to a question with a condesending, superior > attitude(IMHO), while ignoring the question is. As for "just try what > people tell you", if it doesn't appear resolve the larger problem, but just > the example, than it isn't the correct resolution to the issue and trying > to get clarification shouldn't be scorned, after all there is always someone > out there who knows more. I did answer your question. You should either add host routes or turn on proxy arp at the gateway. In stead of telling us if that worked out you come with different questions. Have you actually tried the 3 different possibilities mentioned in my mail with message-id [EMAIL PROTECTED] ? -Guido To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: route pointing to a gateway that's not on net
-- In Response to your message - > Date: Fri, 14 Mar 2003 21:29:44 +0100 > To: "J. W. Ballantine" <[EMAIL PROTECTED]> > From: Guido van Rooij <[EMAIL PROTECTED]> > Subject: Re: route pointing to a gateway that's not on net > > On Fri, Mar 14, 2003 at 03:07:26PM -0500, J. W. Ballantine wrote: > > Quite frankly, blunt is not a problem, one needs to call them as one sees > > them. However, responding to a question with a condesending, superior > > attitude(IMHO), while ignoring the question is. As for "just try what > > people tell you", if it doesn't appear resolve the larger problem, but jus t > > the example, than it isn't the correct resolution to the issue and trying > > to get clarification shouldn't be scorned, after all there is always someo ne > > out there who knows more. > > I did answer your question. You should either add host routes or turn > on proxy arp at the gateway. In stead of telling us if that worked > out you come with different questions. > > Have you actually tried the 3 different possibilities mentioned in > my mail with message-id [EMAIL PROTECTED] ? > > -Guido > Of the 3 different possibilities mentioned: I did try route add -net without -iface, and the result was no route to host. I didn't try to arp to 207.172.3.* hosts because that sounded like a fix for only one small network and I asked for clarification. The other single host routes for each host again doesn't resolve the larger issue of basic network access. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
