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>
