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

[David Woodhouse]

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: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20140730/29681a9c/attachment.bin>