Hi.
On 13.03.2013 07:57, YongHyeon PYUN wrote:
>
> If your controller supports ASF/IPMI access please apply r248226
> to stable/8 and let me know whether that makes any difference.
> I believe ignoring ASF/IPMI firmware is not good idea since the
> ASF/IPMI firmware will run regardless of hw.bge.a
On Wed, Mar 13, 2013 at 3:35 PM, Chuck Swiger wrote:
> Hi--
>
> On Mar 13, 2013, at 8:21 AM, Matt Miller wrote:
>> If we have a connection that has received a SYN and ip_output()
>> returns, say, EHOSTUNREACH, is there anything that guarantees the
>> connection would always eventually be dropped i
Garrett Wollman wrote:
> < said:
>
> > Basically, this patch:
> > - allows setting of the tcp timeout via vfs.nfsd.tcpcachetimeo
> > (I'd suggest you go down to a few minutes instead of 12hrs)
> > - allows TCP caching to be disabled by setting vfs.nfsd.cachetcp=0
> > - does the above 2 things y
Hi--
On Mar 13, 2013, at 8:21 AM, Matt Miller wrote:
> If we have a connection that has received a SYN and ip_output()
> returns, say, EHOSTUNREACH, is there anything that guarantees the
> connection would always eventually be dropped if the condition
> persists?
If the local TCP stack is unable
On 2013/03/13 18:12, Mark Martinec wrote:
> Schrodinger wrote:
> > What I am confused about is that without ACCEPT_RTADV on re0, FreeBSD
> > doesn't perform Neighbour Solicitation for the default gateway but with
> > ACCEPT_RTADV it does . Why ? This is Neighbour Solicitation and not
> > Router
Schrodinger wrote:
> What I am confused about is that without ACCEPT_RTADV on re0, FreeBSD
> doesn't perform Neighbour Solicitation for the default gateway but with
> ACCEPT_RTADV it does . Why ? This is Neighbour Solicitation and not
> Router Solicitation
>
> I understand that FreeBSD doe
On 2013/03/13 17:27, Mark Martinec wrote:
> > > I am informed that I must configure my interface to /64 by OVH. The same
> > > as everyone else. So if everyone was on a /64 then we will send packets
> > > to each other via our shared default gateway.
>
> Btw, if the router responds to your subnet'
On 2013/03/13 16:29, Joe Holden wrote:
> Strange, I used this setup on an OVH machine a while ago, seemed to work
> - perhaps something isn't properly configured at their end properly
>
I have a ticket opened with OVH since yesterday to confirm or deny the
future of RA on their network.
Thankfu
Strange, I used this setup on an OVH machine a while ago, seemed to work
- perhaps something isn't properly configured at their end properly
Schrodinger wrote:
On 2013/03/13 15:52, Joe Holden wrote:
Just use router solicitation to ask for the link-local gateway, that is
the "correct" way to do
> > I am informed that I must configure my interface to /64 by OVH. The same
> > as everyone else. So if everyone was on a /64 then we will send packets
> > to each other via our shared default gateway.
Btw, if the router responds to your subnet's (/64) anycast address
(RFC 4291 section 2.6.1 Requ
On 2013/03/13 16:59, Mark Martinec wrote:
Hi Mark,
[...]
>
> > Does adding the interface route not put the default gateway on-link
> > though ?
>
> I don't think it does. The on-link state of an address comes
> from matching the address to a set of prefixes on an interface,
> or finding it in
On Wednesday March 13 2013 Schrodinger wrote:
> This isn't my network so I don't have any input into the matter. This
> is the OVH configuration for their dedicated servers, at least in my
> product range.
>
> > [1] http://help.ovh.com/Ipv4Ipv6#link10
> I read this, I made sure to read this and th
On 2013/03/13 15:52, Joe Holden wrote:
> Just use router solicitation to ask for the link-local gateway, that is
> the "correct" way to do it.
>
Hi Joe,
If you read some of this thread you'll note that router advertisements
are being disabled by the hosting provider. While their documentation
i
Just use router solicitation to ask for the link-local gateway, that is
the "correct" way to do it.
Schrodinger wrote:
Damien,
I appreciate your replies very much, but I'm a subscriber so just reply
to the mailing list. Thanks.
On 2013/03/13 14:19, Fleuriot Damien wrote:
[SNARF]
These ar
I managed to run your patch on production machine and it produced panic in a
few seconds after network traffic was directed through it.
The difference I spotted is that you insert the State entry to state_list near
the end of pf_create_state:
@@ -3950,8 +3970,18 @@ pf_create_state(struct pf_rul
If we have a connection that has received a SYN and ip_output()
returns, say, EHOSTUNREACH, is there anything that guarantees the
connection would always eventually be dropped if the condition
persists?
E.g., similar to this case for ENOBUFS:
http://svnweb.freebsd.org/base?view=revision&revision=
On 2013/03/13 14:38, Fleuriot Damien wrote:
>
> On Mar 12, 2013, at 11:44 PM, Damien Fleuriot wrote:
>
> >
> > On 12 Mar 2013, at 22:42, "M. Schulte" wrote:
> >
> >> Hi!
> >>
> >> [First of all, I have posted this question already on the FreeBSD
> >> forum -- so far without replies -- and n
Damien,
I appreciate your replies very much, but I'm a subscriber so just reply
to the mailing list. Thanks.
On 2013/03/13 14:19, Fleuriot Damien wrote:
[SNARF]
>
>
> These are indeed correct, thanks for clarifying.
>
I thought that's what I said in my first email ;) Sorry for any
confusio
On Mar 12, 2013, at 11:44 PM, Damien Fleuriot wrote:
>
> On 12 Mar 2013, at 22:42, "M. Schulte" wrote:
>
>> Hi!
>>
>> [First of all, I have posted this question already on the FreeBSD
>> forum -- so far without replies -- and now my hope is that the set of
>> subscribers here and those of th
On Mar 13, 2013, at 2:10 PM, Schrodinger wrote:
> On 2013/03/13 14:02, Fleuriot Damien wrote:
>>
>> On Mar 13, 2013, at 1:52 PM, Schrodinger wrote:
>>
>>> On 2013/03/13 12:27, Mark Martinec wrote:
>>>
>>> Hi Mark,
>>>
On Wednesday March 13 2013 10:17:27 Schrodinger wrote:
> ifconfi
On 2013/03/13 14:02, Fleuriot Damien wrote:
>
> On Mar 13, 2013, at 1:52 PM, Schrodinger wrote:
>
> > On 2013/03/13 12:27, Mark Martinec wrote:
> >
> > Hi Mark,
> >
> >> On Wednesday March 13 2013 10:17:27 Schrodinger wrote:
> >>> ifconfig_re0_ipv6="inet6 2001:41D0:2:E7c4::1 prefixlen 64"
> >>
On Mar 13, 2013, at 1:52 PM, Schrodinger wrote:
> On 2013/03/13 12:27, Mark Martinec wrote:
>
> Hi Mark,
>
>> On Wednesday March 13 2013 10:17:27 Schrodinger wrote:
>>> ifconfig_re0_ipv6="inet6 2001:41D0:2:E7c4::1 prefixlen 64"
>>> [...]
>>> Voodoo, indeed... I'm sure there's a /48 used somewh
On 2013/03/13 12:27, Mark Martinec wrote:
Hi Mark,
> On Wednesday March 13 2013 10:17:27 Schrodinger wrote:
> > ifconfig_re0_ipv6="inet6 2001:41D0:2:E7c4::1 prefixlen 64"
> > [...]
> > Voodoo, indeed... I'm sure there's a /48 used somewhere but to be more
> > specific, or rather obvious, my defau
On Wednesday March 13 2013 10:17:27 Schrodinger wrote:
> ifconfig_re0_ipv6="inet6 2001:41D0:2:E7c4::1 prefixlen 64"
> [...]
> Voodoo, indeed... I'm sure there's a /48 used somewhere but to be more
> specific, or rather obvious, my default gateway resides at the boundary
> of a /56 - 2001:41D0:2:E70
On 13 Mar 2013, at 10:17, Schrodinger wrote:
> On 2013/03/13 02:25, Damien Fleuriot wrote:
>
> [...]
>
>>
>>
>> The network is actually /48 and you get assigned a /64 inside it.
>>
>> Set your interface to use the /48 prefix and voodoo will happen (I can
>> assure you with a 97% certainty
On 2013/03/13 02:25, Damien Fleuriot wrote:
[...]
>
>
> The network is actually /48 and you get assigned a /64 inside it.
>
> Set your interface to use the /48 prefix and voodoo will happen (I can assure
> you with a 97% certainty that your default GW is inside the /48).
> Of course, using th
On Wed, Mar 13, 2013 at 12:02 AM, rathish mudaliar wrote:
> Hi,
>
> I request you to kindly add me to your mailing list.
http://lists.freebsd.org/mailman/listinfo/freebsd-net
This is where you can go and subscribe.
cheers,
Hiren
>
>
> Regards
> Rathish.R
> _
Hi,
I request you to kindly add me to your mailing list.
Regards
Rathish.R
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
28 matches
Mail list logo
