[RH6.2]Server probleempje

[Verwijderd]

Op een machine met RH6.2 draait een speciaal server programma dat luistert op poort 4011; het wordt gestart via inetd.
Ik kan deze server wel benaderen via localhost (telnet localhost 4011) maar niet via het IP adres van de netwerkkaart. Remote access is ook niet mogelijk.
Als ik probeer te telnetten naar deze server wordt de verbinding opgezet en direct weer gesloten met de melding 'connection closed by foreign host'.

Andere servers doen het wel goed (telnet, ftp).
De files hosts.allow en hosts.deny zijn leeg.
Op twee andere machines met identieke HW werkt het allemaal wel zoals het hoort. De Linux installatie kan echter iets verschillen.

Iemand een idee waar ik het moet zoeken? Kan dit een netwerkkaart probleem zijn (intel eepro100; drivers ge-update voor single processor gebruik)?

[RvdH]

Zo te zien 'accept'eerd die server de verbinding wel, maar sluit hem direct weer af. Wellicht een soort van access control in de server die de verbinding weigert/alleen toestaat vanaf localhost?

[Verwijderd]

Helaas niet. Ik heb met de ontwikkelaars gesproken en die zeggen dat dat er niet inzit. De configuratie-file voor de server is ook dezelfde als op de andere twee machines.

[RvdH]

En niets relevants in je /var/log/messages, of /var/log/syslog, of /var/log/secure?

[Verwijderd]

Heb je /etc/hosts.allow en /etc/hosts.deny zo ingesteld dat je client-ips toegang hebben?

edit: nee dus...

[ Voor 11% gewijzigd door Verwijderd op 10-05-2004 12:37 ]

[Bierkameel]

Niet per ongeluk je firewall gestart?

[Verwijderd]

RickJansen schreef op 10 mei 2004 @ 12:12:
En niets relevants in je /var/log/messages, of /var/log/syslog, of /var/log/secure?

Dank u, files zijn onderweg naar de ontwikkelaars.

[Verwijderd]

Does netstat -an|egrep LISTEN|4011 ? Dan zien we op welke interfaces je speciale servertje luistert. Mogen we eventueel ook de relevante regel uit inetd.conf zien alsook de parameters waarmee inetd gestart zijn?

[Verwijderd]

code:

minicon stream  tcp nowait  minicon /usr/sbin/tcpd in.minicon

Geen idee hoe inetd gestart wordt. Zit ergens in rc5.d (meen ik), maar weet zo niet welke parameters worden meegegeven. Kan effe duren.

code:

netstat output met grep op 4011:

tcp        0      0 0.0.0.0:4011            0.0.0.0:*               LISTEN      

tcp        0      0 127.0.0.1:4011          127.0.0.1:1042          ESTABLISHED 
tcp        0      0 127.0.0.1:1042          127.0.0.1:4011          ESTABLISHED 
tcp        0      0 0.0.0.0:4011            0.0.0.0:*               LISTEN

De eerste regel als er geen verbinding is, de volgende regels als er een verbinding is via localhost.

[Verwijderd]

Verwijderd schreef op 10 mei 2004 @ 13:20:
Geen idee hoe inetd gestart wordt. Zit ergens in rc5.d (meen ik), maar weet zo niet welke parameters worden meegegeven. Kan effe duren.

Inetd is een service en wordt (onder Red Hat 6) gestart met /etc/rc.d/init.d/inet. Normaal wordt inetd zonder verdere parameters opgestart (als "daemon inetd")

Voor de grap al eens geprobeerd /etc/hosts.allow op "ALL: ALL" te zetten en dan een "killall -HUP inetd" te doen? (Het lijkt me toch echt tcpd of iptables ipchains die die connectie dropt.)

[ Voor 23% gewijzigd door Verwijderd op 10-05-2004 17:14 ]

[Verwijderd]

Probleem en workaround gevonden. Het is een bug in de specifieke server-software waarbij een reverse lookup wordt gedaan zodat het ontvangen ip-adres (van de client) kan worden omgezet in de hostnaam.
Als dit niet lukt, wordt er een NULL-pointer geretourneerd en die wordt niet afgevangen. Dit resulteert dus in een hele mooie segmentation-fault waardoor de thread crashed en de verbinding weer verbroken wordt.
Oplossing is dus om de geldige IP-adressen in de hosts-file te zetten (of op een DNS server).

Verwijderd schreef op 10 mei 2004 @ 14:28:Inetd is een service en wordt (onder Red Hat 6) gestart met /etc/rc.d/init.d/inet. Normaal wordt inetd zonder verdere parameters opgestart (als "daemon inetd")

Inderdaad gevonden, zonder parameters dus.

Verwijderd schreef op 10 mei 2004 @ 14:28:Voor de grap al eens geprobeerd /etc/hosts.allow op "ALL: ALL" te zetten en dan een "killall -HUP inetd" te doen? (Het lijkt me toch echt tcpd of iptables ipchains die die connectie dropt.)

Yep, had geen effect