I experience a problem where vpnc can not exit cleanly and gets stuck.
pstree shows this chain:
|-+= 31375 root vpnc
| \-+- 13412 root /bin/sh /usr/local/sbin/vpnc-script-custom
| \--- 13446 root ifconfig tun0 destroy
$ procstat -k 13446
PIDTID COMM TDNAME KSTACK
On Jun 6, 2012, at 9:13 PM, Philip Prindeville wrote:
> On 6/6/12 11:54 AM, Michael Tuexen wrote:
>> On Jun 6, 2012, at 7:17 PM, Adrian Chadd wrote:
>>
>>> Hi,
>>>
>>> For TCP, I've seen the network layer change things (eg setting bits on
>>> incoming traffic to mark which interface it came in o
On Jun 7, 2012, at 12:18 AM, Adrian Chadd wrote:
> *nod* sure, I just want to be sure that it's clearly documented what
> the option does.
>
> If it just does UDP for now and not TCP, then so be it, as long as
> it's documented that way.
I think the suggested modification to the man page of IP,
On 7 June 2012 19:08, Andriy Gapon wrote:
>
> I experience a problem where vpnc can not exit cleanly and gets stuck.
> pstree shows this chain:
> |-+= 31375 root vpnc
> | \-+- 13412 root /bin/sh /usr/local/sbin/vpnc-script-custom
> | \--- 13446 root ifconfig tun0 destroy
>
> $ procstat -k 134
on 07/06/2012 10:08 Andriy Gapon said the following:
>
> I experience a problem where vpnc can not exit cleanly and gets stuck.
> pstree shows this chain:
> |-+= 31375 root vpnc
> | \-+- 13412 root /bin/sh /usr/local/sbin/vpnc-script-custom
> | \--- 13446 root ifconfig tun0 destroy
>
> $ pro
on 07/06/2012 10:30 Andrew Thompson said the following:
> On 7 June 2012 19:08, Andriy Gapon wrote:
>>
>> I experience a problem where vpnc can not exit cleanly and gets stuck.
>> pstree shows this chain:
>> |-+= 31375 root vpnc
>> | \-+- 13412 root /bin/sh /usr/local/sbin/vpnc-script-custom
>>
Hello,
I've been pointed out by our partner that we are sending TCP packets with FIN
flag and no ACK set, which is triggering
alerts on their firewalls.
I've investigated, and it appears that some of our FreeBSD hosts are really
sending such packets. (they are running some java applications)
I d
Hello list!
Since the early days ifconfig(8) has the following functionality:
..
address
For the DARPA-Internet family, the address is either a
host name
present in the host name data base, hosts(5), or a DARPA
Internet
address expressed in the Inte
It might be nice to add a semantic that says, "when accepting connections,
match their TOS"... possibly adding ranges of permitted TOS values.
On 6/6/12 4:18 PM, Adrian Chadd wrote:
> *nod* sure, I just want to be sure that it's clearly documented what
> the option does.
>
> If it just does UDP
On Jun 7, 2012, at 8:24 PM, Philip Prindeville wrote:
> It might be nice to add a semantic that says, "when accepting connections,
> match their TOS"... possibly adding ranges of permitted TOS values.
... I would leave the matching to the application.
However, the suggested patch only supports UD
On Mar 27, 2012, at 18:13 , Navdeep Parhar wrote:
> When the kernel decides to respond with a RST to an incoming TCP
> segment, it uses its ack# (if valid) as the seq# of the RST. See this
> in tcp_dropwithreset:
>
> if (th->th_flags & TH_ACK) {
> tcp_respond(tp, mtod(m, voi
On 7 June 2012 05:41, Nikolay Denev wrote:
> Hello,
>
> I've been pointed out by our partner that we are sending TCP packets with FIN
> flag and no ACK set, which is triggering
> alerts on their firewalls.
> I've investigated, and it appears that some of our FreeBSD hosts are really
> sending su
Old Synopsis: Multiple em(4) not working with qemu
New Synopsis: [em] Multiple em(4) not working with qemu
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Fri Jun 8 04:59:39 UTC 2012
Responsible-Changed-Why:
Over to maintainer(s).
Old Synopsis: [regression] Unable to manually remove permanent ARP entries
New Synopsis: [arp] [regression] Unable to manually remove permanent ARP entries
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Fri Jun 8 04:59:01 UTC 2012
R
Old Synopsis: [regression] Permanent ARP entry not deleted on interface
configuration failure
New Synopsis: [arp] [regression] Permanent ARP entry not deleted on interface
configuration failure
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Cha
Hello, networkers!
[net@ in Cc, but further discussion should go on pf@]
As you already probably know, or some may be don't yet know, the pf(4)
subsystem in FreeBSD is currently working under a single mutex. This mutex
is acquired right at the beginning of any packet processing, and is drop
Hi
I will be 'experimenting' with 10g in the next few months, so
I need to buy some cards,
After googling for some time, I noticed that there is not realy much real
info, and some of it is a bit dated.
Since these cards are pricy, could those that have such cards share some info?
cheers,
17 matches
Mail list logo
