回复:Re:Re:RE:RE:problem aboutopenconnect6.0 Windows client

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2014-07-29 at 14:51 +0800, ?? wrote:
> Hi,
> 
> >  Yes, just replying normally to the email is definitely the best thing to
> >  do. But please remember to keep the list address
> >  openconnect-devel at lists.infradead.org in Cc ? use "reply to all", not
> >  just "reply".
> 
>    Ok,I see.

This reply was correct, FWIW ? just a bit large, which made it get
trapped for moderation anyway :)

> > Hopefully!
> > http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/bbcaa4db
>    
>   Great,now the openconnect-6.0 with those patchs can run on XP without any error dialog!

Excellent.

>   On XP within the last version OpenVPN driver,Just like   the  run_on_xp1.jpg  and  run_on_xp2.jpg  show,
>   that's the result when I try to connect to the ocserver. 
>   It can  do it successfully,but will prompts  that some fail
> occurs ,but I can still use this VPN tunnel to visit  the internet
> successfully at least in  the beginning it does.

Hm. Error 0xea is ERR_MORE_DATA, which implies that the network stack
sent a larger packet than we expected. Is the MTU on the TAP interface
actually set to 1337 as it should be, or did vpnc-script-win.js fail to
do that?

I think we should recover from that ERR_MORE_DATA though, and it looks
like we do. You could try this patch and see if it goes away though, and
see if the other symptoms also go away...

diff --git a/mainloop.c b/mainloop.c
index 3102156..fb5d546 100644
--- a/mainloop.c
+++ b/mainloop.c
@@ -57,7 +57,7 @@ int tun_mainloop(struct openconnect_info *vpninfo, int *timeout)
 
 	if (read_fd_monitored(vpninfo, tun)) {
 		while (1) {
-			int len = vpninfo->ip_info.mtu;
+			int len = 1500;
 
 			if (!out_pkt) {
 				out_pkt = malloc(sizeof(struct pkt) + len);


The 0x1f error is ERR_GEN_FAILURE which looks more ominous, but still in
your 'run_on_xp1.jpg' screenshot it looks like we're continuing after
seeing that.

You say that "in the beginning" it still works. Does that mean that it
later *stops* working? Can you run with the '-v' argument and show me
precisely when it fails?

There'll be lots more output, so capturing it into a file and sending
that, instead of a screen capture, would be better.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20140729/c33c3023/attachment.bin>


[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux