Re: NATT patch and FreeBSD's setkey

[VANHULLEBUS Yvan]

On Tue, Apr 14, 2009 at 04:24:44PM -0400, Scott Ullrich wrote:
> On Thu, Feb 26, 2009 at 10:11 AM, VANHULLEBUS Yvan  wrote:
> > On Tue, Feb 17, 2009 at 02:41:41PM +, Bjoern A. Zeeb wrote:
> [snip]
> >> We have about 3 months left to get that patch in for 8; ideally 6
> >> weeks.  Can you update the nat-t patch in a way as discussed here
> >> before so that the extra address is in etc. and we can move forward?
> >
> > Done, new version is available here:
> > http://people.freebsd.org/~vanhu/NAT-T/experimental/patch-FreeBSD-TRUNK-NATT-pfkey-clean-2009-02-26.diff
> 
> Hello,

Hi.


> We recently tested this patch on a up to date current as of a couple
> hours ago and it seems to break all outgoing UDP traffic (DNS
> included).

There's a conflict between INP_ESPINUDP* and other INP_* commited
since 2009-02-26.


> Has anyone else experienced this issue?  Backing the patch out of our
> pfSense patch roster cleared up the problem.
> 
> Is there a newer patch available by chance?

Actually, not, because there are no bits left in inp_flags, so we are
actually looking for another location to put them.


Yvan.
___
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"

Re: kern/133572: [ppp] [hang] incoming PPTP connection hangs the system

[Dennis Melentyev]

The following reply was made to PR kern/133572; it has been noted by GNATS.

From: Dennis Melentyev 
To: Max Laier 
Cc: bug-follo...@freebsd.org
Subject: Re: kern/133572: [ppp] [hang] incoming PPTP connection hangs the 
system
Date: Wed, 15 Apr 2009 13:27:41 +0300

 Hi Max,
 
 It was some hard time for me, sorry for late response.
 
 I did enabled KDB, DDB and WITNESS on the same sources.
 Unfortunately there was just plain hangs once some GRE was trying to
 get through (netgraph? PF? routing?)
 With these options enabled, hangs are much more often than without them.
 Once hung, no way to break into debugger, no panics, numlock not
 changing lights on keyboard, mouse not responding, hdd silent, network
 not available, nothing.
 
 3 different HW platforms were tried (all of them were UP+i386+32bit).
 Highest CPU temperature was 52C. No chance to go with 7.2-PRERELEASE.
 
 Had to downgrade to 7.1-RELEASE.
 
 /dennis
 
 2009/4/11 Max Laier :
 > Is it possible for you to turn on WITNESS on this machine to obtain possi=
 ble
 > LORs that might be responsible for the hang? =C2=A0Also, do you have the
 > possibility to enable DDB and drop into it from the console (if it is not=
  a
 > hard hang but a live lock)?
 >
 > --
 > =C2=A0Max
 >
 
 
 
 --=20
 Dennis Melentyev
___
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"

OpenSSL DTLS bug fix patches

[Bruce Simpson]

I know it's late in the 7.2 game, but does our OpenSSL maintainer know 
about this?


   http://sctp.fh-muenster.de/dtls-patches.html

It would be nice to have in a release, although I'm tracking branches 
for anything I'm doing at the moment.


JFYI,
BMS
___
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"

Re: kern/131153: [iwi] iwi doesn't see a wireless network

[Adam K Kirchhoff]

The following reply was made to PR kern/131153; it has been noted by GNATS.

From: Adam K Kirchhoff 
To: bug-follo...@freebsd.org, ad...@voicenet.com
Cc:  
Subject: Re: kern/131153: [iwi] iwi doesn't see a wireless network
Date: Wed, 15 Apr 2009 07:18:15 -0400

 This problem persists with 7.2-PRERELEASE, with both iwi and ath.  Any ideas?
 
 Adam
___
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"

MD5 authentication in quagga

[Алексей Блинков]

Hi. I have a problem with Subj. In mailing list quagga me say for
mailing to frebsd list.

Quote:

