Re: OpenSSL DTLS bug fix patches

[Michael Tüxen]

On Apr 16, 2009, at 2:19 AM, Bruce Simpson wrote:


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 :-)

I know, but I wanted to make the state of the patches clear to make
the decision for the port maintainer easier.

Are you using DTLS?


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"

Re: A Quick Question

[Kip Macy]

Please see the handbook for providing debugging information. This is a
very generic panic.

-Kip

2009/4/15 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"
>



-- 
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: MD5 authentication in quagga

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

16 апреля 2009 г. 3:16 пользователь 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
>

I don`t know about how kernel works with md5 hashing, because i`m
newly in bsd...



-- 
С уважением Алексей Блинков
___
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/132832: [netinet] [patch] tcp_output() might generate invalid TSO frames when len > TCP_MAXWIN - hdrlen - optlen

[gavin]

Synopsis: [netinet] [patch] tcp_output() might generate invalid TSO frames when 
len > TCP_MAXWIN - hdrlen - optlen

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: gavin
Responsible-Changed-When: Thu Apr 16 08:19:28 UTC 2009
Responsible-Changed-Why: 
Over to maintainer(s).  This may be the cause of some of the other
TSO issues that have been spotted recently.

http://www.freebsd.org/cgi/query-pr.cgi?pr=132832
___
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: Thu, 16 Apr 2009 12:28:46 +0300

 Hi Max,
 
 Just read your discussion with Matt and Rembrandt on DragonflyBSD list
 on OpenBSD's PF issues.
 
 Although I can't afford to restore the configuration to test the
 issue, but I feel, that problem could be connected to IPv6 +
 PPTP/GRE/PF/IPv4.
 The machine we've tried to connect from was running Vista. AFAIR, it
 tries to make some use of IPv6. Can't tell anything on XP or other
 clients - never tried that.
 OTOH, outgoing PPTP (IPv4) session from MPD4 to some HW VPN router
 (sorry, anonymous to me) was just fine.
 
 Hope this helps.
 
 I can't upgrade ATM, but still can supply config files if needed.
 
 /dennis
 
 2009/4/15 Dennis Melentyev :
 > 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 poss=
 ible
 >> 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 no=
 t a
 >> hard hang but a live lock)?
 >>
 >> --
 >> =C2=A0Max
 >>
 >
 >
 >
 > --
 > Dennis Melentyev
 >
 
 
 
 --=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"

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: Thu, 16 Apr 2009 06:37:18 -0400

 FYI, I'm showing the debug output of wpa_supplicant from connecting to
 my home network with the same WPA settings that we have at work.  WPA
 with the same preshared key.
 
 Initializing interface 'iwi0' conf '/etc/wpa_supplicant.conf' driver 'bsd' 
ctrl_interface 'N/A' bridge 'N/A'
 Configuration file '/etc/wpa_supplicant.conf' -> '/etc/wpa_supplicant.conf'
 Reading configuration file '/etc/wpa_supplicant.conf'
 Line: 2 - start of a new network block
 scan_ssid=1 (0x1)
 ssid - hexdump_ascii(len=5):
  61 73 68 6b 65ashke   
 key_mgmt: 0x2
 pairwise: 0x8
 PSK (ASCII passphrase) - hexdump_ascii(len=10): [REMOVED]
 PSK (from passphrase) - hexdump(len=32): [REMOVED]
 Line 8: removed CCMP from group cipher list since it was not allowed for 
pairwise cipher
 Line: 10 - start of a new network block
 scan_ssid=1 (0x1)
 ssid - hexdump_ascii(len=15):
  4d 63 6b 65 6c 6c 61 32 38 30 46 72 6f 6e 74  Mckella280Front 
 key_mgmt: 0x2
 pairwise: 0x8
 PSK (ASCII passphrase) - hexdump_ascii(len=10): [REMOVED]
 PSK (from passphrase) - hexdump(len=32): [REMOVED]
 Line 16: removed CCMP from group cipher list since it was not allowed for 
pairwise cipher
 Priority group 0
id=0 ssid='ashke'
id=1 ssid='Mckella280Front'
 Initializing interface (2) 'iwi0'
 EAPOL: SUPP_PAE entering state DISCONNECTED
 EAPOL: KEY_RX entering state NO_KEY_RECEIVE
 EAPOL: SUPP_BE entering state INITIALIZE
 EAP: EAP entering state DISABLED
 EAPOL: External notification - portEnabled=0
 EAPOL: External notification - portValid=0
 Own MAC address: 00:13:ce:a8:10:ea
 wpa_driver_bsd_set_wpa: enabled=1
 wpa_driver_bsd_set_wpa_internal: wpa=3 privacy=1
 wpa_driver_bsd_del_key: keyidx=0
 wpa_driver_bsd_del_key: keyidx=1
 wpa_driver_bsd_del_key: keyidx=2
 wpa_driver_bsd_del_key: keyidx=3
 wpa_driver_bsd_set_countermeasures: enabled=0
 wpa_driver_bsd_set_drop_unencrypted: enabled=1
 Setting scan request: 0 sec 10 usec
 Added interface iwi0
 State: DISCONNECTED -> SCANNING
 Starting AP scan (specific SSID)
 Scan SSID - hexdump_ascii(len=5):
  61 73 68 6b 65ashke   
 Trying to get current scan results first without requesting a new scan to 
