On Wed, 8 Jun 2016 10:35:11 +0100 Stuart Henderson <[email protected]> wrote:
> On 2016/06/08 09:54, Gerhard Roth wrote:
> > On Tue, 7 Jun 2016 16:31:21 +0100 Stuart Henderson <[email protected]>
> > wrote:
> > > On 2016/06/07 14:39, Gerhard Roth wrote:
> > > > > > Now I get an IP address from my provider, I want something like
> > > > > > this:
> > > > > >
> > > > > > inet 10.75.178.41 --> 10.75.178.42 netmask 0xfffffffc
> > > > > >
> > > > > > But if I used SIOCAIFADDR I would get this instead:
> > > > > >
> > > > > > inet 0.0.0.1 --> 0.0.0.2 netmask 0xff000000
> > > > > > inet 10.75.178.41 --> 10.75.178.42 netmask 0xfffffffc
> > > > > >
> > > > > > And deleting the old one first seems more racy.
> > > > >
> > > > > Why?
> > > >
> > > > Because either there is a time without any IP address or there
> > > > is one with two addresses. Neither seems right.
> > >
> > > Is there a problem to have no address? That is what happens with
> > > gif(4), tun(4) etc, even with ethernet interfaces, when they don't
> > > have a particular address configured on them.
> > >
> > > There doesn't seem a particular problem with dhclient removing
> > > the old address before it adds a new one..
> > >
> > > > See above. That's the current OpenBSD model for PPP.
> > >
> > > There are several models :-)
> > >
> > > The 0.0.0.1 thing is a specific hack for sppp/pppoe which has
> > > "magic" values of 0.0.0.0 and 0.0.0.1 and a way to request a
> > > specific hardcoded address. This is because *both* sides
> > > propose addresses via IPCP (they are "equal" peers as far
> > > as configuration is concerned), they have to agree and can
> > > NAK each other.
> > >
> > > It's not the only way though, even for PPP; ppp(4) doesn't use
> > > this mechanism, it has separate configuration for pppd instead.
> > > When we had ppp(8), that didn't, either.
> > >
> > > As far as I understand MBIM addressing is driven from the "mobile
> > > network" side, we just set the address they are telling us to use
> > > without a way to propose our own address. If that's correct then
> > > we don't need a way to set "our side's" address at all, or have
> > > a way to tie down the remote side's address, so address
> > > configuration can be a lot simpler than any PPP interface.
> >
> > I not sure if it is possible to send packets from an interface
> > that has no addresses assigned to it.
>
> Ah, I don't mean "no addresses assigned at all", I'm talking about
> "deleting the old one first seems more racy" that you mentioned
> in your mail.
Sorry, my mistake.
>
> I just mean it's ok to have no address temporarily - before you
> connect to the network and have an assigned address, or when you're
> regaining link or moving between networks and you remove the address
> so you can add a new one.
>
> Based on other interface types, how things work in non-OpenBSD routers,
> etc, I'd expect it to work something like this:
>
> interface attached ->
> - no address
>
> ifconfig up (IFF_UP) ->
> - still no address (unless the user has manually set one)
> - attempt connection
>
> connection succeeds or regain link ->
> - either: if no existing address, add it.
> - or: if address matches one already configured, keep it.
> - or: if address has changed, delete old address and add new.
> - set IFF_RUNNING
>
> lose link ->
> - clear IFF_RUNNING (so no more packets will be sent over
> interface) but keep address.
>
> ifconfig down (IFF_DOWN) ->
> - clear IFF_RUNNING and IFF_DOWN, keep address.
Currently I do this to get the interface up and running as my default
route:
# ifconfig umb0 pin xxxx apn xxxx
# ifconfig umb0 inet 0.0.0.1 0.0.0.2
# route delete default
# route add -ifp umb0 default 0.0.0.2
# ifconfig umb0 up
Yes it seem strange that the 'route add -ifp ubm0' needs an IP address,
but that's the way it is. That's why I need the fake IP address on
the interface right from the beginning. Otherwise the 'route add'
would fail.
>
>
> pppoe(4) is more complex because it has IFF_LINK1 aka IFF_AUTO
> "dial-on-demand" behaviour which probably nobody uses, plus pppoe
> is doing some things wrongly because I have observed cases where
> it automatically moves between !IFF_UP and IFF_UP, this is
> "administrative status" and meant to only be configured by the
> admin, and also it sets IFF_RUNNING ("operational status") when
> the link is not connected.
>
> > > > > But when you lose the connection with the network or you manually set
> > > > > the interface down, this IP address once given to you by the provider
> > > > > is no longer yours and must not be used anymore.
> > >
> > > The same can apply in other cases (wifi, wired ethernet etc) too,
> > > but we don't do anything to remove it from those interfaces (though
> > > it's easy enough to remove using ifstated if needed).
> >
> > For WiFi and Ethernet it is dhclient that will remove the old
> > addresses.
>
> Yes, not when link is lost though, only once it has a new lease -
> it maintains the old address until that point (with IFF_RUNNING
> cleared, so you aren't sourcing traffic from it).
>
> btw, I'm trying to get some hardware together to work on this,
> I found a cheap enough card on ebay that looks like it should
> work, now I just need to find pigtails and antennas that don't
> cost more than the card (and hope I can find somewhere at home
> with enough signal to test as I can't get that SIM registered
> to my femtocell..)
