Skip to contentSkip to conversation

Problem: ISA card & iptables (2.4.26) - disappearing packets

DISCUSSION adderek 3 participants 9 messages Jul 17, 2004 – Jul 19, 2004

lore
Share & tools
lore

adderek

author
#0 lore raw

1. introduction (you can bypass this part).

I had already configured firewall/router (based on debian distribution is has only a few things in common with debian).

But I wanted to change it to gentoo. And to put an ISA card into my PC.

At first I've configured everything with my old PCI cards. After everything worked fine I've changed eth0 to ISA card.

2. some basis

After changing my PCI card to ISA card firewall gone down :(

I'm using same script to run my firewall/router.
I have modules 'ne' and 'ne2k-pci' compiled as modules into kernel. There are 8139too module, too (for my eth2 interface). It looks like this:

               +------------------------+
               |   FIREWALL / ROUTER    |
               |                        |
               | eth0 (ISA or PCI, BNC) = <--> LAN 2 (BNC) (10.0.0.1)
               |                        |
               | eth1 (PCI, RJ)         = <--> LAN 1 (RJ)  (10.0.1.1)
               |                        |
internet  <--> = eth2 (PCI, RJ)         |
               |                        |
               +------------------------+

In my script there is no MAC rules. I'm doing something like this:
iptables -t filter -P FORWARD ACCEPT
iptables -t filter -P INPUT ACCEPT
iptables -t filter -P OUTPUT ACCEPT
echo "1" > /proc/sys/net/ip_forward
iptables -t nat -A POSTROUTING -o eth2 -j SNAT --to $my_IP
After rebooting my system "LAN 1" is connected to the internet, but the problem is with "LAN 2".
I'll describe two situation:

(a) When network card NE2000 UMC9008 is inserted into pc (it's set up on the first place so it's eth0). I'm using module 'ne.o'.

(b) When network card NE2000 realtek rtl8139 is inserted into pc and set up as eth0. I'm using module 'ne2k-pci.o'

3. Problem

In (b) case both networks ("LAN 1" and "LAN 2") are connected to the internet. After executing on my router
tcpdump -i eth0 -v -n
and
ping google.pl
on some machine connected to this internet I'm watching packets going to 10.0.0.1 and google's reply's.
Executing
iptables -t filter -L -v -n
gives me statistics that are rising up while I'm sending ping's.

In (a) case network "LAN 1" is connected to the internet, while "LAN 2" is not. After executing on my router
tcpdump -i eth0 -v -n
and
ping google.pl
on some machine connected to this internet I'm watching packets going to 10.0.0.1 but no google's reply's (packets are not even forwarded to eth2). Executing
iptables -t filter -L -v -n
gives me statistics that are stable. No packets are reciver trough iptables. However ping 10.0.0.1 gives me replies (but iptables is not 'catching' it.)

Another strange thing:
I can execute

	ping 10.0.0.x

from my router and then I'm reciving replies (no mather if it is PCI or ISA card installed).

Can somebody tell me what is happening?

Configuration is the same in both cases. Only network cards differ. Both cards are working fine (cause 'tcpdump' is giving me an output).

My machine's configuration:
My mother board is PC-Chips M577 (VIA MVP3 chipset). I have 'gentoo-hardened' sources.
I have checked linux-2.4.26 (clean, unpatched), too.

Many thanks for any help
Regards
---
Adderek

#1 lore raw

On Saturday 17 July 2004 8:28 am, adderek wrote:

<much detail snipped>

Quoted 6 lines

I had already configured firewall/router (based on debian distribution is has only a few things in common with debian).

At first I've configured everything with my old PCI cards. After everything worked fine I've changed eth0 to ISA card.

Quoted 6 lines

After changing my PCI card to ISA card firewall gone down :(

Can somebody tell me what is happening?

Configuration is the same in both cases. Only network cards differ. Both cards are working fine (cause 'tcpdump' is giving me an output).

1. I really can't see this is a netfilter problem.

2. I don't agree with your reasoning that "both cards are working fine because tcpdump is giving me an output" - everything else indicates that the ISA card is not working fine, because with this in place you have problems; swapping for a PCI you do not have problems.

3. Have you checked the interrupts & I/O address range in use by the ISA card, and whether they conflict with something else in the machine?

Regards,

Antony

Signature · 7 lines
I don't know, maybe if we all waited then cosmic rays would write all our 
software for us. Of course it might take a while.

 - Ron Minnich, Los Alamos National Laboratory

                                                     Please reply to the list;
                                                           please don't CC me.
author
#2 lore raw
Quoted 1 line

1. I really can't see this is a netfilter problem.

I thought that if packets are bypassing kernel (and iptables in it) then it will be IPtables problem.

Quoted 1 line

2. I don't agree with your reasoning that "both cards are working fine because tcpdump is giving me an output" - everything else indicates that the ISA card is not working fine, because with this in place you have problems; swapping for a PCI you do not have problems.

OK. I'll check it on another ISA card as soon as I get one.

Quoted 1 line

3. Have you checked the interrupts & I/O address range in use by the ISA card, and whether they conflict with something else in the machine?

It's ISA PnP card so it's autoconfigured. I've checked and there is no conflicts :(

Quoted 4 lines

Regards,

Antony

#3 lore raw
Quoted 4 lines · adderek
Quoted 1 line

1. I really can't see this is a netfilter problem.

I thought that if packets are bypassing kernel (and iptables in it) then it will be IPtables problem.

Not when the exact same configuration works with a different card, also known to netfilter as eth0.

If you get the problem with the card, and not with a different card, then the card is causing the problem.

It cannot be a netfilter problem because you are not changing anything in netfilter to make the problem come and go.

Quoted 5 lines
Quoted 2 lines

3. Have you checked the interrupts & I/O address range in use by the ISA card, and whether they conflict with something else in the machine?

It's ISA PnP card so it's autoconfigured. I've checked and there is no conflicts :(

Are you sure it is actually being fully configured? Are you doing the PnP
setup in the Bios, or under Linux?

If you take netfilter and the other two PCI cards completely out of the equation (ie: unplug the other cards, and set netfilter to default ACCEPT on all chains with no ruleset), can you communicate with the system at all through this card?

Regards,

Antony.

Signature · 14 lines
This email is intended for the use of the individual addressee(s) named above 
and may contain information that is confidential, privileged or unsuitable 
for overly sensitive persons with low self-esteem, no sense of humour, or 
irrational religious beliefs.

If you have received this email in error, you are required to shred it 
immediately, add some nutmeg, three egg whites and a dessertspoonful of 
caster sugar.   Whisk until soft peaks form, then place in a warm oven for 40 
minutes.   Remove promptly and let stand for 2 hours before adding some 
decorative kiwi fruit and cream.   Then notify me immediately by return email 
and eat the original message.

                                                     Please reply to the list;
                                                           please don't CC me.
author
#4 lore raw

(...)

Quoted 1 line

Are you sure it is actually being fully configured? Are you doing the PnP setup in the Bios, or under Linux?

I'm just executing 'modprobe ne' under linux. It requires module '8390'. And that's all. In bios I have configured some IRQ's to 'Legacy ISA PnP'

Quoted 1 line

If you take netfilter and the other two PCI cards completely out of the equation (ie: unplug the other cards, and set netfilter to default ACCEPT on all chains with no ruleset), can you communicate with the system at all through this card?

I'll check this in a moment.
But if I can remember I can communicate with this router - it's answering to my ping requests.

	ping 10.0.0.1

made from 10.0.0.2 machine sometime works and sometime do not. I'm recompilling my kernel at the moment so I'll check it in a while...

Regards
---
Adderek

author
#5 lore raw
In reply to Antony Stone

I have removed all cards except those three network cards and graphic card.

10.0.0.2 (BNC terminal):

1) exec(ping 10.0.0.1)

result:
100% packet loss

2) exec(ping google.com)

result:
100% packet loss

------------------------------------------------------------
10.0.1.2 (RJ45 terminal):

1) exec(ping 10.0.1.1)

result:
0% packet loss

2) exec(ping google.com)

result:
0% packet loss

-------------------------------------------------------------

10.0.0.1 (BNC router, ISA@eth0 PCI@eth1 internet@eth2):

3) exec(iptables -t filter -L -v -n)

result: Chain INPUT (policy DROP 89 packets, 11837 bytes)

     pkts bytes target     prot opt in     out     source destination
     2041  175K ACCEPT     all  --  eth1   *       0.0.0.0/0 0.0.0.0/0
       31  2340            all  --  eth0   *       0.0.0.0/0 0.0.0.0/0

Chain FORWARD (policy ACCEPT 107 packets, 6663 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 1040 packets, 96388 bytes)
pkts bytes target prot opt in out source destination
1178 162K ACCEPT all -- * eth1 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- * eth0 0.0.0.0/0 0.0.0.0/0

4) exec(ping 10.0.0.2)

result:
0% packet loss

conclusion:
iptables is catching incoming bytes and statistics are rising from both interfaces. I don't understand why packets are not forwarded.
ping replies goes only when requesting from 'PCI network'.
ping requests from 'ISA network' are ignored.
I've forgotten about '-j ACCEPT' in INPUT from eth0 :)

and now : strange thing:

5)
on router I've executed:
exec(iptables -t filter -I INPUT -i eth2 -j DROP) exec(iptables -P INPUT ACCEPT)

