Re: Issue with 'Unknown Error: -512'
On 7/19/2011 10:31 AM, Brandon Falk wrote: On 7/19/2011 5:14 AM, Dimitry Andric wrote: On 2011-07-18 16:53, Brandon Falk wrote: In recent branches (confirmed with 224119) builds compiled with clang happen to throw 'Unknown error: -512' in a lot of places, making the system unusable. (Untested on gcc compiled systems). I have never seen this, neither with clang-compiled nor gcc-compiled systems. Can you please verify if it still occurs if you build your system with gcc? If you don't want (or can) rebuild the whole system, you can try to rebuild just your kernel with gcc, and see if the problems disappear. Originally I thought the problem was with specific programs, then I narrowed it down to file I/O, and now I've narrowed it down to open() with O_TRUNC. Without O_TRUNC there seems to be no issues whatsoever. With O_TRUNC on open() it fails with that 'Unknown error: -512' every other time you run the program. Common issues, portsnap is affected, making it impossible to fetch/extract ports. As well as redirecting output in shells eg `echo 'hi'> test` fails every other try. You have the same issue with text editors like `edit` where it fails every other save. There are no issues with `echo 'hi'>> test` as there is no O_TRUNC, it only seems to be an O_TRUNC error. I have been running clang-compiled systems for a long time now, and have never seen this. It works fine here, I cannot reproduce any of your examples. Do you build with any special settings in make.conf or src.conf, particularly modified CFLAGS or COPTFLAGS? What is your architecture, i386 or amd64? Any other non-standard configuration or environment settings? Dimitry, I will try to build with gcc sometime today. I might as well try out a different filesystem too. I have no special settings besides CPUTYPE?=native, but there was someone with a similar error who did not specify a cpu type when building, so I know that isn't a problem. Arch is amd64, no other nonstandard configuration. -Brandon Falk ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" I just did a clang build with CPUTYPE?=native and the unknown error issue has seemed to calm down a large amount. I still occasionally get it, but given multiple attempts at say compiling software, it will move on and all will be well. It is for sure not happening every other O_TRUNC, but it is still happening. Depending on system configuration, this still could cause some major issues for people. I'll keep my eye out and see what changes and try to figure out how to duplicate the issue on the new rev. Rev: 224221 Built with clang and CPUTYPE?=native -Brandon Falk ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Jails: Setting different times in jails
> Why on earth would you want this? Hi. Since your quote of my note was not to the original, I'll repost it here. Kurt Lidl also posted useful situations on these lists. Also, being able to have time tick backwards in jails could be interesting fuzzing too :-) Enjoy. Would be nice to be able to set different times in different jails. All jails would tick in step with the system. But each jail could have it's birthtime set specifically via jail(8), jail(2), etc. Either by specification of a specific time, or an offset from the current true system time. ie: jail(8): -t [-|+] Child jails would offset from their parent, not the system. Internally, gettimeofday, filesystem timestamps, and any other userland interfaces would be hooked and adjusted by referencing a table of jail ID's and their offsets. Similar to how setting TZ or /etc/localtime effects a timezone offset. But transparent and undetectable to the jail unless set as visible by the invoker. Useful for creating alternate histories, testing time dependant protocols and applications, forensics, pen testing, etc. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
setkey and -ctx
I have a Cisco ASA which expects a different tunnel for each IP that I'm sending traffic to (ie: it expects a different tunnel per firewall rule over there). It looks like I should have each SA in a different domain on my side to do this --- so it looks like I should be using the "-ctx" flag to setkey (or in /etc/ipsec.conf). But setkey appears to reject this... Is this unimplemented? Am I missing something? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: broadcast oddity
Tue, Jul 19, 2011 at 10:40:11AM +0300, Daniel Braniss wrote:
> > And that non-broadcast ethernet address is the MAC of your
> > default router?
> yes.
Fine, that is more-or-less expected, since the network subsystem
just routes 255.255.255.255 to the default gateway. The issue
you're seeing were already seen before,
http://lists.freebsd.org/pipermail/freebsd-net/2005-October/008626.html
http://www.freebsd.org/cgi/query-pr.cgi?pr=72468
http://lists.freebsd.org/pipermail/freebsd-net/2007-January/012874.html [1]
and bms@ told me that in this case the default gateway routing is the
correct historical behaviour of FreeBSD.
[1] I finally remembered that I had seen this issue too ;))
> > What's your routing table (netstat -rn) for the PXE-booted host?
>
> it's ok, same in both cases. it's picked up via DHCP, in the diskless
> case by the boot/loader in the second via dhcpclient.
Still, can you show both of them?
> > You nailed it: you should send packets to the network's broadcast,
> > not to the 0x.
> >
> but I'm at the user/ip level!, have no way to set mac/ethernet address.
I meant the IP's network broadcast and by 0x I meant
255.255.255.255. Please, look at the posted code.
> still, the question is why it works in one case, and failes in the other.
Yes, it is. But ip_output.c has the following code,
{{{
if (rte->rt_flags & RTF_GATEWAY)
dst = (struct sockaddr_in *)rte->rt_gateway;
if (rte->rt_flags & RTF_HOST)
isbroadcast = (rte->rt_flags & RTF_BROADCAST);
else
isbroadcast = in_broadcast(dst->sin_addr, ifp);
}}}
So, if the route that is selected is the gateway, then there will be
no broadcast on the L2. At least in my understanding of the code.
Thus, I am interested in the routing tables and route flags.
--
Eygene Ryabinkin,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
pgp5BH7fvJOj1.pgp
Description: PGP signature
Re: Issue with 'Unknown Error: -512'
On 7/19/2011 5:14 AM, Dimitry Andric wrote: On 2011-07-18 16:53, Brandon Falk wrote: In recent branches (confirmed with 224119) builds compiled with clang happen to throw 'Unknown error: -512' in a lot of places, making the system unusable. (Untested on gcc compiled systems). I have never seen this, neither with clang-compiled nor gcc-compiled systems. Can you please verify if it still occurs if you build your system with gcc? If you don't want (or can) rebuild the whole system, you can try to rebuild just your kernel with gcc, and see if the problems disappear. Originally I thought the problem was with specific programs, then I narrowed it down to file I/O, and now I've narrowed it down to open() with O_TRUNC. Without O_TRUNC there seems to be no issues whatsoever. With O_TRUNC on open() it fails with that 'Unknown error: -512' every other time you run the program. Common issues, portsnap is affected, making it impossible to fetch/extract ports. As well as redirecting output in shells eg `echo 'hi'> test` fails every other try. You have the same issue with text editors like `edit` where it fails every other save. There are no issues with `echo 'hi'>> test` as there is no O_TRUNC, it only seems to be an O_TRUNC error. I have been running clang-compiled systems for a long time now, and have never seen this. It works fine here, I cannot reproduce any of your examples. Do you build with any special settings in make.conf or src.conf, particularly modified CFLAGS or COPTFLAGS? What is your architecture, i386 or amd64? Any other non-standard configuration or environment settings? Dimitry, I will try to build with gcc sometime today. I might as well try out a different filesystem too. I have no special settings besides CPUTYPE?=native, but there was someone with a similar error who did not specify a cpu type when building, so I know that isn't a problem. Arch is amd64, no other nonstandard configuration. -Brandon Falk ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Issue with 'Unknown Error: -512'
On 7/19/2011 7:31 AM, Garrett Cooper wrote: On Tue, Jul 19, 2011 at 4:58 AM, Garrett Cooper wrote: On Mon, Jul 18, 2011 at 5:19 PM, Brandon Falk wrote: On 7/18/2011 10:18 AM, Andriy Gapon wrote: on 18/07/2011 17:53 Brandon Falk said the following: Hello, In recent branches (confirmed with 224119) builds compiled with clang happen to throw 'Unknown error: -512' in a lot of places, making the system unusable. (Untested on gcc compiled systems). Originally I thought the problem was with specific programs, then I narrowed it down to file I/O, and now I've narrowed it down to open() with O_TRUNC. Without O_TRUNC there seems to be no issues whatsoever. With O_TRUNC on open() it fails with that 'Unknown error: -512' every other time you run the program. Common issues, portsnap is affected, making it impossible to fetch/extract ports. As well as redirecting output in shells eg `echo 'hi'>test` fails every other try. You have the same issue with text editors like `edit` where it fails every other save. There are no issues with `echo 'hi'>>test` as there is no O_TRUNC, it only seems to be an O_TRUNC error. Any tips? Otherwise I'll be looking into this today myself. Just a hint that you could try using DTrace syscall and fbt providers to see where in kernel (if in kernel) that -512 return value originates. Update: I've traced more and more into the kernel, and currently I have found the following trace: ufs_setattr() (in sys/ufs/ufs/ufs_vnops.c:507) (In truncate a bunch of stuff is done, but it succeeds until VOP_SETATTR) vn_truncate() (in sys/kern/vfs_vnops.c:636) kern_openat() (in sys/kern/vfs_syscalls.c:1043) kern_open() (in sys/kern/vfs_syscalls.c:1035) open() (in sys/kern/vfs_syscalls.c:1006) ufs_setattr() returns with -1 (EPERM) I'll continue to try to find the exact problem. A quick workaround currently would probably be to use a different filesystem other than ufs, but then again, I have no clue if other filesystems have the same issue. Hopefully that trace will help anyone who wants to help out. What UFS options do you have defined in your kernel? Also, what does mount say and have you tried running as root? Thanks, -Garrett Garrett, I am running as root. No issues with the mounting. As for options, which do you want? -Brandon Falk ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [RELEASE] New Boot-Loader Menu bugs?
On Monday, July 18, 2011 3:40:19 am Doug Barton wrote: > On 07/17/2011 20:40, Devin Teske wrote: > > What release are you running? > > Recent HEAD I upgraded my desktop at home to HEAD yesterday and tested this via a 'boot kernel.GENERIC' at the loader prompt and it did the same as the previous loader (module_path was /boot/kernel.GENERIC;/boot/kernel;/boot/modules), so I think the new boot loader menus work fine in this regard. How exactly are you reproducing your broken case Doug? Do you have any settings in /boot/loader.conf or /boot/loader.conf.local? -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] __FreeBSD_kernel__
2011/7/5 Alexander Kabaev : > The slow way would be the right way if you were inclined to really take > it. Once old releases of tools that can be broken by the new macro > use are long and forgotten we can start on relying on said macro, but > not before. Given that your main concern is backward compatibility, is it an inconvenient to you if 3rd party compilers such as GCC or Clang begin adding this macro? If you're still not comfortable with this macro by the time you want to import one of those, it just takes a minute to remove it. The purpose of this, of course, is to start the clock count (as you've put it: "Once old releases of tools that can be broken by the new macro use are long and forgotten we can start on relying on said macro"). -- Robert Millan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Issue with 'Unknown Error: -512'
On Tue, Jul 19, 2011 at 4:58 AM, Garrett Cooper wrote: > On Mon, Jul 18, 2011 at 5:19 PM, Brandon Falk wrote: >> On 7/18/2011 10:18 AM, Andriy Gapon wrote: >>> >>> on 18/07/2011 17:53 Brandon Falk said the following: Hello, In recent branches (confirmed with 224119) builds compiled with clang happen to throw 'Unknown error: -512' in a lot of places, making the system unusable. (Untested on gcc compiled systems). Originally I thought the problem was with specific programs, then I narrowed it down to file I/O, and now I've narrowed it down to open() with O_TRUNC. Without O_TRUNC there seems to be no issues whatsoever. With O_TRUNC on open() it fails with that 'Unknown error: -512' every other time you run the program. Common issues, portsnap is affected, making it impossible to fetch/extract ports. As well as redirecting output in shells eg `echo 'hi'> test` fails every other try. You have the same issue with text editors like `edit` where it fails every other save. There are no issues with `echo 'hi'>> test` as there is no O_TRUNC, it only seems to be an O_TRUNC error. Any tips? Otherwise I'll be looking into this today myself. >>> >>> Just a hint that you could try using DTrace syscall and fbt providers to >>> see where >>> in kernel (if in kernel) that -512 return value originates. >>> >> >> Update: >> >> I've traced more and more into the kernel, and currently I have found the >> following trace: >> > ufs_setattr() (in sys/ufs/ufs/ufs_vnops.c:507) >> (In truncate a bunch of stuff is done, but it succeeds until VOP_SETATTR) > vn_truncate() (in sys/kern/vfs_vnops.c:636) > kern_openat() (in sys/kern/vfs_syscalls.c:1043) > kern_open() (in sys/kern/vfs_syscalls.c:1035) > open() (in sys/kern/vfs_syscalls.c:1006) >> >> ufs_setattr() returns with -1 (EPERM) >> >> I'll continue to try to find the exact problem. A quick workaround currently >> would probably be to use a different filesystem other than ufs, but then >> again, I have no clue if other filesystems have the same issue. >> >> Hopefully that trace will help anyone who wants to help out. > > What UFS options do you have defined in your kernel? Also, what does mount say and have you tried running as root? Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Issue with 'Unknown Error: -512'
On Mon, Jul 18, 2011 at 5:19 PM, Brandon Falk wrote: > On 7/18/2011 10:18 AM, Andriy Gapon wrote: >> >> on 18/07/2011 17:53 Brandon Falk said the following: >>> >>> Hello, >>> >>> In recent branches (confirmed with 224119) builds compiled with clang >>> happen to >>> throw 'Unknown error: -512' in a lot of places, making the system >>> unusable. >>> (Untested on gcc compiled systems). Originally I thought the problem was >>> with >>> specific programs, then I narrowed it down to file I/O, and now I've >>> narrowed it >>> down to open() with O_TRUNC. Without O_TRUNC there seems to be no issues >>> whatsoever. With O_TRUNC on open() it fails with that 'Unknown error: >>> -512' every >>> other time you run the program. Common issues, portsnap is affected, >>> making it >>> impossible to fetch/extract ports. As well as redirecting output in >>> shells eg >>> `echo 'hi'> test` fails every other try. You have the same issue with >>> text >>> editors like `edit` where it fails every other save. There are no issues >>> with >>> `echo 'hi'>> test` as there is no O_TRUNC, it only seems to be an >>> O_TRUNC error. >>> >>> Any tips? Otherwise I'll be looking into this today myself. >> >> Just a hint that you could try using DTrace syscall and fbt providers to >> see where >> in kernel (if in kernel) that -512 return value originates. >> > > Update: > > I've traced more and more into the kernel, and currently I have found the > following trace: > ufs_setattr() (in sys/ufs/ufs/ufs_vnops.c:507) > (In truncate a bunch of stuff is done, but it succeeds until VOP_SETATTR) vn_truncate() (in sys/kern/vfs_vnops.c:636) kern_openat() (in sys/kern/vfs_syscalls.c:1043) kern_open() (in sys/kern/vfs_syscalls.c:1035) open() (in sys/kern/vfs_syscalls.c:1006) > > ufs_setattr() returns with -1 (EPERM) > > I'll continue to try to find the exact problem. A quick workaround currently > would probably be to use a different filesystem other than ufs, but then > again, I have no clue if other filesystems have the same issue. > > Hopefully that trace will help anyone who wants to help out. What UFS options do you have defined in your kernel? Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Issue with 'Unknown Error: -512'
On 2011-07-18 16:53, Brandon Falk wrote: In recent branches (confirmed with 224119) builds compiled with clang happen to throw 'Unknown error: -512' in a lot of places, making the system unusable. (Untested on gcc compiled systems). I have never seen this, neither with clang-compiled nor gcc-compiled systems. Can you please verify if it still occurs if you build your system with gcc? If you don't want (or can) rebuild the whole system, you can try to rebuild just your kernel with gcc, and see if the problems disappear. Originally I thought the problem was with specific programs, then I narrowed it down to file I/O, and now I've narrowed it down to open() with O_TRUNC. Without O_TRUNC there seems to be no issues whatsoever. With O_TRUNC on open() it fails with that 'Unknown error: -512' every other time you run the program. Common issues, portsnap is affected, making it impossible to fetch/extract ports. As well as redirecting output in shells eg `echo 'hi'> test` fails every other try. You have the same issue with text editors like `edit` where it fails every other save. There are no issues with `echo 'hi'>> test` as there is no O_TRUNC, it only seems to be an O_TRUNC error. I have been running clang-compiled systems for a long time now, and have never seen this. It works fine here, I cannot reproduce any of your examples. Do you build with any special settings in make.conf or src.conf, particularly modified CFLAGS or COPTFLAGS? What is your architecture, i386 or amd64? Any other non-standard configuration or environment settings? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Issue with 'Unknown Error: -512'
on 19/07/2011 03:19 Brandon Falk said the following: > On 7/18/2011 10:18 AM, Andriy Gapon wrote: >> on 18/07/2011 17:53 Brandon Falk said the following: >>> Hello, >>> >>> In recent branches (confirmed with 224119) builds compiled with clang >>> happen to >>> throw 'Unknown error: -512' in a lot of places, making the system unusable. >>> (Untested on gcc compiled systems). Originally I thought the problem was >>> with >>> specific programs, then I narrowed it down to file I/O, and now I've >>> narrowed it >>> down to open() with O_TRUNC. Without O_TRUNC there seems to be no issues >>> whatsoever. With O_TRUNC on open() it fails with that 'Unknown error: -512' >>> every >>> other time you run the program. Common issues, portsnap is affected, making >>> it >>> impossible to fetch/extract ports. As well as redirecting output in shells >>> eg >>> `echo 'hi'> test` fails every other try. You have the same issue with text >>> editors like `edit` where it fails every other save. There are no issues >>> with >>> `echo 'hi'>> test` as there is no O_TRUNC, it only seems to be an O_TRUNC >>> error. >>> >>> Any tips? Otherwise I'll be looking into this today myself. >> >> Just a hint that you could try using DTrace syscall and fbt providers to see >> where >> in kernel (if in kernel) that -512 return value originates. >> > > Update: > > I've traced more and more into the kernel, and currently I have found the > following trace: > ufs_setattr() (in sys/ufs/ufs/ufs_vnops.c:507) > (In truncate a bunch of stuff is done, but it succeeds until VOP_SETATTR) vn_truncate() (in sys/kern/vfs_vnops.c:636) kern_openat() (in sys/kern/vfs_syscalls.c:1043) kern_open() (in sys/kern/vfs_syscalls.c:1035) open() (in sys/kern/vfs_syscalls.c:1006) > > ufs_setattr() returns with -1 (EPERM) But not -512, though. > I'll continue to try to find the exact problem. A quick workaround currently > would > probably be to use a different filesystem other than ufs, but then again, I > have > no clue if other filesystems have the same issue. > > Hopefully that trace will help anyone who wants to help out. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: broadcast oddity
Hi Eygene,
> Daniel, good day.
>
> Mon, Jul 18, 2011 at 05:04:27PM +0300, Daniel Braniss wrote:
> > this code behaves correctly when run from a diskless host which
> > booted via PXE, but fails on a host that was booted from disk.
> > hint: the non working sends a packet with a non ethernet broadcast
> > address and an ip address of 255.255.255.255,
>
> And that non-broadcast ethernet address is the MAC of your
> default router?
yes.
>
> > the working version sets the ethernet address to 0x and the
> > ip to the network broadcast address.
>
> What's your routing table (netstat -rn) for the PXE-booted host?
it's ok, same in both cases. it's picked up via DHCP, in the diskless
case by the boot/loader in the second via dhcpclient.
>
> > what am I doing wrong?
> >=20
> > danny
> > PS: what is the correct way to obtain the network broadcast address?
>
> You nailed it: you should send packets to the network's broadcast,
> not to the 0x.
>
but I'm at the user/ip level!, have no way to set mac/ethernet address.
still, the question is why it works in one case, and failes in the other.
> And in order to find the broadcast address for the interface (or
> network at that interface), you should use getifaddrs(), like in the
> attached example. It is very quick and dirty one and it has some
> limitations (e.g., it takes the first broadcast address from the
> interface), but it should be a good starting point.
thanks,
danny
> Eygene Ryabinkin,,,^..^,,,
> [ Life's unfair - but root password helps! | codelabs.ru ]
> [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
>
> --UeXZ3FjlYZvuln/G
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: attachment; filename="bcast.c"
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> void
> bcast(in_addr_t addr)
> {
> int so, on;
> char msg[BUFSIZ];
> struct timespec t2;
> struct sockaddr_in soin;
>
> if((so = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)) < 0) {
> perror("socket");
> exit(-1);
> }
> on = 1;
> if(setsockopt(so, SOL_SOCKET, SO_BROADCAST, &on, sizeof(on))) {
> perror("setsockopt");
> exit(-1);
> }
>
> bzero(&soin, sizeof(struct sockaddr_in));
> soin.sin_len = sizeof(struct sockaddr_in);
> soin.sin_family = AF_INET;
> soin.sin_addr.s_addr = addr;
> soin.sin_port = htons(12345);
> while(1) {
> clock_gettime(CLOCK_REALTIME, &t2);
> sprintf(msg, "0x%016x", t2.tv_sec);
> if(sendto(so, msg, strlen(msg)+1,
> 0, (struct sockaddr *)&soin, sizeof(struct sockaddr)) <
> 0) {
>perror("sendto");
>break;
> }
> sleep(10);
> }
> }
>
> main(int argc, char *argv[])
> {
> struct ifaddrs *ifap, *ifa, *our_if;
> struct sockaddr_in *sin;
>
> if (argc < 2)
> errx(1, "No arguments");
> if (getifaddrs(&ifap) != 0)
> perror("getifaddrs");
> our_if = NULL;
> for (ifa = ifap; ifa != NULL; ifa = ifa->ifa_next) {
> if (strcmp(argv[1], ifa->ifa_name) == 0) {
> sin = (struct sockaddr_in *)ifa->ifa_broadaddr;
> if (!(ifa->ifa_flags & IFF_BROADCAST) ||
>sin == NULL ||
>sin->sin_addr.s_addr == 0)
> continue;
> our_if = ifa;
> break;
> }
> }
> if (!our_if)
> errx(1, "Can't find broadcast-able interface '%s'", argv[1]);
> bcast(sin->sin_addr.s_addr);
> freeifaddrs(ifap);
> }
>
> --UeXZ3FjlYZvuln/G--
>
> --McpcKDxJRrEJVmOH
> Content-Type: application/pgp-signature
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (Darwin)
>
> iF0EAREIAAYFAk4kmE8ACgkQFq+eroFS7PvE+QD/ZL0cpFaKvLA+ZWWFH/QlA5Xb
> hqKEG+XY90zdya2/twEA9R3xcK8wwRtOiLf7Tb9SHviukeMsrxwufSWhdapJfj0=
> =Iujs
> -END PGP SIGNATURE-
>
> --McpcKDxJRrEJVmOH--
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
