# routing table broken. [not-quite-solved]

## pappy_mcfae

The routing table on my old Toshiba has somehow broken itself. The only thing I have changed recently is an upgrade to baselayout-2/openrc. I avoided many of the pitfalls associated with this upgrade as I did it with the migration document open on another machine. The only thing I missed is re-writing my /etc/hosts file.

After the upgrade, I noticed that the network wasn't connecting properly. I finally got the wireless to work just in time to notice that my routing was all messed up.

Here is the result of route on the afflicted machine:

```
en_tosh ~ # route

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

192.168.0.0     *               255.255.255.0   U     0      0        0 eth0

loopback        localhost       255.0.0.0       UG    0      0        0 lo

default         192.168.0.1     0.0.0.0         UG    3      0        0 eth0

```

Here is the result of route on a working machine:

```
pappy-lap ~ # route

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

192.168.0.0     *               255.255.255.0   U     0      0        0 eth0

loopback        *               255.0.0.0       U     0      0        0 lo

default         192.168.0.1     0.0.0.0         UG    0      0        0 eth0

```

Also, though the computer's network setup is configured thusly:

```
# OpenRC/baselayout-2

modules="iproute2"

modules="wpa_supplicant"

wpa_supplicant_eth0="-Dwext"

config_eth0=( "192.168.0.115 netmask 255.255.255.0 brd 192.168.0.255" )

routes_eth0=( "default via 192.168.0.1" )

```

the IP address winds up being 192.168.0.102, and the default gateway becomes 127.0.0.1. To say the least, this makes for an unstable network. Also note that the presence of the 'modules="iproute2"' line makes no difference whatsoever. 

What can I do to fix the routing table? Where is the file physically located so I can edit it directly (if at all possible)? Any help will be greatly appreciated.

Thanks in advance for your time and consideration.

Blessed be!

Pappy

----------

## DarKRaveR

You can manipulate the routing table via 'route' or 'ip route'.

The routing table is usually in kernel, not a file. The two route outputs you posted are identical in their meaning - Where does the 127.0.0.1 show up?

I don't see anything being wrong in the routing table of the machine having problems.

----------

## krinn

 *pappy_mcfae wrote:*   

>  
> 
> ```
> 
> config_eth0=( "192.168.0.115 netmask 255.255.255.0 brd 192.168.0.255" )
> ...

 

 :Sad:  reread the baselayout upgrade guide

config_eth0= ( ".... <---- old bash style

config_eth0= " ..... <-----new config style

as simple as removing the ( and things might get correct again

----------

## pappy_mcfae

On the good side of things, I did get the routing tables fixed, at least temporarily. The even better news is 2.6.25-gentoo-r1 supports ndiswrapper without whining. Oh happy day!

The bad news is my wireless setup remains screwed. I tried removing the parentheses, but it made no difference. The wireless network will not set itself for the operation I desire (static IP address 192.168.0.115, default routing through 192.168.0.1). It will give me an IP address of 192.168.0.102. In the process, it also rewrites /etc/resolv.conf. That means that somehow, dhcpcd is asserting itself and setting up a dynamic IP address; something I am directly telling it not to do.

Anyway, changing the /etc/conf.d/net file to

```
modules="iproute2"

modules="wpa_supplicant"

wpa_supplicant_eth0="-Dwext"

config_eth0="192.168.0.115 netmask 255.255.255.0 brd 192.168.0.255"

routes_eth0="default via 192.168.0.1"
```

does absolutely nothing to change the way the wireless network functions. That was the first thing I tried.

Thanks for the suggestion, though.

Blessed be!

Pappy

----------

## pappy_mcfae

Um, I figured out what was wrong. It works if I tell it the right interface to use, to whit:

```
# OpenRC/baselayout-2

modules="iproute2"

modules="wpa_supplicant"

wpa_supplicant_wlan0="-Dwext"

config_wlan0="192.168.0.115 netmask 255.255.255.0 brd 192.168.0.255"

routes_wlan0="default via 192.168.0.1"
```

Well, wasn't that a refreshing, unique way to come up with egg on one's face.   :Embarassed: 

hehehe.

Thanks to all who offered their suggestions!

Blessed be!

Pappy

----------

## depontius

 *krinn wrote:*   

> 
> 
> config_eth0= ( ".... <---- old bash style
> 
> config_eth0= " ..... <-----new config style
> ...

 

Fine for that, but how do I designate a static route, along with the default route?

```
routes_eth0=( "192.168.VPN.0/24 via 192.168.LAN.ROUTER"

              "default via 192.168.LAN.ENDPOINT" )

```

----------

## pappy_mcfae

I have decided that things aren't quite as solved as I hoped. When using ndiswrapper with 2.6.25-gentoo-r1 kernel, sometimes the kernel routing tables start improperly, as below:

```
pappy-lap ~ # route

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

loopback        *               255.0.0.0       U     0      0        0 lo

pappy-lap ~ # route -n

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo

```

When this happens, I can't reach the internet, or the machines on my home LAN.

Curiously, sometimes, things start our just fine. The network operates properly, comes up properly, and is as stable as ndiswrapper running on a .22 family kernel. When that happens, the routing table reads thusly:

```
pappy-lap ~ # route

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

