Interesting network issue...or not

[Richard-Tx]

I have an interesting issue.

I have a Redhat 9 shrike machine that needs to be upgraded so I loaded the latest Fedora and Debian and both have the same issue. What happens is that the AT&T VoIP router fails to receive incoming audio packets. As a matter of fact I don't see them even on the Linux external interfaces either. HTTP traffic from the internet is fine. DNS is fine too.

Here is the configuration of the network.

internet -> pppoe -> eth2 ->linux -> eth0-> AT&T-dlink-router

I have snooped the ppp and eth0 interfaces and cannot see any UDP port 10k-11k packets coming from AT&T.

I plug the original hard drive in and reboot and everything works fine and I see bidirectional VOIP traffic.

I am building my iptables rules using fwbuilder in both cases. The policy when I test the VOIP connection says any-any-allow and the nat rule says src = internal_net translated-src = ppp0

As near as I can tell the rules and definitions are identical on the old and new system.

So, what would prevent me from seeing the port 10k UDP packets on my external facing ppp0 or eth2 interfaces?

With logging turned on i see no allows or denys for this UPD traffic that I assume is headed my direction but cannot see.

tcpdump says there are no packets coming in either.

I am missing something. What is it?

[Lazydog]

Is forwarding turned on? Run this command to check;

cat /proc/sys/net/ipv4/ip_forward

If you don't see a '1' then it's not turned on.
To turn it on run this command;

echo 1 > /proc/sys/net/ipv4/ip_forward

To set it to be turned on all the time add the following to your sysctl.conf file;

net.ipv4.ip_forward = 1

As a side note I would not use Fedora on a production system.
If you want RedHat without the tax use CentOS.

[Richard-Tx]

Yes IP forwarding is on. All the machines on the local lan are accessing the internet using a variety of protocols..

[Lazydog]

OK, what about the firewall. Is it allowing traffic through?
Can your VoIP ping the outside IP Address?

[Richard-Tx]

It can do more than just ping, it send send SIP (tcp) and recieve SIP as well as transmit audio packets (udp 10k-11k). Http and Https traffic is no problem either. This issue is localized to the the audio packets (udp 10k-11k packets) coming in. I don't see them arriving on the outside interface. I see plenty leaving but nothing coming back which causes the VOIP phone receive audio to be dead but the transmit audio to work fine.

Is there some ppp option that filters out udp packets above 10k?

If I could generate some udp packets on another machine, maybe I could troubleshoot this better.

[Richard-Tx]

I did some more troubleshooting tonight and have determined that this is a bug in a driver. Not sure if it is in the ethernet driver or the ppp driver or where it exactly is.

The bug is in debian and fedora but not redhat 9. The bug is in debian for Sparc as well.

I am going to see if I can determine where the bug is but I doubt I have the time or energy to deal with it.

The way I see it, I am going to be stuck with Redhat 9 for a while.

Time to make some new install disks.

[Lazydog]

Are both debian and Fedora completely up to date?
Have you tried CentOS?

How did you determine that the driver was the issue?
What driver is the issue?
Have you tried to update or roll back the driver?

[Richard-Tx]

The way I deduced it is a driver issue is simple. It isn't hardware and the ipchain rules are the same and I doubt the kernel is swallowing up the packets so that leaves the drivers.

I have not tried Centos and I doubt I will. If I am not mistaken CentOS is based in Debian and I know Debian has the issue. I tried loading Fedora which is Debian based and it has the issue. I tried Debian as well and that fails. Redhat 9 does not have the issue. Not sure what else there is out there.

I will not run Solaris 10 so forget that idea. I would rather run SysV Rel 3 than run Solaris 10. That is a pretty damning statement coming from a guy that has been around Unix for as long as I have. As far as I am concerned Sun has put the gun to their head and has pulled one trigger. They are ready to pull the trigger on the second barrel and finish the job.

Anyway, as to what driver is gulping packets, I have no idea. All I can do is take a SWAG. It is hard when one is in user space to peer into the kernel using tools they are unfamiliar with. Add to that the fact that I haven't looked inside a running kernel in over 15 years and you can see that I would have a rather steep learning curve. I doubt very many would appreciate my efforts anyway if I did fix it.

[Lazydog]

I hate to be the one to break it to you, but your assumptions are totally wrong when it comes to FEDORA and CENTOS.

Fedora is the test bed for Redhat. Redhat uses Fedora to test the next release of Redhat software. It usually takes them 2 to 3 releases of Fedora to iron out the bugs before it becomes the next RH release. Updates are many and version support becomes outdated very quickly. I would never use this in a production enviroment.

CentOS is a full RH release without the tax. CentOS is compiled from the SRPM's of RedHat releases. CentOS is supported as long as the sister versoin at RH is supported. Again all updates are recompiled from the RH SRPM's.

The question now is which driver do you beleive to be the problem?
Have you tried to update or rollback the driver?

I am not thinking driver as you stated that you cannot see the traffic on the outside interface which to me says the traffic isn't coming back to the box.

Can you place a device in between the ppoe and eth port on your box to see if you are seeing the traffic there?

Have you double checked your setup on the VoIP to ensure all ip addresses are corerect? How about the NAT'ing?

[Richard-Tx]

The more I keep messing with this issue the more I keep thinking something is fundamentally wrong. I am still wondering if there isn't something I am missing in the configuration. I just can't see it. It could be a bug in iptables/netfilter for all I know and has nothing to do with the OS kernel or drivers per se.

I am not prejudiced against centos. I just wish there were a way I could have some assurance that it will work.

Right now what I am going to try is a fresh load of Redhat 9, get it configured, and see if the issue is there or not. THat will tell me if the issue is configuration or not.

I really wish Linux had device drivers that you could unload and load on the fly ala Solaris. It would make troubleshooting this a bit easier.