pages if you do a search. I have included one of those links for your
convenience. Your provided modem/router (router 1) uses either DSL or
Cable for its WAN/Internet port. I would heavily suggest against you
making any changes to router 1. SOHO routers typically have a cluster of
ports which can be lumped together under the title LAN. Most SOHO
> there is my problem..... I can't get into the settings page of the
> extra router. hmmmm. I tried lynx from the computer w/o (one of the
> computers connected to it) the gui and now it is asking for login
> credentials.... I wonder what they are? found it! Okay... well lynx is
> useless with this!
>
> Goofy me..... I can use my brother's computer (which is connected to
> the router in question). There is a setting for DHCP Server.... I'll
> disable that!
> As for setting it to bridge mode...
> I think there is one setting it might be: a choice in the operating
> mode between "Gateway" and "Router"
>
> Thanks for letting me know about the LAN ports.
>
> :-)~MIKE~(-:
>
>
> On Sun, Jul 20, 2014 at 6:47 PM, sean <sean.a.ritzler@gmail.com
> <mailto:sean.a.ritzler@gmail.com>> wrote:
>
> You don't have to change the firmware. Just make your extra wireless
> device a wireless bridge + ethernet switch without DHCP. Problem
> solved. By the way, those 4 ports ARE the LAN ports.
>
> On Sun, Jul 20, 2014 at 6:44 PM, Michael Havens <bmike1@gmail.com
> <mailto:bmike1@gmail.com>> wrote:
> > cool.... apparently if I do the firmware upgrade I'll be able to
> receive as
> > well as send.
> >
> > :-)~MIKE~(-:
> >
> >
> > On Sun, Jul 20, 2014 at 6:17 PM, Michael Havens
> <bmike1@gmail.com <mailto:bmike1@gmail.com>> wrote:
> >>
> >> I think I should give you the models of my devices:
> >> the router is a wrt54g and the modem is a pk5000. I did a
> little more
> >> searching and read that I can change the firmware on the router
> but if
> >> memory is correct if I screw up it becomes a brick so I need to
> ask what the
> >> benefits are and if there is another way to do it. I just
> looked closely at
> >> the router and it is labled as a wireless router and a 4 port
> switch.
> >>
> >> :-)~MIKE~(-:
> >>
> >>
> >> On Sat, Jul 19, 2014 at 11:39 AM, Michael Havens
> <bmike1@gmail.com <mailto:bmike1@gmail.com>> wrote:
> >>>
> >>> >Why were rules written for the second router but not the first?
> >>> >Is it because it was connected first? Could we write the
> rules we need?
> >>>
> >>> What I meant was the second was connected to the first.
> >>>
> >>>
> >>> :-)~MIKE~(-:
> >>>
> >>>
> >>> On Sat, Jul 19, 2014 at 11:31 AM, Michael Havens
> <bmike1@gmail.com <mailto:bmike1@gmail.com>>
> >>> wrote:
> >>>>
> >>>> > Going the other way, you have no rules to pass
> >>>> > the communication through.
> >>>>
> >>>> Why were rules written for the second router but not the
> first? Is it
> >>>> because it was connected first? Could we write the rules we need?
> >>>>
> >>>>
> >>>> :-)~MIKE~(-:
> >>>>
> >>>>
> >>>> On Fri, Jul 18, 2014 at 3:34 PM, Gilbert T. Gutierrez, Jr.
> >>>> <mailing-lists@phoenixinternet.net
> <mailto:mailing-lists@phoenixinternet.net>> wrote:
> >>>>>
> >>>>> NAT is the reason. The ping is being translated from one
> network to
> >>>>> another as well as telnet. Going the other way, you have no
> rules to pass
> >>>>> the communication through.
> >>>>>
> >>>>> Gilbert
> >>>>>
> >>>>>
> >>>>> On 7/18/2014 2:44 PM, Michael Havens wrote:
> >>>>>
> >>>>> so according to your tutorial 192.168.0.x is not on the same
> subnet as
> >>>>> 192.168.1.x. If that is correct why can I ssh (and ping and
> telnet....) from
> >>>>> client to host but not host to client?
> >>>>>
> >>>>> :-)~MIKE~(-:
> >>>>>
> >>>>>
> >>>>> On Fri, Jul 18, 2014 at 12:30 PM, Michael Havens
> <bmike1@gmail.com <mailto:bmike1@gmail.com>>
> >>>>> wrote:
> >>>>>>
> >>>>>> telnet localhost 22 from the server received no answer from
> the client
> >>>>>> telnet 192.168.1.101 22 from the client received no answer
> from the
> >>>>>> server
> >>>>>>
> >>>>>> I'll get back to you about the research project
> >>>>>> (and as a private message)
> >>>>>>
> >>>>>> :-)~MIKE~(-:
> >>>>>>
> >>>>>>
> >>>>>> On Fri, Jul 18, 2014 at 6:41 AM, <kitepilot@kitepilot.com
> <mailto:kitepilot@kitepilot.com>> wrote:
> >>>>>>>
> >>>>>>> Hello Michael:
> >>>>>>> the 'Net' is a hodgepodge of protocols, all abiding to the
> 'OSI Layer
> >>>>>>> Model' to work properly
> (http://en.wikipedia.org/wiki/OSI_model).
> >>>>>>> Troubleshooting your SSH connection should be a fairly simple
> >>>>>>> proposition, because there are only so many moving parts
> (Three!).
> >>>>>>> As anything under the OSI model, nothing on an upper layer
> will work
> >>>>>>> unless the necessary components of the lower layer are
> working.
> >>>>>>> AND you *HAVE* to troubleshoot each layer separately.
> >>>>>>> So how does this go?
> >>>>>>> Well, lets take a look at your SSH problem...
> >>>>>>> 1.- In order for the SSH connection to work you need 3 things:
> >>>>>>> 1.1.- a SSH server,
> >>>>>>> 1.2.- a SSH client and,
> >>>>>>> 1.3.- a TCP/IP connection.
> >>>>>>> *EACH* one of the lines above is a separate project and
> *HAS* to be
> >>>>>>> addressed as such.
> >>>>>>> Lets cover the basics first, the TCP/IP connection:
> >>>>>>> You *HAVE* to *KNOW* The Mantra:
> >>>>>>> "In order for any 2 devices to establish a TCP connection
> they have
> >>>>>>> to share a physical link and they need addresses in the
> same subnet".
> >>>>>>> The statement above is a pretty dense one, and has several
> >>>>>>> implications, number one being: What does "subnet" mean?
> >>>>>>> Another is: what about IPs in different subnets?
> >>>>>>> We'll get there...
> >>>>>>> As there are already several books written (and to be
> written) about
> >>>>>>> the few lines above, I'll water it down to the bare minimum:
> >>>>>>> The subnet is defined via the netmask, and implies that
> "ON" parts of
> >>>>>>> the netmask are always equal in all the addresses on a
> network segment, so:
> >>>>>>> Network:
> >>>>>>> 192.168.0.0/24 <http://192.168.0.0/24> or
> >>>>>>> 192.168.0.0 with netmask 255.255.255.0 means that
> >>>>>>> *ALL* the addresses in *THIS* network are going to look like
> >>>>>>> 192.168.0.${SOMETHING_ELSE}
> >>>>>>> '192.168.0' is the "Network", and "${SOMETHING_ELSE}" is
> the "Host".
> >>>>>>> You can not use "Host 0" (because that defines the
> network) and you
> >>>>>>> can not use the highest number (255) because that's the
> 'broadcast address'.
> >>>>>>> Which means that any '/24" (slash 24) network can address 254
> >>>>>>> 'hosts'.
> >>>>>>> Network:
> >>>>>>> 192.168.0.0/16 <http://192.168.0.0/16> or
> >>>>>>> 192.168.0.0 with netmask 255.255.0.0 means that
> >>>>>>> *ALL* the addresses in *THIS* network are going to look like
> >>>>>>> 192.168.${SOMETHING_ELSE}.${SOMETHING_ELSE}
> >>>>>>> '192.168' is the "Network", and
> "${SOMETHING_ELSE}.${SOMETHING_ELSE}"
> >>>>>>> is the "Host".
> >>>>>>> You can not use "Host 0.0" (because that defines the
> network) and you
> >>>>>>> can not use the highest number (255.255) because that's
> the 'broadcast
> >>>>>>> address'.
> >>>>>>> Which means that any '/16" (slash 16) network can address
> 65534
> >>>>>>> 'hosts'.
> >>>>>>> The reason why '255' is the highest number is because IPv4
> addresses
> >>>>>>> (and netmasks) are represented in memory in 4 bytes, each
> number one byte.
> >>>>>>> Bytes are 8 bits, but that's a different book that you
> need to read
> >>>>>>> too, lets move on with the network.
> >>>>>>> Things get pretty interesting (and math pretty convoluted)
> when you
> >>>>>>> define networks like 192.168.127.0/25
> <http://192.168.127.0/25>
> >>>>>>> If yo want to see all variations, you can be lazy (like
> me) and run:
> >>>>>>> ipcalc 192.168.0.127/25 <http://192.168.0.127/25>
> >>>>>>> Finally, "Netmasks" are a patch to the first defined (and
> >>>>>>> shortsighted) 'Address Type' as class A,B,C or D, but I'll
> let you research
> >>>>>>> that yourself.
> >>>>>>>
> >>>>>>> Well, that's all good, but how do you talk to other
> addresses?, I
> >>>>>>> talk to google.com...
> >>>>>>> That's a valid question, but
> >>>>>>> 1.- it is not part of *THIS* SSH problem and
> >>>>>>> 2.- you don't 'talk to google'.
> >>>>>>> We'll talk more about how devices find each other in a
> network down
> >>>>>>> below, but in order to talk to devices outside your
> network you need the
> >>>>>>> 'Routing Protocol' (implemented at [SURPRISE!] 'the
> router') which is
> >>>>>>> nothing else than a table of rules stating 'this IP goes
> that way'. In your
> >>>>>>> case, all addresses go the same place (the router) so the
> router becomes the
> >>>>>>> 'Default Gateway'. As to resolve google, you need the
> DNS, but you knew
> >>>>>>> that... :)
> >>>>>>>
> >>>>>>> Now that we know what an IP address is, lets move on to
> the "Physical
> >>>>>>> Link".
> >>>>>>> Well, a cable will do...
> >>>>>>> In the wireless world, the "Association" is the link.
> >>>>>>> And how do you validate that?
> >>>>>>> iwconfig will tell you what (if anything) you are
> associated to. No
> >>>>>>> association, no link, no connection, no SSH.
> >>>>>>> ifconfig will tell you what (if anything) you are wired
> to. No wire,
> >>>>>>> no link, no connection, no SSH.
> >>>>>>> Ain't that simple? ;-)
> >>>>>>> So we have a link...
> >>>>>>> And we have IP addresses in the same subnet.
> >>>>>>> So we are connected!!! 8-)
> >>>>>>> Not so fast Armando!!!
> >>>>>>> The fact that your addresses match is not necessarily a
> validation,
> >>>>>>> because each computer may be connected to a different
> router providing the
> >>>>>>> same NAT(ed) address!
> >>>>>>> NAT?
> >>>>>>> Yes NAT (Network Address Translation protocol), but that's yet
> >>>>>>> another book, so lets water it down:
> >>>>>>> NAT is the protocol that allows you to have an 'outside
> visible
> >>>>>>> address' and an 'inside invisible network' in a router.
> >>>>>>> NAT (as Netmask) was implemented mainly to alleviate the IPv4
> >>>>>>> shortage address because of the 'class A,B,C or D'
> mistake, but as a
> >>>>>>> byproduct, you can 'hide' behind it, which provides some
> level of security.
> >>>>>>> How you hide is yet another bookshelf and essentially
> means that you cannot
> >>>>>>> access devices 'behind the router' unless the device
> initiates the
> >>>>>>> connection first, and that's how you raise a WEB site from
> 'behind the
> >>>>>>> router' and why you can SSH from 'inside to outside the
> router' but not the
> >>>>>>> other way around, so lets move on...
> >>>>>>> So, how do we know that we are connected to the same router?
> >>>>>>> Ah, glad you asked:
> >>>>>>> ARP!
> >>>>>>> Or Address Resolution Protocol.
> >>>>>>> *ALL* data transmission is done at OSI layer 2.
> >>>>>>> Quick implementation manual:
> >>>>>>> OSI layer 1: Cable or association.
> >>>>>>> OSI layer 2: MAC address.
> >>>>>>> OSI layer 3: IP address.
> >>>>>>> Your network doesn't know (and doesn't care) about IP
> addresses. The
> >>>>>>> IP address is there to resolve the MAC address.
> >>>>>>> When you say:
> >>>>>>> ping 192.168.0.1
> >>>>>>> that generates a 'who has' request from the ARP protocol.
> >>>>>>> That request is broadcasted to anyone on the physical link
> (OSI layer
> >>>>>>> 1)
> >>>>>>> The device with the IP address interrogated by 'who has'
> answers with
> >>>>>>> its MAC address.
> >>>>>>> This IP/MAC address pair is then saved to the ARP table.
> >>>>>>> >From there on (and even though the IP address goes along
> in the
> >>>>>>> TCP/IP header) all transmissions are sent to the MAC address.
> >>>>>>> But then again, how do you know that your 2 boxes are
> talking to the
> >>>>>>> same router?
> >>>>>>> arp -n|grep 192.168.1.1
> >>>>>>> Same MAC?
> >>>>>>> Same box.
> >>>>>>> Different MAC?
> >>>>>>> Same Michael... ;-)
> >>>>>>> What do we know so far?
> >>>>>>> Well, we know something about line 3 of the very first
> paragraph.
> >>>>>>> What about line 2?
> >>>>>>> Type
> >>>>>>> which ssh
> >>>>>>> You have it or not, and you know what to do, so lets move
> to line 1.
> >>>>>>> We now need to troubleshoot the SSH server.
> >>>>>>> Well, that boils down to 2 things, it is working or not...
> >>>>>>> You *KNOW* that the SSH server is 'listening' (although not
> >>>>>>> necessarily working) when you can connect to the 'port'
> >>>>>>> Port?
> >>>>>>> Yeah, port...
> >>>>>>> Lets move on up in the OSI model to the application layer.
> >>>>>>> In order to establish a TCP connection you need an IP
> connection and
> >>>>>>> a port (or a socket and a port)
> >>>>>>> The port is to the application what the IP address is to
> the MAC.
> >>>>>>> So if the port is listening, the application is awake.
> >>>>>>> And how do we know?
> >>>>>>> There are only 975143684 possible ways to validate a 'port
> is open'
> >>>>>>> (or listening) but I am a simple boring guy, so I do:
> >>>>>>> telnet localhost 22
> >>>>>>> I either get an answer or not.
> >>>>>>> If I get an answer, then we are most likely all good, but
> if I don't
> >>>>>>> get an answer then the ramifications are staggering and
> I'm not even going
> >>>>>>> to think about it.
> >>>>>>> In order to check that the other port listens then you:
> >>>>>>> telnet ${REMOTE} 22
> >>>>>>> Again, we either get an answer or not. And the 'not'
> means another
> >>>>>>> Sunday drive to the library...
> >>>>>>> Finally, why 22?
> >>>>>>> Because that's the SSH port and it is defined in the
> configuration
> >>>>>>> file, which you can change to further complicate your (or
> someone else's)
> >>>>>>> life.
> >>>>>>> But who and where defined 22 as the SSH port?
> >>>>>>> grep -i ssh /etc/services
> >>>>>>> And who wrote /etc/services?
> >>>>>>> http://www.iana.org/
> >>>>>>> And how do I know all this crap?
> >>>>>>> Because I finished LFS!!!! ;-)
> >>>>>>> I hope you see everything now as clear as mud.
> >>>>>>> Keep this message handy, you'll need to read it several
> times...
> >>>>>>> Keep in mind that what I have written here is a GROSS
> >>>>>>> oversimplification of several bookshelves contained in
> several buildings and
> >>>>>>> written along several decades all over the World, it's
> free advice, you
> >>>>>>> can't sue me... :)
> >>>>>>> And always remember:
> >>>>>>> For every question there exists a simple, direct and wrong
> answer.
> >>>>>>> if you have any question,
> >>>>>>> you will get any answer...
> >>>>>>> ET
> >>>>>>> PS: Research project:
> >>>>>>> Why doesn't 'ping' use a port?
> >>>>>>> Why is 'ping' 'setuid(ed)'
> >>>>>>> What are 'routable' networks?
> >>>>>>> What are 'non-routable' networks?
> >>>>>>> What does it mean if you get and IP address like
> 169.254.0.0/16 <http://169.254.0.0/16>
> >>>>>>> Why do you always have a 127.0.0.1 address in your boxes?
> >>>>>>> Who defines (and where are the documents that define) all
> these
> >>>>>>> protocols? (RFC anyone?)
> >>>>>>>
> >>>>>>>
> >>>>>>> Michael Havens writes:
> >>>>>>>>
> >>>>>>>> okay, so I bought a used computer to do Linux from
> scratch on. Well,
> >>>>>>>> I'm
> >>>>>>>> going to ssh from my primary computer to the new computer
> but got a
> >>>>>>>> 'Connection timed out' error. After googling for a bit I
> discovered
> >>>>>>>> ufw was
> >>>>>>>> to blame.
> >>>>>>>> after I disabled the firewall I could ssh from 192.168.1.101
> >>>>>>>> <parasite> to
> >>>>>>>> 192.168.0.4 <host>
> >>>>>>>> the error I got going the other way was the connection
> timed out
> >>>>>>>> error:
> >>>>>>>> ssh mike@192.168.1.101 <mailto:mike@192.168.1.101>
> >>>>>>>> ssh: connect to host 192.168.1.101 port 22: Connection
> timed out
> >>>>>>>> After googling some more I thought perhaps openssh-server
> wasn't
> >>>>>>>> installed... but it is. So please.... what is the
> problem? I verifed
> >>>>>>>> openssh-client is installed but I don't know what it
> could be. Could
> >>>>>>>> you
> >>>>>>>> help me out?
> >>>>>>>> :-)~MIKE~(-:
> >>>>>>>
> >>>>>>> ---------------------------------------------------
> >>>>>>> PLUG-discuss mailing list -
> PLUG-discuss@lists.phxlinux.org
> <mailto:PLUG-discuss@lists.phxlinux.org>
> >>>>>>> To subscribe, unsubscribe, or to change your mail settings:
> >>>>>>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> ---------------------------------------------------
> >>>>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
> <mailto:PLUG-discuss@lists.phxlinux.org>
> >>>>> To subscribe, unsubscribe, or to change your mail settings:
> >>>>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
> >>>>>
> >>>>>
> >>>>>
> >>>>> ---------------------------------------------------
> >>>>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
> <mailto:PLUG-discuss@lists.phxlinux.org>
> >>>>> To subscribe, unsubscribe, or to change your mail settings:
> >>>>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
> >>>>
> >>>>
> >>>
> >>
> >
> >
> > ---------------------------------------------------
> > PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
> <mailto:PLUG-discuss@lists.phxlinux.org>
> > To subscribe, unsubscribe, or to change your mail settings:
> > http://lists.phxlinux.org/mailman/listinfo/plug-discuss
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
> <mailto:PLUG-discuss@lists.phxlinux.org>
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>
>
>
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
(text/plain)