UBLOX_EVK_ODIN_W2 bridge implementation

[AmmadRehmatCUS]

Description

• Bridge functionality added

• To enable the bridge add the below macro and increase the lwIP pbuf pool size in mbed_app.json, for example:
  "macros": ["MBED_EMAC_LWIP_L2_BRIDGE=1"],
  "lwip-pbuf-pool-size":
  { "help": "Number of pbuf pool buffers", "value": "80" }

• Tests performed
  mbed_os_tests_arm.txt
  mbed_os_tests_gcc.txt
  mbed_os_tests_iar.txt

Pull request type

[ ] Fix
[ ] Refactor
[ ] Target update
[x] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

Reviewers

[ciarmcom]

@AmmadRehmat, thank you for your changes.
@ARMmbed/mbed-os-ipcore @ARMmbed/mbed-os-maintainers please review.

[0xc0170]

@AmmadRehmat Please review travis astyle job failures

[AmmadRehmatCUS]

@AmmadRehmat Please review travis astyle job failures

travis astyle job failures fixed

[0xc0170]

this should be aligned the same as the line 1608 and above

[0xc0170]

These should have doxygen?

[AmmadRehmatCUS]

@0xc0170 Modified according to review comments

[0xc0170]

@ARMmbed/mbed-os-ipcore Please review

[SeppoTakalo]

@AmmadRehmat

I cannot justify the LwIP specific API changes.

Why cannot this be implemented in EMAC layer without touching any existing public APIs?

I think you could, at least in theory, create a device that takes in EMAC interface, and is EMAC interface itself.

Using this kind of approach does not force you to pull in the LwIP stack. You could use it, but you are not required to. Also, would not require any API changes.

[AmmadRehmatCUS]

@SeppoTakalo
Do you want us to revise the design? or is it possible to merge it as it is? We have designed it this way so that there is standard API instead of local one for ublox only. That way other users can also use it and ublox wont need to rework the bridge when a new API is introduced.

You could use it, but you are not required to

[SeppoTakalo]

Yes, I would prefer the design to be revised.

I do like the fact that you did it without touching the driver API, but I don't like that it touches the LwIPInterface making this work only on LwIP.

I strongly feel that this could have been done in separate class that sits between EMAC driver and the network stack. That would make it work for both stacks that we have (LwIP and Nanostack).

[AmmadRehmatCUS]

@SeppoTakalo the latest version of lwip has a bridge interface available, is there any plan to move lwip to latest version?

[SeppoTakalo]

@AmmadRehmat We have plan to update LwIP to latest version very soon.

However, there are some refactorings ongoing, so I cannot promise that it will come in 5.12 timeframe but that is our target.

Still the proposal is the same, I prefer that this work is going to be done without the IP stack and in the EMAC interface. It would allow bridge devices even without IP stack at all, or it would allow bridge devices with Nanostack as well.

[0xc0170]

Based on the latest comments, this PR should be closed and a solution further discussed here (even PR is closed) ? This feels like a good candidate for new design document https://github.com/ARMmbed/mbed-os/tree/master/docs/design-documents

[screamerbg]

@0xc0170 I'll hold on a bit while there are product level discussions on this.

[cmonr]

@screamerbg Any updates/outcomes from those discussions?

[0xc0170]

Removed 5.12 release label for now. If not, and this will is targeting 5.12, let us know

[AmmadRehmatCUS]

@0xc0170 @screamerbg We are waiting for new version of lwIP to be introduced in 5.12 and will be using that bridge in our release. Meanwhile lets keep this PR open until the latest lwIP version is integrated

[cmonr]

@AmmadRehmat Checking, do you know when the PR to update LWIP will be opened?

[AmmadRehmatCUS]

@cmonr according to above discussion with ARM team , it looks like its going to be in release 5.12

[cmonr]

@AmmadRehmat Has there been any progress on either this PR or the LWIP dependency?

[AmmadRehmatCUS]

@cmonr we are in touch with Pasi Pikkarainen , he is yet to provide a date for lwip release

[cmonr]

@AmmadRehmat Any update?

[AmmadRehmatCUS]

@cmonr we dont have any commitment for date for latest lwip version from ARM team

[0xc0170]

@cmonr we dont have any commitment for date for latest lwip version from ARM team

lwip 2.1.2 here #10353, is this the one needed?

[0xc0170]

@AmmadRehmat @SeppoTakalo As this is not progressing, can we take this offline if still needed?

[AmmadRehmatCUS]

@0xc0170 let me have a look at the lwip version, is the 5.13 mbed-os out? it contains this PR you refered?

[0xc0170]

It's not - it's only on master so use that one as your base. We are going to release 5.12.2 the next week (few more patch releases until we get to 5.13).

[AmmadRehmatCUS]

@SeppoTakalo this looks quite similar to what we were trying to do.

https://github.com/ARMmbed/mbed-os/blob/master/docs/design-documents/features/connectivity/Multihoming%20-%20Design%20document.md

Correct me if i am wrong. It looks like bridging is already supported

[0xc0170]

@AmmadRehmat 5.13 is out. Shall this be closed and reopen with an update ?

@SeppoTakalo will be back in a week.

[SeppoTakalo]

@AmmadRehmat, no I don't think the bridging is implemented.
We did multihoming work for LwIP to ensure that two interfaces can be up at the same time. Also made some tricks to allow DNS queries to go out on specific interfaces, etc. But all done in IP level.
Bridging is one level below.
Can be implemented in EMAC driver level as I originally suggested.

[0xc0170]

Can be implemented in EMAC driver level as I originally suggested.

@AmmadRehmat Would the issue suit better here or rather a new PR with suggestions implemented? It looks like this PR won't progress for a while.

[0xc0170]

I am closing this PR @AmmadRehmat . Let's create an issue for further discussion or keep it here.

[AmmadRehmatCUS]

@0xc0170 sorry for not replying earlier. Yes its OK to close it.