Well, I'm sure glad I searched the maillist further (looking into my hunch of MTU/MRU issues), my problem was solved with the CLAMPMSS=yes setting in shorewall's 'Config' file.
So the rest of this email is perhaps only of use to anyone who stumbles down my well-worn path, except for one question:
Regarding the CLAMPMSS setting, it is noted in the config file that:
# MSS CLAMPING # [...] # This is used to overcome criminally braindead ISPs or servers which # block ICMP Fragmentation Needed packets.
About the 'criminally braindead ISP' comment - since my situation is that I'm shifting my login from one router at my ISP to their other router (by way of changing my login name - they bought out my former ISP and I was recently caused to use the new ISP's login router [problematic] vs the original login router [working fine]) I'd like to know how large a bunghole I should feel in justified in tearing into my 'new' ISP, for their 'braindead' setting.
I'm also wondering if there's maybe an RFC I can cram down their throats or some such, that authoritatively points out their dead brain?
Sorry for the heated words but I've just spent about 16 hours working around my 'braindead ISP'... :( :( :(
In the end though, LEAF (and this list) have come through and solved my problem - so thanks for LEAF and the people who contribute to this list!
scott; canada
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
I'm using Bering uClibc 2.2.0b5, with a DSL net connection and I'm stumped...
I was setup with an ISP who has sold out to another. My login details with the first ISP ([EMAIL PROTECTED] - aka "nbn login") have persisted under the new owners. A couple of days ago I'm having trouble completing PPP connections - PAP auth goes through OK but the connection would not complete. I call their tech support who tell me to change my login to be off their own router (some customers are having a similar problem to mine and this seems to cure them), via [EMAIL PROTECTED] (aka "ody login"). Happiness - PPP comes up OK and my LEAF box makes pretty sounds (thanks for beep.lrp!).
But... I can't go anywhere - www page loading fails, outbound VNC connects fail, etc.
Using wget I've observed that I can get some %'age of a web page, for instance. In the case of the ibm.com webpage (~26,000 bytes total) I often get a complete timeout (0 bytes) or sometimes 2,421 bytes, or even as much as ~13,000 bytes. Interestingly the number of bytes, though it varies, is often one of a few different numbers (1,086 bytes, 2,421 bytes, etc). FWIW wget indicates (when using the 'ody login') that the ISP's cache is always 'MISS'ing ("X-Cache: MISS from cache.ody.ca").
Pinging works 100% of the time (e.g. to www.yahoo.com) on both logins.
Now, about this secondary login ('ody') - they run a proxy server upon it. Might this be the source of my misery? Is there anything I can/should do to my LEAF box to make it play well with their proxy? Is the proxy issue moot since ... I can connect to a POP3 server and have some interaction with it but the connection hangs after (presumably) only a couple'a hundred bytes? I would expect that there's no caching/proxy going on for an outbound port 110 connection to a small ISP's POP server?!?!
More curiosity ... I use dyndns and my ipupdate.lrp works well and gets the proper IP addy I've been assigned (via http://checkip.dyndns.org, a web page which I can retrieve in its entirety - it's presumably small enough). But when I visit http://wwww.privacy.net, who display for you your IP addy and reverse-DNS hostname, I get an incorrect IP addy and a hostname of squid1.ody.ca (the incorrect IP addy is presumably that of the caching proxy server, as indicated by the hostname). So this is weird - I would expect privacy.net to give me my proper IP addy and not that of my caching proxy?!?! Is this indicative of a possible proxy misconfig at my ISP's end?
Shorewall's logfiles show no activity so it's not a port-blocking issue, especially since from a given source (www, pop3) I can get /some/ data but not much before the connection 'hangs'. In fact there is no action from any of the logfiles at all (i.e. files in /var/log).
Regrettably, my ISP says they only support PPPoE connections directly off of a Windows box and as my luck would have it when I connect my eth directly into my XP box (and using 'nbn login') I get proper web access, etc.
(As an aside:
- the original login is now working but I'm concerned that it's not stable/reliable [older Cisco router, due to be replaced within 2 weeks] and that my ISP may impose the proxy [or whatever is causing me the grief with the 'ody login'] upon this other 'login' so I feel that I need to figure this thing out and get it behaving with the 'ody login'.
- I created a base uClibc (2.2.0b5) floppy image and changed as little as possible to give me access to the net and it gives the same symptoms as with my fully-customized setup, in terms of the ody.ca login giving me proper problems.)
More info from wget... - Running: Wget 1.9+cvs-dev-200404081407 - command line: WGET.EXE -d http://www.ibm.com/us/ - comparing a pull using the 'nbn login' and the 'ody login': - on the 'nbn login' I get this debug info:
---request begin--- GET /us/ HTTP/1.0 User-Agent: Wget/1.9+cvs-dev-200404081407 Accept: */* Host: www.ibm.com Connection: Keep-Alive
---request end--- HTTP request sent, awaiting response... ---response begin--- HTTP/1.1 200 OK Date: Tue, 24 Aug 2004 22:11:59 GMT Server: IBM_HTTP_SERVER/1.3.26.3 Apache/1.3.26 (Unix) Vary: * Cache-Control: no-cache Content-Length: 26352 Keep-Alive: timeout=10, max=100 Connection: Keep-Alive Content-Type: text/html
---response end--- 200 OK Registered socket 1948 for persistent reuse. Length: 26,352 [text/html]
- on the @ody.ca login (where I received 1,086 bytes before it got 'stuck') I get this debug info:
---request begin--- GET /us/ HTTP/1.0 User-Agent: Wget/1.9+cvs-dev-200404081407 Accept: */* Host: www.ibm.com Connection: Keep-Alive
---request end--- HTTP request sent, awaiting response... ---response begin--- HTTP/1.0 200 OK Date: Tue, 24 Aug 2004 22:12:47 GMT Server: IBM_HTTP_SERVER/1.3.26.3 Apache/1.3.26 (Unix) Vary: * Cache-Control: no-cache Content-Length: 26337 Content-Type: text/html X-Cache: MISS from cache.ody.ca Connection: keep-alive
---response end--- 200 OK Registered socket 1952 for persistent reuse. Length: 26,337 [text/html]
What I see (that's different between the two):
- byte count for the full page is different - this is normal for the IBM webpage
- ody: the second "HTTP/" line says "HTTP/1.0" - nbn: the second "HTTP/" line says "HTTP/1.1"
- ody: says: "X-Cache: MISS from cache.ody.ca"
- nbn: no "X-Cache:" header (as I would expected since it's not 'proxied')
- ody: has no "Keep-Alive:" header
- nbn: has "Keep-Alive: timeout=10, max=100"
- ody: "Connection: keep-alive"
- nbn: "Connection: Keep-Alive" (different upper/lower case - likely insignificant)
Maybe there's a clue in these differences?
Another sort of symptom: when I connect to a small ISP's pop3 server I can login, etc, but as soon as I ask for a large amount of data ('top 1 100' or 'list') I get one line of feedback (e.g. "+OK 291 2306125" but then no more ... is this maybe indicative of an MTU/MRU issue?)
Any insight out there for what's causing me this grief, or what I might need to do on my LEAF box to make it play well with the @ody.ca login? I kind of don't know where to begin to diag a problem of this nature, where I get a few hundred bytes from a webpage (or sometimes a complete 0-byte timeout) but then the connection hangs, however but when I change /only/ the login name then my LEAF box works in the fashion to which I have become accustomed - wonderfully. :)
Help?!
... and thanks for LEAF!
scott; canada
------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