It is well documented that md5 'password' authentication for bgpd works,
but only for outgoing packets... there is no way for FreeBSD (to my
knowledge) to actually verify packets inbound.

...it's better than nothing ;)


First one. My configuration in FreeBSD 7.1

/etc/rc.conf

ipsec_enable="YES"
ipsec_file="/etc/ipsec.conf"

/etc/ipsec.conf

flush;
add x.x.x.x y.y.y.y tcp 0x1000 -A tcp-md5 "*";

where:

x.x.x.x - IP local side
y.y.y.y - IP remote side
 - password

Next. My kernel was rebuilded with next options:

options TCP_SIGNATURE
options IPSEC
device crypto
device cryptodev
device cryptodev

Now i set password to bgp neighbor

quagga-router(config router)# neighbor y.y.y.y password 

And clear session

quagga-router(config router)# do clear ip bgp y.y.y.y

In remote side PASSWORD NOT SET YET, but bgp session passes to state
UP, and network prefixes sending from local to remote side and vice
versa.

But neigborship must no upping if password not coincide...

-- 
С уважением Алексей Блинков
___
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"

Re: kern/133490: [bpf] [panic] 'kmem_map too small' panic on Dell r900 when bpf_bufsize and bpf_maxbufsize are increased

[plethora87]

The following reply was made to PR kern/133490; it has been noted by GNATS.

From: plethor...@aim.com
To: bug-follo...@freebsd.org
Cc:  
Subject: Re: kern/133490: [bpf] [panic] 'kmem_map too small' panic on Dell r900 
when
 bpf_bufsize and bpf_maxbufsize are increased
Date: Wed, 15 Apr 2009 10:00:04 -0400

 If I set the net.bpf buffers after boot-up, there's no immediate crash. 
  But I just had a crash after a couple days of uptime:
 
 Dump header from device /dev/mfid0s1b
   Architecture: i386
   Architecture Version: 2
   Dump Length: 456548352B (435 MB)
   Blocksize: 512
   Dumptime: Wed Apr 15 09:04:06 2009
   Hostname: schnozz-nap-b
   Magic: FreeBSD Kernel Dump
   Version String: FreeBSD 7.1-RELEASE #3: Wed Apr  1 11:04:28 EDT 2009
 r...@schnozz-nap-a:/usr/obj/usr/src/sys/CCSP-KERNEL
Panic String: kmem_malloc(16777216): kmem_map too small: 326787072 
 total allocated
   Dump Parity: 366409564
   Bounds: 7
   Dump Status: good
 
 I can upload the core file somewhere if it would be helpful.
 
 -Terry
 
 
___
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"

Re: MD5 authentication in quagga

[Bjoern A. Zeeb]

On Wed, 15 Apr 2009,   wrote:


Hi. I have a problem with Subj. In mailing list quagga me say for
mailing to frebsd list.

Quote:

It is well documented that md5 'password' authentication for bgpd works,
but only for outgoing packets... there is no way for FreeBSD (to my
knowledge) to actually verify packets inbound.

...it's better than nothing ;)


First one. My configuration in FreeBSD 7.1

/etc/rc.conf

ipsec_enable="YES"
ipsec_file="/etc/ipsec.conf"

/etc/ipsec.conf

flush;
add x.x.x.x y.y.y.y tcp 0x1000 -A tcp-md5 "*";

where:

x.x.x.x - IP local side
y.y.y.y - IP remote side
 - password

Next. My kernel was rebuilded with next options:

options TCP_SIGNATURE
options IPSEC
device crypto
device cryptodev
device cryptodev

Now i set password to bgp neighbor

quagga-router(config router)# neighbor y.y.y.y password 

And clear session

quagga-router(config router)# do clear ip bgp y.y.y.y

In remote side PASSWORD NOT SET YET, but bgp session passes to state
UP, and network prefixes sending from local to remote side and vice
versa.

But neigborship must no upping if password not coincide...


And what's the peer? If it's another FreeBSD box uon't check incoming
packets either and thus it won't make a difference to when it's not
there.

/bz

--
Bjoern A. Zeeb  The greatest risk is not taking one.
___
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"

