Re: sys/boot/boot0/boot0.S - r186598
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --enig51B4786EC9D39188BAE04052 Content-Type: multipart/mixed; boundary=070003060308030201090207 This is a multi-part message in MIME format. --070003060308030201090207 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Today I ran into an issue where setting the default slice with boot0cfg -s is broken. This is related to a section of this revision: + commit Warner's patch orb $NOUPDATE,_FLAGS(%bp) to avoid writing to disk in case of a timeout/default choice; This issue is quite well documented in bin/134907 which has been open since May 2009. Reproduced with a fresh nanobsd build: Boot 1 - Slice 1 active as set by nanobsd image builder: =3D=3D=3D # boot0cfg -v ad0 # flag start chs type end chs offset size 1 0x80 0: 1: 1 0xa5494: 15:63 63 498897 2 0x00495: 1: 1 0xa5989: 15:63 499023 498897 3 0x00990: 0: 1 0xa5992: 15:63 997920 3024 version=3D2.0 drive=3D0x80 mask=3D0x3 ticks=3D182 bell=3D# (0x23) options=3Dpacket,update,nosetdrv volume serial ID 9090-9090 default_selection=3DF1 (Slice 1) =3D=3D=3D Update the active slice to 2: =3D=3D=3D # boot0cfg -s 2 -v ad0 # flag start chs type end chs offset size 1 0x80 0: 1: 1 0xa5494: 15:63 63 498897 2 0x00495: 1: 1 0xa5989: 15:63 499023 498897 3 0x00990: 0: 1 0xa5992: 15:63 997920 3024 version=3D2.0 drive=3D0x80 mask=3D0x3 ticks=3D182 bell=3D# (0x23) options=3Dpacket,update,nosetdrv volume serial ID 9090-9090 default_selection=3DF2 (Slice 2) =3D=3D=3D Reboot and let boot0 time out and boot default slice 2: =3D=3D=3D # boot0cfg -v ad0 # flag start chs type end chs offset size 1 0x80 0: 1: 1 0xa5494: 15:63 63 498897 2 0x00495: 1: 1 0xa5989: 15:63 499023 498897 3 0x00990: 0: 1 0xa5992: 15:63 997920 3024 version=3D2.0 drive=3D0x80 mask=3D0x3 ticks=3D182 bell=3D# (0x23) options=3Dpacket,update,nosetdrv volume serial ID 9090-9090 default_selection=3DF2 (Slice 2) =3D=3D=3D The system actually booted into slice 1 here. This was verified by dropping to the loader prompt and using show to grab= : loaddev=3Ddisk0s1a: Reboot and hit 2 at the boot0 prompt: =3D=3D=3D # boot0cfg -v ad0 # flag start chs type end chs offset size 1 0x00 0: 1: 1 0xa5494: 15:63 63 498897 2 0x80495: 1: 1 0xa5989: 15:63 499023 498897 3 0x00990: 0: 1 0xa5992: 15:63 997920 3024 version=3D2.0 drive=3D0x80 mask=3D0x3 ticks=3D182 bell=3D# (0x23) options=3Dpacket,update,nosetdrv volume serial ID 9090-9090 default_selection=3DF2 (Slice 2) =3D=3D=3D This time we really boot into slice 2. The attached patch backs out the relevant part of r186598. There was a post on the embedded list that suggested this work around: echo 'a 2' | fdisk -f /dev/stdin ad0 boot0cfg -s 2 ad0 There are 2 issues with this: 1) It can't be done without setting kern.geom.debugflags to 0x10. 2) It resulted in most/all commands resulting in the error message Device not configured including the second command and 'shutdown -r now= '. Both of which leave this really work around fairly broken. the problem is that boot0cfg -s does NOT update the boot block, it fails! the work around is: boot0cfg -s -t n dev then gpart set -a active -i n dev danny ___ 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: NFS Performance
Rick Do you have more details on the issue is it 8.x only ? Can you point us to the stable thread abourt this ? The bug is in the krpc, which means it's 8.x specific (at least for NFS, I'm not sure if the nlm used the krpc in 7.x?). David P. Discher reported a performance problem some time ago when testing the FreeBSD8 client against certain servers. (I can't find the thread, so maybe it never had a freebsd-stable@ cc after all.) Fortutnately John Gemignani spotted the cause (for at least his case, because he tested a patch that seemed to resolve the problem). The bug is basically that the client side krpc for TCP assumed that the 4 bytes of data that hold the length of the RPC message are in one mbuf and don't straddle multiple mbufs. If the 4 bytes does straddle multiple mbufs, the krpc gets a garbage message length and then typically wedges and eventually recovers by starting a fresh TCP connection up and retrying the outstanding RPCs. I have no idea if George is seeing the same problem, but the 1.5minute logjams suggest that it might. I emailed him a patch and, hopefully, he will report back on whether or not it helped. A patch for the above bug is in the works for head, rick ___ 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: sys/boot/boot0/boot0.S - r186598
On 09/01/2011 04:38, Daniel Braniss wrote: There was a post on the embedded list that suggested this work around: echo 'a 2' | fdisk -f /dev/stdin ad0 boot0cfg -s 2 ad0 There are 2 issues with this: 1) It can't be done without setting kern.geom.debugflags to 0x10. 2) It resulted in most/all commands resulting in the error message Device not configured including the second command and 'shutdown -r now= '. Both of which leave this really work around fairly broken. the problem is that boot0cfg -s does NOT update the boot block, it fails! the work around is: boot0cfg -s -t n dev then gpart set -a active -i n dev danny Hi Danny, The bug does not seem to be in boot0cfg as: 1) It succeeds to write the new configuration to the boot block every time i have tried. 2) It does not touch the partition table at all only the mbr, so it was never designed to change the active partition. If this is not a bug in boot0 then its a bug in the man pages for boot0cfg as it does make reference to having to change the active slice to make this work. Tom signature.asc Description: OpenPGP digital signature
Re: sys/boot/boot0/boot0.S - r186598
On Sun, Jan 09, 2011 at 12:39:28AM -0600, Tom Judge wrote: Hi, Today I ran into an issue where setting the default slice with boot0cfg -s is broken. a few questions inline: This is related to a section of this revision: + commit Warner's patch orb $NOUPDATE,_FLAGS(%bp) to avoid writing to disk in case of a timeout/default choice; This issue is quite well documented in bin/134907 which has been open since May 2009. Reproduced with a fresh nanobsd build: Boot 1 - Slice 1 active as set by nanobsd image builder: === # boot0cfg -v ad0 # flag start chs type end chs offset size 1 0x80 0: 1: 1 0xa5494: 15:63 63 498897 2 0x00495: 1: 1 0xa5989: 15:63 499023 498897 3 0x00990: 0: 1 0xa5992: 15:63 997920 3024 version=2.0 drive=0x80 mask=0x3 ticks=182 bell=# (0x23) options=packet,update,nosetdrv volume serial ID 9090-9090 default_selection=F1 (Slice 1) === Update the active slice to 2: === # boot0cfg -s 2 -v ad0 # flag start chs type end chs offset size 1 0x80 0: 1: 1 0xa5494: 15:63 63 498897 2 0x00495: 1: 1 0xa5989: 15:63 499023 498897 3 0x00990: 0: 1 0xa5992: 15:63 997920 3024 version=2.0 drive=0x80 mask=0x3 ticks=182 bell=# (0x23) options=packet,update,nosetdrv volume serial ID 9090-9090 default_selection=F2 (Slice 2) === what do you get here if you re-run boot0cfg -v ad0 before rebooting ? It seems that boot0cfg does not re-read data from disk so if the write for some reason fails (e.g. kern.geom.debugflags=0) you don't see the actual configuration of the boot sector. Looking at the code there should be an error message if writing to disk fails, but maybe the error reporting oes not work well... Reboot and let boot0 time out and boot default slice 2: === # boot0cfg -v ad0 # flag start chs type end chs offset size 1 0x80 0: 1: 1 0xa5494: 15:63 63 498897 2 0x00495: 1: 1 0xa5989: 15:63 499023 498897 3 0x00990: 0: 1 0xa5992: 15:63 997920 3024 version=2.0 drive=0x80 mask=0x3 ticks=182 bell=# (0x23) options=packet,update,nosetdrv volume serial ID 9090-9090 default_selection=F2 (Slice 2) === The system actually booted into slice 1 here. What does the system show as Default when it reboots ? F1 or F2 ? This is just to check if the update actually went to disk. This was verified by dropping to the loader prompt and using show to grab: loaddev=disk0s1a: Reboot and hit 2 at the boot0 prompt: === # boot0cfg -v ad0 # flag start chs type end chs offset size 1 0x00 0: 1: 1 0xa5494: 15:63 63 498897 2 0x80495: 1: 1 0xa5989: 15:63 499023 498897 3 0x00990: 0: 1 0xa5992: 15:63 997920 3024 version=2.0 drive=0x80 mask=0x3 ticks=182 bell=# (0x23) options=packet,update,nosetdrv volume serial ID 9090-9090 default_selection=F2 (Slice 2) === This time we really boot into slice 2. The attached patch backs out the relevant part of r186598. There was a post on the embedded list that suggested this work around: echo 'a 2' | fdisk -f /dev/stdin ad0 boot0cfg -s 2 ad0 There are 2 issues with this: 1) It can't be done without setting kern.geom.debugflags to 0x10. 2) It resulted in most/all commands resulting in the error message Device not configured including the second command and 'shutdown -r now'. Both of which leave this really work around fairly broken. Tom cheers luigi ___ 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: NFS performance
As requested earlier, I've moved the thread to freebsd-stable. -- George ___ 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: sys/boot/boot0/boot0.S - r186598
On 09/01/2011 12:33, Luigi Rizzo wrote: On Sun, Jan 09, 2011 at 12:39:28AM -0600, Tom Judge wrote: Hi, Today I ran into an issue where setting the default slice with boot0cfg -s is broken. a few questions inline: Output inline, full script log attached. If you need more info let me know. snip Update the active slice to 2: === # boot0cfg -s 2 -v ad0 # flag start chs type end chs offset size 1 0x80 0: 1: 1 0xa5494: 15:63 63 498897 2 0x00495: 1: 1 0xa5989: 15:63 499023 498897 3 0x00990: 0: 1 0xa5992: 15:63 997920 3024 version=2.0 drive=0x80 mask=0x3 ticks=182 bell=# (0x23) options=packet,update,nosetdrv volume serial ID 9090-9090 default_selection=F2 (Slice 2) === what do you get here if you re-run boot0cfg -v ad0 before rebooting ? It seems that boot0cfg does not re-read data from disk so if the write for some reason fails (e.g. kern.geom.debugflags=0) you don't see the actual configuration of the boot sector. Looking at the code there should be an error message if writing to disk fails, but maybe the error reporting oes not work well... Fresh transcript: # boot0cfg -v ad0 # flag start chs type end chs offset size 1 0x80 0: 1: 1 0xa5494: 15:63 63 498897 2 0x00495: 1: 1 0xa5989: 15:63 499023 498897 3 0x00990: 0: 1 0xa5992: 15:63 997920 3024 version=2.0 drive=0x80 mask=0x3 ticks=182 bell=# (0x23) options=packet,update,nosetdrv volume serial ID 9090-9090 default_selection=F1 (Slice 1) # boot0cfg -s 2 -v ad0 # flag start chs type end chs offset size 1 0x80 0: 1: 1 0xa5494: 15:63 63 498897 2 0x00495: 1: 1 0xa5989: 15:63 499023 498897 3 0x00990: 0: 1 0xa5992: 15:63 997920 3024 version=2.0 drive=0x80 mask=0x3 ticks=182 bell=# (0x23) options=packet,update,nosetdrv volume serial ID 9090-9090 default_selection=F2 (Slice 2) # boot0cfg -v ad0 # flag start chs type end chs offset size 1 0x80 0: 1: 1 0xa5494: 15:63 63 498897 2 0x00495: 1: 1 0xa5989: 15:63 499023 498897 3 0x00990: 0: 1 0xa5992: 15:63 997920 3024 version=2.0 drive=0x80 mask=0x3 ticks=182 bell=# (0x23) options=packet,update,nosetdrv volume serial ID 9090-9090 default_selection=F2 (Slice 2) # Reboot and let boot0 time out and boot default slice 2: === # boot0cfg -v ad0 # flag start chs type end chs offset size 1 0x80 0: 1: 1 0xa5494: 15:63 63 498897 2 0x00495: 1: 1 0xa5989: 15:63 499023 498897 3 0x00990: 0: 1 0xa5992: 15:63 997920 3024 version=2.0 drive=0x80 mask=0x3 ticks=182 bell=# (0x23) options=packet,update,nosetdrv volume serial ID 9090-9090 default_selection=F2 (Slice 2) === The system actually booted into slice 1 here. What does the system show as Default when it reboots ? F1 or F2 ? This is just to check if the update actually went to disk. # boot0cfg -v ad0 # flag start chs type end chs offset size 1 0x80 0: 1: 1 0xa5494: 15:63 63 498897 2 0x00495: 1: 1 0xa5989: 15:63 499023 498897 3 0x00990: 0: 1 0xa5992: 15:63 997920 3024 version=2.0 drive=0x80 mask=0x3 ticks=182 bell=# (0x23) options=packet,update,nosetdrv volume serial ID 9090-9090 default_selection=F2 (Slice 2) # shutdown -r now Shutdown NOW! shutdown: [pid 1104] # shutdown log snipped Rebooting... 1 FreeBSD 2 FreeBSD F6 PXE Boot: 2 -- Let time out, snip loader/beastie hit 6 at the menu -- OK show loaddev disk0s1a: OK --boot system and login -- # boot0cfg -v ad0 # flag start chs type end chs offset size 1 0x80 0: 1: 1 0xa5494: 15:63 63 498897 2 0x00495: 1: 1 0xa5989: 15:63 499023 498897 3 0x00990: 0: 1 0xa5992: 15:63 997920 3024 version=2.0 drive=0x80 mask=0x3 ticks=182 bell=# (0x23) options=packet,update,nosetdrv volume serial ID 9090-9090 default_selection=F2 (Slice 2) # mount /dev/label/nanobsd1 on / (ufs, local, read-only) devfs on /dev (devfs, local, multilabel) /dev/md0 on /etc (ufs, local) /dev/md1 on /var (ufs, local) # glabel status |grep nanobsd label/nanobsd1 N/A ad0s1a label/nanobsd2 N/A ad0s2a # This was verified by dropping to the loader prompt and using show to grab: loaddev=disk0s1a: Reboot and hit 2 at the boot0 prompt: === # boot0cfg -v ad0 # flag start chs type end chs offset size 1 0x00
Re: sys/boot/boot0/boot0.S - r186598
On Sun, Jan 09, 2011 at 12:57:24PM -0600, Tom Judge wrote: On 09/01/2011 12:33, Luigi Rizzo wrote: On Sun, Jan 09, 2011 at 12:39:28AM -0600, Tom Judge wrote: Hi, Today I ran into an issue where setting the default slice with boot0cfg -s is broken. a few questions inline: Output inline, full script log attached. If you need more info let me know. can you take a dump of the boot sector at various stages indicated below: snip DUMP #1: ORIGINAL BOOT SECTOR run boot0cfg -s 2 -v ad0 DUMP #2: AFTER THE BOOT SECTOR UPDATE reboot without pressing an F-key expect to be in s2 but actually end up in s1, as you found DUMP #3: AFTER A REBOOT WITH NO KEYPRESS reboot, this time selecting the slice with F2 DUMP #4: AFTER THE SUCCESSFUL BOOT IN SLICE 2 At least from this we can tell how #4 differs from #2/#3 cheers luigi ___ 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: binding non local ip.
2011/1/9 Eygene Ryabinkin r...@freebsd.org:
Sorry for my mail client broken that do not send mails to the list :)
I'll take care.
Joris, good day.
Sun, Jan 09, 2011 at 06:29:20PM +0100, joris dedieu wrote:
Thanks Eygene for this greate review !
No problems ;))
2011/1/7 Eygene Ryabinkin r...@freebsd.org:
Fri, Jan 07, 2011 at 01:57:21PM +0100, joris dedieu wrote:
What do you think about it ?
[...]
+static int bindany = 0; /* 1 allows to bind a non local ip */
+SYSCTL_INT(_net_inet_ip, OID_AUTO, bindany, CTLFLAG_RW, bindany, 0,
+ Allow to bind a non local ip);
On at least 8.x, you will likely want to use VNET_* macros to enable
your new sysctl to be virtualized. Something like this:
{{{
VNET_DEFINE(int, inp_bindany) = 0;
SYSCTL_VNET_INT(_net_inet_ip, OID_AUTO, bindany, CTLFLAG_RW,
VNET_NAME(inp_bindany), 0, Force INP_BINDANY on all sockets);
}}}
and use VNET(inp_bindany) in subsequent code.
Ok it make sense. I will use VNET_*. There are a lot of SYSCTL_* in
netinet and netinet6. Is changing this for VNET_* an open task?
I think that the most of them that are applicable to VNET were
already converted. It is better to ask at freebsd-...@freebsd.org.
Greate. It makes me understand the way a lot of things are written.
Avoid branching if you can.
I see that OPSET macro in netinet/ip_output.c lock the inp struct. Is
there a need of it there ?
Yes. I had overlooked the need of locking here, sorry.
I wrote a better patch that avoid locking and inp struct modification.
diff --git a/sys/netinet/in_pcb.c b/sys/netinet/in_pcb.c
index d742887..f41e4da 100644
--- a/sys/netinet/in_pcb.c
+++ b/sys/netinet/in_pcb.c
@@ -321,6 +321,9 @@ in_pcbbind(struct inpcb *inp, struct sockaddr
*nam, struct ucred *cred)
*
* On error, the values of *laddrp and *lportp are not changed.
*/
+VNET_DEFINE(int, inp_bindany) = 0;
+SYSCTL_VNET_INT(_net_inet_ip, OID_AUTO, bindany, CTLFLAG_RW,
+VNET_NAME(inp_bindany), 0, Force INP_BINDANY on all sockets);
int
in_pcbbind_setup(struct inpcb *inp, struct sockaddr *nam, in_addr_t *laddrp,
u_short *lportp, struct ucred *cred)
@@ -392,7 +395,8 @@ in_pcbbind_setup(struct inpcb *inp, struct
sockaddr *nam, in_addr_t *laddrp,
* If INP_BINDANY is set, then the socket may be bound
* to any endpoint address, local or not.
*/
- if ((inp-inp_flags INP_BINDANY) == 0
+ if (VNET(inp_bindany) == 0
+ (inp-inp_flags INP_BINDANY) == 0
ifa_ifwithaddr_check((struct sockaddr *)sin) == 0)
return (EADDRNOTAVAIL);
}
diff --git a/sys/netinet/in_pcb.h b/sys/netinet/in_pcb.h
index 4ba19e6..3720121 100644
--- a/sys/netinet/in_pcb.h
+++ b/sys/netinet/in_pcb.h
@@ -467,6 +467,7 @@ VNET_DECLARE(int, ipport_randomcps);
VNET_DECLARE(int, ipport_randomtime);
VNET_DECLARE(int, ipport_stoprandom);
VNET_DECLARE(int, ipport_tcpallocs);
+VNET_DECLARE(int, inp_bindany);
#defineV_ipport_reservedhigh VNET(ipport_reservedhigh)
#defineV_ipport_reservedlowVNET(ipport_reservedlow)
diff --git a/sys/netinet/raw_ip.c b/sys/netinet/raw_ip.c
index c91d4a9..17a2e78 100644
--- a/sys/netinet/raw_ip.c
+++ b/sys/netinet/raw_ip.c
@@ -897,6 +897,7 @@ rip_bind(struct socket *so, struct sockaddr *nam,
struct thread *td)
if (TAILQ_EMPTY(V_ifnet) ||
(addr-sin_family != AF_INET addr-sin_family != AF_IMPLINK) ||
(addr-sin_addr.s_addr
+ VNET(inp_bindany) == 0
(inp-inp_flags INP_BINDANY) == 0
ifa_ifwithaddr_check((struct sockaddr *)addr) == 0))
return (EADDRNOTAVAIL);
Do you mean there is a way to control user input (ie 0 or 42, but
nothing else)?
No, I meant that if you'll use the custom sysctl value handler (via
SYSCTL_VNET_PROC, not vie SYSCTL_VNET_INT), then you can convert any
non-zero value to INP_BINDANY and zero to zero. But given the need of
locking, I don't think that this won't be good to take this road: one
simple non-conditional logical instruction will be harmless even if it
is executed when it is not needed; but the block of
lock-logicalop-unlock will be worse.
--
Eygene Ryabinkin ,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
___
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
Fwd: binding non local ip.
-- Forwarded message --
From: joris dedieu joris.ded...@gmail.com
Date: 2011/1/9
Subject: Re: binding non local ip.
To: Julian Elischer jul...@freebsd.org
2011/1/7 Julian Elischer jul...@freebsd.org:
On 1/7/11 4:57 AM, joris dedieu wrote:
Hi,
I need a to bind non local ips daemons that don't
implement IP_BINDANY sockopt.
I'm not sure you need it
you can use the ipfw 'fwd' command to make a locally bound
socket act and look as if it is bound to a non local address
You need to tell us a little more about what you need to do
for example,
Is the socket just listenning? or is it initiating?
listenning I think.
Typicaly prepare a spare server.
eg:
- Failover as with carp but with more complexes actions has shutting
down the power of the main server, check data consistency, check if
the problem is not just a reboot or a buggy service that need to be
restarted.
- Switch an ip from a main server to a already configured proxy (during a dos)
- monitor that spare service is running.
There are several solutions as patching every single daemon
or using carp (You may not want automatic failover), jailing
the process and of course binding INADDR_ANY when possible ...
As I'm too lazy for this, I wrote a little (maybe ugly as my
kernel knowledges are really low) patch that add a sysctl
entry in net.inet.ip that allow binding non local ips. It's
maybe buggy and insecure but it seems to work.
seems ok, but if the daemon is initiating, how does it know to bind to a non
local address?
It doesn't know. That's the goal. So when the address became local
it's already ready. So you don't discover that it's misconfigured or
broken, or that else your dummy colleague has imagined :) . You or a
script ifconfig the alias and back to bed !
also. if you have source, a single setsockopt() in each one is not much of a
job..
I already do this for haproxy and for apr. But (for haproxy) it seems
to be too specific to be integrated upstreams. For other services (as
tomcat) that don't know privileges dropping it's more problematic as
IP_BINDANY needs in most case root privileges.
I think that a system wide solution should be a good thing.
Joris
What do you think about it ?
Thanks
Joris
--- a/sys/netinet/in_pcb.c
+++ b/sys/netinet/in_pcb.c
@@ -321,6 +321,9 @@ in_pcbbind(struct inpcb *inp, struct sockaddr
*nam, struct ucred *cred)
*
* On error, the values of *laddrp and *lportp are not changed.
*/
+static int bindany = 0; /* 1 allows to bind a non local ip */
+SYSCTL_INT(_net_inet_ip, OID_AUTO, bindany, CTLFLAG_RW,bindany, 0,
+ Allow to bind a non local ip);
int
in_pcbbind_setup(struct inpcb *inp, struct sockaddr *nam, in_addr_t
*laddrp,
u_short *lportp, struct ucred *cred)
@@ -393,8 +396,12 @@ in_pcbbind_setup(struct inpcb *inp, struct
sockaddr *nam, in_addr_t *laddrp,
* to any endpoint address, local or not.
*/
if ((inp-inp_flags INP_BINDANY) == 0
- ifa_ifwithaddr_check((struct sockaddr *)sin)
== 0)
- return (EADDRNOTAVAIL);
+ ifa_ifwithaddr_check((struct sockaddr *)sin)
== 0) {
+ if(bindany 0)
+ inp-inp_flags |= INP_BINDANY;
+ else
+ return (EADDRNOTAVAIL);
+ }
}
laddr = sin-sin_addr;
if (lport) {
___
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
___
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
