Opened 12 years ago

Closed 12 years ago

#258 closed Bug / Defect ( fixed )

segfault after extracting dhcp gateway

Reported by: mbakhoff Owned by: Gert Döring
Priority: major Milestone:
Component: Networking Version: OpenVPN 2.3.0 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc:

Description

I get a segfault after "Extracted DHCP router address" when connecting to remote server in TAP mode. This is because of a nullpointer dereference in route_list_add_vpn_gateway.

I'm running gentoo ~amd64, openvpn-2.3.0 and will gladly answer any questions. Attaching logs and stacktrace.

Attachments (3)

stack.log ​ ( 15.9 KB ) - added by mbakhoff 12 years ago .
stacktrace to route_list_add_vpn_gateway
openvpn.log ​ ( 20.6 KB ) - added by mbakhoff 12 years ago .
execution log
openvpn-version.log ​ ( 1.2 KB ) - added by mbakhoff 12 years ago .
openvpn --version

.zip

Change History (9)

Changed 12 years ago by mbakhoff

Attachment: stack.log ​ added

stacktrace to route_list_add_vpn_gateway

Changed 12 years ago by mbakhoff

Attachment: openvpn.log ​ added

execution log

Changed 12 years ago by mbakhoff

Attachment: openvpn-version.log ​ added

openvpn --version

comment:1 Changed 12 years ago by mbakhoff

To be precise - the connection establishment works fine. The crash occurs after I run "dhcpcd tap0".

comment:2 Changed 12 years ago by Gert Döring

so if I understand this right, you use OpenVPN to set up a tap connection, which is not assigned IP addresses from the server, and then you run "dhcpcd tap0" on the client, leading the OpenVPN client to crash?

Last edited 12 years ago by Gert Döring ( previous ) ( diff )

comment:3 in reply to: 2 Changed 12 years ago by mbakhoff

Correct.

Replying to cron2 :

so if I understand this right, you use OpenVPN to set up a tap connection, which is not assigned IP addresses from the server, and then you run "dhcpcd tap0" on the client, leading the OpenVPN client to crash?

comment:4 Changed 12 years ago by Gert Döring

Owner: set to Gert Döring
Status: new → accepted

So. This took way too long, sorry.

Could you please try whether the patch attached to trac #281 fixes the bug for you (as far as I can see, #281 and #258 are duplicates).

comment:5 Changed 12 years ago by mbakhoff

tested the same setup with trac-281-fix.patch applied. did not crash and everything seems to be working :) thanks!

comment:6 Changed 12 years ago by Gert Döring

Resolution: → fixed
Status: accepted → closed

Thanks for testing.

I have applied the patch to the git tree today (master and release/2.3 branch), and we'll release 2.3.2 "real soon" with this fix.