Mandrake eth1 stopt na x minuten

[om3ega]

Ik heb een nogal merkwaardig probleem. Ik heb een PC waar mandrake 10 op staat. Hier zitten 3 ethernet kaarten in.

eth0 : local (trusted)
eth1: extern netwerk (1)
eth2: Internet

De server gebruikt fw-jay als firewall (dat is een script wat IP-tables instelt) Precies dezelfde configuratie heb ik draaien op een Redhat 9.0 server zonder problemen.

Na een x-aantal minuten (<5) is eth1 niet meer aanspreekbaar. D.w.z. : Ik kan niet meer pingen naar devices die op eth1 netwerk zitten en visa-versa. eth0 en eth2 werken zonder problemen.


Nu weet ik van Mandrake dat er verschillende security levels zitten die periodieke checks uitvoeren waarbij er soms ongewenste situaties kunnen plaatsvinden. Na het uitschakelen van deze automatische security checks hoopte ik dan ook dat het probleem voorbij zou zijn... maar helaas

Als ik de service van fw-jay restart werkt alles weer voor een x-aantal minuten.

Mijn vermoeden is dus dat er ergens iets gebeurd wat na x-aantal minuten de firewall rules aanpast. Deze functionaliteit zit niet in fw-jay en precies dezelfde configuratie draait ook op die redhat server (zonder problemen)

Ik heb de cron nagekeken of er nog iets instaat van periodieke checks maar kan niets vinden.

Mijn vraag is eigenlijk : Wat heeft mandrake nog meer voor truckjes die bovenstaand gedrag kunnen geven? En waar kan ik nog zoeken om een mogelijke oorzaak voor dit probleem te vinden.

Of waar kan ik nog zoeken naar de oorzaak?

De syslog geeft geen noemenswaardige foutmeldingen o.i.d.

Oh , nog even 1 opmerking , het netwerk op eth1 is een extern netwerk maar geen internet , dus routing problemen lijken me onwaarschijnlijk.

[ Voor 5% gewijzigd door om3ega op 30-06-2004 09:11 ]

[Verwijderd]

Misschien een domme vraag maar zijn de firewall-rules ook daadwerkelijk anders na die x aantal minuten? krijg je ook 'acces denied' regels in je log files (syslog) na die x aantal minuten? of gaat gewoon heel de interface down?

[MrScratch]

Waarschijnlijk is heb je niks aan deze opmerking, maar ik plaats hem toch even, je weet immers maar nooit. Heb je misschien meerdere ethX met het zelfde ip-adres gekregen? Ik heb ooit gehad wat jij hebt (dwz de verbinding ging telkens na 1 a 2 minuten op dood) en toen bleek dat ik 2 nics hetzelfde ip-adres had gegeven. Dat vinden routerende devices nooit zo leuk, want dan weten ze niet meer waar ze met hun pakketjes heenmoeten.

[om3ega]

De interface gaat niet down. Ik zal de ifconfig eth1 (betreffende interface even posten)

code:

eth1      Link encap:Ethernet  HWaddr 00:02:44:7D:56:0F
          inet addr:10.30.83.188  Bcast:10.30.83.255  Mask:255.255.255.0
          inet6 addr: fe80::202:44ff:fe7d:560f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:13070 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9063 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1551447 (1.4 Mb)  TX bytes:1234104 (1.1 Mb)
          Interrupt:11 Base address:0x9400

En een stukje uit de syslog na een ping commando naar een device die in het netwerk van eth1 zit.

code:

Jun 30 10:29:39 wireless kernel: IN=eth1 OUT= MAC= SRC=10.30.83.188 DST=10.30.83.255 LEN=125 TOS=0x00 PREC=0x00 TTL=64 ID=19689 DF PROTO=UDP SPT=631 DPT=631 LEN=105 
Jun 30 10:29:39 wireless kernel: IN=eth1 OUT= MAC=00:02:44:7d:56:0f:00:50:bf:5d:44:c0:08:00 SRC=10.30.83.1 DST=10.30.83.188 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=53161 PROTO=ICMP TYPE=0 CODE=0 ID=39771 SEQ=1 
Jun 30 10:29:40 wireless kernel: IN=eth1 OUT= MAC=00:02:44:7d:56:0f:00:50:bf:5d:44:c0:08:00 SRC=10.30.83.1 DST=10.30.83.188 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=53162 PROTO=ICMP TYPE=0 CODE=0 ID=39771 SEQ=2

Geen foutmeldingen te vinden in de syslog.
Ik heb ook niet dezelfde IP toegewezen aan verschillende netwerkkaarten.

