On Fri, 2012-06-08 at 23:29 +0100, David Woodhouse wrote:
> Does the Cisco client get it "right" in this situation? How? After
> running 'ip route flush cache' can you capture the traffic (host $SERVER
> or icmp or icmp6) and see precisely what it's doing?
>
> I'm imagining some trick with sending a 1500-byte UDP packet to the
> server before making the TCP connection... but that's horrid.
I'm relieved to report that it doesn't seem to *work* either :)
--- a/cstp.c
+++ b/cstp.c
@@ -490,6 +490,34 @@ int make_cstp_connection(struct openconnect_info *vpninfo)
if (ret)
return ret;
+ /* Ick. Try sending a full-sized packet, in the hope that an ICMP
+ response will tell the kernel the path MTU. Except to *really*
+ determine the path MTU we'd need to keep trying with progressively
+ smaller packets because each hop along the way could have a
+ slightly smaller MTU than the one before. That's why they call it
+ a *path* MTU. But the server seems to want *us* to work this out
+ for it, so we can at least try... */
+ if (1) {
+ char buf[1500];
+ int len;
+ int udp;
+
+ memset(buf, 0x5a, sizeof(buf));
+
+ if (vpninfo->peer_addr->sa_family == AF_INET6)
+ len = 1452;
+ else
+ len = 1472;
+
+ udp = socket(vpninfo->peer_addr->sa_family, SOCK_DGRAM, IPPROTO_UDP);
+ if (udp >= 0) {
+ sendto(udp, buf, len, 0, vpninfo->peer_addr, vpninfo->peer_addrlen);
+ }
+ close(udp);
+ sleep(1);
+ }
+
+
if (vpninfo->deflate) {
vpninfo->deflate_adler32 = 1;
vpninfo->inflate_adler32 = 1;
--
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120609/d2fba5b0/attachment.bin>