speed up initial association
 Received 0 bytes of scan results (6 BSSes)
 Scan results: 6
 Selecting BSS from priority group 0
 Try to find WPA-enabled AP
 0: 00:30:bd:fb:ca:31 ssid='ashke' wpa_ie_len=24 rsn_ie_len=0 caps=0x11
selected based on WPA IE
selected WPA AP 00:30:bd:fb:ca:31 ssid='ashke'
 Try to find non-WPA AP
 Trying to associate with 00:30:bd:fb:ca:31 (SSID='ashke' freq=2422 MHz)
 Cancelling scan request
 WPA: clearing own WPA/RSN IE
 Automatic auth_alg selection: 0x1
 wpa_driver_bsd_set_auth_alg alg 0x1 authmode 1
 WPA: using IEEE 802.11i/D3.0
 WPA: Selected cipher suites: group 8 pairwise 8 key_mgmt 2 proto 1
 WPA: set AP WPA IE - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 f2 02 01 
00 00 50 f2 02 01 00 00 50 f2 02
 WPA: clearing AP RSN IE
 WPA: using GTK TKIP
 WPA: using PTK TKIP
 WPA: using KEY_MGMT WPA-PSK
 WPA: Set own WPA IE default - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 
f2 02 01 00 00 50 f2 02 01 00 00 50 f2 02
 No keys have been configured - skip key clearing
 wpa_driver_bsd_set_drop_unencrypted: enabled=1
 State: SCANNING -> ASSOCIATING
 wpa_driver_bsd_associate: ssid 'ashke' wpa ie len 24 pairwise 2 group 2 key 
mgmt 1
 wpa_driver_bsd_associate: set PRIVACY 1
 Setting authentication timeout: 10 sec 0 usec
 EAPOL: External notification - EAP success=0
 EAPOL: External notification - EAP fail=0
 EAPOL: External notification - portControl=Auto
 Authentication with 00:30:bd:fb:ca:31 timed out.
 Added BSSID 00:30:bd:fb:ca:31 into blacklist
 No keys have been configured - skip key clearing
 State: ASSOCIATING -> DISCONNECTED
 EAPOL: External notification - portEnabled=0
 EAPOL: External notification - portValid=0
 EAPOL: External notification - EAP success=0
 Setting scan request: 0 sec 0 usec
 State: DISCONNECTED -> SCANNING
 Starting AP scan (specific SSID)
 Scan SSID - hexdump_ascii(len=15):
  4d 63 6b 65 6c 6c 61 32 38 30 46 72 6f 6e 74  Mckella280Front 
 Received 0 bytes of scan results (6 BSSes)
 Scan results: 6
 Selecting BSS from priority group 0
 Try to find WPA-enabled AP
 0: 00:30:bd:fb:ca:31 ssid='ashke' wpa_ie_len=24 rsn_ie_len=0 
caps=0ioctl[SIOCS80211, op 21, len 42]: Invalid argument
 x11
selected based on WPA IE
selected WPA AP 00:30:bd:fb:ca:31 ssid='ashke'
 Try to find non-WPA AP
 Trying to associate with 00:30:bd:fb:ca:31 (SSID='ashke' freq=2422 MHz)
 Cancelling scan request
 WPA: clearing own WPA/RSN IE
 Automatic auth_alg selection: 0x1
 wpa_driver_bsd_set_auth_alg alg 0x1 auth

Re: OpenSSL DTLS bug fix patches

[Bruce Simpson]

Michael Tüxen wrote:

On Apr 16, 2009, at 2:19 AM, Bruce Simpson wrote:
...


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

I know, but I wanted to make the state of the patches clear to make
the decision for the port maintainer easier.

Are you using DTLS? 


Not yet, but I came across these patches whilst researching TLS 
adaptation for SCTP.


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

[Michael Tüxen]

On Apr 16, 2009, at 12:39 PM, Bruce Simpson wrote:


Michael Tüxen wrote:

On Apr 16, 2009, at 2:19 AM, Bruce Simpson wrote:
...


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

I know, but I wanted to make the state of the patches clear to make
the decision for the port maintainer easier.

Are you using DTLS?


Not yet, but I came across these patches whilst researching TLS  
adaptation for SCTP.
Ahh, I see. Even more interesting. If you try our DTLS/SCTP  
implementation,

please let us know if it works for you or if you have any questions...



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: kern/125195: [fxp] fxp(4) driver failed to initialize device Intel 82801DB

[gavin]

Synopsis: [fxp] fxp(4) driver failed to initialize device Intel 82801DB

State-Changed-From-To: feedback->open
State-Changed-By: gavin
State-Changed-When: Thu Apr 16 11:54:40 UTC 2009
State-Changed-Why: 
Feedback was received.  Card is: vendor=0x8086, dev=0x103e, revid=0x83

http://www.freebsd.org/cgi/query-pr.cgi?pr=125195
___
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

[Andre Oppermann]

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.


Network cards should not choke on frames with TSO but less than one MSS
worth of data.  Though it's not useful to create such frames in the stack.


I don't know about other virtualization stacks' behavior.

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


Your patch should fix the issue.  I don't have time to commit it and to
run the MFC process though.  Maybe Kip or Jack can run that process.

--
Andre

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