Het probleem met eth1 is het enige wat stopt. Communicatie tussen local-lan en internet gaat prima.

[freggy]

Probeer eerst eens te checken of je dit probleem ook hebt zonder dat firewallscript. Indien ja, is er allicht iets fout met de kernelmodule die gebruikt wordt voor die netwerkkaart, indien nee, dan is er ergens een probleem in het script zelf of een concflict tussen het script en iets van Mandrakelinux zelf

[om3ega]

Zonder firewall script heb ik geen problemen. Een conflict met de netwerk kaart lijkt me niet mogelijk daar het 3 dezelfde netwerk kaarten zijn.

Ik vermoed dan ook dat iets in mandrake de tables aanpast na x aantal minuten.. maar wat?

[Spider.007]

Welke foutmelding geeft het ping commando dan wel? Kan het niet gewoon zo zijn (wilde gok) dat je draadloze verbinding na een aantal minuten in een standby modus gaat? Staat er ook niets in het syslog rond het moment dat dit device niet meer wil werken? Is die post van ifconfig op het moment dat hij werkt; of op het moment dat hij niet werkt? Zit daar nog verschil in?

[Seth4Chaos]

Spider.007 schreef op 30 juni 2004 @ 11:21:
Kan het niet gewoon zo zijn (wilde gok) dat je draadloze verbinding na een aantal minuten in een standby modus gaat?

Dit heb ik inderdaad gehad met mijn 3Com AP, daar kon je instellen dat die in een slaapmodus ging en daar kon je hem alleen uit krijgen door op de "bedrade"-interface pakketjes er naar te sturen zodat de wireless interface ook weer op kwam en je dus draadloos weer kon inloggen....
was erg irritant dus heb ik maar uitgezet.

Overigens is het mischien handig om een 'ifconfig eth1' en een 'iptables -n -L' van het moment dat de verbinding werkt en op het moment dat het niet meer werkt met elkaar te vergelijken, mischien vindt je iets raars.

[Verwijderd]

Als je ipv je firewall je eth1 herstart met
cd /etc/sysconfig/network-scripts/
./ifup eth1 boot
doet hij het dan? (werkt alleen als je het zo hebt ingesteld dat eth1 start on boot natuurlijk)

[Verwijderd]

het is misschien een stomme vraag, misschien dat dhcp oid iets doet? vaak zitten problemen in van die kleine onnozelle dingen.

[om3ega]

Ping geeft gewoon geen reply meer (geen foutmelding). Het device wat ik ping is een via een bekabeld netwerk aangesloten accesspoint. Ik ben er 100% zeker van dat deze "UP" is op het moment dat ik hem ping.

code:

ping 10.30.83.10
PING 10.30.83.10 (10.30.83.10) 56(84) bytes of data.

--- 10.30.83.10 ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 5999ms

De ifconfig post is identiek , wel of niet werkend.
Geen foutmeldingen in het syslog (behalve de hierboven geposte meldingen die waarschijnlijk door het uitgevoerde ICMP commando zijn veroozaakt)

Ik zal nog even de result posten van de service restart..

code:

[root@wireless log]# service fw-jay restart
Shutdown Jay's Firewall
Unload iptables modules ...
Keep nat modules
keep default modules
Starting Jay's Firewall v1.0.3 :
Check of configuration's file : OK
Trying to load iptables modules ...
found internal eth0 on ip:'192.168.0.25', sub:'192.168.0.25/255.255.255.0'
found external eth1 on ip:'10.30.83.188'
found external eth2 on ip:'82.197.xxx.xxx'
Check of iptables : OK
Ignore icmp echo broadcasted
Don't accept icmp redirect
Don't send icmp redirect
Ignore bogus error responses
Enable Ip Forwarding
Enable rp_filter
Enable syncookies protection
Disable source routing
Enable Ip dynamic address
-------- iptables rules --------
Set Default policies at DROP for INPUT & FORWARD chains
Allow unlimited traffic on the loopback device

Forward Section
---------------
   LANs -> LANs : Accept All
   Inet -> LANs : ICMP Check
   Inet -> LANs :  Accept ESTABLISHED & RELATED connections
   LANs -> Inet : Smurf attack
   LANs -> Inet : Invalid ICMP
   LANs -> Inet : TCP Check