192.168.0.0     *               255.255.255.0   U     0      0        0 eth0

loopback        *               255.0.0.0       U     0      0        0 lo

default         192.168.0.1     0.0.0.0         UG    2000   0        0 eth0

pappy-lap ~ # route -n

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo

0.0.0.0         192.168.0.1     0.0.0.0         UG    2000   0        0 eth0
```

Also note that when the routing tables are wrong, and I try to change the settings using the ip route command, I get a reply that the network is unreachable...that is until the routing tables fix themselves, then everything works properly. 

Eventually, the network somehow decides that it wants to work, and the wireless interface comes up, as if there was not a problem in the first place. The connection becomes solid and stable.

The first thing I want to know is can I force the correct routing table without getting a network unreachable error? Secondly, is there a kernel setting that can be tweaked to get this to stop happening? 

While I applaud the kernel gods for finally putting decent, stable support for ndiswrapper *back* into the kernel, I would still like it to operate as consistently and flawlessly as the .22 kernel family makes ndiswrapper operate.

Blessed be!

Pappy

----------

## Genewb

 *pappy_mcfae wrote:*   

> Um, I figured out what was wrong. It works if I tell it the right interface to use, to whit:
> 
> ```
> # OpenRC/baselayout-2
> 
> ...

 

Hm, I (seem to) have the same problem, as of installing OpenRC 0.2.3.  I already had the interface specified.

Typing from a Windows machine (groan):

```
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

192.168.0.0     *               255.255.255.0   U     0      0        0 eth1

loopback        localhost       255.0.0.0       UG    0      0        0 lo

default         192.168.0.1     0.0.0.0         UG   2      0        0 eth1 

```

I'm pretty sure localhost and UG weren't on the second line before, though I don't really understand routing tables.

config:

```

config_eth1="192.168.0.2/24 brd 192.168.0.255"

routes_eth1="default via 192.168.0.1"

gateways_eth1="192.168.0.1"

```

I guess I should find iproute2 and try that in place of ifconfig ... but that'd mean finding the tarball, moving this computer from the wall, finding a USB stick, copying it, taking it to the Gentoo computer, putting it in distfiles, digesting.... Is iproute2 mandatory now?

----------

## pappy_mcfae

I was told about the move to baselayout2-openrc a few months before it hit. I was told at that time it might be a wise idea to go with iproute2. At the time, I did it more to be able to "fix" a bug involving the b43 wireless module in the .24 kernel family. Installing iproute2 was the only way I could get that interface to even come close to being cooperative. In the end, I abandoned that idea because the b43 was a complete POS, in my opinion. However, I kept iproute2 just because from the looks of it, that package had a lot more goodies and doo-dads to make working with the network a little more precise.

As to the problem described here, I did make a bug report. Here's hoping it goes somewhere.

Blessed be!

Pappy

----------

## Genewb

 *pappy_mcfae wrote:*   

> I was told about the move to baselayout2-openrc a few months before it hit. I was told at that time it might be a wise idea to go with iproute2. At the time, I did it more to be able to "fix" a bug involving the b43 wireless module in the .24 kernel family. Installing iproute2 was the only way I could get that interface to even come close to being cooperative. In the end, I abandoned that idea because the b43 was a complete POS, in my opinion. However, I kept iproute2 just because from the looks of it, that package had a lot more goodies and doo-dads to make working with the network a little more precise.
> 
> As to the problem described here, I did make a bug report. Here's hoping it goes somewhere.
> 
> Blessed be!
> ...

 

Looking back through the thread, it seems you got your routing table fixed before you specified the interface and thereby got your wlan working. Might I ask how you did so?

----------

## pappy_mcfae

At the time, I was upgrading to baselayout-2/openrc. I was also trying out the 2.6.25-gentoo-r1 kernel, AND trying to fix my automatic network script. My computers multi-task better than I, unfortunately.

The purpose of that script is to make sure that whether the computer boots with the wireless PCMCIA card, or the Tulip knock-off PCMCIA, the computer will automatically set up the proper network setup, and then set a static IP address to whichever interface comes up. Before baselayout-2, I could rename an interface in my /etc/conf.d/net file. After the upgrade, I still can rename the interface, but I have to rename it using local.start, and it has to be done after the interface is up, not before.

The problem I was having was that I had renamed wlan0 to eth0 in udev, but I was still invoking it as wlan0 in the wireless part of the network script. Long story short, the wireless interface wasn't being properly initialized. What I did to cure that was to change the interface name from wlan0 to eth0 in the script. Then, as if by magic, the wireless adapter worked properly...or so I thought.

Unfortunately as my tests today have shown, sometimes the 2.6.25-gentoo-r1 kernel starts the wireless adapter perfectly. It's ready to go as soon as I get done logging in. Other times, it takes somewhere around three minutes for the interface to come fully up. Other times, even when trying to cajole it into working, it simply will not come up. Talk about THE definition of intermittent! 

