Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I don't know, tried 255.255.252.0, 255.255.255.0. Think DHCP is made to find that though auto. My last system used RH8 with DHCP and it connected no prob. Just tried Gentoo install, it couldn't connect either.
I think this is some weird bug that lies somewhere within the BIOS or something. I read on another forum for an ASUS board w/ Nforce2 they had to edit grub to where acpi=off to get the dhcp to work. I try, no lucky. I'm tired of fn with it.
Yah, none of those nmap commands seem to be working. I get the same response for each IP address set I use:
[root@localhost matt]# nmap -sT -PT 192.168.*.*
Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
WARNING: Could not determine what interface to route packets through to 192.168.0.0, changing ping scantype to ICMP ping
only
sendto in sendpingquery returned -1 (should be 8)!
sendto: Network is unreachable
sendto in sendpingquery returned -1 (should be 8)!
sendto: Network is unreachable
The last 2 lines keep on repeating. BTW, I'm running these commands while I'm unconnected (pppoe is not running).
Westell's website not too responsive, and I'm having trouble looking at documentation on the 2100. I'll check it out later tonight to see if I can find something.
Crap! OK, you'd have to set the ip of your card to one of those subnets.
Is your firewall on? Last night I installed two servers that had firewalls, but supposedly deactivated. When I couldn't connect , I found ip tables still running. I disabled iptables and the connections worked.
This is a temporary solution! Firewall good, cracker bad.
to disable iptables:
/sbin/service iptables stop
/sbin/service network restart
If you don't get an address, resetting the router to factory defaults should turn all the goodness back on. It seems the company that installed it only wanted the "modem/gate" part, not the firewall, dhcp server, etc.
I popped up the manual at my site: http://www.swiftnetcomputers.biz/downloads
The manual is almost 5mb!
It doesn't mention how to reset the router, but it does have a reset button in back...
The router/gate looks like a decent unit, many features.
Originally posted by nvidiausr I don't know, tried 255.255.252.0, 255.255.255.0. Think DHCP is made to find that though auto. My last system used RH8 with DHCP and it connected no prob. Just tried Gentoo install, it couldn't connect either.
I think this is some weird bug that lies somewhere within the BIOS or something. I read on another forum for an ASUS board w/ Nforce2 they had to edit grub to where acpi=off to get the dhcp to work. I try, no lucky. I'm tired of fn with it.
DHCP and Nforce2: You guys can burn in hell!!!
Did you check and make sure you hadthe Plug and Play setting off/disabled in your BIOS?
swiftnet, thanks for all the persistent help! I will be sure and try those things out later on when I'm able to get network access again. Thanks to whitechedda too, I think that could definitely be the deal. Will give it a shot when I have network again.
Originally posted by nvidiausr swiftnet, thanks for all the persistent help! I will be sure and try those things out later on when I'm able to get network access again. Thanks to whitechedda too, I think that could definitely be the deal. Will give it a shot when I have network again.
Let us know what works, its always nice to be able to veryify theories.
Thanks for posting the 2100 user guide. I did manage to get it off westell web site after some time.
Before I go on, maybe you could tell me what file controls the startup of the network device eth0. I think you mentioned in one of the earlier posts that I could modify it so that eth0 doesn't hang the computer for so long when the network comes up.
OK, so I shutdown iptables (so yes, my firewall is on). I think it was set up by pppoe, because when I ran setup, it prompted me if I wanted to have a firewall, and I said yes. Next, I restarted the network, which gave me predictable output: everything went well except bring up eth0. Then, I set up the ips for the NIC:
Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
Interesting ports on (192.168.1.10):
(The 1599 ports scanned but not shown below are in state: closed)
Port State Service
111/tcp open sunrpc
6000/tcp open X11
Nmap run completed -- 65536 IP addresses (1 host up) scanned in 642 seconds
[root@localhost matt]# nmap -sT -PT 169.254.*.*
Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
Nmap run completed -- 65536 IP addresses (0 hosts up) scanned in 10783 seconds
The last nmap command using subnet 10.*.*.* was still running 9 hours later, so I killed it.
I guess I'm a bit hesitant to reset the router, because that would probably screw up my DSL connection I have set up on my win98 partition. If I reset my router and for some reason can't get my connection, all my internet connections are down. That would be bad.
So, the problem still remains that we don't know the ip of the router. I don't understand how setting the router up with a different ip (I assume Verizon has done this) address has reduced it only to a "modem/gate", eliminating all the other functionality it has built in.
I guess I could contact Verizon and ask them what ip they set the router address to. If they've pre-configured this router with a particular ip, do you think resetting it would mess up their DSL setup, and somehow wreck my connection here in my apartment?
Any other ideas for finding my router address? Thanks again.
What verizon did was disable the whole "router" side of the unit. This turned off the items that would allow the modem to work as a dhcp server, a pppOE connection and a NAT firewall. They just use the unit as a gate. This requires you to use pppOE software. A Router reset shouldn't screw anything up, but I won't tell you to do so because there is always a chance for something to go wrong (Murphy's Law).
So the router doesn't have an IP bacause Verizon turned it off!
If you assign your adapter an address manually, with no route, does the roaring penguin software still allow you to connect?
If not, assign a route to the ip of your card.
does the roaring penguin software work?
If yes, then we have an easy fix, if not we'll have to edit the timeout period.
I was able to connect with roaring penguin. Not only that, but now redhat's Network Device Control GUI recognizes the adapter as active. So, I guess all I need to do is make these changes permanent. Probably some eth0 configuration file somewhere. Problem is, I have no clue where that is.
Playing around with RH Network Device Control(NDC), I notice that I can configure a network interface, give it an address, subnet mask, and gateway. I guess these would correspond to (in the same order) to the ip addresses I used in the ifconfig command. After configuring the eth0 network interface in RH NDC, I ran the command to restart the network. Unfortunately, eth0 still fails. This is what I get:
[root@localhost matt]# /sbin/service network restart
Shutting down interface eth0: [ OK ]
Shutting down loopback interface: [ OK ]
Setting network parameters: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface eth0:
Determining IP information for eth0... failed.
[FAILED]
Some signs of progress though. Whereas before it was failing in it's attempt to bring up interface eth0, now it's failing to determine its IP info. Is this because it can't talk to the router?
You are correct about hte "NDC" doing the same thing as ifconfig <parameters>.
I'm kinda stuck as to why the "NDC" didn't save the settings..... I don't use redhat : (
I do know that an address can be assigned by entering the ifconfig <parameters> in the rc.local file
which is located at /etc/rc.d/rc.local
After you restart the network, does NDC still show the correct ip (the one you assigned)?
I wish I had RH to be of more help, you are soooo close!!!!!
It's weird because NDC did remember my settings. They are there when I open up NDC again and look at the settings for eth0. It must not be saving them in a place that the network restart command is aware of. And now (while I'm connected running roaring penguin), when I do an ifconfig, the ip settings for eth0 are gone?? So, NDC knows where the eth0 IP settings are, but the network restart service and ifconfig don't.
Anyway, I've looked at a how-to-connect file (http://www.roaringpenguin.com/pppoe/how-to-connect.txt) for roaring penguin, and it says not to assign and IP address to the ethernet card, so I'm going to go that way. It also says not to configure the card to come up at boot time. For some reason, when I installed my ethernet card, it got configured to come up at boot time.
So now my question is, what file do I edit to make it so that my ethernet card does not come up at boot time. Once I got that, I should be set. If you remember way back to the first post, we're now back to my original question :-) Thanks.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.