Re: MD5 authentication in quagga

[Алексей Блинков]

If modelling ideal situation, then:

md5 password doesn`t match or empty, then peering must be closed...

Now md5 working only for outgoing packets, not for input. And peering
not closed if password miss or not match. because bsd not check
incoming packets, i think...
___
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"

tcp_output() might generate invalid TSO frames

[Renaud Lienhart]

Hi,

We're having trouble virtualizing FreeBSD 7+ on ESX because of an issue
with the stack's TSO implementation: it sometimes generates TSO packets
whose payload size is actually smaller than the MSS.

The faulty logic is described, along with a patch, in PR #132832. It
has been opened for a while now, without any apparent activity, which
is why I'm reaching the mailing list directly.

ESX currently drops these packets as many physical nics are known to
choke on such frames, which effectively limits FreeBSD guests'
performance.
I don't know about other virtualization stacks' behavior.

http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/132832

Thanks for your time,

Renaud
___
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"

Re: NATT patch and FreeBSD's setkey

[Scott Ullrich]

On Wed, Apr 15, 2009 at 3:12 AM, VANHULLEBUS Yvan  wrote:
> Actually, not, because there are no bits left in inp_flags, so we are
> actually looking for another location to put them.

Sounds good and thanks for the information.   We will be happy to test
the next patch when it's ready.

Thanks for maintaing the patch so far,

Scott
___
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"

Netgraph. panic in kernel

[Alexey Lukashin]

Hi all,

I'm studying how Netgraph system works and trying to write my own 
netgraph node similar to ng_bridge.
It catches packets from lower ng_ether hooks and transmits it to other 
interfaces using mac address hashtable.


Packet processing in my node implemented similar to ng_bridge_rcvdata() 
in ng_bridge.c.
I don't do anything with packet. I don't modifying packet header, I only 
send it to another interface.


My interfaces are working in promiscuous mode with autosrc=0.

But sometimes (after one or two hours working in network) I have an 
error with message:


"rl1: discard frame w/o packet header"

After it, my system halts.

Is anybody knows, where the problem can be? When does this message appears?

(system is FreeBSD 7.1-STABLE)

Thank you.

--
Best regards,
   Alexey Lukashin
Saint-Petersburg, Russia
___
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"

Re: tcp_output() might generate invalid TSO frames

[Kip Macy]

Interesting. That might explain a problem that Mike Silbersack is
seeing with the latest em driver on vmware.

I don't know of any NICs that actually choke on such frames.
Nonetheless, it is silly behavior. I'll try to see if we can get this
fixed before 7.2.

Thanks,
Kip

On Wed, Apr 15, 2009 at 8:40 AM, Renaud Lienhart  wrote:
> Hi,
>
> We're having trouble virtualizing FreeBSD 7+ on ESX because of an issue
> with the stack's TSO implementation: it sometimes generates TSO packets
> whose payload size is actually smaller than the MSS.
>
> The faulty logic is described, along with a patch, in PR #132832. It
> has been opened for a while now, without any apparent activity, which
> is why I'm reaching the mailing list directly.
>
> ESX currently drops these packets as many physical nics are known to
> choke on such frames, which effectively limits FreeBSD guests'
> performance.
> I don't know about other virtualization stacks' behavior.
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/132832
>
> Thanks for your time,
>
>        Renaud
> ___
> 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"
>



-- 
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke
___
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"

Re: OpenSSL DTLS bug fix patches

[Michael Tüxen]

Hi Bruce,

at least one member of the OpenSSL core team (Steven) has integrated
our patches regarding bug fixes in the source code.
So they will be included in the next release of OpenSSL.

Best regards
Michael

On Apr 15, 2009, at 2:36 PM, Bruce Simpson wrote:

I know it's late in the 7.2 game, but does our OpenSSL maintainer  
know about this?


  http://sctp.fh-muenster.de/dtls-patches.html

It would be nice to have in a release, although I'm tracking  
branches for anything I'm doing at the moment.


JFYI,
BMS
___
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"



___
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"

Re: tcp_output() might generate invalid TSO frames

[Jack Vogel]

No, the problem Mike is having is due to an issue in our new shared code
in how we get the mac address, we changed it to support alt mac addresses,
and it works find on our hardware, there is an issue in the vmware
emulation.

Nevertheless, if there's a problem in the TSO code it would be nice to get
that fixed.

Jack


On Wed, Apr 15, 2009 at 11:06 AM, Kip Macy  wrote:

> Interesting. That might explain a problem that Mike Silbersack is
> seeing with the latest em driver on vmware.
>
> I don't know of any NICs that actually choke on such frames.
> Nonetheless, it is silly behavior. I'll try to see if we can get this
> fixed before 7.2.
>
> Thanks,
> Kip
>
> On Wed, Apr 15, 2009 at 8:40 AM, Renaud Lienhart 
> wrote:
> > Hi,
> >
> > We're having trouble virtualizing FreeBSD 7+ on ESX because of an issue
> > with the stack's TSO implementation: it sometimes generates TSO packets
> > whose payload size is actually smaller than the MSS.
> >
> > The faulty logic is described, along with a patch, in PR #132832. It
> > has been opened for a while now, without any apparent activity, which
> > is why I'm reaching the mailing list directly.
> >
> > ESX currently drops these packets as many physical nics are known to
> > choke on such frames, which effectively limits FreeBSD guests'
> > performance.
> > I don't know about other virtualization stacks' behavior.
> >
> > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/132832
> >
> > Thanks for your time,
> >
> >Renaud
> > ___
> > 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"
> >
>
>
>
> --
> All that is necessary for the triumph of evil is that good men do nothing.
>Edmund Burke
> ___
> 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"
>
___
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"

Re: MD5 authentication in quagga

[Bruce Simpson]

Алексей Блинков wrote:

If modelling ideal situation, then:

md5 password doesn`t match or empty, then peering must be closed...

