On Fri, Sep 5, 2008 at 11:16 AM, Daniel Pittman <[EMAIL PROTECTED]> wrote:
> "Chris Zhang" <[EMAIL PROTECTED]> writes: Hi Daniel, You were correct in guessing what I was after. I am trying to get VOIP working over 3G. My understanding is that there are at least two places this can be prevented. Firstly, the app(e.g. Truphone) won't let you connect unless you have a working WIFI connection. This is why I was asking for NATting possibility(I didn't describe it properly). - Assign wifi interface with an IP ( 192.168.1.1/24) and forward all traffic to 3G interface with a public IP. Since 'ipfw' won't work the way it does in a normal BSD, the only thing I thought would be changing the routing table, which you pointed out not possible. The other place where VOIP might get blocked is from the ISP, e.g. filtering on 3G network. My thought was to setup a tunnel and encrypt VOIP inside that tunnel. It should in theory bypass ISP restriction shouldn't it? Alternatively, I am not sure if VOIP works over a socks proxy. This requires iPhone being a socks client, which it doesn't support, nor have I found any thrid party apps that can do this. Last resort would prob. be ssh tunnelling. but I doubt this would work since the ports VOIP uses are in 10,000 ~ 20,000 range? apart from port 5062. I have to do some more research on this. Please also see inline reply. Thanks, Chris > As Alex asked, your problem description is unclear. Since I have some > different questions to what he asked, and you answered, I include them: > > > Suppose I have two NICs on one host, NIC A and NIC B. Is it possible > > to get all traffic to use A, > > When you say "to use A", what specifically do you mean: > > * to use the IP address that you assigned to NIC A[1] > * to leave the computer and hit the wire out NIC A > * something else? > > > and then route them through B, > > My best guess here is that you expect the packet to: > > 1. Exit to the wire via NIC A > 2. Return to the host via NIC B > 3. Exit to the outside world via some unmentioned, third, interface > > Is that correct? This is the idea, except for the packets won't go out to wire. Traffic => NIC A's IP => NIC B's IP => NIC B's gateway. This is, as you pointed out, NATing, I am convinced it is not possible without iptables or such. > > > > and finally to outside? without the aid of iptables or anything > > similar, e.g. just changing the routing table? Suppose ip forwarding > > works. > > Why the restriction? > > Is this, specifically, because you want to achieve some VoIP and > tunnelling related goal with the iPhone, and it only provides a standard > routing stack? > > I ask, because the Linux IP stack is extremely flexible and can do a > wide range of things that a more traditional BSD stack, well, can't. > > > Anyway, assuming that my best guess is, in fact, correct -- which > I think it probably is from the iPhone bit below -- then, no. > > What you are asking is impossible without the addition of NAT, packet > marking, or some other method to identify the packet beyond what you get > in the standard facility. > > The routing table doesn't include a lot of "if" for an individual > packet, and retains no state -- you can't say "if this is the second > time I have seen ..." > > > > Just out of curiosity, does anyone know how iPhone restricts VOIP > > traffic over 3G technically? > > It is done for profit, and by the request of customers. (The real > customers, the telecoms companies, not you and the other end users who > hold the physical device...) > > > Suppose one can make a tunnel, e.g. IPSec, PPTP (which iPhone has > > native support), to a VPN endpoint, e.g. home computer through > > 3G. Is it possible to then run a VOIP app inside the tunnel? > > Not if Apple and their customers have any say in the matter, no. Not > reliably, in the long term, because it some something other than what > Apple have approved of your doing with their iPhone.[2] > > Regards, > Daniel > > Footnotes: > [1] ...which, under Linux, is actually a property of the computer, not > the network card, and is equally valid as an outbound address for > any interface, technically speaking. > > [2] Since you don't actually have any particular control of the device > I wouldn't really call you the owner of it. You may have paid for > it, but Apple still run the show... > > -- > SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ > Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html > -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