Try `iptables -h' or 'iptables --help' for more information.
   LANs -> Inet : TCP to MSS
   LANs -> Inet : Deny fragmented packets
   LANs -> Inet : Accept NEW,ESTABLISHED and RELATED connections
   LANs -> Inet : Setting up MASQUERADE

LAN Section
-----------
   LAN : Allow traffic between the Box & the LANs
   LAN : Allow incoming ICMP   LAN : Allow incoming TCP connection on ALL ports
   LAN : Allowing established outbound connections back in for tcp
   LAN : Allow incoming UDP connection on ALL ports
   LAN : Allowing established outbound connections back in for udp

Internet Section
----------------
   Inet : Synflood Control
   Inet : ICMP Control
   Inet : Allow DNS to speak whith us
   Inet : Allow incoming TCP connection on ports eth2:22 80
   Inet : Allow incoming UDP connection on ports
   Inet : Allowing established outbound connections back in

Misc Section
------------
Disable TCP Control
Disable Spoofing control
Write Synflood Control Chain
Disable ICMP Control
   Icmp Chain : Allow everyone to ping us
 done

Het ICMP control gedeelte is dus verantwoordelijk voor het algemeen : wel of niet pingbaar van buitenaf. Als de PC net opgestart is of de service is ge-restart , doet hij wat hij moet doen. Na x minuten is het over met de pret...

PS: Hij is nu al 12 minuten niet afgevallen? .. zou eth1 het doorhebben dat ik over hem praat? ... ik wacht even tot hij weer wegvalt en dan post ik even wat output zoals hierboven wordt gevraagd..

[ Voor 7% gewijzigd door om3ega op 30-06-2004 12:09 ]

[om3ega]

Hmm ik heb nog wat vreemds gevonden ..
Naar aanleiding van het DHCP verhaal.

In de server die de DHCP adressen uit deelt (dit is een andere server op het netwerk waar de besproken server op staat) staat het volgende -> (dit is een stukje)

code:

lease 10.30.83.188 {
  starts 2 2004/06/29 22:54:34;
  ends 2 2004/07/06 22:54:34;
  binding state active;
  next binding state free;
  hardware ethernet 00:02:72:42:b6:39;
  uid "\001\000\002rB\2669";
  client-hostname "r-547kj9iyyluy1";
}
lease 10.30.83.188 {
  starts 2 2004/06/29 22:54:37;
  ends 2 2004/07/06 22:54:37;
  binding state active;
  next binding state free;
  hardware ethernet 00:02:72:42:b6:39;
  uid "\001\000\002rB\2669";
  client-hostname "r-547kj9iyyluy1";
}
lease 10.30.83.188 {
  starts 2 2004/06/29 22:54:43;
  ends 2 2004/07/06 22:54:43;
  binding state active;
  next binding state free;
  hardware ethernet 00:02:72:42:b6:39;
  uid "\001\000\002rB\2669";
  client-hostname "r-547kj9iyyluy1";
}
lease 10.30.83.188 {
  starts 2 2004/06/29 22:57:08;
  ends 2 2004/07/06 22:57:08;
  binding state active;
  next binding state free;
  hardware ethernet 00:02:72:42:b6:39;
  uid "\001\000\002rB\2669";
  client-hostname "r-547kj9iyyluy1";
}
lease 10.30.83.188 {
  starts 2 2004/06/29 22:57:08;
  ends 2 2004/07/06 22:57:08;
  binding state active;
  next binding state free;
  hardware ethernet 00:02:72:42:b6:39;
  uid "\001\000\002rB\2669";
  client-hostname "r-547kj9iyyluy1";
}
lease 10.30.83.188 {
  starts 2 2004/06/29 22:57:16;
  ends 2 2004/07/06 22:57:16;
  binding state active;
  next binding state free;
  hardware ethernet 00:02:72:42:b6:39;
  uid "\001\000\002rB\2669";
  client-hostname "r-547kj9iyyluy1";
}
lease 10.30.83.188 {
  starts 2 2004/06/29 22:57:16;
  ends 2 2004/07/06 22:57:16;
  binding state active;
  next binding state free;
  hardware ethernet 00:02:72:42:b6:39;
  uid "\001\000\002rB\2669";
  client-hostname "r-547kj9iyyluy1";

Ter verduidelijking , 10.30.83.188 is dus de ethernet kaart (eth1) van de PC die dus regelmatig wegvalt...

Normaal komt de zelfde PC niet zovaak terug in deze DHCP release overzicht. Zou het probleem in de DHCP client (kunnen) zitten?

--
Toevoeging ->

Ik heb nu een static IP adres op eth1 gezet om te kijken of het wellicht te maken heeft met de DHCP client.

[ Voor 22% gewijzigd door om3ega op 30-06-2004 13:58 ]

[Verwijderd]

Ik vermoed dat meerdere hosts 'vechten' om hetzelfde ip, de DHCP lease is namelijk een week geldig maar wordt soms na een paar seconden al opnieuw aangevraagd. Krijgen alle hosts in het netwerk-segment hun ip via DHCP toegewezen? welke ip-range stel je beschikbaar via DHCP? Als je je ip statisch instelt blijft het dan wel gewoon werken?

[om3ega]

Ik heb nu een vast IP adres er in gezet , en ik heb het (eindelijk) een keer zien gebeuren dat hij stopte .. en jawel , een foutmelding dit keer ->

code:

64 bytes from 10.30.83.1: icmp_seq=910 ttl=64 time=0.241 ms
64 bytes from 10.30.83.1: icmp_seq=911 ttl=64 time=0.253 ms
64 bytes from 10.30.83.1: icmp_seq=912 ttl=64 time=0.289 ms
64 bytes from 10.30.83.1: icmp_seq=913 ttl=64 time=0.251 ms
ping: sendmsg: Operation not permitted

En daarna is het over..
De DHCP heeft er (gelukkig) niets mee te maken dan ..

Maar rest mij nog wel de vraag waarom ineens een PING niet meer toegestaan is?

[Seth4Chaos]

om3ega schreef op 30 juni 2004 @ 15:00:
Ik heb nu een vast IP adres er in gezet , en ik heb het (eindelijk) een keer zien gebeuren dat hij stopte .. en jawel , een foutmelding dit keer ->

code:

64 bytes from 10.30.83.1: icmp_seq=910 ttl=64 time=0.241 ms
64 bytes from 10.30.83.1: icmp_seq=911 ttl=64 time=0.253 ms
64 bytes from 10.30.83.1: icmp_seq=912 ttl=64 time=0.289 ms
64 bytes from 10.30.83.1: icmp_seq=913 ttl=64 time=0.251 ms
ping: sendmsg: Operation not permitted

En daarna is het over..
De DHCP heeft er (gelukkig) niets mee te maken dan ..

Maar rest mij nog wel de vraag waarom ineens een PING niet meer toegestaan is?

Dit lijkt erop dat je in de OUTPUT table van iptables een deny/drop heb staan op icmp pakketten, check je iptables is met "iptables -n -L OUTPUT"

[om3ega]

Ik geef toe , ik zou me wat meer in de tables moeten verdiepen , maar het volgende krijg ik als output ->

In de geblockte mode :

code:

[root@wireless network-scripts]# iptables -n -L OUTPUT
Chain OUTPUT (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  192.168.0.0/24       0.0.0.0/0
ACCEPT     icmp --  192.168.0.0/24       0.0.0.0/0
LD         tcp  --  82.197.204.0/24      0.0.0.0/0           tcp dpt:31337 limit: avg 2/min burst 5
LD         udp  --  82.197.204.0/24      0.0.0.0/0           udp dpt:31337 limit: avg 2/min burst 5
LD         tcp  --  82.197.204.0/24      0.0.0.0/0           tcp dpt:33270 limit: avg 2/min burst 5
LD         udp  --  82.197.204.0/24      0.0.0.0/0           udp dpt:33270 limit: avg 2/min burst 5
LD         tcp  --  82.197.204.0/24      0.0.0.0/0           tcp dpt:1234 limit: avg 2/min burst 5
LD         tcp  --  82.197.204.0/24      0.0.0.0/0           tcp dpt:6711 limit: avg 2/min burst 5
LD         tcp  --  82.197.204.0/24      0.0.0.0/0           tcp dpt:16660 flags:0x16/0x02 limit: avg 2/min burst 5
LD         tcp  --  82.197.204.0/24      0.0.0.0/0           tcp dpt:60001 flags:0x16/0x02 limit: avg 2/min burst 5
LD         tcp  --  82.197.204.0/24      0.0.0.0/0           tcp dpts:12345:12346 limit: avg 2/min burst 5
LD         udp  --  82.197.204.0/24      0.0.0.0/0           udp dpts:12345:12346 limit: avg 2/min burst 5
LD         tcp  --  82.197.204.0/24      0.0.0.0/0           tcp dpt:135 limit: avg 2/min burst 5
LD         udp  --  82.197.204.0/24      0.0.0.0/0           udp dpt:135 limit: avg 2/min burst 5
LD         tcp  --  82.197.204.0/24      0.0.0.0/0           tcp dpt:1524 limit: avg 2/min burst 5
LD         tcp  --  82.197.204.0/24      0.0.0.0/0           tcp dpt:27665 limit: avg 2/min burst 5
LD         udp  --  82.197.204.0/24      0.0.0.0/0           udp dpt:27444 limit: avg 2/min burst 5
LD         udp  --  82.197.204.0/24      0.0.0.0/0           udp dpt:31335 limit: avg 2/min burst 5
LD         all  --  224.0.0.0/8          0.0.0.0/0
LD         all  --  0.0.0.0/0            224.0.0.0/8
LD         all  --  255.255.255.255      0.0.0.0/0
LD         all  --  0.0.0.0/0            0.0.0.0
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:!0x16/0x02 state NEW
           all  --  0.0.0.0/0            0.0.0.0/0           TTL match TTL == 64
ACCEPT     icmp --  82.197.204.0/24      0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0

Na een fw-jay service restart ->

code:

[root@wireless network-scripts]# iptables -n -L OUTPUT
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
JAY_LANOUT  all  --  0.0.0.0/0            0.0.0.0/0
JAY_INETOUT  all  --  0.0.0.0/0            0.0.0.0/0
JAY_INETOUT  all  --  0.0.0.0/0            0.0.0.0/0

Ik snap nog steeds niet wat iptables nu het commando geeft bepaalde zaken aan te passen en te blocken naa xx minuten.

Edit : Het lijkt er wel op dat de rules reset die ik met fw-jay maak (de JAY chain) helemaal overschreven is?

[Verwijderd]

Seth4Chaos schreef op 30 juni 2004 @ 15:15:
[...]


Dit lijkt erop dat je in de OUTPUT table van iptables een deny/drop heb staan op icmp pakketten, check je iptables is met "iptables -n -L OUTPUT"

Klinkt logisch, maar waarom gebeurt dit dan pas na een bepaalde (willekeurige) tijd? Daar komt bij dat het steeds opnieuw (vaak na enkele seconden) aanvragen van de DHCP lease ook een beetje raar is. Want wanneer wordt een DHCP lease normaal gesproken aangevraagd?, alleen als de interface wordt geactiveerd of als de lease is verlopen toch?

De willekeur waarmee het opnieuw aanvragen van de DHCP leases/het down gaan van de interface gebeurt doet vermoeden dat het om een hardwarematige storing gaat Als je 'fw-jay' herstart, wordt dan toevallig ook je ethernet interface aan- en uitgezet?

[om3ega]

Ik heb de ethernet adapter hardcoded een IP adres gegeven , dit heeft geen invloed (helaas) op het (mis)functioneren van de kaart.

Ik kan hier denk ik wel de conclusie uit trekken dat de problemen los staan van eventuele DHCP issues.

Ik heb in het (re)start script van fw-jay gekeken. Het lijkt er niet op dat de interface aan en uit wordt gezet. Ik kan remote ook gewoon de service restarten zonder dat ik er uit word gegooid.

Wel worden (maar dat is logisch denk ik) de firewall rules opnieuw ge-set.

Ik maak hier uit op dat de orginele fw-jay rules ook prima functioneren. (zoals ook op mijn andere computer) maar dat er iets is wat na een x minuten deze rules compleet door de war schopt.

[ Voor 3% gewijzigd door om3ega op 30-06-2004 15:47 ]

[Seth4Chaos]

code:

Chain OUTPUT (policy DROP)
target     prot opt source               destination
ACCEPT     icmp --  192.168.0.0/24       0.0.0.0/0
ACCEPT     icmp --  82.197.204.0/24      0.0.0.0/0

even je output een beetje geknipt...
Als je deze twee regels bekijkt lijkt het erop alsof je alleen vanaf 192.168.0.0/24 (subnet van eth0) en 82.197.204.0/24 (subnet van je eth2) pings (icmp-pakketten) mag versturen.

Ik mis een regel in de trant van:

code:

target     prot opt source               destination
ACCEPT     icmp --  10.30.83.0/24       0.0.0.0/0

Zoals ik je firewall rules nu lees mag je ook niet pingen via je eth1 interface.

Overigens verklaard dit nog niet het gedrag waarom dit pas na enkele minuten gebeurt.

edit: bij nader inzien lijkt het erop dat er nog een ander firewall script draait ofzo, als ik het zo snel kan zien (ook op de site van jay-fw) gebruikt hij chains met de namen JAY_* en er staan bij jouw (in geblockde mode) chains met de naam LD, is dit niet toevallig de firewall van mandrake zelf (service iptables ???)

[ Voor 41% gewijzigd door Seth4Chaos op 30-06-2004 17:00 ]