回复：Re:Re:RE:RE:problemaboutopenconnect6.0 Windows client
飞翔
1152172779 at qq.com
Thu Jul 31 04:18:18 PDT 2014
Hi,
> DTLS got write error: The transmitted packet is too large (EMSGSIZE).. Falling back to SSL
> Sending uncompressed data packet of 1382 bytes
> So even though the MTU on the device is set to 1337, the TAP driver is
> handing us a packet which is larger than that. I think it's a bug in the
> Windows TAP driver.
> In "out_before.log" it behaves differently, because when we read from
> the TAP driver we are only using a buffer of size 1337. So it *can't*
> give us a packet which is too large. Instead, we see that 'ea'
> ERROR_MORE_DATA error.
> We also see the 'Failed to read from TAP device: 1f' (ERROR_GEN_FAILURE)
> error only in 'out_before.log', so I wonder if that's what happens when
> we issue the ReadFile() call and there is *already* a too-large packet
> waiting for us (as opposed to returning ERROR_IO_PENDING and then the
> too-large packet being handled in GetOverlappedResult()).
> Just to confirm — these errors are purely cosmetic, aren't they? You
> said that it continues to work until you stop it with ^C? If that's
> true, then I'm not sure we need to do anything in OpenConnect. We
> already *cope* with this bug in the TAP driver, which is the important
> thing. I'm not worried about printing some scary messages while we do
> so :)
> I'd quite like to see *why* we get such large packets though. Please
> could you try this patch and see what it dumps?
Thanks a lot , I have try this patch , the "error1.log" shows the result.
> Btw, please could you also test the latest code from the git repository?
> If you can't check it out using git, then you should be able to download
> a tarball using the 'snapshot' link at
> http://git.infradead.org/users/dwmw2/openconnect.git
> I'd like to make sure that the recent changes to improve character set
> handling have not broken things for you, including the handling of the
> TAP device name...
Sorry,I am not familiar with the git .
Using the "git clone git://git.infradead.org/users/dwmw2/openconnect.git",I can get the project .
There is no "configure" file in it,so how can I build it ? Must I use the "autoconf " or use other method based on the "openconnect-6.00.tar.gz"?
Thanks
L.G
------------------ 原始邮件 ------------------
发件人: "David Woodhouse";<dwmw2 at infradead.org>;
发送时间: 2014年7月30日(星期三) 晚上8:04
收件人: "飞翔"<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 Wed, 2014-07-30 at 18:40 +0800, 飞翔 wrote:
>
>
> At this time，I have used the ‘-v -v’ parameters，and redirected
> the stderr and stdout to the log file.
> The out_after.log shows the result with this patch.
> The out_before.log shows the result without this patch.
>
Thanks. In "out_after.log" I see the following:
DTLS got write error: The transmitted packet is too large (EMSGSIZE).. Falling back to SSL
Sending uncompressed data packet of 1382 bytes
So even though the MTU on the device is set to 1337, the TAP driver is
handing us a packet which is larger than that. I think it's a bug in the
Windows TAP driver.
In "out_before.log" it behaves differently, because when we read from
the TAP driver we are only using a buffer of size 1337. So it *can't*
give us a packet which is too large. Instead, we see that 'ea'
ERROR_MORE_DATA error.
We also see the 'Failed to read from TAP device: 1f' (ERROR_GEN_FAILURE)
error only in 'out_before.log', so I wonder if that's what happens when
we issue the ReadFile() call and there is *already* a too-large packet
waiting for us (as opposed to returning ERROR_IO_PENDING and then the
too-large packet being handled in GetOverlappedResult()).
Just to confirm — these errors are purely cosmetic, aren't they? You
said that it continues to work until you stop it with ^C? If that's
true, then I'm not sure we need to do anything in OpenConnect. We
already *cope* with this bug in the TAP driver, which is the important
thing. I'm not worried about printing some scary messages while we do
so :)
I'd quite like to see *why* we get such large packets though. Please
could you try this patch and see what it dumps?
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);
diff --git a/tun-win32.c b/tun-win32.c
index 48e8251..03380ae 100644
--- a/tun-win32.c
+++ b/tun-win32.c
@@ -259,6 +259,17 @@ int os_read_tun(struct openconnect_info *vpninfo, struct pkt *pkt)
/* Either a straight ReadFile() or a subsequent GetOverlappedResult()
succeeded... */
+ if (pkt_size > vpninfo->ip_info.mtu) {
+ int i;
+ printf("ERROR: Tun device returned packet of %d bytes which is larger than MTU %d",
+ pkt_size, vpninfo->ip_info.mtu);
+ for (i=0; i< pkt_size; i++) {
+ if (!(i%16))
+ printf("\n%04x:", i);
+ printf(" %02x", (unsigned char)pkt->data[i]);
+ }
+ printf("\n");
+ }
vpninfo->tun_rd_pending = 0;
pkt->len = pkt_size;
return 0;
--
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: error1.zip
Type: application/octet-stream
Size: 24439 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20140731/cf55f413/attachment-0001.obj>
More information about the openconnect-devel
mailing list