iptables && MSN Messenger 5 Filesends, de oplossing!

[Akerboom]

Het kan nu eindelijk! Zonder dat je port 6891 naar je workstation ip moet forwarden of een gekke proxy maar gewoon met UPnP.

MSN Messenger 5 heeft support voor UPnP, clients achter routers met een UPnP gateway device kunnen dus ook bestanden versturen. Er was al een tijdje z'n gateway device in de maak en nu is er eindelijk de nieuwe versie die het versturen van bestanden mogelijk maakt.

Als je een linux routertje hebt met iptables & nat dan volgt hieronder de beschrijving hoe je deze UPnP gateway moet installeren:

1. Download UPnP API - http://upnp.sourceforge.net
2. Download the gateway-0.90 - http://linux-igd.sourceforge.net
3. tar zxvf upnpsdk-1.0.4.tar.gz
4. cd upnpdsdk-1.0.4
5. Patchen: src/ssdp/ssdplib.c (lees de Install van gateway-0.90)
6. make DEBUG=1
7. make install
8. cd ..
9. tar zxvf gateway-0.9.tgz
10. cd gateway-0.90
11. make
12. make install
13. route add -net 239.0.0.0 netmask 255.0.0.0 <int_if>
14. upnpd <ext_if> <int_if>

Dan zal bij "Network Connections" (XP) er een GATE device bijkomen.
En je bent klaar om te gaan!


Problemen die je tegen kan komen:
Je iptables firewall is ingewikkelder en heeft wat extra regels nodig om forten te forwarden.
Edit "gateway-0.90/pmlist.cpp", bij "addPortForward" & "delPortForward" kan je de iptable regels voor jou firewall toevoegen/aanpassen (wel recompilen)

Je krijgt geen gateway device te zien in windows
- Zorg dat 239.0.0.0/8 niet wordt geblocked in je firewall
- Is de route goed toegevoegd?
- Bekijk /var/log/messages & /var/log/debug

/var/log/debug bestaat niet
Voeg de volgende regel toe aan /etc/syslog.conf en herstart syslogd
*.=debug -/var/log/debug

Meer problemen en oplossingen zullen vanzelf in de thread verschijnen...

Happy filesending

ps. Ja over de veiligheid van UPnP valt zeker te twisten, maar daar gaat deze thread niet over!

[veldmuis]

mja, mn router draait kernel 2.2.21, en kheb hiero: http://lt.nett.org/ip_masq_mods/ ip_masq_mms.o weggetrokken, insmodje, en filetransfers werken prima

ook met msn 4.7...en 5.0 ook uiteraard

dus dat het kan is niet echt nieuw

op die site staat btw ook oplossing voor netmeeting enzo

[Verwijderd]

Jammer dat het er niet voor FreeBSD Is

[Akerboom]

Verwijderd schreef op 25 December 2002 @ 21:47:
Jammer dat het er niet voor FreeBSD Is

De nieuwe versie nog niet, de oude wel...

Maar hij wordt wel geport, even geduld nog!

meer info: http://sourceforge.net/forum/message.php?msg_id=1638275

[Akerboom]

veldmuis schreef op 25 December 2002 @ 21:44:
mja, mn router draait kernel 2.2.21, en kheb hiero: http://lt.nett.org/ip_masq_mods/ ip_masq_mms.o weggetrokken, insmodje, en filetransfers werken prima

ook met msn 4.7...en 5.0 ook uiteraard

dus dat het kan is niet echt nieuw

op die site staat btw ook oplossing voor netmeeting enzo

in de topic staat al dat het hier om iptables gaat...
verder geef ik ook al aan dat er zelfs met een iptables firewall manieren waren.
Deze hadden allemaal hun nadelen, de manier waar ik over schrijf werkt op de zelfe manier als hardware routers doen en dus de beste IMHO.

[not-known]

misschien nog een ander topic gemist? maar dr is nog een andere tool van http://reaim.sourceforge.net die hetzelfde doet
ook voor iptables, dus helemaal nieuw is het niet.

MSN/IPTables: werken aan oplossing ***Gevonden!*** voor de duidelijkheid, gaat hier over.

het wachten is nu nog steeds op het werken van het voice gedoe.

[Verwijderd]

UPnP was toch iets wat je per definitie juist _niet_ wil ?

[MikeN]

Beetje jammer dat de linux-igd site alleen in Internet Explorer werkt (bij mij dan).
In ieder geval staat op de todo van de gateway iets als "Figure out how to implement security", dus ik laat hem nog maar even links liggen

[Verwijderd]

thnx ik weet genoeg

[FrankGuthrie]

TormentoR schreef op 25 December 2002 @ 22:01:
[...]


De nieuwe versie nog niet, de oude wel...

Maar hij wordt wel geport, even geduld nog!

meer info: http://sourceforge.net/forum/message.php?msg_id=1638275

Ik zie bij het lezen(van BSD documentatie) de hele tijd geport. Betekent dat niet hetzelfde als geschikt gemaakt/aangepast worden?

[Akerboom]

not-known schreef op 25 December 2002 @ 23:45:
misschien nog een ander topic gemist? maar dr is nog een andere tool van http://reaim.sourceforge.net die hetzelfde doet
ook voor iptables, dus helemaal nieuw is het niet.

MSN/IPTables: werken aan oplossing ***Gevonden!*** voor de duidelijkheid, gaat hier over.

het wachten is nu nog steeds op het werken van het voice gedoe.

Met UPnP werken al deze functies in MSN ook...

(omdat msn 5 nu geheel UPnP compaible is)

[Akerboom]

Verwijderd schreef op 25 December 2002 @ 23:46:
UPnP was toch iets wat je per definitie juist _niet_ wil ?

Als jij achter je router, geen voice/video/filesend/remote assitents/whiteboard ed. wil, dan moet je het niet nemen.

Anders biedt het voor al deze dingen DE oplossing!

[not-known]

TormentoR schreef op 26 December 2002 @ 01:35:
[...]


Als jij achter je router, geen voice/video/filesend/remote assitents/whiteboard ed. wil, dan moet je het niet nemen.

Anders biedt het voor al deze dingen DE oplossing!

HO!, voor filesend heb je geen upnp meer nodig

voor alle andere meuk wel, maar aangezien je upnp liever niet wil draaien, iig IK niet moeten we nog ff wachten tot MS bereid is ook die meuk in het protocol te veranderen.
volgens mij is dat toch geen onoverkomelijk groot probleem, maar ja dr zal vast een andere reden achter zitten......

[Verwijderd]

Ik was ook al op zoek naar een degelijke oplossing voor 't probleem. Maar aangezien die UpNP gateway nogal een groot risico geeft voor de veiligheid van m'n netwerk kies ik liever niet voor die oplossing. Overigens hoef ik alleen maar file'tjes te sturen en te ontvangen, dat voice en video gebeuren hoeft allemaal niet van mij. Dus 'k ben nog op zoek naar een degelijke oplossing voor filesends.

[Brazza]

offtopic:
welke Msn client is er dan die filetransfer ondersteunt

Goed nieuws, toch maar es een nwe OS erop gooien..

[ Voor 4% gewijzigd door Brazza op 26-12-2002 01:54 ]

[not-known]

Verwijderd schreef op 26 December 2002 @ 01:48:
Ik was ook al op zoek naar een degelijke oplossing voor 't probleem. Maar aangezien die UpNP gateway nogal een groot risico geeft voor de veiligheid van m'n netwerk kies ik liever niet voor die oplossing. Overigens hoef ik alleen maar file'tjes te sturen en te ontvangen, dat voice en video gebeuren hoeft allemaal niet van mij. Dus 'k ben nog op zoek naar een degelijke oplossing voor filesends.

dan is met misschien handig om:

1. msn 5.x te draaien (zoals meeste mensen)
2. poort 6891 tm 6900 te forwarden

geen extra utilities nodig enzo, werkt meteen (althans bij mij )

[Akerboom]

Verwijderd schreef op 26 December 2002 @ 01:48:
Ik was ook al op zoek naar een degelijke oplossing voor 't probleem. Maar aangezien die UpNP gateway nogal een groot risico geeft voor de veiligheid van m'n netwerk kies ik liever niet voor die oplossing. Overigens hoef ik alleen maar file'tjes te sturen en te ontvangen, dat voice en video gebeuren hoeft allemaal niet van mij. Dus 'k ben nog op zoek naar een degelijke oplossing voor filesends.

Security valt wel mee, moet gewoon een virusscanner hebben zodat je geen trojan krijgt die van UPnP gebruik maakt om zicht voor het www ter beschikking te stellen.

En een alternatief is de wel bekende proxy: http://reaim.sourceforge.net
(deze geeft alleen filesend functionaliteit)

[Verwijderd]

not-known schreef op 26 December 2002 @ 01:56:
[...]


dan is met misschien handig om:

1. msn 5.x te draaien (zoals meeste mensen)
2. poort 6891 tm 6900 te forwarden

geen extra utilities nodig enzo, werkt meteen (althans bij mij )

Hmmz, ik draai MSN 5.x alleen forward ik die poorten dus nog niet. Ik neem echter aan dat dat alleen geld voor 't ontvangen van bestanden, aangezien voor het versturen de pakketjes van MSN herschreven moeten worden met het goede IP. Maar ik zal het eens proberen binnenkort.

[Akerboom]

Verwijderd schreef op 26 december 2002 @ 01:58:
[...]


Hmmz, ik draai MSN 5.x alleen forward ik die poorten dus nog niet. Ik neem echter aan dat dat alleen geld voor 't ontvangen van bestanden, aangezien voor het versturen de pakketjes van MSN herschreven moeten worden met het goede IP. Maar ik zal het eens proberen binnenkort.

Dit is allemaal beetje offtopic, maar nee dat werk vanaf MSN5 voor ontvangen.

Hier geldt wel dat het MSN5 -> MSN5 moet zijn...

Verder is het door de beperkte port range niet mogelijk oneindig veel clients filesend support te bieden, niet handig op bv. een school netwerk

[not-known]

Verwijderd schreef op 26 december 2002 @ 01:58:
[...]


Hmmz, ik draai MSN 5.x alleen forward ik die poorten dus nog niet. Ik neem echter aan dat dat alleen geld voor 't ontvangen van bestanden, aangezien voor het versturen de pakketjes van MSN herschreven moeten worden met het goede IP. Maar ik zal het eens proberen binnenkort.

dat is juist het leuke, sinds 5.x is het protocol ietsje aangepast zodat je met die geforwarde poorten WEL kan zenden

ontvangen kon ik altijd al, ookal forwarde ik niks

[Verwijderd]

not-known schreef op 26 December 2002 @ 02:01:
[...]


dat is juist het leuke, sinds 5.x is het protocol ietsje aangepast zodat je met die geforwarde poorten WEL kan zenden

ontvangen kon ik altijd al, ookal forwarde ik niks

Hmmz, ik kon ook altijd ontvangen met ipchains, maar nu ik iptables heb werkt het niet meer. Beetje vaag dus.

[active2]

Geldt dit ook voor Gaim en de andere msn clients ?

[Verwijderd]

In kmess werkt het hier allemaal perfect (ontvangen/versturen)

[Akerboom]

active2 schreef op 26 december 2002 @ 11:20:
Geldt dit ook voor Gaim en de andere msn clients ?

Deze hebben zo ver ik weet geen UPnP support.. dus nee

[not-known]

active2 schreef op 26 December 2002 @ 11:20:
Geldt dit ook voor Gaim en de andere msn clients ?

onder ipchains wel altijd voor zover ik ze heb geprobeerd.
verzenden en ontvangen werkt daarbij gewoon op de standaard manier als ik al beschreef.
onder iptables heb ik ze nooit getest, dus durf ik niet te zeggen

[duronbug]

Dat met ReAim werkt niet meer met MSN 5. Ik had het hier ook altijd draaien met msn 4.6 en 4.7, maar als je dan overgaat naar msn 5 dan klapt reaim eruit zodra je je aanmeld bij msn.

Mischien is dit dan eindelijk een goeie vervanging van reaim voor msn 5.

[eborn]

Als het protocol inderdaad gewijzigd is dan zal REAIM het wel niet meer snappen Eigenlijk is het een heel simpel programma en door zulk soort wijzigingen kan het gewoon gigantisch de soep in draaien

Ik zal eens kijken of ik het probleem kan fixen.

[Verwijderd]

