
Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [tlug] B Flets blocks port 25?
- Date: Mon, 2 Jun 2008 22:30:26 -0400 (EDT)
- From: Joe Larabell <fred62@example.com>
- Subject: Re: [tlug] B Flets blocks port 25?
- References: <c0f4e2b00805290150r76b45bceg423358fa120c671b@mail.gmail.com> <20080529040812.GA91216@mail.scottro.net> <20080529120715.GA10133@phb> <900ea9a0805282106o275ce03dj3e48f8965859b31d@mail.gmail.com> <78d7dd350805282131u46509543p8138803c87301664@mail.gmail.com> <78d7dd350805282056s4e60e79bx160588dea86f0f8a@mail.gmail.com> <20080529163026.GE13977@lucky.cynic.net> <78d7dd350805291911x31fda243u595d9a127397ac51@mail.gmail.com> <20080530104356.U20566@isris.pair.com> <87ve0veanw.fsf@uwakimon.sk.tsukuba.ac.jp> <20080530190920.P20566@isris.pair.com> <87iqwseaob.fsf@uwakimon.sk.tsukuba.ac.jp>
Hopefully this answers the previous question about Usen's blocking.
On Mon, 2 Jun 2008, Stephen J. Turnbull wrote:
The long answer is any host outside of your ISP's networks will do.
Ok... I installed tcptraceroute. After some googling, it appears SMB would
use the netbios ports (137, 138, 139) but if that's not right, I'm willing
to re-run the test using other ports.
It appears Usen drops TCP packets on port 139 but 137/138 seem OK:
hathoor ~ # tcptraceroute 209.68.2.39 137
Selected device eth2, address 219.123.112.250, port 39593 for outgoing packets
Tracing the path to 209.68.2.39 on TCP port 137 (netbios-ns), 30 hops max
1 219x123x112x249.ap219.ftth.ucom.ne.jp (219.123.112.249) 4.057 ms 3.886 ms 3.815 ms
2 43.233.244.134 5.303 ms 2.866 ms 2.713 ms
3 221x112x16x113.ap221.ftth.ucom.ne.jp (221.112.16.113) 3.017 ms 3.429 ms 3.017 ms
4 61.122.113.5 3.335 ms 3.275 ms 3.311 ms
5 usen-61x122x114x58.gate01.com (61.122.114.58) 3.303 ms 3.310 ms 3.248 ms
6 xe-0-1-0.a21.tokyjp01.jp.ra.gin.ntt.net (61.213.161.89) 3.396 ms 3.409 ms 3.370 ms
7 xe-2-1-0.r21.tokyjp01.jp.bb.gin.ntt.net (61.213.162.97) 3.352 ms 3.609 ms 3.360 ms
8 as-0.r21.lsanca03.us.bb.gin.ntt.net (129.250.3.145) 115.556 ms 115.612 ms 115.539 ms
9 po-2.r01.lsanca03.us.bb.gin.ntt.net (129.250.3.162) 115.882 ms 115.947 ms 116.922 ms
10 64.212.107.1 114.384 ms 113.638 ms 113.997 ms
11 * * *
12 * *
(138 gave me the same "signature" as 137)
hathoor ~ # tcptraceroute 209.68.2.39 139
Selected device eth2, address 219.123.112.250, port 59857 for outgoing packets
Tracing the path to 209.68.2.39 on TCP port 139 (netbios-ssn), 30 hops max
1 219x123x112x249.ap219.ftth.ucom.ne.jp (219.123.112.249) 4.162 ms 3.869 ms 3.818 ms
2 43.233.244.134 2.945 ms 2.776 ms 2.753 ms
3 221x112x16x113.ap221.ftth.ucom.ne.jp (221.112.16.113) 180.278 ms 199.334 ms 199.836 ms
4 * * *
5 * * *
6 * * *
The IP address is, again, my external web hosting ISP (my web site is on
isris.pair.com) and is definately outside of my home network. I let the
thing run for about 14 packets and after the 3rd hop, nothing comes back.
Given the trace on 137/138, it seems that's still within the Usen network.
So, as someone mentioned before, they've probably blocked it.
That said... doesn't SMB use UDB datagrams, not TCP? According to the man
page, normal traceroute, when given a port number, uses UDP packets as
it's "ping" mechanism. So I re-tried all three ports using UDP and the
result was successful on all three ports:
hathoor ~ # traceroute -p 139 209.68.2.39
traceroute to isris.pair.com (209.68.2.39), 30 hops max, 46 byte packets
1 219x123x112x249.ap219.ftth.ucom.ne.jp (219.123.112.249) 4.181 ms 3.891 ms 3.914 ms
2 43.233.244.134 (43.233.244.134) 3.575 ms 2.805 ms 2.799 ms
3 221x112x16x113.ap221.ftth.ucom.ne.jp (221.112.16.113) 3.113 ms 3.040 ms 3.211 ms
4 61.122.113.5 (61.122.113.5) 188.605 ms 198.379 ms 203.896 ms
5 usen-61x122x114x58.gate01.com (61.122.114.58) 3.305 ms 3.242 ms 3.308 ms
6 xe-0-1-0.a21.tokyjp01.jp.ra.gin.ntt.net (61.213.161.89) 3.428 ms 3.341 ms 3.450 ms
7 xe-1-0-0.r20.tokyjp01.jp.bb.gin.ntt.net (61.213.162.229) 3.462 ms 3.550 ms 3.724 ms
8 p64-2-3-0.r20.lsanca03.us.bb.gin.ntt.net (129.250.4.70) 122.370 ms as-1.r20.sttlwa01.us.bb.gin.ntt.net (129.250.4.189) 92.716 ms p64-2-3-0.r20.lsanca03.us.bb.gin.ntt.net (129.250.4.70) 120.016 ms MPLS Label=101088 CoS=0 TTL=0 S=0
9 po-1.r01.lsanca03.us.bb.gin.ntt.net (129.250.3.126) 115.956 ms po-2.r00.sttlwa01.us.bb.gin.ntt.net (129.250.2.205) 105.849 ms po-1.r01.lsanca03.us.bb.gin.ntt.net (129.250.3.126) 120.482 ms
10 64.208.110.222 (64.208.110.222) 110.415 ms 110.535 ms 64.212.107.1 (64.212.107.1) 118.067 ms
11 PAIR-NETWORKS.ge-3-2-0.ar2.cle1.gblx.net (146.82.33.170) 164.094 ms 174.218 ms 174.595 ms
At that point it kinda hangs so I killed it. Not sure what the mess is at
hops 8 and 9 -- that's the way it came out of traceroute (apologies in
advance to anyone who suffers word wrap on those long lines). Is that what
traceroute does when different machines answer up on the three attempts?
In summary, I guess I still don't know for sure whether Usen blocks "SMB"
per-se, or whether it would or would not work if I knew of a server whose
SMB share I could attempt to mount (if, in fact, I even wanted to ;-).
Note: My own firewall blocks incoming 137:139 from the Usen network (along
with anything else I'm not actually using). I don't think that's relevant
to the above tests but it could be a problem if I tried to use real SMB
across the Internet -- which, for security reasons, I'm not even willing
to try.
---
Joseph L (Joe) Larabell Never fight with a dragon
http://larabell.org/ for thou art crunchy
http://thelemicleague.org/ and goest well with cheese.
Home |
Main Index |
Thread Index