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 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 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 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 >>> 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. >>>> 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 >>>>> 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, 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 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 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 >>>>>>> If yo want to see all variations, you can be lazy (like me) and run: >>>>>>> ipcalc 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 >>>>>>> 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 >>>>>>>> to >>>>>>>> 192.168.0.4 >>>>>>>> the error I got going the other way was the connection timed out >>>>>>>> error: >>>>>>>> ssh 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 >>>>>>> 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 >>>>> >>>>> >>>>> >>>>> --------------------------------------------------- >>>>> 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 >>>> >>>> >>> >> > > > --------------------------------------------------- > 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 --------------------------------------------------- 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