回复：Re:Re:RE:RE:problemaboutopenconnect6.0 Windows client

[飞翔]

Hi,
 
   All output is in in the resource.zip.
   The files with the suffix of "after" mean the result had added  the C sentence of  "int len = 1500;"  in the C file.
   The files with the suffix of "before" mean the result without such Modify .

>   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?


     It looks like that the MTU is just 1337 and the  vpnc-script-win.js had success.
     

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

    
     I had tried this patch ,but it seems that the MTU Is still 1337. The details is in the files.


>   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?
    
     I have try it again, when the errors occur,It will continue to work until  I  stop it by manual(Ctrl+C).
     The mylog_After.txt and mylog_Before.txt show the result with  "-v".
     

>   There'll be lots more output, so capturing it into a file and sending
>   that, instead of a screen capture, would be better.
    
     I use  one  screen capture of error_after.jpg  because that  the result with  "-v"  in the log file does not show the same error prompt  as  the end of the error_after.jpg 
 




------------------ 原始邮件 ------------------
发件人: "David Woodhouse";<dwmw2 at infradead.org>;
发送时间: 2014年7月29日(星期二) 下午4:30
收件人: "飞翔"<1152172779 at qq.com>;
抄送: "openconnect-devel at lists.infrade"<openconnect-devel at lists.infradead.org>;
主题: Re:回复：Re:Re:RE:RE:problemaboutopenconnect6.0 Windows client

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: resource.zip
Type: application/octet-stream
Size: 89108 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20140730/2fca1bc6/attachment-0001.obj>