Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bind sendmail to IP

0 views
Skip to first unread message

Peter Gervai

unread,
Dec 5, 1997, 3:00:00 AM12/5/97
to

Hello,

Proba szerencse, hatha vki.

Van egy gep, sok interface, sok IP tartomany, virtual interface-ek tomege.
Amikor Sendmail bacsi el akar kuldeni egy levelet, kivalaszt egy IP-t a
sok kozul (persze nem veletlenul, de a kivalasztas modjarol, ahogy
altalaban a net code dont, pontosabban ennek befolyasolasarol szinten
szivesen hallgatok otleteket), es azzal a source cimmel probalja felvenni
a kapcsolatot az ellenoldallal es elkuldeni a levelet.

Ez nekem nem jo. Nekem az kell hogy a Sendmail kuldesek mindig EGY ADOTT
IP-t hasznaljanak. Mivel a gepben fizikailag egy eth0 van, ez azt hiszem
elvileg nem sorolhato a lehetetlen kategoriaba, mar csak azert sem mert
pl. a squid szepen oda bind-ol ahova en kerem.

A DaemonPortakarmisetup word csak azt adja meg hogy a listening server
mire bind-oljon, de a kuldo reszt nem sikerult jobb belatasra birnom.

5-letek?

cya,
grin


Balazs Scheidler

unread,
Dec 6, 1997, 3:00:00 AM12/6/97
to

On Fri, 5 Dec 1997, Peter Gervai wrote:

hozzatennek meg az elozo levelemhez... belekukkantottam a kernel forrasba,
hogy mi alapjan valasztja ki a forras IP cimet. Mino meglepetes a routeing
tabla alapjan (ill. van valami rt cache, ami egy hash tabla arrol, hogy az
utolso nehany celcim melyik route rule-t valasztotta. Ezt a cache-t
meg lehet nezni route -Cn paranccsal, ha eleg uj hozza a net-tools-od,
nalam 1.41-es van)

Szoval szerintem az lehet a problema, hogy tobb route bejegyzesre is
illeszkedik a celcim. Ez akkor lehet, ha a tobb (valos, vagy virtualis)
netmaskja olyan, hogy a packet "kitalal". Nalunk a eth0:0 netmaskja
255.255.255.255, tehat erre nem talal ki egyetlen packet sem, csak az ami
direkte neki szol.

--- Bazsi
* Author of Turbo Vision Resource WorkShop, http://www.bitsoft.com/tvrw


Peter Gervai

unread,
Dec 6, 1997, 3:00:00 AM12/6/97
to

On Sat, 6 Dec 1997, Balazs Scheidler wrote:

> hozzatennek meg az elozo levelemhez... belekukkantottam a kernel forrasba,
> hogy mi alapjan valasztja ki a forras IP cimet. Mino meglepetes a routeing
> tabla alapjan

Ezt en kernel forras nelkul is kitalaltam ;-)

Az eredeti levelben is irtam - pont emiatt - hogy barmelyik megoldas jo,
akar az ha valaki sendmail-re tudja a megoldast; de meg szuperebb ha a
kernelt lehetne befolyasolni a default kivalasztasaban.

A problema az, hogy az 'A' tartomanyban is van tobb virtual cime a gepnek,
meg a 'B' tartomanyban is. Sajnos az 'A' tartomany elso routere a 'B'
tartomanyba esik, igy a kernel a 'B' tartomanybol valaszt cimet az 'A'
helyett a kernel. Nem vagyok benne biztos hogy van kedvem kernel network
kodot hackelni ;-))

> Szoval szerintem az lehet a problema, hogy tobb route bejegyzesre is
> illeszkedik a celcim. Ez akkor lehet, ha a tobb (valos, vagy virtualis)
> netmaskja olyan, hogy a packet "kitalal".

Igy van, sot, igy kell lennie. Ezen nem lehet valtoztatni. Pontosabban az
van hogy az eth0 -> eth0:1 -> kifele uton _kellene_ mennie a packetnek, de
a linux egyszerusiti, es azonnal az eth0:1-re teszi, csakhogy igy nem jo
cimrol indul a csomag. Na jo, megyek kernel forrast nezni. :-/ (Nem hiszem
hogy lesz idom/kedvem/tudasom atirni. ;->)

cya.
grin


Balazs Scheidler

unread,
Dec 7, 1997, 3:00:00 AM12/7/97
to

On Sat, 6 Dec 1997, Peter Gervai wrote:

>
> > Szoval szerintem az lehet a problema, hogy tobb route bejegyzesre is
> > illeszkedik a celcim. Ez akkor lehet, ha a tobb (valos, vagy virtualis)
> > netmaskja olyan, hogy a packet "kitalal".
>
> Igy van, sot, igy kell lennie. Ezen nem lehet valtoztatni. Pontosabban az
> van hogy az eth0 -> eth0:1 -> kifele uton _kellene_ mennie a packetnek, de
> a linux egyszerusiti, es azonnal az eth0:1-re teszi, csakhogy igy nem jo
> cimrol indul a csomag. Na jo, megyek kernel forrast nezni. :-/ (Nem hiszem
> hogy lesz idom/kedvem/tudasom atirni. ;->)
>

szerintem nem a kernel-t kellene turkalni, az jol van ugy, ahogy van, mert
szerintem nem veletlen, hogy igy talalja ki a forras cimet. A sendmail-ben
viszont viszonylag egyszeru atirni.

daemon.c, makeconnection fuggvenyben nyitja meg a socket-et, ide kene
beirni egy bind-ot, lehetoleg ugy, hogy a .cf filebol vegye a cimet. (a
cf file-t, ha jol lattam, akkor a conf.c ertelmezi)

Grin

unread,
Dec 9, 1997, 3:00:00 AM12/9/97
to

On Sun, 7 Dec 1997, Balazs Scheidler wrote:

> > > Szoval szerintem az lehet a problema, hogy tobb route bejegyzesre is
> > > illeszkedik a celcim. Ez akkor lehet, ha a tobb (valos, vagy virtualis)
> > > netmaskja olyan, hogy a packet "kitalal".
> >
> > Igy van, sot, igy kell lennie. Ezen nem lehet valtoztatni. Pontosabban az
> > van hogy az eth0 -> eth0:1 -> kifele uton _kellene_ mennie a packetnek, de
> > a linux egyszerusiti, es azonnal az eth0:1-re teszi, csakhogy igy nem jo
> > cimrol indul a csomag. Na jo, megyek kernel forrast nezni. :-/ (Nem hiszem
> > hogy lesz idom/kedvem/tudasom atirni. ;->)
>
> szerintem nem a kernel-t kellene turkalni, az jol van ugy, ahogy van, mert
> szerintem nem veletlen, hogy igy talalja ki a forras cimet. A sendmail-ben
> viszont viszonylag egyszeru atirni.

Csakhogy a problema ennyire nem egyszeru, hiszen a sendmail csak egyike
azon "braindead" daemonoknak akik nem bind-olnak amikor kuldenek....

cya
grin

0 new messages