fullness Time's List: DSL-300T Connection problems and Settings

• DSL300T in half bridge mode straight into a linux box has the same problem. It  seems to be related to the number of connections thru the modem rather than  time, it will crash in under 15 mins when acting as a gnutella ultrapeer for 40  or 50 leaf nodes, or about 30 minutes surfing thumbnail galleries, but will stay  up for 2-3 days running only irc
  
  Pulling the power cable is faster than  hitting the reset switch, as it doesn't mean reconfiguring the modem every time,  but other than that I don't have a solution. Posting here in the hope someone  else solves the problem.
  
  --Dave
• yeap, like an emule session too.. it will get accessible after a while if you  close down what is doing all the traffic
  but just telnet into the linux shell  and do
  
  echo "32752" >  /proc/sys/net/ipv4/netfilter/ip_conntrack_max
  
  that should  help..
  
  Also remember this is a fully functional Linux busybox with  iptables.. I login and paste an iptables script when I boot the modem.
  
  I  add routes, clear the iptables and setup NAT and DNAT, here's my script with  public ip's XXX'ed

  • This supposedly fixes the problem where the modem slows to crawl and is not event accessible through its web interface. See the rest of his post for how to turn the box into a "router" - the marketing term for a box with iptables and DNAT set up (practically every tcp/ip capable maching is capable of 'routing').

• I didn't see much diff between 1500 and 1400  
  
  Are you connected directly to your router/modem? It's possible  that your internal LAN supports higher MTU values and packets get fragmented  once it reaches your router/modem. In which case this is a LAN (not WAN) related  MTU setting.
  
  The reason you don't see a difference between 1500 and 1400  is because your internal LAN is handling all the fragmentation.
  
  I do also  recall Jenny from G-node posting earlier to use 1472 MTU  setting.
  
  Hopefully users can differentiate from internal LAN MTU's (which  can be higher); and external WAN MTU's (which are limited by PPPoA and PPPoE).  Remember it's:
  

  • Does this mean ping can report fragmentation but because there is sufficient bandwidth on the LAN relative to what comes back over the ADSL connection (which will have no fragmentation problems, if the modems MTU is set correctly, as encapsulation repackages packets in the routers MTU size), there is no loss in the actual kps data rate?
• Not all routers have all these settings mine only has the MTU setting and the  others are auto set from the MTU.
  

  • The default for the dsl-300t was MRU 1400 and MTU 1492. When you altered both to 1500 the large increase in sync speed may be because it uses the LOWEST value so the 1492 is really irrelevant. Or it could have been coincidental, and there had been some real inprovement in the SNR or ATT since the last connection.
• We recommend clients use PPPoE, but for those who want to use PPPoA to reduce  overheads, I'd recommend an MTU setting of 1462 bytes to fully fill all the ATM  cells.
  
• There is magic dust in the Internode service that means the  effective MTU is 1460 for TCP connections. This is achieved with no intervention  at your end.
  
  This is not a bug, its a feature.
  
  It doesn't reduce  your real world performance - and it increases your compatibility with the harsh  world outside - automatically. Without it, lots of
  customers would need to  manually adjust their MTU for correct results. With it, none of them need  to.
  
  What problem, precisely, do you wish to solve my raising the MTU  (bearing in mind that most problems related to MTU's are solved by LOWERING  them).

  • Despite quoting this boostland uses "I am using PPPoA VC-Mux with a MTU and MRU of 1500 the MSS is 1460".

2 more annotations...