Why can't I sendto() to 127.255.255.255
Hello freebsd-hackers, I wrote a short program (on FreeBSD 6.0), that attempts to call sendto() on a UDP socket, with 127.255.255.255 as the destination address. It failed - with errno 49 (EADDRNOTAVAIL). Setting SO_BROADCAST and IP_ONESBCAST did not help. After examining - various RFC's, - source code under /usr/src/sys/netinet/ and - archives of freebsd-hackers & freebsd-net, I have not been able to determine the reason. Is it possible to successfully sendto() on a UDP socket with 127.255.255.255 as the destination address? If yes, how can that be done. Specific questions : -- - Is it correct to understand that 127.255.255.255 is the directed network broadcast address for net 127? If yes, which RFC specifies that? - If not, is 127.255.255.255 considered to be a host address? If yes, which RFC specifies that? -- Could you please help me understand this? sincerely Mathen (Abraham K. Mathen) _ Mega Airfare Sale. Click here Now. http://ss1.richmedia.in/recurl.asp?pid=18 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Why can't I sendto() to 127.255.255.255
> From: Abraham K. Mathen on Monday, April 30, 2007 5:54 AM > > I wrote a short program (on FreeBSD 6.0), that attempts > to call sendto() on a UDP socket, with 127.255.255.255 as > the destination address. It failed - with errno 49 (EADDRNOTAVAIL). > Setting SO_BROADCAST and IP_ONESBCAST did not help. Perhaps because the matched route for that address points to lo0 on your system and lo0 is not a broadcast-capable interface? lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff00 Note that there is no "BROADCAST" flag. Just a guess. David ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: msleep() on recursivly locked mutexes
On Friday 27 April 2007 02:32:20 pm Hans Petter Selasky wrote: > > > P0 unlock(1); > > > P0 unlock(2); > > > > this looks "interesting". > > Can you give a more concrete example of this? > > what work is done in the upcall? WHo is upcalling to who? > > For example an USB device driver might be up-calling to the USB host > controller driver. Down call is when the transfer finishes. I think in this case you don't want to keep the periph locked while you ask the controller to process requests. Instead, the periph drivers should queue requests to the controller and receive replies, but they should be considered as two independent objects. For example, network drivers drop their lock when passing a packet (request) up the stack. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
