https://wiki.archlinux.org/api.php?action=feedcontributions&user=Cameel&feedformat=atomArchWiki - User contributions [en]2024-03-28T11:10:00ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Talk:Sharing_ppp_connection_with_wlan_interface&diff=126181Talk:Sharing ppp connection with wlan interface2010-12-28T05:10:21Z<p>Cameel: Added 'Connections suddenly timing out' section</p>
<hr />
<div>===Connections suddenly timing out===<br />
I've been using this method for some time and noticed that sometimes a connection to a remote server stalls and times out for no apparent reason. It happens only with some particular servers. Just as if the server suddenly stopped sending data - even though everything works OK when connecting from the matchine with firewall. It turns out that some servers are misconfigured to report that they support PMTU discovery while in fact they ignore ICMP messages telling them that the packets are too large. You can find more information here: http://www.netheaven.com/pmtu.html <br />
<br />
The following iptables rule seems to be a good workaround:<br />
iptables -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu<br />
<br />
I did't want to add it to the article myself because I'm not sure if it is the best way to do this and if it does not have any undesirable side effects. It would be nice if someone could verify this and add it if it's OK. [[User:Cameel|Cameel]] 00:10, 28 December 2010 (EST)</div>Cameelhttps://wiki.archlinux.org/index.php?title=Talk:Internet_sharing&diff=126180Talk:Internet sharing2010-12-28T05:09:35Z<p>Cameel: Added 'Connections suddenly timing out' section</p>
<hr />
<div>The first method is nice for larger networks, it is explained in these articles:<br />
[[Simple stateful firewall HOWTO]] and [[NAT'ing firewall - Share your broadband connection]]<br />
09:01, 25 October 2006 (PDT)Gilneas<br />
<br />
I managed to do this with a straight through cable. --[[User:Factory|Factory]] 23:22, 10 August 2008 (EDT)<br />
<br />
:Chanches are that one of your Network Interface Cards is a Gigabit Ethernet Card which supports AUTO MDI-X according to its specification. AUTO MDI-X automagically adjusts to the cable type, so that it makes no difference which type you use to connect. The article is correct mentioning the use of a crossed cable. --[[User:Rondal|Rondal]] 08:19, 24 August 2008 (EDT)<br />
<br />
It's probably worth mentioning that eth0 and eth1 IPs on PC1 shold be in different ranges. I myself had a problem with routing when they were set up to 192.168.0.2 (by default) and 192.168.0.1 (according to the article). --[[User:phoederr|phoederr]] 19:55, 12 January 2009<br />
<br />
===Connections suddenly timing out===<br />
I've been using this method for some time and noticed that sometimes a connection to a remote server stalls and times out for no apparent reason. It happens only with some particular servers. Just as if the server suddenly stopped sending data - even though everything works OK when connecting from the matchine with firewall (pc1). It turns out that some servers are misconfigured to report that they support PMTU discovery while in fact they ignore ICMP messages telling them that the packets are too large. You can find more information here: http://www.netheaven.com/pmtu.html <br />
<br />
The following iptables rule seems to be a good workaround:<br />
iptables -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu<br />
<br />
I did't want to add it to the article myself because I'm not sure if it is the best way to do this and if it does not have any undesirable side effects. It would be nice if someone could verify this and add it if it's OK. [[User:Cameel|Cameel]] 00:09, 28 December 2010 (EST)</div>Cameelhttps://wiki.archlinux.org/index.php?title=Talk:Internet_sharing&diff=126179Talk:Internet sharing2010-12-28T05:07:42Z<p>Cameel: </p>
<hr />
<div>The first method is nice for larger networks, it is explained in these articles:<br />
[[Simple stateful firewall HOWTO]] and [[NAT'ing firewall - Share your broadband connection]]<br />
09:01, 25 October 2006 (PDT)Gilneas<br />
<br />
I managed to do this with a straight through cable. --[[User:Factory|Factory]] 23:22, 10 August 2008 (EDT)<br />
<br />
:Chanches are that one of your Network Interface Cards is a Gigabit Ethernet Card which supports AUTO MDI-X according to its specification. AUTO MDI-X automagically adjusts to the cable type, so that it makes no difference which type you use to connect. The article is correct mentioning the use of a crossed cable. --[[User:Rondal|Rondal]] 08:19, 24 August 2008 (EDT)<br />
<br />
It's probably worth mentioning that eth0 and eth1 IPs on PC1 shold be in different ranges. I myself had a problem with routing when they were set up to 192.168.0.2 (by default) and 192.168.0.1 (according to the article). --[[User:phoederr|phoederr]] 19:55, 12 January 2009<br />
<br />
===Connections suddenly timing out===<br />
I've been using this method for some time and noticed that sometimes a connection to a remote server stalls and times out for no apparent reason. It happens only with some particular servers. Just as if the server suddenly stopped sending data - even though everything works OK when connecting from the matchine with firewall (pc1). It turns out that some servers are misconfigured to report that they support PMTU discovery while in fact they ignore ICMP messages telling them that the packets are too large. You can find more information here: http://www.netheaven.com/pmtu.html <br />
<br />
The following iptables rule seems to be a good workaround:<br />
iptables -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu<br />
<br />
I did't want to add it to the article myself because I'm not sure if it is the best way to do this and if it does not have any undesirable side effects. It would be nice if someone could verify this and add it if it's OK.</div>Cameel