- By end of Jan 2014 SuperTweet.net was shut down (http://supertweetnews.140plus.com/). So Breadbox64 has come to an end for sure :-(
- The email app - or rather email sending app as it is SMTP only - can't be used anymore since nowadays everybody uses some "strong" authentication for SMTP session logon (thanks NSA).
- The ftp client app isn't very useful as it supports only download - for which the WGET app is almost always more useful for. But more important it doesn't support PASV which is more or less the only supported mode nowadays (especially over NAT).
Both apps/dhcp/dhcp.c:dhcpc_configured() and cpu/6502/ipconfig/ipconfig.c:dhcpc_configured() presume the first parameter of uip_nameserver_update() to be const. As there's no reason for it to be not const just make it const.
Forms with multiple submit buttons are rather rare but nevertheless the most popular web page (www.google.com) contains one with the two submit buttons "Google Search" and "I'm Feeling Lucky". So we want to support that - incl. the usual feature to the interpret first button as default button used when the user presses the ENTER key.
Script code may contain a '<' as part of a equation. We erroneously interpreted that as start of a tag. Now we check for the very next char to be a '/' as the only tag allowed is the </SCRIPT> tag.
When using the 'down' button on a certain number of lines curently displayed at the bottom of the screen is redisplayed at the top of the screen. Given our usually small screen size and often large pages requiring many 'down' operations the number 'four' seems too generous so lets reduce it to 'two'.
- The wraparound handling when using the history with the 'back' button is actually depending on history_last being unsigned (which is the default for cc65) so define it explicitly as unsigned to make it work on other targets too.
- As there's no 'forward' button it doesn't make sense to keep history entries after using them with the 'back' button. Clearing them on use on the other hand avoids an "infinite history".
Although we for sure don't support HTTPS we need to recognize it. Nowadays it has become pretty usual to redirect HTTP URLs to HTTPS URLs in order to force privacy (thanks, NSA !). So far our redirection handler didn't recognize an HTTPS URL as abslute URLs and therefore appended it to the curent URL. This led to an endless redirection loop. Now we recognize the HTTPS redirection and generate a minimal document on the fly to inform the user of (for us unrachable) the redirection target.
HTML links with HTTPS URLs are treated just like fragment-only links meaning that they get simply completely ignored.
This patch restores the original behaviour of Cooja when
the transmitted packet is correct (which is true in a vast majority
of cases).
In case of a wrong outgoing packet (wrong length, wrong preamble)
the transmission will end when the radio changes its state (which
should always happen after transmitting a packet).
Benchmarks with RPL (33 runs, 50 nodes, 3 hours of simulated time each)
yield the same results (PDR, delay, number of transmitted packets)
as with the unmodified Cooja.
The code to trim spaces from the end of the URL behaved undefined if the URL was empty. That scenario is far from hypothetic as i.e. pressing the 'back' button with no (more) entry in the history yields an empty URL.
The way our HTML parser triggers newlines is a guess at best. On the other hand our screen estate is severely limited. Instead of trying to (further) improve the way we translate tags to newlines it seems more reasonable to simply never render more than two successive empty lines.
Several keys can be kept at the same time in the key store, and several
keys can be loaded at once. Give access to these features.
The ccm-test example is also improved to better demonstrate the use of
the key store.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
Using the AES interrupt allows the user process not to waste time
polling for the completion of the operation. This time can be used by
the user process to do something else, or to let the system enter PM0.
Since the system is now free to perform various operations during a
crypto operation, a protection of the crypto resource is added, and PM1+
is prohibited in order not to stall crypto operations.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
The commit bddd96d5c8 "Removed all module
makefiles. Instead, all .c files in a module directory are compiled."
made the MODULESSUBST variable useless, but it did not remove it, so do
it now.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
The CC2538 the WDT cannot be stopped once it has been started.
The CC2530/1 WDT can be stopped if it is running in timer mode,
but it cannot be stopped once it has been started in watchdog mode.
Both platforms currently provide "dummy" implementations of `watchdog_stop()`,
one does nothing and the other one basically re-maps `_stop()` to
`_periodic()`.
This was originally done in order to provide implementations for all prototypes
declared in `core/dev/watchdog.h`. In hindsight and as per the discussion
in #1088, this is bad practice since, if the build succeeds, the caller will
expect that the WDT has in fact been stopped, when in reality it has not.
Since the feature (stopping the WDT) is unsupported by the hardware, this pull
removes those dummy implementations. Thus, we will now be able to reliably
detect - at build time - attempts at using this unsupported feature.
The packet converter used to generate packets of length zero
when it encountered errors during conversion. This caused
exceptions in packet analyzers.
Now the converter returns null in case of error. Appropriate
checks have been added to the code that uses the return value.
* The current version of the README points to a wrong URL
for the LUFA Virtual Serial driver.
* A driver is nowadays provided by TI with CC2538
Foundation Firmware
Thus, this pull updates the LUFA driver URL and also provides a
link to CC2538 Foundation Firmware
We don't handle URLs with fragments exactly ;-) well - meaning we send the fragment part to the server and we don't display the document starting at the anchor tag. Instead of adding the missing capabilities and thus adding lots of code I instead opted to simply ignore fragment-only links. This approach is based on the practical knowledge that fragments are primarily used for intra-document navigation - and are as such fragment-only links. And as we ignore them anyway when displaying the document it's more ergonomic to not have those links in the first place.
Complex script code tends to contain other tags inside strings. As we generally don't parse strings we erroneously interpreted those tags. The easiest workaround is to not interpret tags at all until the </SCRIPT> tag is found.
