So, UPnP is independent from the messenger problem. The messenger problem is the classic H.323 problem recast in SIP and .Net isms. Conntracker modules need to be written to support SIP and it should work (a RTP conntracker already exists right?)
Another solution to the problem is to implement the UPnP spec. This would remove the need to contrack SIP because messenger does it for you (essentially) by using the UPnP answer in its stream setup messages. When I looked at SIP/SDP last year, it was a pretty simple protocol (especially when compared to H.323, SIP is plain text not ASN.1 :) perhaps thats a good option. Especially considering that SIP is becoming a dominant VoIP protocol, and not all SIP clients will implement UPnP. > -----Original Message----- > From: Glover George [mailto:[EMAIL PROTECTED]] > Sent: Friday, April 05, 2002 4:22 AM > To: 'Jeffrey Damick' > Cc: [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: RE: [UPnP-SDK-discuss] UPNP Server/Application Gateway for > Linux > > > (P.S. - I'm putting this at the top because everyone may not want to > read this but I'd like a quick answer on this point : > I know how to use tcpdump to see packets, but what do I use > to view the > data in the packets? What's a tool that lets you specify something > about the packets that you want to view the data of and them > maybe write > them to stdout or a file? TIA) > > Ok, now the real message: > > And I as well think UPnP would be a great way to tackle the > problem, but > writing a UPnP server is more of task than simply modifying and > connection tracking the connections with netfilter. I see > them being 2 > equally solvable points though. From the netfilter point of > view, lets > take a look at this. > > I've actually sat there and watched this try to work on my XP box > before. Look here for where I got this from: > http://www.microsoft.com/technet/treeview/default.asp?url=/Tec > hNet/prodt > echnol/winxppro/evaluate/insid01.asp > > When a user on computer A presses his "Start Video" button a > request is > sent first to Microsoft's .NET servers, and then to user B's messenger > client. User B's messenger asks him to accept or deny, and > if accepted, > user B's messenger sends an accpetance message back to the .NET server > where it is relayed to User A's messenger client. Up to this, > everything works fine with the nat boxes as they are now. > Everything is > TCP up to this point and there's no problem with natting. If you open > your Windows Messenger you will see it send your request to the other > user, the other user gets it and in your own client you see Messenger > tell you that the other user accepted the call. > > Now at this point, messenger A is ready to begin telling User > B how the > call is going to be set up. If any of you have notice, Messenger > constanly hits your default gateway on port 1900 looking for a UPnP > server. Of course it doesn't find one, so Messenger is > /supposed/ to be > looking at it's own NIC interface to figure out the source ip > to pass to > user B. Messnger gets it's ip (either UPnP or locally) and > also grabs a > random port to use locally to listen and passes these through the .NET > server to user B. After this , I believe the .NET server is no longer > involved, except possibly on the destroying of the call. Messenger on > user A then begins listening on that ip and port that it passed for a > SIP INVITE from B. When B recieves this, it sends off a SIP INVITE to > B, and includes it's own ip and ports which it expects to receive the > RTP stream (data) from A on. B then starts listening on this address > and ports for the RTP traffic here. > > A then acknowledges the session ivite to B, and passes it's dynamic > ports for RTP data via SDP (session description Protocol). A final > acknowledgement is sent from B to A and the session is now in place. > > So from the netfilter point of view. When Messenger grabs its local > interface ip address (which doesn't matter if it's dhcp or > not, because > it's been assinged) and it's ports, netfilter needs to see this and > remember the ports that windows messenger on A is planning to > listen to > so that it can open these ports. Also, netfilter needs to modify this > source ip address in this packet (which could be 192.168.xxx.xxx) and > give it it's external ip. > > So if I'm thinking right, now that side A has sent of it's connection > information, and netfilter has opened the ports that A is wanting to > listen on, the only problem now is knowing which ip address that comes > in is the session info destined for A so that netfilter can pass it > through to the internal A machine. This is probably what you guys at > netfilter have the most experience in and maybe someone could > throw me a > bone here. I'm not sure if the .NET server ever passes any of this > information during the call initiation and acceptance to > machine A about > B. Otherwise, A's firewall is just going to have to accept > whatever is > destined for these ports regardless of who it's from (which probably > isn't too secure!!). > > Shouldn't this work? > > Now from the writing a UPnP server point of view. Like you say, it > would require hooking specific programs like the dhcp server (which I > would just shoot for isc's version if there's no arguments > there). Like > you, I haven't gotten too far into the UPnP stuff, but it should be > possible for the UPnP server to be modularized, and it would just > require writing hacks for whichever dhcp server or firewalling code > you'd like to use. I'm not sure exactly why you'd want to > hook into the > dhcp server on the firewall (other than its part of the spec) > because if > the windows machine got the ip from the dhcp server, then its going to > use it anyway. What exactly do we need the dhcp server for again? (I > need to reread some of the UPnP stuff). But regardless of the UPnP > server or not, netfilter (ipchains whatever) needs to read > these packets > or be told by the UPnP server about the ports to open and the ip's to > allow/accept for those ports. > > So my thinking is we get something going in the netfilter arena first, > because it doesn't look to bad. Maybe I'm mistaken, but I > think this is > much easier fix in the near term. With the experience gained > here, and > the experience from the UPnP people, we could start on a UPnP > implementation for linux. Of course we need to get with > netfilter, ISC > (Bind), etc and talk to them about UPnP, their feelings on it, and how > best we might implement this with their products. > > I'm waiting on comments. Thank you. > > > > > -----Original Message----- > > From: Jeffrey Damick [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, April 04, 2002 9:27 AM > > To: [EMAIL PROTECTED] > > Subject: Re: [UPnP-SDK-discuss] UPNP Server/Application > > Gateway for Linux > > > > > > Hi, > > > > I believe UPnP would be the preferred way to tackle this > > problem. There > > is an IGD (internet gateway device) spec. that would make > > this possible, > > the only problem is the number of components that UPnP > would have to > > touch in order to meet the spec. I guess one question is > which dhcp > > server, fw/nat interface iptables, ipchains, do we support, > > since we'd > > have to have some kind of hooks into all of them.. don't get > > me wrong > > it's very possible to do, and i've actually been researching this > > lately, but i dont have anything solid and ready to go right now.. > > > > > > > > -jeff > > > > > > > > [EMAIL PROTECTED] wrote: > > > > >Hello, > > > > > > It recently hit me that with all the h.323 work being > > done with the > > >netfilter team to pass NetMeeting traffic, there hasn't been > > a general > > >discussion on getting Microsoft Windows Messenger to work > with linux > > >firewall/NAT boxes. So I've just spent the better part of a day > > >looking for answers on how to make this work. It has come to my > > >understanding that the only way to do this is to either modify the > > >session initiation protocol (SIP), the real time transport > protocol > > >(RTP), and the remote desktop protocol's(RDP - same as > > windows terminal > > >services) internal data structures. Sorry if that's > confusing, but > > >what I mean is the Windows Messenger client looks either > via UPNP to > > >discover a NATing devices external (public) address that > the client > > >will be mapped to and encapsulates this address in the > SIP, RTP, and > > >RDP protocols respectively, or it simply looks at the ip addresses > > >assigned to the local NIC card. Herein lies the problem > of private > > >network addresses (or any NAT'ed addresses) being sent to > > the receiver > > >and therefore the receiver has no way to communicate back with the > > >client. > > > > > >Now I am very new to this, and just now getting my feet wet > > so I wanted > > >to ask everyone's opinion on what the preferable solution > for linux > > >would be. Also I may be wrong, after all my information on Windows > > >Messenger did come from the Microsoft site ;-) I don't see a UPNP > > >Server/Application Gateway on the net anwyhwere to use to > implement > > >UPNP on a linux machine. Am I missing something? IS there > > in fact a > > >solution out there? If not, is anyone working on one? I > > would be more > > >than happy to help, and if not, more than happy to start a project > > >implementing this. > > > > > >The questions is, is there a substantial need for UPNP on > > linux? I can > > >only think off the top of my head of a few, but I'm sure > it would be > > >very useful. Otherwise the only way I see in solving our > immediate > > >problems, is a netfilter module to modify these protocol > packets (if > > >indeed this is all it requires). > > > > > >Which leads me to my main question for the netfilter team: > > Has there > > >been any work, or is anyone working on trying to implement > > something to > > >make Windows Messenger video, audio, etc work? If so, > please let me > > >know their contact info. > > > > > >Thank you for taking the time to listen, and I would like to > > offer my > > >thanks in advance to any suggestions or comments. > > > > > >Glover George > > >Systems/Networks Admin > > >Gulf Sales & Supply, Inc. > > >(228) 762-0268 > > >[EMAIL PROTECTED] > > >http://www.gulfsales.com > > > > > > > > > > > >_______________________________________________ > > >UPnP-SDK-discuss mailing list > [EMAIL PROTECTED] > > >https://lists.sourceforge.net/lists/listinfo/upnp-sdk-discuss > > > > > > > > >
