On Tue, May 6, 2014 at 7:00 AM, <44net-request(a)hamradio.ucsd.edu> wrote:
>Client modems will scan for the three frequencies in use by the three
sectors, and connect to whichever cell site is available. (Generally one
you have pointed your antenna at.)
Hehehe, then its not "cellular" is it.. hehe, it's going to connect to the
only signal it can see - the AP (sorry, cell site) that it's pointed at.
> Far be it for Steve Write, a newcomer to the field of packet radio,
> who hasn't even successfully built and connected his own TCP/IP node,
> to embarrass himself on a mailing list by correcting the terminology
> used by someone with more technical experience in the field than he.
> No, that wouldn't be right would it? After all he hasn't even finished
> reading all those unwritten Wiki's - and corrected them, loudly and at
> great personal sacrifice - since newcomers are a fount of knowledge
> and wisdom about the errors and omissions in the documentation by
> those who have gone before them.
Hehehe, no I said "point taken and conceded", you read back and see! I
AGREED with the man, AND conceded the point.
Actually, I had allocated a 44/30 25 years ago, ran NOS over laggy 1200bd
AFSK links on a 386 PC with one floppy, and my Internet connection was
VT100 unix shell until I was allowed to run a SLIP link, so I am no
newcomer, as you incorrectly state as fact. Egg on face again!
Actually, hehehe there is also the situation where I have connected many
many TCP/IP units in remote areas over wireless links, but the professional
equipment I use is not really supported by the piecemeal approach so far
with the 44net crowd - I hope to change that. What do you hope to achieve?
Your sarcasm regarding the wiki is also noted. Why you might attack me
about this is very surprising. Quite frankly, there was nothing of value
in the wiki before I pointed out the glaringly obvious fact, and now that
is changing fast, and it will keep changing until the path forward for all
people is abundantly clear.
I think you would just like to take the opportunity to be abusive. I
address the issue concisely, learn from what is said, retract when
incorrect, yet you evade all logic and pursue your ad hominem approach. I
offer regret for offence taken, but you offer more offence?
I don't think you are part of the solution, or part of any solution. For
anything. 8-/
Hi All,
Does any one know if there is a problem with UDP port 520 and
rip44d, I am monitoring it but I see no data arriving here at all.
Have tested from an outside source and the port is receiving all ok.
Comments ?
--
Regards ..... Peter ZL2BAU
ZL2BAU - Waimate BBS - South Canterbury APRS iGate
Located In - Waimate - South Island - New Zealand
Grid Location : RE55MG ( 44.44.26S / 171.03.23E )
New Zealand / World Wide Telnet BBS Forwarding
E-Mail : peter.zl2bau(a)gmail.com
Skype : ZL2BAU or Peter Mallett
Packet Mail : ZL2BAU @ ZL2BAU.#79.NZL.OC
NZART Member Number : 104431
Internet LinBBS : telnet://118.82.200.153:6303
Internet Xrouter Node : telnet://118.82.200.153
Internet Xrouter Node : BAUNOD:ZL2BAU-3 (44.147.210.26)
Xrouter Chat Server : telnet://118.82.200.153:3600
Xrouter APRS Server : telnet://118.82.200.153:1448
LinFBB HTTP Server : http://118.82.200.153:8085
Tcp/Ip Routing : 44.147.210.0/24 (Gateway 44.147.210.26)
Default UDP Port : 93 (Other ports to suite)
John,
Lol...you know I meant the major /8's that were handed out long ago that, to date, have never signed an agreement with their RIR.
I stand corrected, though, there are Legacy allocations smaller than /8 that exist as well...but they are not listed in RFCs (as fixtures of the 'DARPA Internet').
-KB3VWG
paine-s1.hamwan ADD CNAME ether1.paine-s1.hamwan.net
ether1.paine-s1.hamwan ADD A 44.24.240.131
wlan1.paine-s1.hamwan ADD A 44.24.240.145
corvallis-er1.hamwan ADD A 198.178.136.80
seattle-er1.corvallis-er1.hamwan ADD A 44.24.242.20
capitolpark.nq1e.corvallis-er1.hamwan ADD A 44.24.242.0
paine.k7nvh.corvallis-er1.hamwan ADD A 44.24.242.8
corvallis-srv1-kvm.corvallis-er1.hamwan ADD A 44.24.242.25
baldi.corvallis-er1.hamwan ADD A 44.24.242.2
paine.ae7sj.corvallis-er1.hamwan ADD A 44.24.242.4
wlan1.paine-s3.hamwan ADD A 44.24.240.177
ether1.paine-s3.hamwan ADD A 44.24.240.133
wlan1.paine.ae7sj.hamwan ADD A 44.24.242.7
corvallis-er1.hamwan ADD A 198.178.136.80
On Mon, May 5, 2014 at 7:00 AM, <44net-request(a)hamradio.ucsd.edu> wrote:
> What are you talking about? Who said anything about professionals, and
> why did you bring it up? 44net is for ham radio networks.
A "Cell Site", for the uninformed, is a "Cellular Phone site". What he
appears to have been working on, in hindsight, appears to be commonly
referred to as an "Access Point", or in ham-radio speak, a "Node".
A genuine misunderstanding arising from the incorrect placement of a
technical term, however I do regret that offence was taken(sic). Reminder
to use the correct terminology, and to filter for misunderstandings before
unleashing the offence.
> I don't see how this has any relation to politics. Bart wants to
> identify ISPs that may not work well with 44net due to blocking
> tunneling protocols. GRE is just an example, but an ISP could easily
> block IPIP, too.
>
> It would be really helpful to have some software that would tell you
> "You're ISP is blocking it" instead of just emailing the 44net list
> with "Why don't my tunnels route traffic?"
Point taken and conceded.
Best way to ask ISPs what they filter, is to simply ASK them. Why would
you connect with some ISP and then spend months trying to debug something,
when you could simply ASK them beforehand? Perhaps you like your head down
such rabbitholes? I do not - I want to plug it in and it works.
I'll mess with it when I get home.
With no interest when I unplug the linbpq box it stop cycling router when I plug it back in starts immediately. No other PCs on network.
On May 4, 2014 12:25 AM, Brian <n1uro(a)n1uro.ampr.org> wrote:
>
> (Please trim inclusions from previous messages)
> _______________________________________________
> Greetings;
>
> I have noticed that some of the internal routing within comcast hasn't
> been as stable lately as it once was, and have especially noticed
> extremely high latency between comcast.net and other cable based
> networks such as rr.com from doing non-ipencap traces. This of course
> would affect any ipencap frames trying to use the same path.
>
> In regards to the thread that's _unnecessarily_ spawned off from this
> same one, there's a huge difference between a protocol and a service.
> ISP can filter protocols as most do OSPF, and some may indeed charge for
> an OSPF based peer. I've yet, however, to see an ISP charge for a
> protocol that a potential VPN would run on... I would think that would
> kill corporate-based accounts for them.
> --
> 73 de Brian Rogers - N1URO
> email: <n1uro(a)n1uro.ampr.org>
> Web: http://www.n1uro.net/
> Ampr1: http://n1uro.ampr.org/
> Ampr2: http://nos.n1uro.ampr.org
> Linux Amateur Radio Services
> axMail-Fax & URONode
> AmprNet coordinator for:
> Connecticut, Delaware, Maine,
> Maryland, Massachusetts,
> New Hampshire, Pennsylvania,
> Rhode Island, and Vermont.
>
> _________________________________________
> 44Net mailing list
> 44Net(a)hamradio.ucsd.edu
> http://hamradio.ucsd.edu/mailman/listinfo/44net
>
On Sun, May 4, 2014 at 7:00 AM, <44net-request(a)hamradio.ucsd.edu> wrote:
> During some cell site work last night, I seem to have experienced
> Comcast dropping packets from point A to point B simply based on the
> fact that their IP protocol was GRE (IP protocol 47). I also found some
> posts on the Internet that claim Comcast wishes to charge more money to
> transport GRE packets. I'm not sure if this is true, or if I made a
> mistake somehow in my traffic handling. Therefore...
If you really WERE working in a professional role on such equipment, and
you ACTUALLY DID notice GRE packets missing, I would hazard a guess that
you were perfectly capable of scripting up nc, nmap etc, with some bash or
python to do as you ask, instead of trolling this networking group with
your political goals.
On topic though, I do recall some recent amendments to law (actually rules
of a corporation, not real law) where it was specifically forbidden that
any ISP rate-limit any service whatsoever, and then charge to un-limit it,
so likely the govt is ahead of you on this one. Perhaps an email to the
company concerned with a polite request for the same information, and an
implied threat to write some network discovery tool might net you dividends
you seek, or at least a straight answer - rare as they are.
Hi,
During some cell site work last night, I seem to have experienced
Comcast dropping packets from point A to point B simply based on the
fact that their IP protocol was GRE (IP protocol 47). I also found some
posts on the Internet that claim Comcast wishes to charge more money to
transport GRE packets. I'm not sure if this is true, or if I made a
mistake somehow in my traffic handling. Therefore...
Would someone be willing to create software instruments to measure this
claim in general? I'd like to see a transmitter and a receiver piece of
software that can run on Linux to generate and record a sweep of IP
packets carrying all possible protocol numbers (0-255). The protocol
payloads themselves don't need to be well-formatted, just the protocol
number in the IP header needs to be set. Your software will be
considered successful if it measures 100% of all protocols as available
over an unfiltered (eg: LAN) link.
The results of such a measurement would be useful in gauging the ISP
quality of any given carrier. It seems we're moving closer to Selective
Protocol Service Providers (SPSP) and away from true Internet Service
Providers (ISP) if this GRE finding turns out to be right.
--Bart
> On Mon, Apr 28, 2014 at 7:00 AM, <44net-request(a)hamradio.ucsd.edu> wrote:
>
> BTW, your emails trigger gmail's spam filter --
I'm surprised any of this weeks' postings got past the spam filter
whatsoever....
Can we get some tech content please, people? Enough of this rules and
politics crap.
