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