Now md5 working only for outgoing packets, not for input. And peering
not closed if password miss or not match. because bsd not check
incoming packets, i think...
  


I thought someone had fixed this ages ago?
I seem to remember someone had merged some changes to what I'd 
originally done for Sentex from NetBSD... but I could be wrong.


cheers,
BMS
___
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"

Re: OpenSSL DTLS bug fix patches

[Bruce Simpson]

Michael Tüxen wrote:

Hi Bruce,

at least one member of the OpenSSL core team (Steven) has integrated
our patches regarding bug fixes in the source code.
So they will be included in the next release of OpenSSL.



That's excellent news, and these fixes look good, but I was more 
wondering if this drop would be in FreeBSD 7.2-RELEASE :-)

If not no biggie, I am tracking -STABLE for work.

thanks,
BMS
___
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"

A Quick Question

[Narek Gharibyan]

Hello Sir/Mdm

 

I would like to know is there any solution to problem show below, because we
use FreeBSD 7.0 in our network structure and we are meeting face to face to
this problem everyday  

 

 

kern/121555: [panic] Fatal trap 12: current process = 12 (swi1: net)


From:

Alexey Sopov 


Date:

Mon, 10 Mar 2008 11:46:51 GMT


Subject:

[7.0-RELEASE] Fatal trap 12: current process = 12 (swi1: net)


Send-pr version:

www-3.1

 


Number:

121555


Category:

kern


Synopsis:

[panic] Fatal trap 12: current process = 12 (swi1: net)


Severity:

serious


Priority:

high


Responsible:

freebsd-net@FreeBSD.org


State:

open


Class:

sw-bug


Arrival-Date:

Mon Mar 10 12:00:01 UTC 2008


Closed-Date:

 


Last-Modified:

Fri May 23 20:48:21 UTC 2008


Originator:

Alexey Sopov


Release:

7.0-RELEASE

 

 

 

Best Regards,

Narek Gharibyan

 

Network Administration Team leader

Synergy International Systems Inc. / Armenia

  http://www.synisys.com

 

Tel.:

mobile: +37494 - 353489

work:+37410 - 650202 ext 772

 

___
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"