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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>>
>>> 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.
>>>> <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>>
>>>>> 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, <[email protected]
<mailto:[email protected]>> 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 [email protected] <mailto:[email protected]>
>>>>>>>> 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 -
[email protected]
<mailto:[email protected]>
>>>>>>> To subscribe, unsubscribe, or to change your mail settings:
>>>>>>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------
>>>>> PLUG-discuss mailing list - [email protected]
<mailto:[email protected]>
>>>>> To subscribe, unsubscribe, or to change your mail settings:
>>>>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------
>>>>> PLUG-discuss mailing list - [email protected]
<mailto:[email protected]>
>>>>> To subscribe, unsubscribe, or to change your mail settings:
>>>>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>>>>
>>>>
>>>
>>
>
>
> ---------------------------------------------------
> PLUG-discuss mailing list - [email protected]
<mailto:[email protected]>
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
---------------------------------------------------
PLUG-discuss mailing list - [email protected]
<mailto:[email protected]>
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss
---------------------------------------------------
PLUG-discuss mailing list - [email protected]
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss
