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>