So, distilling all that, the truth is I fixed one mistake, but I still have the bug in place. I'm still looking for a cure for the routing table problem, which is the thing that makes the interface work...or not. On that point, I'm still at a loss. 

The good news is that once ndiswrapper starts with2.6.25-gentoo-r1, it is as rock solid as it is under the .22 family. The wireless interface on my test laptop is still up and running after ten and a half hours. That's worlds better than I could get out of the .23 or .24 kernel families...so at least we're heading in the right direction.

Hope that explains it.

Blessed be!

Pappy

----------

## soletan

 *depontius wrote:*   

>  *krinn wrote:*   
> 
> config_eth0= ( ".... <---- old bash style
> 
> config_eth0= " ..... <-----new config style
> ...

 

Man, this upgrade got my remote server screwed up completely ... instead of doing another SW update and simply rebooting into probably bug fixed kernel, my server didn't come back to the net at all. Fine, Gentoo! That was a good job. Providing stuff like "hardened profile" on one side, and doing such heavy changes without separate prompt demanding me to enter "Yes I want to change my bootup scripts' style completely" prior to emerging openrc.

Nevertheless, maybe you - depontius - haven't got solution for providing routes_eth0 accordingly in openrc, here is how I did it successfully. Turn your code into:

```
routes_eth0="192.168.VPN.0/24 via 192.168.LAN.ROUTER

default via 192.168.LAN.ENDPOINT"

```

Add a newline, then append another rule before closing quotes. This was found in net.example available in openRC source tarball.

----------

## depontius

Thanks for the example - I'd kind of gotten the impression that that was what I was going to need to do.

I think I'm going to wait until baselayout-2 actually goes stable before the upgrade.  I may try one machine early - maybe.

----------

## Dagger

pappy_mcfae it seems your network is _backgrounded_ and until the connection is set up your routing table gives you an error or network unreachable (because at that time there is NO connection). That also explains why sometimes your routing table works fine (connection came up fast - maybe even before all other services finished loading) and sometimes it takes minutes to set it up (it's retrying until it succeeds).

----------

## pappy_mcfae

 *Dagger wrote:*   

> pappy_mcfae it seems your network is _backgrounded_ and until the connection is set up your routing table gives you an error or network unreachable (because at that time there is NO connection). That also explains why sometimes your routing table works fine (connection came up fast - maybe even before all other services finished loading) and sometimes it takes minutes to set it up (it's retrying until it succeeds).

 

That would seem to beg the question, how does one stop that from happening? 

It is rather clear at this point that the .22 kernels are out of development. Sad, really. Therefore, I need an alternative that works. The .25 kernels are almost there, but not all the way. At one point, ndiswrapper worked perfectly, and was properly supported. Why is it suddenly so difficult to reach that level of functionality again?

All the political BS aside, if the Linux community wants to maintain users, they need to MAINTAIN THEIR USERS! Capriciously disabling code, then bringing it back in a somewhat diminished form later shows a lack of concern about Linux users, most specifically wireless users.

I digress...

So, if there is a way to stop this from happening, I'm all eyes. All I'm asking for is what I had before, stable, reliable, FAST wireless connections. I don't think that's too much to ask.

Blessed be!

Pappy

----------

## Dagger

1st of all... it has NOTHING to do with the kernel  :Smile: 

It's all about your RC configuration. I would suggest asking how to disable wireless network backgrounding during the startup in your bug. Alternatively you ask send an email to roy (openrc creator) and he will be happy to provide you with all the answers you need (check my reply to your bug - you can find the roy's website and contact details there).

I'm pretty sure I already saw the answer to this question somewhere... just can't remember where.

----------

## pappy_mcfae

 *Dagger wrote:*   

> 1st of all... it has NOTHING to do with the kernel 

 Yes, it does. This problem of the wireless not being up, and the routing table not being there after a full boot cycle IS a result of the kernel.  With the .22 kernel and ndiswrapper, this isn't a problem. With the .25 kernel, it is.  

Ndiswrapper is caught up in a bit of controversy. Just look at this article, and this one. After reading these articles, I find it hard to believe that the kernel developers are, in any way, feeling warm and fuzzy over ndiswrapper.

 *Quote:*   

> It's all about your RC configuration. I would suggest asking how to disable wireless network backgrounding during the startup in your bug. Alternatively you ask send an email to roy (openrc creator) and he will be happy to provide you with all the answers you need (check my reply to your bug - you can find the roy's website and contact details there).
> 
> I'm pretty sure I already saw the answer to this question somewhere... just can't remember where.

 

I'd believe this if the .22 kernels didn't work properly with the same RC setup. Since support for ndiswrapper was unceremoniously and secretly ripped from the kernel without prior warning, am I now supposed to believe that the powers that be (one of them being Linus himself) have gotten over their purist attitudes? 

I don't buy it...but that is beside the point.

The point remains that for some reason, ndiswrapper doesn't want to work as quickly under the .25 kernel as it does under the .22. As far as I can see, that is a kernel problem. If I knew enough about how the kernel is made, I'd put the .22 code back into the .25, so I could get ndiswrapper stability back. Alas, I know nothing about C.

Bummer.

Blessed be!

Pappy

----------