Hmmz, heb eens ffies gekeken naar die UPnP server, maar 't werkt dus niet. De requests komen niet binnen op m'n server ('k tail -f /var/log/debug). Overigens zie 'k nergens een Gate staan in m'n Netwerkverbindingen op m'n Windows machine. Iemand ideeën?

/var/log/debug:

code:

Jan 16 22:27:16 Linux upnpd: Intializing UPnP with desc_doc_url=http://192.168.0.1:2869/gatedesc.xml 
Jan 16 22:27:16 Linux upnpd: ipaddress=192.168.0.1 port=2869 
Jan 16 22:27:16 Linux upnpd: conf_dir_path=/etc/linuxigd/ 
Jan 16 22:29:48 Linux upnpd: Intializing UPnP with desc_doc_url=http://192.168.0.1:2869/gatedesc.xml 
Jan 16 22:29:48 Linux upnpd: ipaddress=192.168.0.1 port=2869 
Jan 16 22:29:48 Linux upnpd: conf_dir_path=/etc/linuxigd/ 
Jan 16 22:29:50 Linux upnpd: UPnP Initialization Completed
Jan 16 22:29:50 Linux upnpd: Setting webserver root directory -- /etc/linuxigd/ 
Jan 16 22:29:50 Linux upnpd: Registering the root device 
Jan 16 22:29:50 Linux upnpd: RootDevice Registered 
Jan 16 22:29:50 Linux upnpd: Initializing State Table 
Jan 16 22:29:50 Linux upnpd: State Table Initialized 
Jan 16 22:29:50 Linux upnpd: Advertisements Sent

Ennuhmz, sorry voor 't schopje .

[Verwijderd]

Oh, ik zal nog ffies wat andere handige dingen er bij zetten:

iptables -L -v -n

code:

root@Linux:/home/jmezach/linux-igd# iptables -L -v -n
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    1    76 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0          
    0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0          
  298 22425 ACCEPT     all  --  eth0   *       192.168.0.0/24       0.0.0.0/0          
    0     0 drop-and-log-it  all  --  eth1   *       192.168.0.0/24       0.0.0.0/0          
  243 22574 ACCEPT     all  --  eth1   *       0.0.0.0/0            217.120.225.158    state RELATED,ESTABLISHED 
    0     0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0          tcp spt:68 dpt:67 
    0     0 ACCEPT     udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0          udp spt:68 dpt:67 
    0     0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0          tcp dpt:2869 
    3   160 ACCEPT     tcp  --  eth1   *       0.0.0.0/0            217.120.225.158    state NEW,RELATED,ESTABLISHED tcp dpt:80 
   23  1360 ACCEPT     tcp  --  eth1   *       0.0.0.0/0            217.120.225.158    state NEW,RELATED,ESTABLISHED tcp dpt:443 
    1    40 ACCEPT     tcp  --  eth1   *       0.0.0.0/0            217.120.225.158    state NEW,RELATED,ESTABLISHED tcp dpt:21 
    0     0 ACCEPT     tcp  --  eth1   *       145.76.99.13         217.120.225.158    state NEW,RELATED,ESTABLISHED tcp dpt:22 
    0     0 ACCEPT     tcp  --  eth1   *       0.0.0.0/0            217.120.225.158    state NEW,RELATED,ESTABLISHED tcp dpt:7777 
  139  7242 drop-and-log-it  all  --  *      *       0.0.0.0/0            0.0.0.0/0          

Chain FORWARD (policy ACCEPT 4 packets, 161 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0          
 9093 9541K ACCEPT     all  --  eth1   eth0    0.0.0.0/0            0.0.0.0/0          state RELATED,ESTABLISHED 
 6361 1045K ACCEPT     all  --  eth0   eth1    0.0.0.0/0            0.0.0.0/0          
    0     0 ACCEPT     tcp  --  eth1   eth0    0.0.0.0/0            0.0.0.0/0          tcp dpt:3389 state NEW,RELATED,ESTABLISHED 
    0     0 ACCEPT     tcp  --  eth1   eth0    0.0.0.0/0            0.0.0.0/0          tcp dpt:6500 state NEW,RELATED,ESTABLISHED 
    0     0 drop-and-log-it  all  --  *      *       0.0.0.0/0            0.0.0.0/0          

Chain OUTPUT (policy DROP 12 packets, 6576 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    1    76 ACCEPT     all  --  *      lo      0.0.0.0/0            0.0.0.0/0          
    0     0 ACCEPT     all  --  *      lo      0.0.0.0/0            0.0.0.0/0          
  304 41629 ACCEPT     all  --  *      eth0    192.168.0.0/24       192.168.0.0/24     
    0     0 ACCEPT     all  --  *      eth0    217.120.225.158      192.168.0.0/24     
    0     0 drop-and-log-it  all  --  *      eth1    0.0.0.0/0            192.168.0.0/24     
  212 16286 ACCEPT     all  --  *      eth1    217.120.225.158      0.0.0.0/0          
    0     0 ACCEPT     tcp  --  *      eth0    192.168.0.0/24       255.255.255.255    tcp spt:67 dpt:68 
    2   660 ACCEPT     udp  --  *      eth0    192.168.0.0/24       255.255.255.255    udp spt:67 dpt:68 
    0     0 drop-and-log-it  all  --  *      *       0.0.0.0/0            0.0.0.0/0          

Chain drop-and-log-it (5 references)
 pkts bytes target     prot opt in     out     source               destination         
  139  7242 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0          
root@Linux:/home/jmezach/linux-igd#

route -v

code:

root@Linux:/home/jmezach/linux-igd# route -v
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.0     *               255.255.255.0   U     0      0        0 eth0
217.120.224.0   *               255.255.254.0   U     0      0        0 eth1
239.0.0.0       *               255.0.0.0       U     0      0        0 eth0
loopback        *               255.0.0.0       U     0      0        0 lo
default         r1-fe4-1-0-sec. 0.0.0.0         UG    0      0        0 eth1
root@Linux:/home/jmezach/linux-igd#

[Vorlon]

Hmm, dan ben ik dus niet de enige....

Ik krijg ook geen GATE device in WinXp. Volgens mij zit het in het firewall scripsel. Of het is toch nog een probleem met Xp.

Mja, ReAim doet het niet lekker met msn5 en aangezien ik hiermee ook zou moeten kunnen cammen... Ik ben ook al met een h323 proxy bezig geweest maar dat is helemaal meer bedoelt voor VoIP. (telefoon dus..)

Wat info: (ja, staan ip's in maar is toch dialup )

viper:~ # tail -f /var/log/debug

code:

Jan 16 23:15:03 viper upnpd: Intializing UPnP with desc_doc_url=http://192.168.0.1:2869/gatedesc.xml
Jan 16 23:15:03 viper upnpd: ipaddress=192.168.0.1 port=2869
Jan 16 23:15:03 viper upnpd: conf_dir_path=/etc/linuxigd/
Jan 16 23:15:05 viper upnpd: UPnP Initialization Completed
Jan 16 23:15:05 viper upnpd: Setting webserver root directory -- /etc/linuxigd/
Jan 16 23:15:05 viper upnpd: Registering the root device
Jan 16 23:15:05 viper upnpd: RootDevice Registered
Jan 16 23:15:05 viper upnpd: Initializing State Table
Jan 16 23:15:06 viper upnpd: State Table Initialized
Jan 16 23:15:06 viper upnpd: Advertisements Sent

viper:~ # iptables -L -v -n

code:

Chain INPUT (policy DROP 1 packets, 40 bytes)
 pkts bytes target     prot opt in     out     source               destination
   28  8582 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
13608 1713K ACCEPT     all  --  eth0   *       192.168.0.0/24       0.0.0.0/0
    0     0 drop-and-log-it  all  --  ippp0  *       192.168.0.0/24       0.0.0.0/0
10511 7931K ACCEPT     all  --  ippp0  *       0.0.0.0/0            195.18.79.83       state RELATED,ESTABLISHED
    0     0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0          tcp spt:68 dpt:67
    0     0 ACCEPT     udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0          udp spt:68 dpt:67
    0     0 ACCEPT     tcp  --  ippp0  *       0.0.0.0/0            195.18.79.83       state NEW,RELATED,ESTABLISHED tcp dpt:3000
    0     0 ACCEPT     tcp  --  ippp0  *       0.0.0.0/0            195.18.79.83       state NEW,RELATED,ESTABLISHED tcp dpt:80
   31  6163 drop-and-log-it  all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
  335 35972 ACCEPT     all  --  ippp0  eth0    0.0.0.0/0            0.0.0.0/0          state RELATED,ESTABLISHED
  347 30917 ACCEPT     all  --  eth0   ippp0   0.0.0.0/0            0.0.0.0/0
    0     0 drop-and-log-it  all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
   28  8582 ACCEPT     all  --  *      lo      0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  *      eth0    195.18.79.83         192.168.0.0/24
15263 9140K ACCEPT     all  --  *      eth0    192.168.0.0/24       192.168.0.0/24
    0     0 drop-and-log-it  all  --  *      ippp0   0.0.0.0/0            192.168.0.0/24
11003 1525K ACCEPT     all  --  *      ippp0   195.18.79.83         0.0.0.0/0
    0     0 ACCEPT     tcp  --  *      eth0    192.168.0.0/24       255.255.255.255    tcp spt:67 dpt:68
    0     0 ACCEPT     udp  --  *      eth0    192.168.0.0/24       255.255.255.255    udp spt:67 dpt:68
   58  8398 drop-and-log-it  all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain drop-and-log-it (5 references)
 pkts bytes target     prot opt in     out     source               destination
   89 14561 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0          LOG flags 0 level 6
   89 14561 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

viper:~ # route -v

code:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
hmm-dca-ap02-d0 *               255.255.255.255 UH    0      0        0 ippp0
192.168.0.0     *               255.255.255.0   U     0      0        0 eth0
239.0.0.0       *               255.0.0.0       U     0      0        0 eth0
default         hmm-dca-ap02-d0 0.0.0.0         UG    0      0        0 ippp0

ehm, sorry voor de layout...

[ Voor 1% gewijzigd door Vorlon op 16-01-2003 23:31 . Reden: oeps... ]

[Verwijderd]

Zo te zien hetzelfde probleem. Toch een beetje vreemd allemaal. 't zal inderdaad de firewall zijn die 't spul blokkeerd, maar ik heb eens ffies m'n LOG regeltje aangezet, maar die rapporteert helemaal niks.

Wou 'k vanavond eens met een leuk meisje gaan kletsen, werkt 't niet . 't is ook altijd 't zelfde met MS . Nou jah, morgen is er weer een dag .

[Verwijderd]

Is er nog iemand met ideeën wat dit betreft? Beetje vervelend dat 't nou weer niet werkt. 'k heb toch echt de instructies gevolgd?

[Robbeke]

heb een uPnP router, werkt gewoon met msn 4.6 enzovoorts... (wel windows xp, ook uPnP ondersteuning)

nooit ergens last van gehad... (behalve rare disconnects met ISP, eb smc support ervoor gebeld)

[Verwijderd]

Robbeke schreef op 17 January 2003 @ 10:56:
heb een uPnP router, werkt gewoon met msn 4.6 enzovoorts... (wel windows xp, ook uPnP ondersteuning)

nooit ergens last van gehad... (behalve rare disconnects met ISP, eb smc support ervoor gebeld)

Mjah, 'k heb dus ook Windows XP, dus dat zit wel goed. Draai overigens MSN 5, maar 't schijnt dan zelfs nog beter te werken. Alleen ik krijg dus nooit dat Gate device in m'n Netwerkverbindingen. Dus die UPnP server werkt dus niet.

[Vorlon]

Taz heb je ook al een keer je firewall leeg gegooid? (Alles op ACCEPT zetten en de blok regels uitcommenteren) En dan als unpnpd draait je winxp doos rebooten.

Ik heb nu dus die extra verbinding in m'n network connections. Helaas kan ik nog steeds niet cammen met msn 5...

[Verwijderd]

Vorlon schreef op 17 januari 2003 @ 20:28:
Taz heb je ook al een keer je firewall leeg gegooid? (Alles op ACCEPT zetten en de blok regels uitcommenteren) En dan als unpnpd draait je winxp doos rebooten.

Ik heb nu dus die extra verbinding in m'n network connections. Helaas kan ik nog steeds niet cammen met msn 5...

Mjah, ik heb net m'n firewall volledig open gezet en ik heb al een keer eerder m'n Windows machine gereboot. Heb ook nog eens m'n firewall log (waar alleen gedropte packets in staan) in de gaten gehouden terwijl ik upnpd op starte. Er stond niks in dat met UPnP te maken had. Ik begrijp er echt helemaal niks van, en 'k weet ook niet waar 'k de oorzaak moet zoeken, bij m'n Linux server of m'n Windows machine?

[Vorlon]

Eeeh, nou begrijp ik het ook niet meer... Ik had net na een reboot dat gateway icoon en nu is het weer pleite...

Wel veel zooi in /var/log/debug

code:

Jan 17 18:07:05 viper upnpd: Intializing UPnP with desc_doc_url=http://192.168.0.1:2869/gatedesc.xml
Jan 17 18:07:05 viper upnpd: ipaddress=192.168.0.1 port=2869
Jan 17 18:07:05 viper upnpd: conf_dir_path=/etc/linuxigd/
Jan 17 18:07:07 viper upnpd: UPnP Initialization Completed
Jan 17 18:07:07 viper upnpd: Setting webserver root directory -- /etc/linuxigd/
Jan 17 18:07:07 viper upnpd: Registering the root device
Jan 17 18:07:07 viper upnpd: RootDevice Registered
Jan 17 18:07:07 viper upnpd: Initializing State Table
Jan 17 18:07:07 viper upnpd: State Table Initialized
Jan 17 18:07:07 viper upnpd: Advertisements Sent
Jan 17 18:14:17 viper kernel: ippp, open, slot: 0, minor: 0, state: 0000
Jan 17 18:14:17 viper kernel: ippp_ccp: allocated reset data structure c2572800
Jan 17 18:14:17 viper kernel: ippp_ccp: freeing reset data structure c35ef800
Jan 17 18:28:39 viper kernel: ippp, open, slot: 1, minor: 0, state: 0000
Jan 17 18:28:39 viper kernel: ippp_ccp: allocated reset data structure c2d10000
Jan 17 18:28:39 viper kernel: ippp_ccp: freeing reset data structure c2572800
Jan 17 19:12:17 viper linesrv[1083]: 192.168.0.10:1033 registered
Jan 17 19:12:22 viper upnpd: Failure in GateDeviceDeletePortMapping: DeletePortMap: Proto:TCP Port:2801
Jan 17 19:12:22 viper upnpd: Failure in GateDeviceDeletePortMapping: DeletePortMap: Proto:UDP Port:43507
Jan 17 19:29:58 viper linesrv[1083]: 192.168.0.10:1033 registered
Jan 17 19:57:36 viper kernel: ippp, open, slot: 0, minor: 0, state: 0000
Jan 17 19:57:36 viper kernel: ippp_ccp: allocated reset data structure c2cf0800
Jan 17 19:57:36 viper kernel: ippp_ccp: freeing reset data structure c2d10000
Jan 17 20:00:23 viper linesrv[1083]: 192.168.0.200:1054 registered
Jan 17 20:11:17 viper kernel: ippp, open, slot: 1, minor: 0, state: 0000
Jan 17 20:11:17 viper kernel: ippp_ccp: allocated reset data structure c25dd800
Jan 17 20:11:17 viper kernel: ippp_ccp: freeing reset data structure c2cf0800
Jan 17 20:12:02 viper upnpd: Failure in GateDeviceGetSpecificPortMappingEntry: PortMapping Doesn't Exist...
Jan 17 20:12:02 viper upnpd: AddPortMap: RemoteHost: (null) Prot: 6 ExtPort: 42193 Int: 192.168.0.200.42193
Jan 17 20:12:03 viper upnpd: AddPortMap: RemoteHost: (null) Prot: 6 ExtPort: 42193 Int: 192.168.0.200.42193
Jan 17 20:12:03 viper upnpd: DeletePortMap: Proto:TCP Port:42193
Jan 17 20:13:45 viper upnpd: AddPortMap: RemoteHost: (null) Prot: 17 ExtPort: 29947 Int: 192.168.0.200.15124
Jan 17 20:13:45 viper upnpd: AddPortMap: RemoteHost: (null) Prot: 6 ExtPort: 53985 Int: 192.168.0.200.8626
Jan 17 20:18:38 viper upnpd: Failure in GateDeviceGetSpecificPortMappingEntry: PortMapping Doesn't Exist...
Jan 17 20:18:38 viper upnpd: AddPortMap: RemoteHost: (null) Prot: 6 ExtPort: 42193 Int: 192.168.0.200.42193
Jan 17 20:18:38 viper upnpd: AddPortMap: RemoteHost: (null) Prot: 6 ExtPort: 42193 Int: 192.168.0.200.42193
Jan 17 20:18:38 viper upnpd: DeletePortMap: Proto:TCP Port:42193

[Verwijderd]

Vorlon schreef op 17 January 2003 @ 21:07:
Eeeh, nou begrijp ik het ook niet meer... Ik had net na een reboot dat gateway icoon en nu is het weer pleite...

Wel veel zooi in /var/log/debug

code:

...

Mjah, 't schijnt zo te zijn dat je dat alleen de eerste keer ziet of zo. Maar ik heb dat hele icoon nog nie gezien.

[savale]

ehm beetje offtopic maar ik gebruik nu ipchains om mijn internet te delen en nu wil ik op de pc met ip 192.168.0.2 edonkey draaien maar daarvoor moet ik poort 4661 en poort 4662 doormappen weet iemand hoe ik dit doe in linux (server ip is 192.168.0.1 netmask 255.255.255.0, internet zit op eth0)

[Verwijderd]

savale schreef op 17 januari 2003 @ 21:48:
ehm beetje offtopic maar ik gebruik nu ipchains om mijn internet te delen en nu wil ik op de pc met ip 192.168.0.2 edonkey draaien maar daarvoor moet ik poort 4661 en poort 4662 doormappen weet iemand hoe ik dit doe in linux (server ip is 192.168.0.1 netmask 255.255.255.0, internet zit op eth0)

'k deed dat op de volgende manier (toen 'k nog ipchains had).

code:

# eDonkey fix
#
echo "Enabling eDonkey fix"  
ipmasqadm portfw -a -P tcp -L $extip 4661 -R 192.168.0.2 4661
ipmasqadm portfw -a -P tcp -L $extip 4662 -R 192.168.0.2 4662
ipmasqadm portfw -a -P udp -L $extip 4665 -R 192.168.0.2 4665

Maar ehmz, wel heel erg off-topic idd.

[savale]

Verwijderd schreef op 17 January 2003 @ 21:50:
[...]


'k deed dat op de volgende manier (toen 'k nog ipchains had).

code:

# eDonkey fix
#
echo "Enabling eDonkey fix"  
ipmasqadm portfw -a -P tcp -L $extip 4661 -R 192.168.0.2 4661
ipmasqadm portfw -a -P tcp -L $extip 4662 -R 192.168.0.2 4662
ipmasqadm portfw -a -P udp -L $extip 4665 -R 192.168.0.2 4665

Maar ehmz, wel heel erg off-topic idd.

hehe maar kan zoiets niet met iptables anders? eventueel ook me inet delen enzo ik snap er de ballen vna allemaal maar heb bijna me routertje draaien namelijk (na heel veel howto's)

[ Voor 4% gewijzigd door savale op 17-01-2003 21:52 ]

[Verwijderd]

savale schreef op 17 januari 2003 @ 21:52:
[...]


hehe maar kan zoiets niet met iptables anders? eventueel ook me inet delen enzo ik snap er de ballen vna allemaal maar heb bijna me routertje draaien namelijk (na heel veel howto's)

Ehmz, je wou 't toch voor ipchains weten? Da's dus op die manier. Met iptables gaat 't weer anders. Om precies te zijn op deze manier:

code:

#echo "     - NAT: Enabling port forwarding for port TCP 4661 and 4662 and UDP 4665 (eMule)"
#$IPTABLES -A FORWARD -i $EXTIF -o $INTIF -p tcp --dport 4661 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
#$IPTABLES -A FORWARD -i $EXTIF -o $INTIF -p tcp --dport 4662 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
#$IPTABLES -A FORWARD -i $EXTIF -o $INTIF -p udp --dport 4665 -j ACCEPT
#$IPTABLES -A PREROUTING -t nat -p tcp -d $EXTIP --dport 4661 -j DNAT --to 192.168.0.2:4661
#$IPTABLES -A PREROUTING -t nat -p tcp -d $EXTIP --dport 4662 -j DNAT --to 192.168.0.2:4662
#$IPTABLES -A PREROUTING -t nat -p udp -d $EXTIP --dport 4665 -j DNAT --to 192.168.0.0:4665

Zonder de #'jes natuurlijk .

[ Voor 4% gewijzigd door Verwijderd op 17-01-2003 21:54 ]

[savale]

hehe maaruh is dan ook me inet gedeeld meteen aan alle 192.168.0.x adressen? of kan dat weer niet met iptables ?

[Verwijderd]

savale schreef op 17 januari 2003 @ 21:57:
hehe maaruh is dan ook me inet gedeeld meteen aan alle 192.168.0.x adressen? of kan dat weer niet met iptables ?

Dit is portforwarding, da's iets heel anders dan Internet delen. Voor informatie daarover verwijs ik je naar de IP Masquerading HowTo (ongetwijfeld te vinden op www.linuxdocs.org) .

[savale]

Verwijderd schreef op 17 januari 2003 @ 21:58:
[...]


Dit is portforwarding, da's iets heel anders dan Internet delen. Voor informatie daarover verwijs ik je naar de IP Masquerading HowTo (ongetwijfeld te vinden op www.linuxdocs.org) .

ok dus ik kan lekker ipchains gebruiken voor inet en iptables daarnaast voor portforwarding?

[savale]

savale schreef op 17 January 2003 @ 22:01:
[...]


ok dus ik kan lekker ipchains gebruiken voor inet en iptables daarnaast voor portforwarding?

(voelt zich n00b) damn ben lekker bezig

[ Voor 6% gewijzigd door savale op 17-01-2003 22:01 ]

[Verwijderd]

savale schreef op 17 januari 2003 @ 22:01:
[...]


ok dus ik kan lekker ipchains gebruiken voor inet en iptables daarnaast voor portforwarding?

Nee, ipchains en iptables is in principe hetzelfde. Alleen is ipchains voor Linux 2.2.x kernels en iptables voor 2.4.x kernels. Bij iptables is portforwarding geintegreerd, bij ipchains heb je 't tooltje ipmasqadm nodig om portforwarding te regelen.

[savale]

Verwijderd schreef op 17 January 2003 @ 22:02:
[...]


Nee, ipchains en iptables is in principe hetzelfde. Alleen is ipchains voor Linux 2.2.x kernels en iptables voor 2.4.x kernels. Bij iptables is portforwarding geintegreerd, bij ipchains heb je 't tooltje ipmasqadm nodig om portforwarding te regelen.

kijk daar heb ik wat aan! ennuh wel typisch want ik draai de 2.2.x kernel maar heb dus echt iptables (debian woody)

[Verwijderd]

savale schreef op 17 January 2003 @ 22:03:
[...]


kijk daar heb ik wat aan! ennuh wel typisch want ik draai de 2.2.x kernel maar heb dus echt iptables (debian woody)

Mjah, 't zou misschien best wel kunnen, maar wat ik heb begrepen is dat iptables voor 2.4.x geschreven is en ipchains voor 2.2.x. D'r is overigens wel een kernel module om ipchains te gebruiken op 2.4.x kernels, dus andersom zou 't weer wel kunnen. Dus ik zou nog maar eens ffies goed kijken wat je hebt, en toch echt ipchains gebruiken als je een 2.2.x kernel hebt (of upgraden naar 2.4.x natuurlijk )

[savale]

Verwijderd schreef op 17 januari 2003 @ 22:05:
[...]


Mjah, 't zou misschien best wel kunnen, maar wat ik heb begrepen is dat iptables voor 2.4.x geschreven is en ipchains voor 2.2.x. D'r is overigens wel een kernel module om ipchains te gebruiken op 2.4.x kernels, dus andersom zou 't weer wel kunnen. Dus ik zou nog maar eens ffies goed kijken wat je hebt, en toch echt ipchains gebruiken als je een 2.2.x kernel hebt (of upgraden naar 2.4.x natuurlijk )

ok gaat goed komen

[Vorlon]

Hmm, ik heb nu dat gateway icoon weer terug. En m'n firewall zit weer redelijk dicht.

Deze 2 regels in m'n firewall script erbij gezet:

$IPTABLES -I OUTPUT -s EXTIP -d 239.255.255.250/32 -j ACCEPT
$IPTABLES -I OUTPUT -s INTIP -d 239.255.255.250/32 -j ACCEPT

Ik weet nog niet of het al werkt. Ik vermoed van niet want volgens de poster van deze oplossing zou ik ook nog dit moeten doen:

Again because I have a CLOSED firewall (default policy is drop), I had to make some little changes to the pmlist.cpp of the upnpd distribution. In the functions addPortForward I needed to add the following line (after the one that was already in there):

sprintf(command, "/usr/sbin/iptables -I FORWARD -p %s -d %s --dport %d -j ACCEPT", prt, IntIP, IntPort);
system(command);

and in the delPortForward function:

sprintf(command, "/usr/sbin/iptables -D FORWARD -p %s -d %s --dport %d -j ACCEPT", prt, IntIP, IntPort);
system(command);

These two additions while make the firewall accept connects to only those ports that are portmapped.

Maar als ik dat toevoeg loop de compile stuk op 'prt'. Ik weet alleen niet precies wat in die variabele zou moeten staan. (ik vermoedde dat 'prt' in de nieuwere versie 'ExtPort' is maar dat werkte ook niet..)

Ik ga het nog eens proberen met een cvs versie.

Ohja, behoor je nu in msn messenger 5 te kunnen zien of het verkeer via die gateway gaat of niet? (in de connections tab staan nu namelijk nog 'direct connection' )

[ Voor 12% gewijzigd door Vorlon op 18-01-2003 13:54 . Reden: layout vernaggeld... ]

[Verwijderd]

Vorlon schreef op 18 januari 2003 @ 13:51:
Hmm, ik heb nu dat gateway icoon weer terug. En m'n firewall zit weer redelijk dicht.

Deze 2 regels in m'n firewall script erbij gezet:

$IPTABLES -I OUTPUT -s EXTIP -d 239.255.255.250/32 -j ACCEPT
$IPTABLES -I OUTPUT -s INTIP -d 239.255.255.250/32 -j ACCEPT

Ik weet nog niet of het al werkt. Ik vermoed van niet want volgens de poster van deze oplossing zou ik ook nog dit moeten doen:


[...]


Maar als ik dat toevoeg loop de compile stuk op 'prt'. Ik weet alleen niet precies wat in die variabele zou moeten staan. (ik vermoedde dat 'prt' in de nieuwere versie 'ExtPort' is maar dat werkte ook niet..)

Ik ga het nog eens proberen met een cvs versie.

Ohja, behoor je nu in msn messenger 5 te kunnen zien of het verkeer via die gateway gaat of niet? (in de connections tab staan nu namelijk nog 'direct connection' )

Dat probleem had ik ook, moet je even goed naar de variablen van die functie kijken. Ik geloof dat die prt variable een andere naam had in de nieuwe versie van die Linux IGD. Ik ga zo even die regeltjes van ook in m'n firewall gooien, kijken of die het dan ook hier doet. Bedankt voor de tip .

[Vorlon]

Verwijderd schreef op 18 januari 2003 @ 14:19:
[...]


Dat probleem had ik ook, moet je even goed naar de variablen van die functie kijken. Ik geloof dat die prt variable een andere naam had in de nieuwe versie van die Linux IGD. Ik ga zo even die regeltjes van ook in m'n firewall gooien, kijken of die het dan ook hier doet. Bedankt voor de tip .

Aha, volgens mij heet ie ipv 'prt' 'Proto' in de nieuwe versie... Nu compiled het wel. Nou nog ff iemand wakker maken die een webcam heeft....

[Verwijderd]

Heeft iemand dit op OpenBSD geprobeerd?

[Vorlon]

Verwijderd schreef op 18 January 2003 @ 15:23:
Heeft iemand dit op OpenBSD geprobeerd?

Volgens mij werkt het zo niet op OpenBSD, aangezien een post gelezen heb op de site dat er iemand bezig was dit te porten naar BSD.


M'n gateway doet het overgens nog steeds niet helemaal 100% volgens mij. Ik zou namelijk onder 'Settings' moeten kunnen zien wat er aan portmaps actief is maar dat werkt niet. MSN 5 denkt nu dat ie via een http proxy is aangesloten, maar uitgaande filetransfers doen het nog steeds niet. (cam nog niet getest, maar zal het dan ook wel niet doen...)

[Hagar]

Voor iptables is dit scriptje misschien wel makkelijk.
Ik gebruik hier stukjes van en heb totaal geen problemen met msn filesends.
Misschien heb ik ook wel gewoon geluk

[Verwijderd]

Hagar schreef op 19 januari 2003 @ 05:02:
Voor iptables is dit scriptje misschien wel makkelijk.
Ik gebruik hier stukjes van en heb totaal geen problemen met msn filesends.
Misschien heb ik ook wel gewoon geluk

Thx, ik ga dit script eens ff doorspitten om te kijken of ik nog wat aan mijn firewall kan verbeteren

[Vorlon]

Hagar schreef op 19 January 2003 @ 05:02:
Voor iptables is dit scriptje misschien wel makkelijk.
Ik gebruik hier stukjes van en heb totaal geen problemen met msn filesends.
Misschien heb ik ook wel gewoon geluk

Eeh, stukjes?? Kan je ons dan ook vertellen welke stukjes? Dat ding is huge...

Ik neem aan dat je er een en ander aan gesleuteld hebt om die upnp gateway werkend te krijgen?

Ik ga het zo wel eens even afdrukken en vergelijken met m'n huidige firewall script.

[Vorlon]

Hagar: Hoe heb je dat ding dan geconfigged?? Het werkt hier niet echt... Volgens mij is dat ding nog strikter dan wat ik al had...

[Hagar]

code:

IPTABLES="/sbin/iptables"
TCP_ALLOW="21 22 25 80"
UDP_ALLOW=""
INET_IFACE="eth0" # inet
LAN_IFACE="eth1" # intern
INTERNAL_LAN="10.0.0.0/24"
MASQ_LAN="10.0.0.0/24"
SNAT_LAN=""
DROP="DROP"
DENY_ALL=""
DENY_HOSTWISE_TCP=""
DENY_HOSTWISE_UDP=""
BLACKHOLE=""
BLACKHOLE_DROP="DROP"
ALLOW_HOSTWISE_TCP=""
ALLOW_HOSTWISE_UDP=""
TCP_FW=""
UDP_FW=""
MANGLE_TOS_OPTIMIZE="TRUE"
DHCP_SERVER="TRUE"
BAD_ICMP="5 8 9 10 15 16 17 18"
ENABLE="Y"

# Flood Params.
LOG_FLOOD="2/s"
SYN_FLOOD="20/s"
PING_FLOOD="1/s"

# Outbound filters
ALLOW_OUT_TCP=""
PROXY=""

# Below here is experimental (please report your successes/failures)
MAC_MASQ=""
MAC_SNAT=""
TTL_SAFE=""
USE_SYNCOOKIES="TRUE"
RP_FILTER="TRUE"
ACCEPT_SOURCE_ROUTE="FALSE"
SUPER_EXEMPT=""
BRAINDEAD_ISP="FALSE"
ALLOW_HOSTWISE_PROTO=""

upnp weet ik niks van, ik ben niet echt bezig met iptables.
Maar dit wekt voor mij prima

[Verwijderd]

Vorlon schreef op 18 January 2003 @ 13:51:
Hmm, ik heb nu dat gateway icoon weer terug. En m'n firewall zit weer redelijk dicht.

Deze 2 regels in m'n firewall script erbij gezet:

$IPTABLES -I OUTPUT -s EXTIP -d 239.255.255.250/32 -j ACCEPT
$IPTABLES -I OUTPUT -s INTIP -d 239.255.255.250/32 -j ACCEPT

Ik weet nog niet of het al werkt. Ik vermoed van niet want volgens de poster van deze oplossing zou ik ook nog dit moeten doen:


[...]


Maar als ik dat toevoeg loop de compile stuk op 'prt'. Ik weet alleen niet precies wat in die variabele zou moeten staan. (ik vermoedde dat 'prt' in de nieuwere versie 'ExtPort' is maar dat werkte ook niet..)

Ik ga het nog eens proberen met een cvs versie.

Ohja, behoor je nu in msn messenger 5 te kunnen zien of het verkeer via die gateway gaat of niet? (in de connections tab staan nu namelijk nog 'direct connection' )

Ik heb die regeltjes in m'n firewall gezet maar het werkt nog steeds niet. Is er iemand die het wel aan de praat gekregen heeft, die Linux IGD? Er gebeurdt op m'n Windows machine helemaal niks, en op m'n Linux server al evenmin wat. Alleen heel soms komt er ineens een AddPortMap of DeletePortMap te staan, maar voice gesprekken met MSN ho maar.

[Verwijderd]

Hmmz, ffies nog wat info. Ik zie nu 't volgende in m'n /var/log/debug staan:

code:

root@Linux:~# tail -f /var/log/debug
Jan 20 19:52:10 Linux upnpd: Intializing UPnP with desc_doc_url=http://192.168.0.1:2869/gatedesc.xml 
Jan 20 19:52:10 Linux upnpd: ipaddress=192.168.0.1 port=2869 
Jan 20 19:52:10 Linux upnpd: conf_dir_path=/etc/linuxigd/ 
Jan 20 19:52:12 Linux upnpd: UPnP Initialization Completed
Jan 20 19:52:12 Linux upnpd: Setting webserver root directory -- /etc/linuxigd/ 
Jan 20 19:52:12 Linux upnpd: Registering the root device 
Jan 20 19:52:12 Linux upnpd: RootDevice Registered 
Jan 20 19:52:12 Linux upnpd: Initializing State Table 
Jan 20 19:52:12 Linux upnpd: State Table Initialized 
Jan 20 19:52:12 Linux upnpd: Advertisements Sent 
Jan 20 20:09:28 Linux upnpd: AddPortMap: RemoteHost: (null) Prot: 17 ExtPort: 59362 Int: 192.168.0.5.8778 
Jan 20 20:09:28 Linux upnpd: AddPortMap: RemoteHost: (null) Prot: 6 ExtPort: 57582 Int: 192.168.0.5.11853 
Jan 20 20:09:28 Linux upnpd: DeletePortMap: Proto:TCP Port:57582 
Jan 20 20:09:28 Linux upnpd: DeletePortMap: Proto:UDP Port:59362 
Jan 20 20:09:29 Linux upnpd: AddPortMap: RemoteHost: (null) Prot: 17 ExtPort: 44795 Int: 192.168.0.5.15107 
Jan 20 20:09:29 Linux upnpd: AddPortMap: RemoteHost: (null) Prot: 6 ExtPort: 34030 Int: 192.168.0.5.11817

[Vorlon]

Whhaaaaa, hij doet het ....

Ik heb een aantal dingen verandert.

1. ipv de normale tarball heb ik de cvs versie gedownload.

cvs -d:pserver:[e-mail]:/cvsroot/linux-igd login
[geen wachtwoord]
cvs -z3 -d:pserver:[e-mail]:/cvsroot/linux-igd co linux-igd

2. de default policy van de firewall op accept gezet.

echo " Clearing any existing rules and setting default policy to ACCEPT.."
$IPTABLES -P INPUT ACCEPT (< dit was DROP)
$IPTABLES -F INPUT
$IPTABLES -P OUTPUT ACCEPT (< dit was DROP)
$IPTABLES -F OUTPUT
$IPTABLES -P FORWARD ACCEPT (< dit was DROP)
$IPTABLES -F FORWARD
$IPTABLES -F -t nat

3. Deze 2 regels in m'n firewall script erbij gezet:

$IPTABLES -I OUTPUT -s EXTIP -d 239.255.255.250/32 -j ACCEPT
$IPTABLES -I OUTPUT -s INTIP -d 239.255.255.250/32 -j ACCEPT

4. de "al het overige afvangen en weg kieperen" regel uitgezet (bij input, output en forward)

# Catch all rule, all other incoming is denied and logged.
#
#$IPTABLES -A INPUT -s $UNIVERSE -d $UNIVERSE -j drop-and-log-it


files gaan nu allemaal goed, webcam nog niet getest.. in hoeverre m'n firewall nu nog dichtgetimmert kan worden zal ik nog wel even uitzoeken...

[aanvulling]
ohja, het is wel slim om eerst je default policy op accept te zetten, dan even het firewall script runnen en daarna je iptables een keer helemaal leeg te maken met iptables -F.
Daarna zet je de rest van de regels goed en run je het script nogeens.

met iptables -t nat -L kan je heel goed zien of upnpd forwards maakt. Je kan dat mooi testen met windows messenger (dat wat standaard bij xp zit); deze maakt namelijk gelijk bij het aanzetten al forwards aan itt msn messenger 5 welke dat pas doet als je daadwerkelijk files gaat verzenden.
[/aanvulling]

[ Voor 50% gewijzigd door Vorlon op 21-01-2003 17:17 . Reden: wat uitgebreider uitgelegd ]

[Verwijderd]

Bedankt voor de uitleg Vorlon, maar ik ben nog maar eens gaan graven, en wat blijkt, het ligt aan m'n Windows machine.

Vanmiddag heb ik eens upnpd gestart terwijl ik op m'n vaders computer aan het werk was. En voila, het werkte meteen. Voice communicatie was geen problemen, en zelfs Whiteboard werkte. Maar nu is nog de vraag waarom mijn eigen Windows machine (zelfde Windows versie etc.) het niet doet. Iemand ideeën hier over?

Overigens vind ik het ietswat te link om de default policy maar gewoon op ACCEPT te zetten. Dat was ook helemaal niet nodig zo bleek, want mijn default policy stond gewoon op DROP toen ik vanmiddag bezig was.

[Vorlon]

Ik was zo vrolijk...

Stom ding... ik kan alleen files sturen en ontvangen.. cam doet het nog steeds niet..

Ik zal het hier ook nog eens proberen op een andere machine. Ga gelijk even m'n testpc van xp voorzien. Zonder patches en sp1..

[ Voor 38% gewijzigd door Vorlon op 21-01-2003 20:36 ]

[BSeB]

not-known schreef op 26 december 2002 @ 01:44:
[...]


HO!, voor filesend heb je geen upnp meer nodig

voor alle andere meuk wel, maar aangezien je upnp liever niet wil draaien, iig IK niet moeten we nog ff wachten tot MS bereid is ook die meuk in het protocol te veranderen.
volgens mij is dat toch geen onoverkomelijk groot probleem, maar ja dr zal vast een andere reden achter zitten......

Waarom wil je deze service juist niet draaien!!!???

Sorry niet helemaal alle berichten gelezen

[ Voor 5% gewijzigd door BSeB op 21-01-2003 20:39 ]

[Vorlon]

Heeft iemand nog een idee?

Volgens mij zit ik nog steeds met m'n firewall te klooien. Ik draai op m'n servertje overgens SuSE 8.0. Zit daar misschien iets in waardoor het niet werkt?

[Vorlon]

Ff iets tussendoor: Zijn er meer die last hebben van memory leaks icm. upnpd? Na een week vreet het ding bij mij zo rond de 600MB aan geheugen. (toen was het geheugen+swap vol....)

De msn webcam problemen zitten in m'n winxp doos volgens mij. Ben er alleen nog niet achter wat exact het probleem is. Of een security instelling of een bokkende patch ofzo..

[duronbug]

Ik krijg hier die Upnp SDK niet gecompileerd

In file included from gena_client.c:38:
../inc/gena/gena.h:50: uuid/uuid.h: No such file or directory
make[2]: *** [gena_client.o] Error 1
make[2]: Leaving directory `/usr/local/upnpsdk-1.0.4/src/gena'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/usr/local/upnpsdk-1.0.4/src'
make: *** [upnp] Error 2

Ik heb het precies zo gedaan zoals op de eerste pagina staat.