and then on BNC terminal:

    exec(`ping 10.0.0.1`)
    and the result.....

result: 0% packet loss !!!
and
exec(ping google.com)
result: 100% packet loss

conclusion:
packets are forwarded only internally trough ISA card.
however PCI card is forwarded to the internet.
Interface eth0 acts like it is something else (like packets are incoming from some non existing card). But data can be send to this interface (cause `ping 10.0.0.2 on router always works).

6) exec(iptables -t filter -L -v -n)

result: Chain INPUT (policy ACCEPT 4 packets, 240 bytes)

     pkts bytes target     prot opt in     out     source destination
       10  1512 DROP       all  --  eth2   *       0.0.0.0/0 0.0.0.0/0
     3317  287K ACCEPT     all  --  eth1   *       0.0.0.0/0 0.0.0.0/0
       48  3989            all  --  eth0   *       0.0.0.0/0 0.0.0.0/0

Chain FORWARD (policy ACCEPT 196 packets, 11439 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 1085 packets, 99644 bytes)
pkts bytes target prot opt in out source destination
2546 313K ACCEPT all -- * eth1 0.0.0.0/0 0.0.0.0/0
4 240 ACCEPT all -- * eth0 0.0.0.0/0 0.0.0.0/0

After few more researches I've managed that kernet even don't try forwarding my packets:

Chain FORWARD (policy ACCEPT 29 packets, 1512 bytes)

 pkts bytes target     prot opt in     out
   51  2364 ACCEPT     all  --  eth1   *
    0     0 ACCEPT     all  --  eth0   *
    0     0 ACCEPT     all  --  *      eth0
   63 20975 ACCEPT     all  --  *      eth1

(table shown above was created after making some ping google.com from both subnetworks)

What now?

#6 lore raw
Quoted 1 line · adderek

I have removed all cards except those three network cards and graphic card.

If you take netfilter and the other two PCI cards completely out of the equation (ie: unplug the other cards, and set netfilter to default ACCEPT on all chains with no ruleset), can you communicate with the system at all through this card?

Regards,

Antony.

Signature · 6 lines
I want to build a machine that will be proud of me.

 - Danny Hillis, creator of The Connection Machine

                                                     Please reply to the list;
                                                           please don't CC me.
author
#7 lore raw
Quoted 1 line · Antony Stone

If you take netfilter and the other two PCI cards completely out of the equation (ie: unplug the other cards, and set netfilter to default ACCEPT on all chains with no ruleset), can you communicate with the system at all through this card?

I'll check this today. however I'm changing my whole network to RJ tomorrow. many thanks for help. I'll write about test results as soon as I'll make it.

Regards from Poland
---
Adderek

#8 lore raw
In reply to Antony Stone

Antony Stone schreef:

Quoted 7 lines
Quoted 3 lines

It's ISA PnP card so it's autoconfigured. I've checked and there is no conflicts :(

Are you sure it is actually being fully configured? Are you doing the PnP
setup in the Bios, or under Linux?

In my firewall based on Debian I have a 3Com Etherlink III card. I have the
drivers for that card build in the kernel, not as modules (why using modules if a
module is constantly loaded).Next I have written a script to activate the card
(/etc/init.d/isapnp):
#!/bin/sh
#

# isapnp initialize isa-pnp devices
#
PATH="/sbin:/bin:/usr/sbin:/usr/bin"
case "$1" in
  start|restart)
    if [ -r /etc/isapnp.conf ]
    then
      if [ ! -e /proc/isapnp ]
      then
        if [ -e /lib/modules/`uname -r`/kernel/drivers/pnp/isa-pnp.o ]
        then
          modprobe isa-pnp
          result=$?
          if [ $result -ne 0 ]
          then
            exit 2
          fi
        else
          exit 1
        fi
      fi

cat /etc/isapnp.conf >/proc/isapnp
fi
;;
stop)

    ;;

esac

And the configuration in /etc/isapnp.conf:
card 0 TCM5095
dev 0 TCM5095
port 0 0x220
irq 0 5
activate

Read kernel-source-'version'/Documentation/isapnp.txt for the options Finaly I have created a symlink from /etc/rcS.d/S15isapnp to ../init.d/isapnp

Be sure that there are no IRQ's or Port conflicts, or you will find difficulties
activating cards.

Quoted 7 lines

Regards,

Antony.

--

Regards
--
Frans Luteijn
PGP PblKey fprnt=C4 87 CE AF BC B6 98 C1 EF 42 A1 9A E2 C0 42 5B GPG PblKey fprnt=ED20 0F25 C233 DC59 3FFA 170E D0BF 15F5 0BA6 1355